![\"Authority](\"http:\/\/doc.qt.nokia.com\/4.7\/images\/qurl-authority.png\" "\\"Authority")
Authority chunks on an URL<\/p><\/div>\n
At the moment of writing this, QUrl documentation<\/a>, although quite complete, could be much more explanatory. For example, it says that the recommended way for creating a QUrl from a QString is:<\/p>\n But this is explained in the documentation for QUrl::fromUserInput(), instead of in the Detailed Description [ 1<\/a> ].<\/p>\n What is important from this explanation is that it is not a matter of favor the use of QUrl::from\/toEncoded() over QUrl::(from)toString() but, I would say, a must if you don’t want to end up with bogus corner cases.<\/p>\n Why would this happen? Well, as I was saying, QUrl is meant for much more than universally representing the location of a file so, here go the big tips<\/strong>:<\/p>\n Correct:<\/p>\n Incorrect:<\/p>\n The problem here is the way QUrl will treat the \u00ab#\u00bb character in the second example. It will think, as it actually doesn’t have a way of guessing, that the character is delimiting the fragment part of the URL.<\/p>\n Fragment part on an URL<\/p><\/div>\n As a result, calling to:<\/p>\n in the first case will result to:<\/p>\n while in the second will be:<\/p>\n (encoded) url representation:<\/p>\n Correct:<\/p>\n Incorrect:<\/p>\n The problem here is the way QUrl will treat the \u00ab%23\u00bb encoding in the second example. Although it is not explicitly explained in the documentation [ 2<\/a> ], QUrl will use QUrl::TolerantMode as ParsingMode by default. Therefore, it will think that the input comes from an ignorant user which was actually trying to pass \u00abfile:\/\/\/mypath\/my#file.jpg\u00bb. Again, it will understand after converting back \u00ab%23\u00bb to \u00ab#\u00bb, that the character is delimiting the fragment part of the URL.<\/p>\n As a result, calling to:<\/p>\n in the first case will result to:<\/p>\n while in the second will be:<\/p>\n (encoded) url representation:<\/p>\n (unencoded and wrong) url representation:<\/p>\n Correct:<\/p>\n Incorrect:<\/p>\n Here, we have another incarnation of the very same problem than the two examples above. QUrl will think, again, as it actually doesn’t have a way of guessing, that the character is delimiting the fragment part of the URL.<\/p>\n As a result, calling to:<\/p>\n in the first case will result to:<\/p>\n while in the second will be:<\/p>\n The default behavior of QUrl is to provide an easy handling of URLs to the user of our programs, the end user<\/strong>, but not the user of QUrl, the developers. I find this quite awkward but, still, it is a decision of Qt people and, as developers, we only have to take this into account when writing our code.<\/p>\n These bogus URLs, which are to be corrected with the usage of the QUrl::TolerantMode ParsingMode, usually come from a text entry box \u00ab\u00e0 l\u00e0\u00bb browser location bar, but this use case is, actually, not so common when talking from the developer’s point of view. When dealing with URLs in our code we have to take into account what an URL is and how it should be formatted\/encoded to be valid. Therefore, if I’m receiving a wrongly encoded URL I should go to the source code providing this URL and fix the problem there rather than trying to smartly guess which should be the proper URL. For example, in my software currently in development we use Tracker<\/a> and I rely on it to feed my code with properly formatted URLs. If for some reason Tracker gives me a wrongly encoded one, the place for solving it is, actually, Tracker, and not my software. I should not and must not interpret what Tracker may have wanted to pass me, but open a bug in its bugzilla and provide as accurate information as I can to help them solve this issue.<\/p>\n Just so my friend Iv\u00e1n Frade<\/a> doesn’t kill me, make notice that Tracker is, so far, perfectly dealing with URLs \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":" Lately, I’ve been developing some software which makes an intensive usage of QUrls as resource locators for local files. Nothing wrong here. QUrl is a powerful way of sharing the locations of those in an universal way. The problem is … Sigue leyendo
\n* When creating an URL QString from a QByteArray or a char*,
\nalways use QString::fromUtf8().
\n* Favor the use of QUrl::fromEncoded() and QUrl::toEncoded()
\ninstead of QUrl(string) and QUrl::toString() when converting
\nQUrl to\/from string.
\n<\/code><\/p>\n\n
Bogus examples for each case:<\/h3>\n
Local file<\/h4>\n
\/mypath\/my#file.jpg<\/code><\/p>\nQUrl myUrl = QUrl::fromLocalFile(\"\/mypath\/my#file.jpg\")<\/code><\/p>\nQUrl myUrl = QUrl(\"file:\/\/\/mypath\/my#file.jpg\")<\/code><\/p>\n![\"Fragment](\"http:\/\/doc.qt.nokia.com\/4.7\/images\/qurl-fragment.png\" "\\"Fragment")
myUrl.toLocalFile()<\/code><\/p>\n\/mypath\/my#file.jpg<\/code><\/p>\n\/mypath\/my<\/code><\/p>\nParsing mode<\/h4>\n
\/mypath\/my#file.jpg<\/code><\/p>\nfile:\/\/\/mypath\/my%23file.jpg<\/code><\/p>\nQUrl myUrl = QUrl::fromEncoded(\"file:\/\/\/mypath\/my%23file.jpg\", QUrl::StrictMode)<\/code><\/p>\nQUrl myUrl = QUrl::fromEncoded(\"file:\/\/\/mypath\/my%23file.jpg\")<\/code><\/p>\nmyUrl.toLocalFile()<\/code><\/p>\n\/mypath\/my#file.jpg<\/code><\/p>\n\/mypath\/my<\/code><\/p>\nEncoded usage<\/h4>\n
\/mypath\/my#file.jpg<\/code><\/p>\nfile:\/\/\/mypath\/my%23file.jpg<\/code><\/p>\nfile:\/\/\/mypath\/my#file.jpg<\/code><\/p>\nQUrl myUrl = QUrl::fromEncoded(\"file:\/\/\/mypath\/my%23file.jpg\", QUrl::StrictMode)<\/code><\/p>\nQUrl myUrl = QUrl(\"file:\/\/\/mypath\/my#file.jpg\")<\/code><\/p>\nmyUrl.toLocalFile()<\/code><\/p>\n\/mypath\/my#file.jpg<\/code><\/p>\n\/mypath\/my<\/code><\/p>\nCorollary:<\/h3>\n