(Looks like I'm one of the first to get caught hitting reply without
thinking ;)
----- Forwarded by Ben Carlyle/AU/IRSA/Rail on 27/10/2003 09:37 AM -----
Ben Carlyle
27/10/2003 09:33 AM
To: Wayne Venables <[EMAIL PROTECTED]>@CORP
cc:
Subject: Re: [sqlite] Making sqlite support unicode?
Hello,
Wayne Venables <[EMAIL PROTECTED]>
25/10/2003 11:06 AM
To: "Mrs. Brisby" <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject: Re: [sqlite] Making sqlite support unicode?
> Win32 is unicode
> (UCS16). Writing C/C++ w/ Win32 generally involves using wide char
> strings. Visual Basic natively stores strings as unicode. Java
natively
> stores strings as unicode. I'd say that covers a lot more than 1%. And
if
> you're coding for a non-unicode operating system, I sure hope you're
using
> unicode anyway or otherwise you're alienating a large portion of users.
I
> purely ASCII database in this day and age is terribly
> backwards. Thankfully, sqlite has the UTF-8 option.
(Not to add too much heat to any flame war that might be happening on this
subject... :)
The thing that most scared me about the higher-order unicode encodings
(16, 32-bit etc) was this "Encoding" list under Windows XP notepad:
ANSI
Unicode
Unicode Big Endian
UTF-8
All I can say is "Eeek! Higher-order unicode encodings are
endian-specific!!!". In my mind this puts their applicabilty to on-disk
file formats at risk. UTF-8, on the other hand, can be read regardless of
architecture. While I know there are technical solutions to
endian-specific encodings, so long as you know which endian the data was
saved under, I personally find the endian-free nature of UTF-8 comforting.
Benjamin.
