summaryrefslogtreecommitdiffstats
path: root/src/corelib/io/qurlrecode.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Change copyrights from Nokia to DigiaIikka Eklund2012-09-221-23/+23
| | | | | | | | Change copyrights and license headers from Nokia to Digia Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e Reviewed-by: Lars Knoll <lars.knoll@digia.com> Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
* Fix decoding of QByteArray in the deprecated "encoded" setters in QUrlThiago Macieira2012-08-201-0/+50
| | | | | | | | | | | | | | The asymmetry is intentional: the getters can use toLatin1() because the called functions, with a QUrl::FullyEncoded parameter, return ASCII only. This gives a small performance improvement over the need to run the UTF-8 encoder. However, the data passed to setters could contain non-ASCII binary data, in addition to the percent-encoded data. We can't use fromUtf8 because it's binary and we can't use toPercentEncoded because it already encoded. Change-Id: I5ecdb49be5af51ac86fd9764eb3a6aa96385f512 Reviewed-by: David Faure <faure@kde.org>
* Add the QUrl::FullyDecoded flag to the component formattingThiago Macieira2012-05-221-0/+47
| | | | | | | | | | | | | | | | | | This allows the QUrl component getters to return fully decoded data, like they did in Qt 4. This is necessary for some use-cases where the component like the user name, password or path are used outside the context of a URL. In those contexts, the percent-encoded data makes no sense, and the loss of data of what could be represented in a URL is acceptable. Also take the opportunity to expand the documentation of those getter methods, explaining what the options argument does. Discussed-on: http://lists.qt-project.org/pipermail/development/2012-May/003811.html Change-Id: I89f743cde78c02f169c88314bff0768714341419 Reviewed-by: Lars Knoll <lars.knoll@nokia.com> Reviewed-by: David Faure <faure@kde.org> Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
* QChar: add isSurrogate() and isNonCharacter() to the public APIKonstantin Ritt2012-05-161-14/+1
| | | | | | | | + QChar::LastValidCodePoint enum value that supercede the UNICODE_LAST_CODEPOINT macro replace uses of hardcoded values with the new API; remove leftovers Change-Id: I1395c9840b85fcb6b08e241b131794a98773c952 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix compiler warningOlivier Goffart2012-05-041-3/+2
| | | | | | | | qurlrecode.cpp:481:24: warning: ‘action’ may be used uninitialized in this function [-Wmaybe-uninitialized] Change-Id: I638b65218d1875667e2c60a5720ecda87202b82f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Change the component formatting enum values so the default is zeroThiago Macieira2012-04-111-6/+33
| | | | | | | | | | | | | | | | | | | | | | 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>
* Introduce QUrl::DecodeReserved and reorder the enumsThiago Macieira2012-04-111-1/+122
| | | | | | | | 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>
* Merge QUrl::DecodeAllDelimiters and QUrl::DecodeUnambiguousDelimitersThiago Macieira2012-04-111-1/+1
| | | | | | | | | | | | | | | | | | | 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>
* Refactor the URL recoder a littleThiago Macieira2012-03-301-77/+80
| | | | | | | | | | | | | 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>
* Remove the tolerant parsing function and make the recoder tolerantThiago Macieira2012-03-301-106/+95
| | | | | | | | | | | | | | | 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>
* Add the code that recodes URLs.Thiago Macieira2012-03-301-0/+504
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>