<table><tr><td style="">dantti added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D14006">View Revision</a></tr></table><br /><div><div><p>Well the issue will probably depend on the server,<br />
for example Apache2 with Nextcloud it returns forbidden for both operations,<br />
in Cloudlyst which does:<br />
QUrl::fromEncoded(QStringLiteral("file:///speçiál").toLatin1()).toLocalFile();<br />
you get a file with a different file name as URL.<br />
Since 'ç' is extended ASCII this "fails" only because URL are sopposed<br />
to use only printable ASCII chars</p>

<p>If you use some some UTF-8 char like ←it wil<br />
produce that behavior:<br />
QStringLiteral("spe←ail\r\n").toLatin1()<br />
will produce:<br />
"spe?ail\r\n"<br />
and the question mark is interpreted as being the query part<br />
of an URL, thus what I said before that it cuts<br />
everything past the special char due URL parsing.<br />
you can see doing this:<br />
QUrl::fromEncoded(QStringLiteral("file:///file←sadssad").toLatin1()).toLocalFile()<br />
local file will be "/file"</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R241 KIO</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D14006">https://phabricator.kde.org/D14006</a></div></div><br /><div><strong>To: </strong>dantti, dfaure, Frameworks, Dolphin<br /><strong>Cc: </strong>bruns, anthonyfieroni, ngraham, kde-frameworks-devel, michaelh<br /></div>