GNOME Bugzilla – Bug 314538
Non-UTF-8 Encoding Fixes
Last modified: 2013-04-29 19:23:47 UTC
In the environment with the locale is not UTF-8 but other 8-bit one, such as ja_JP.eucJP (uses EUC-JP the 8-bit codeset), the following problems occur: 1. The names of remote files or directories are broken Nautilus assumes that all remote directories or files have names with UTF-8 codeset. So if remote environment holds those in the codesets after local locale, the names are broken and trailed with '(Invalid Unicode)'. 2. The names in file operation dialogs are broken The dialog shown while files are under copying assumes that directories or files have names with UTF-8, even if they are in the local filesystem. 3. The remote files will be renamed and falls down in UTF-8 codeset. If the remote files or directories are renamed, the names will have UTF-8 codesets.
Created attachment 51368 [details] [review] Patch for fix them This patch fixes the problems above in the following way: 1. Broken remote filenames... 1-1. Try below only in remote files or directories. 1-2. First, assume names of remote files or directories having UTF-8 codeset. 1-3. If broken unicodes found, falling back to locale specified codeset (using G_FILENAME_ENCODING or G_BROKEN_FILENAMES). 1-4. Finally, force validate the names into UTF-8 by eel_make_valid_utf8(). (Now nautilus does only 1-2 and 1-4) 2. Broken names in dialogs... 2-1. First, assume names having UTF-8 codeset. 2-2. If broken unicodes found, falling back to locale specified codeset (using G_FILENAME_ENCODING or G_BROKEN_FILENAMES). 2-3. Finally, force validate the names into UTF-8 by eel_make_valid_utf8(). (Now nautilus does only 2-1 and 2-3) 3. Remote file renaming problem... 3-1. Try below only in remote files or directories. 3-2. If the original name has invalid unicode, and has valid code in locale specified codeset, rename it with the codeset in the locale, otherwise use UTF-8 codeset. (When renaming file with the codeset of its name us-ascii, new name stored in UTF-8 anyway, but above are, I think, effective as a minimum rescue) The patch has four parts, the first part is hack for 2, the second and the fourth for 1, and the third for 3. Although it is for nautilus-2.10.1, it can also be applied into CVS HEAD. Regards.
Thanks for your bug report and these excellent fixes!
*** Bug 308599 has been marked as a duplicate of this bug. ***
Maybe that patch should be sent on the nautilus-list, maintainers usually use it for commenting
Sorry for not having given feedback. Sebastien is right, it would be great if you could submit this patch to the nautilus mailing list: http://mail.gnome.org/mailman/listinfo/nautilus-list
Shun-ichi TAHARA, is this still an issue in nautilus 2.18/2.20? if so, we should definitely get this in for 2.22. sorry for the missing feedback so far. :-(
Setting patch status as "needs-work", as it does not apply anymore.
*** Bug 459402 has been marked as a duplicate of this bug. ***
It would be nice to see whether this is still needed for 3.2.
Does anyone know if this is still required or if there are other issues?
*** Bug 301777 has been marked as a duplicate of this bug. ***
Let's presume this is OBSOLETE. Please reopen if this is not the case.