gnupg 1.2.1&1.3.1 - BAD output with --with-colons --list-keys for russian uid, not equal --charset utf8 --list-keys

[Sekretnii Yenot]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 23 March 2003 03:06 am, David Shaw wrote:
>
> --list-colons doesn't decode UTF8 output.  It outputs the raw bytes,
> and escapes those that aren't 8-bit safe.  It is up to the program
> that calls GnuPG with --with-colons to properly handle the UTF8.

This is painful for developers.  I think it's the reason almost
all the GUI software for GnuPG doesn't handle Russian UID's correctly.
(Examples: kmail and kgpg.)  These programs are all written with
libraries that love raw UTF-8, but GPG is forcing these developers
to hand code an extra level of nonstandard decoding.  (Actually, it's
not, most programs appear to be skipping the step and just giving the
end user garbage.)

Here's some QT code that gets around the problem.

//
//  GPG escapes certain UTF-8 characters in UID's with '\xHH'. The
//  following replaces '\xHH' sequences with the unicode character
//  represented by hex 'HH', then we convert from UTF-8 to QT's
//  unicode format.
//
void GpgParse::decodeUID( QString &s )
{
  QRegExp rx( "\\\\[xX]([0-9,a-f,A-F]{2})" );

  int pos = 0;
  while ( (pos = rx.search ( s, pos )) >= 0 ) {
    QChar c( rx.cap(1).toUShort( NULL, 16 ) );
    s.replace( pos, 4, &c, 1);
    pos++;
  }

  s = QString::fromUtf8( s, s.length() );
}


I'm attaching my public as well, since it makes a good test case.

 - Yenot

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+gcHKVPC8odwI3c0RAkgCAJ9674zGPodPyzEjg6cSX/1e4ru7FgCdElsT
uohbxsm3sHnQQDwX/t5bHrs=
=nms9
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: public_key.asc
Type: application/pgp-keys
Size: 1698 bytes
Desc: not available
Url : /pipermail/attachments/20030326/43e201a5/public_key.bin