From: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
---|---|
To: | Magnus Hagander <mha(at)sollentuna(dot)net> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Kellerer <spam_eater(at)gmx(dot)net>, pgsql-hackers-win32(at)postgresql(dot)org |
Subject: | Re: locales and encodings on Windows |
Date: | 2004-12-22 18:35:58 |
Message-ID: | 41C9BE8E.2090908@pse-consulting.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers-win32 |
Magnus Hagander wrote:
>
> The implementation is not buggy.
> The implementation of strcoll() etc *does not exist* for UTF-8.
> There is a perfectly working Unicode system on Windows - it has been
> there since Windows NT 3.1. *Every* API in Windows is unicode
> internally. With Unicode in this case, MS means UTF-16.
> How do other programs do? They convert their strings to UTF-16 and use
> the unicode functions in the OS. UTF8 support only exists in the two
> functinos used to convert to/from UTF-16.
In general I agree. Most programs won't use UTF-8 at all, but will work
with wchar_t (i.e. UTF-16 or UTF-32) since coding is easier, and will
convert to UTF-8 on interfaces only. Additionally, storing UTF-8 seems
uncommon to me too; this is usually done using NVARCHAR.
> That's at least how I understand it. I'm not a locale/encoding expert
> though, so I could be wrong :)
>
> Perhaps an emulation layer could be written for port/win32. I can't
> really say, because I don't know these things well enough (on any
> platform).
Shouldn't be too complicated.
Regards,
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Korea PostgreSQL Users' Group | 2004-12-23 05:18:20 | bug plpython compile error for win32 |
Previous Message | Magnus Hagander | 2004-12-22 17:40:24 | Re: locales and encodings on Windows |