| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By having the default value equal to zero, we follow the principle of
least surprise. For example, if we had
url.path()
and we refactored to
url.path(QUrl::DecodeSpaces)
Then instead of ensuring spaces are decoded, we make spaces the only
thing encoded (unicode, delimiters and reserved characters are
encoded).
Besides, modifying the default can only be used to encode something
that wasn't encoded previously, so having the enums as Encode makes
more sense.
As a side-effect, toEncoded() does not support any extra encoding
options.
Change-Id: I2624ec446e65c2d979e9ca2f81bd3db22b00bb13
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
|
|
|
|
|
|
|
|
| |
DecodeReserved applies to all characters between 0x21 and 0x7E that
aren't unreserved, a delimiter, or the percent sign itself.
Change-Id: Ie64bddb6b814dfa3bb8380e3aa24de1bb3645a65
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's little value in having the DecodeUnambiguousDelimiters option
since neither QUrl nor QUrlQuery can return values that are ambiguous
in that particular context, ever.
This option could be used to encode a character if, when placed
in a URL, it would need to be encoded. Such cases are hash (#) or
question marks (?) in the path component, or slashes (/) and at signs
(@) in the userinfo.
However, we don't need two enums for that, since there are no
other characters that can appear in either form. Still, leave two bits
for this enum. In the future, if we want to split the gen-delims from
the sub-delims, we are able to.
Change-Id: If5416b524680eb67dd4abbe7d072ca0ef7218506
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change it to operate on QChar pointers, which gains a little in
performance. This also avoids unnecessary detaching in the QString
source.
In addition, make the output be appended to an existing QString. This
will be useful later when we're reconstructing a URL from its
components.
Change-Id: I7e2f64028277637bd329af5f98001ace253a50c7
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reason for this change is that the strict parser made little sense
to exist. What would the recoder do if it was passed an invalid
string?
I believe that the tolerant recoder is more efficient than the
correcting code followed by the strict recoder. This makes the recoder
more complex and probably a little less efficient, but it's better in
the common case (tolerant that doesn't need fixes) and in the worst
case (needs fixes).
Change-Id: I68a0c9fda6765de05914cbd6ba7d3cea560a7cd6
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
|
This one function is an all-in-one:
- UTF-8 encoder
- UTF-8 decoder
- percent encoder
- percent decoder
The next step is add the ability to modify the behaviour, by telling
the function what else it must encode or decode and what it should
leave untouched.
Change-Id: I997eccfd2f9ad8487305670b18d6c806f4cf6717
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|