From: | Marc Herbert <Marc(dot)Herbert(at)continuent(dot)com> |
---|---|
To: | pgsql-odbc(at)postgresql(dot)org |
Subject: | Re: Unicode is not UTF-8. was :psqlODBC-Driver Test / text |
Date: | 2006-04-03 08:55:30 |
Message-ID: | khjacb3hwcd.fsf@meije.emic.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-odbc |
Bart Samwel <bart(at)samwel(dot)tk> writes:
>
> C++ even introduced a special alternative character type "wchar_t" for
> this, just so that people could handle both 8-bit char* and 16-bit
> wchar_t* strings. In wchar_t* strings, 8-bit NULs are not a problem
> because only 16-bit NULs count (and AFAIK the Unicode standard does
> allows this to be interpreted as a NUL aka end-of-string). The
> downside of this solution is that no application actually uses it, and
> everybody is stuck with 8-bit ASCII plus a random local codepage
> unless special support is added.
wchar_t is not defined as 16-bits, but as "wide enough to hold any
character of the platform". For instance if the platform uses UCS-4,
then wchar_t is 32 bits wide.
(UTF-16 wchar_t violates this)
I don't clearly see how you want to use a 8-bit NULL to terminate a
(wider) wchar_t array... ?
> Why didn't they just upgrade chars to 32 bits and be done with
> it... :-/
Because "char" was and is still used to store multibyte /
variable-length / encoded characters.
From | Date | Subject | |
---|---|---|---|
Next Message | Bart Samwel | 2006-04-03 09:03:40 | Re: Unicode is not UTF-8. was :psqlODBC-Driver Test / text |
Previous Message | Dave Page | 2006-04-03 08:29:42 | Re: problem about maximum row size ? |