<div dir="ltr">Hi all,<div><br></div><div>One meta-question I have which may already have been discussed much earlier in this whole proposal series, is:<br>How common is this problem?</div><div><br></div><div>Because I have the impression that nowadays all Linux distributions are UTF-8 by default and you have to show some</div><div>bloody-mindedness to end up with a POSIX locale.</div><div><br></div><div>Docker was mentioned, is this not really an issue which should be solved at the Docker level?</div><div>Since it would affect *all* applications which are doing something non-trivial with encodings?</div><div><br></div><div>I realise there is some attractiveness in solving the issue "for Python", since that will reduce the amount of bug reports<br>and get people off the chests of the maintainers, but to get this fixed in the wider Linux ecosystem it might be preferable to <br>"Let them eat mojibake", to paraphrase what Marie-Antoinette never said.</div><div><br></div><div>Stephan </div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-01-06 5:49 GMT+01:00 Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Jan 06, 2017 at 02:54:49AM +0100, Victor Stinner wrote:<br>
<br>
> Let's say that you have the filename b'nonascii\xff': it's decoded as<br>
> 'nonascii\xdcff' by the UTF-8 mode. How do GUIs handle such filename?<br>
> (I don't know the answer, it's a real question ;-))<br>
<br>
</span>I ran this in Python 2.7 to create the file:<br>
<br>
open(b'/tmp/nonascii\xff-', 'w')<br>
<br>
and then confirmed the filename:<br>
<br>
[steve@ando tmp]$ ls -b nonascii*<br>
nonascii\377-<br>
<br>
Konquorer in KDE 3 displays it with *two* "missing character" glyphs<br>
(small hollow boxes) before the hyphen. The KDE "Open File" dialog box<br>
shows the file with two blank spaces before the hyphen.<br>
<br>
My interpretation of this is that the difference is due to using<br>
different fonts: the file name is shown the same way, but in one font<br>
the missing character is a small box and in the other it is a blank<br>
space.<br>
<br>
I cannot tell what KDE is using for the invalid character, if I copy it<br>
as text and paste it into a file I just get the original \xFF.<br>
<br>
The Geany text editor, which I think uses the same GUI toolkit as Gnome,<br>
shows the file with a single "missing glyph" character, this time a<br>
black diamond with a question mark in it.<br>
<br>
It looks like Geany (Gnome?) is displaying the invalid byte as U+FFFD,<br>
the Unicode "REPLACEMENT CHARACTER".<br>
<br>
So at least two Linux GUI environments are capable of dealing with<br>
filenames that are invalid UTF-8, in two different ways.<br>
<br>
Does this answer your question about GUIs?<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Steve<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</div></div></blockquote></div><br></div>