PuTTY wish windows-utf16

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

summary: Support UTF-16 on Windows
class: wish: This is a request for an enhancement.
difficulty: tricky: Needs many tuits.
priority: low: We aren't sure whether to fix this or not.
fixed-in: r8495 87aafaa89a5c39bfe121a5bedfc84887bdeb9f20 2009-03-25 (0.61)

Josef Hinteregger reports that the CF_UNICODETEXT data stored by Windows in the clipboard is encoded in UTF-16; that is, it can contain surrogate pairs representing characters outside the BMP. PuTTY does not currently interpret those pairs. Of course, if it did, it would also have to be able to write them out again when copying to the clipboard itself or talking to the Windows GDI text display primitives, etc.

I can see two sensible ways to solve this. One is to do translation to and from UTF-16 on the platform side of the front end interface, if necessary for a given platform. So:

The other option is to do the UTF-32/UTF-16 translation on the cross-platform side (terminal.c and ldisc.c), and have it enabled or disabled by a #define in each platform header file. (The #define is certainly necessary: partly because we shouldn't accept UTF-16 surrogate pairs coming from front ends which are supposed to be speaking UTF-32, on the usual grounds of not accepting redundant encodings, but mostly because terminal.c will obviously need to know whether to send surrogate pairs when sending Unicode data back to the front end!)

I'm currently inclined to the first option, because UTF-16 is nasty and I'd rather it complicated only those front ends that had to deal with it than that it complicated the core code.

Update, 2009-03: fixed (using the second option).


If you want to comment on this web site, see the Feedback page.
Audit trail for this wish.
(last revision of this bug record was at 2016-12-27 11:40:21 +0000)