Version: (using KDE KDE 3.0.4) Installed from: Debian testing/unstable Packages Compiler: gcc 2.95.4 OS: Linux My system locale is ru_RU.KOI8-R. If I create a directory with russian name, and place some cross-linked HTML pages in windows-1251 encoding, konqueror is unable to follow local links (such as <a href="x.html">). When the pointer in over the link, konqueror shows in the status line the pathname it is going to open. It has the russian directory name recoded from koi8 to windows-1251. I've looked at the sources. In khtml_part.cpp, in method KHMLPart::completeURL(), the following is written: ... if (d->m_decoder) return KURL(d->m_doc->completeURL(url), d->m_decoder->codec()->mibEnum()); ... I guess that in my case m_doc->completeURL() returns full pathname of the link (including cyrrilic-named directory in correct encoding), and then it is recoded. If I comment out those lines, the problem disappears. But I guess it is not the correct fix. Possibly the correct fix is to recode relative URL, but not the base URL.
do you still have the problem with KDE 3.1 or even 3.2?
Unfortunately yes. I can reproduce this on current Debian Sid system, with KDE 3.1. The bug is reproduced as follows: - ensure that system locale is ru_RU.KOI8-R - make a directory with russian name, e.g. "
Hmm, did you set the LANG in kdeinit's environment too?
Yes. LANG is set in environment of all apps. It is absolutely necessary to get correct behaviour on russian system (e.g. to read russian filenames from filesystem)
I was a bit inaccurate "
Just want to note that the bug is still there in KDE 3.2.2
*** Bug 99777 has been marked as a duplicate of this bug. ***
Created attachment 17109 [details] This patch seems to correct the Konqueror's behavior on my machine. I use UTF-8 locale. I found the same problem with KDE 3.5.3. My locale is UTF-8 and I have problems with paths containing hungarian accentuated letters. The attached patch seems to solve this problem although I don't know whether this is the right approach to eliminate this bug...
Can you reproduce the bug with kde 3.5.4?
Yes, bug could be reproduced in KDE 3.5.4 (debian sid, konqueror package version 4:3.5.4-2, kdelibs 4:3.5.4-3)
nikita, thanks for reporting. confirming the bug.
I was just about to report the same bug with German umlauts in the file name. I'm using (K)Ubuntu with KDE 3.5.5. To reproduce: Create path with umlauts in the name with system charset set to UTF-8. Create HTML frameset with a couple frames in that directory with a "meta http-equiv charset=iso8859-1" header inside them. Display HTML file with Konqueror. Result: Konqueror cannot display the frameset. Even though the file names contain no special characters, Konqueror tries to find the frame files by using the _full_ path of the file, but converted to the charset specified in the frameset. This is obviously wrong ... and a major PITA, because you cannot save any downloaded web site directories in a directory whose path contains non-ASCII characters. A quick fix with the above patch would really be appreciated! Thank you :) Jens
*** Bug 116523 has been marked as a duplicate of this bug. ***
Here's the more concrete testcase. I suppose that your locale is UTF8. Steps: 1. Create directory with russian name (you may copy-paste) it from here: mkdir СуперПуперПапка cd СуперПуперПапка 2. Put attached index.html and 1.html to created directory 3. Open index.html in konqueror (index.html is a very simple html with charset=koi8-r) 4. Hover a link, look what status bar shows (doh!) and try to follow it. No luck If you edit index.html and change it so "charset=utf-8", all will start to work - you can follow the link. Hope this helps :). Cheers.
Created attachment 19124 [details] index.html file which helps to reproduce the bug
Created attachment 19125 [details] 1.html file to be placed into the same directory as index.html
It seems konqueror is encoding the whole URL to that specified in the webpage. I placed the two testcase files in a directory named ЧтоНибудь The encoding on my machine is utf-8 so this was the directory's encoding. The index.html containing the link to 1.html was koi8-r encoded. This forced the link to 1.html to become koi8-r encoded. Since the directory which contained 1.html was encoded in utf-8, the whole url being in koi8-r no longer pointed to the correct location. Konq is correct, but a little too correct. Apparently a fix exists in this thread. Just encoding the part of an URL in a webpage instead of the whole URL seems to be a potential solution. Good luck with that ;-)
*** Bug 82145 has been marked as a duplicate of this bug. ***
Already more than four years to this problem! Dear developers - please repair this bug! FreeBSD-6.2, KDE-3.5.5
Created attachment 20664 [details] Please see this patch. Hello. Please see attached patch. The main problem is in kdelibs-3.5.6/kdecore/kurl.cpp in constructor: KURL::KURL( const KURL& _u, const QString& _rel_url, int encoding_hint ) at: 599 :KURL tmp( url() + rUrl, encoding_hint); url() - return string not encoded in encoding_hint Have fun.
This bug is still there in KDE 3.5.8 (using Debian testing). It only occurs when the charset in the HTML page is explicitly set and differs from the one used for the filesystem. I mirrored recently the FFMPEG doxygen documentation from www.irisa.fr, which contains charset=iso8859-1. When I remove this or change it to utf-8, all works as expected. I am very in favor of the fix to only recode the relative URL since it works as expected for me.
test case from comment #14 works for me in svn trunk r793457.
Bug still present in Konqueror 3.5.9.
As this bug is fixed in recent releases it's being closed. Setting it to LATER because it does qualify for backporting to the 3.x branch.
*** Bug 59150 has been marked as a duplicate of this bug. ***