Notices with refresh-keys but I also had this on other places where Gpg Output was used in Kleopatra.
I think that stringFromGpgOutput (I think that is what is called) might be wrong now that GnuPG trys to always output UTF-8
Reproducable with German l10n and refresh-keys. Both the output window and the error message (if there is an error) have broken umlauts.
| rLIBKLEO Libkleo | |||
| rLIBKLEO026797ff38b4 Add helper for converting description of GpgME::Error to Unicode | |||
| rLIBKLEO481c6ccf5359 Ask gpgconf for the console output codepage used by gpg on Windows | |||
| rKLEOPATRA Kleopatra | |||
| rKLEOPATRA2c8ab3cfaed0 Fix/unify conversion of GpgME::Error description to Unicode | |||
| rW Gpg4win | |||
| rWe5dee8abf304 Add tools needed for building Solid and other KDE frameworks | |||
| rM GPGME | |||
| rMe80bf34bf86f Update NEWS | |||
| rMd256ba7cc57d w32: Always use UTF-8 for localized texts | |||
I would love to defer those encoding problems to gpgme. The output of gpgme should always be UTF-8 encoded, so that higher API doesn't need to bother about encoding. Obviously, this would mean that we shouldn't bypass gpgme by running gpg commands with QProcess.
It's a pity that gpg's --display-charset "should not be used on Windows" (the man page). Because I wanted to propose to force gpg to output UTF-8 on Windows, so that we can be sure that we are dealing with UTF-8. But I guess there's a reason why that's not done on Windows.
stringFromGpgOutput is used by
gpg always used UTF-8 the option to enable this is the default for more than a decade.
Oh well, in case you mean the diagnostic output things are different. gpg uses the code page as returned by GetConsoleOutputCP becuase we are a console program. Qt might assume that GetACP is used (as for GUis and thus we get a wrong codepage. You may try to run "chcp 65001" before starrting kleopatra or figure out how to convince Qt to set the codepage to 65001 (utf-8)
I created a self-signed X.509 test certficate with subject CN=日本国,C=JP (Nihon-koku/Nippon-koku; formal name of Japan).
Import the certificate and click on More Details in the Certificate Details window to reproduce the problem. For me the subject is displayed as
Subject: CN=µùѵ£¼Õø¢,C=JP
Test certificate:
In Windows PowerShell, I get the following output:
The active codepage is 65001.
Copying the output and pasting it in Editor (notepad?), it is displayed correctly. So maybe PowerShell just lacks a font to display Kanji characters.
Debug output in stringFromGpgOutput gives me
[1352] org.kde.pim.libkleo: stringFromGpgOutput GetConsoleOutputCP() returned 0 [1352] org.kde.pim.libkleo: stringFromGpgOutput GetOEMCP() returned 850 [1352] org.kde.pim.libkleo: stringFromGpgOutput GetACP() returned 1252
Kleopatra uses the first one that's not 0, i.e. 850, which is obviously a bad choice. The latin-*-variant 1252 won't help either.
stringFromGpgOutput actually received the following 8-bit data:
[1352] org.kde.pim.libkleo: stringFromGpgOutput ba: " Subject: CN=\xE6\x97\xA5\xE6\x9C\xAC\xE5\x9B\xBD,C=JP"
This looks very much like UTF-8 (i.e. codepage 65001).
Since GetConsoleOutputCP() returns 0 for Kleopatra we probably need to ask gpg what codepage to use.
Should be fixed. Tested as described in the above comment T5960#165845.
Note that this requires a version of gpgconf that supports the --show-codepages option.
Here is an other instance with broken encoding (on 3.1.27.0-beta44):
Technically, this is a completely different problem because in this case the text is not read from stdout/stderr of a different process but it is returned by GnuPG's own gettext implementation (on Windows). We may have to call gettext_use_utf8(1) somewhere. Otherwise, GnuPG's gettext seems to convert the texts to local encoding, but Kleopatra always assumes UTF-8. This should affect all texts containing non-ASCII.
@werner Can you confirm that we have to call gettext_use_utf8(1) in Kleopatra to make GnuPG's gettext return UTF-8 on Windows?
