Bug #392

Non-ASCII characters cannot be used on command line in Windows

Added by John Lindgren almost 4 years ago. Updated almost 4 years ago.

Status:Closed Start date:January 10, 2014
Priority:Major Due date:
Assignee:John Lindgren % Done:


Target version:3.5
Affects version:3.4.3


As noticed here [1], filenames with non-ASCII characters cannot be opened via the command line in Windows. Opening the same files from the Open dialog works correctly.

Technical details:

This is due to GLib's crazy definition of "filename encoding", which means the system locale on every system except Windows, but UTF-8 on Windows [2]. When we pass G_OPTION_ARG_FILENAME_ARRAY to GLib to get our list of filenames from the command line, we are treating these filenames as though they are in the system locale. This is a correct assumption on most systems, but on Windows, GLib has already converted those filenames to UTF-8. We happily go and run the conversion a second time, which (for example) turns "ú" (FAh in CP1252, C3h BAh in UTF-8) into "ú" (C3h 83h C2h BAh in UTF-8).

[1] http://redmine.audacious-media-player.org/boards/1/topics/1018

[2] Particularly ironic since UTF-8 is one of the few encodings you cannot use for filenames in Windows. You can use CP1252 and most other legacy encodings, or you can use UTF-16, but not UTF-8.

Associated revisions

Revision e1d4c975
Added by John Lindgren almost 4 years ago

Replace GOptionContext with a command-line parser that does not mangle character encodings. Closes: #392.


#1 Updated by John Lindgren almost 4 years ago

  • % Done changed from 0 to 100
  • Target version changed from 52 to 3.5
  • Status changed from New to Closed

Also available in: Atom PDF