This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Sworddragon, a.badger, bkabrda, larry, lemburg, loewis, ncoghlan, pitrou, r.david.murray, serhiy.storchaka, terry.reedy, vstinner
Date 2013-12-10.10:36:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAMpsgwYMv5HenLSmsqYFO-bh+EALbhuNsftDHuAvEAxDjf45aA@mail.gmail.com>
In-reply-to <1386659325.72.0.313292500541.issue19846@psf.upfronthosting.co.za>
Content
2013/12/10 Martin v. Löwis <report@bugs.python.org>:
> >From what I read, it appears that the SO posting is plain wrong. Consider, for example,
>
> https://developer.gnome.org/glib/stable/glib-Character-Set-Conversion.html#g-filename-to-utf8
>
> # Converts a string which is in the encoding used by GLib for filenames
> # into a UTF-8 string. Note that on Windows GLib uses UTF-8 for filenames;
> # on other platforms, this function indirectly depends on the current locale.
>
> The SO author might have misread the part where it says that glib uses UTF-8 *on Windows* (instead of the braindead "ANSI" encoding indirection).

I wrote some notes about glib here:
http://unicodebook.readthedocs.org/en/latest/libraries.html#the-glib-library

g_filename_from_utf8() uses the g_get_filename_charsets() encoding.
g_get_filename_charsets() is the ANSI code page on Windows and the
locale encoding on Linux, except if G_FILENAME_ENCODING or
G_BROKEN_FILENAMES environment variables are set.

glib has a nice g_filename_display_name() function.
History
Date User Action Args
2013-12-10 10:36:37vstinnersetrecipients: + vstinner, lemburg, loewis, terry.reedy, ncoghlan, pitrou, larry, a.badger, r.david.murray, Sworddragon, serhiy.storchaka, bkabrda
2013-12-10 10:36:37vstinnerlinkissue19846 messages
2013-12-10 10:36:37vstinnercreate