On Windows, when entering multibyte characters in an interactive prompt, gpg(2) only takes the first byte of each character.
This creates problems when generating new keys with Chinese names, for example.
Chinese characters are usually encoded with 2 bytes in appropriate Windows code page (e.g. "cp936" aka "GBK"). Taking only the first byte makes it impossible (or at least very difficult) to create keys with correct Chinese names using gpg.
Example command and output:
gpg -vvv --generate-key gpg (GnuPG) 2.2.13; Copyright (C) 2019 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. gpg: using character set 'GBK' Note: Use "gpg --full-generate-key" for a full featured key generation dialog. GnuPG needs to construct a user ID to identify your key. Real name: 一二三四五六 Email address: You are using the 'GBK' character set. You selected this USER-ID: "叶人瘟" Change (N)ame, (E)mail, or (O)kay/(Q)uit? q gpg: Key generation canceled.
Python commands verifying that gpg really is taking the first byte of each encoded character:
>> for c in '一二三四五六': .. print(c, c.encode('gbk')) .. 一 b'\xd2\xbb' 二 b'\xb6\xfe' 三 b'\xc8\xfd' 四 b'\xcb\xc4' 五 b'\xce\xe5' 六 b'\xc1\xf9' >> print(b'\xd2\xb6\xc8\xcb\xce\xc1'.decode('gbk')) '叶人瘟'
- This problem only exists for some interactive prompts (AFAIK), not for command line arguments, not for PGP messages typed in stdin.
- I'm using the "simple installer" for gpg on Windows, not gpg4win. Although, I believe the "gpg.exe" binary is exactly the same in both versions.