From: Charles Yeomans <[EMAIL PROTECTED]>
Date: Thu, 3 Aug 2006 00:02:45 -0400
Just the same for encodings. UTF-8 does everything so there's no
advantage in using anything other than UTF-8 except for input and
output.
It should be considered a design error to be processing strings in
more than one encoding, except to convert it to and from the
dominant encoding.
Well, I think you can assume that people should stick to your
suggested design principles.
Probably Apple has some good developers, and they think UTF-16 is the
better choice.
I think NSString was made before they were aware of UTF-8 and
definitely before UTF-8 became popular. UTF-16's inclusion could just
be a historical quirk. After all, it's a variable width encoding that
takes up far more space for most purposes. UTF-16 takes less space
for pure CJK, however.
But a Japanese HTML page will take up less space in UTF-8, due to all
the English tags and the spaces and returns.
UTF-16 also had some historical quirk, that it was originally
proposed that it would be a fixed size encoding. Then it later turned
out that it wouldn't be. While people still believed it was fixed
size, I think it was more attractive than it is now. I've seen this
refered to as an unintentional "Switch and bait" tactic. People were
opposed to variable length characters, so we gave them UTF-16. Then
it turned out that UTF-16 was variable length anyhow, therefor you
may as well use the UTF-8 that they originally proposed.
Also, Apple return their strings via an [NSString UTF8String]; method
and they have a [NSString stringWithUTF8String]; method too. These
are really handy for processing strings.
--
http://elfdata.com/plugin/
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
