Page MenuHome GnuPG

garbled characters on command line on windows with on-ascii locales
Closed, ResolvedPublic

Description

When starting gpg on the cmd.com on windows the non-ascii output is garbled.

E.g. with Vista in German
Reproduced with Gpg4win 2.2.1.
gpg2 --version leads to

"
Home: C:/Users/Admin/AppData/Roaming/gnupg
Unterst³tzte Verfahren:
Íff. Schl³ssel: RSA, ELG, DSA, ?, ?"

Expected would be that the umlauts are displayed correctly, e.g.
"Unterstützte Verfahren:".

in OS Win XP (in case loc gr_EL)
the command line is completey useless.
https://wald.intevation.org/forum/forum.php?thread_id=1358&forum_id=21&group_id=11

A workaround to get at least English strings is to use the "LANG" environment
variable.

SET LANG=C
gpg2 --version

Event Timeline

Switch the console to utf-8 and things will work. There is no explict support
for this.

werner lowered the priority of this task from Normal to Wishlist.Jul 25 2014, 3:18 PM
werner added a project: Feature Request.
werner removed a project: Bug Report.
werner removed a project: gpg4win.
werner added a project: gnupg.

What is the best way to switch the console to utf mode?
Should someone use the chcp command and how?

Anyway the default behaviour is surprising for users, so from my point of view,
it should be improved somehow. A good documentation how to switch would only
be a second grade solution. A better one would be if the .exes would switch the
code page themselfs, I assume.

You probably need a helper. I have no idea whether such a tool exists. Windows
System Programming should have all the details.

I don't think switching the console to UTF-8 is the real problem here.

At least just using chcp is not enough. Fonts do also factor into this and this
is where it gets weird:

If you run chcp 65001 and have a raster font selected the output is garbled.
If you then switch to a truetype font the output is correctly interpreted.

Now if you run the command while already having a truetype font selected the
output is garbled again but differently.. o.O

And looking at common/utf8conf.c there is already code that tries to handle
different Console Output Codepages but appearently there is a bug somewhere in
there :) (Or that code is not used / respected)

IIRC, there is a need to allocate a new console or something like this. It is
too long since I studied this and concluded it is too much work and English
users won't appreciate it anyway ;-)