| Summary: | Kleopatra displays an error report received from gpg in gibberish after clicking "refresh OpenPGP certificates". . | ||
|---|---|---|---|
| Product: | [Applications] kleopatra | Reporter: | lockywolf |
| Component: | general | Assignee: | Andre Heinecke <aheinecke> |
| Status: | RESOLVED FIXED | ||
| Severity: | grave | CC: | kdepim-bugs, mutz |
| Priority: | NOR | ||
| Version: | 3.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| URL: | http://i.imgur.com/LYpH90d.png | ||
| Latest Commit: | https://commits.kde.org/kleopatra/289efa360f6b15a3389ea2f2efede352711e7d7e | Version Fixed In: | |
| Attachments: |
New screenshot 1
New screenshot 2 |
||
|
Description
lockywolf
2016-03-10 15:50:46 UTC
This looks like a nasty mismatch between console OEM charset and gui ANSI charset. I've looked at it and Kleopatra takes the error from GnuPG and converts it with QString::fromLocal8Bit and this uses the ANSI charset while GnuPG uses the OEM charset. *sigh* I'll add some conversion code to handle this properly. Created attachment 108735 [details]
New screenshot 1
Created attachment 108736 [details]
New screenshot 2
The bug is still there :-). One of the problems here may be the historical disparity and hassle with Cyrillic encodings. Nearly everywhere MS Windows uses cp1251, their own development. In all strings, in Notepad-created text files, etc. But cmd.exe console uses cp866, inherited from IBM DOS. (In fact, both encodings are non-standard, but that's a different story.) Git commit 289efa360f6b15a3389ea2f2efede352711e7d7e by Andre Heinecke. Committed on 18/07/2018 at 09:26. Pushed by aheinecke into branch 'master'. Another try to fix windows encoding mess We now put GnuPG's output through a central conversion function so that we have a place to modify when things change. The Problem is that on my western windows system GnuPG gets CP 437 as GetConsoleOutputCP and prints in that codepage. We get 0 as GetConsoleOutputCP and 1252 with GetACP. The only thing that seemed to somehow match was GetOEMCP but that might just be luck and it might still be broken in other windows languages. Using --display-charset utf8 does not work (even when fixing the argument order) and is also not available for GPGSM. M +1 -1 src/commands/dumpcertificatecommand.cpp M +5 -4 src/commands/gnupgprocesscommand.cpp M +51 -0 src/utils/gnupg-helper.cpp M +6 -1 src/utils/gnupg-helper.h https://commits.kde.org/kleopatra/289efa360f6b15a3389ea2f2efede352711e7d7e I hope that it will be fixed with Gpg4win-3.1.3 At least for my windows test system it works now. But the encoding is so messy that it might still be broken in other situations. I don't have Windows at the moment to test the issue, but thanks for your work! Windows character encoding system is unbelievably messy. |
