citerar Colin Putney <firstname.lastname@example.org>:
> On Saturday, June 1, 2002, at 08:08 AM, Henrik Svensson wrote:
> > It is not very difficult to convert from unicode to any other
> > Code and recommendations how to do it (for most standard charsets)
> > available. Some systems even have functions that will do it for
> > the case of a simple client that for example only can display 7 bit
> > ASCII it is even trivial, only remove the most significant byte from
> > every character in the array. The only thing the client has to
> > is that the text can contain characters that it can't convert and
> > print. How to handle this case has to be decided by the client
> > developer, but an easy solution is to replace the unprintable
> > characters with a simple placehoder.
> Well, just stripping off the high bit would leave garbage characters
> wherever there are multibyte sequences, so you'd have to be able to
> recognize those sequences and deal with them appropriately.
Please read the last sentence of my posting.
> I realize that it's not impossible, or even difficult to do the
> conversion. But it will take time and effort to do the research,
> testing and maintenance. It's another hurdle that a client developer
> will have to clear, for no particular benefit.
Please read sentence one and two. For more information go to
www.unicode.org. It's all there. It will benfit all people the want to
use a language that needs more than US-ASCII.
> What will likely happen is that simple clients will just ignore the
> problem, like CVS does. Then everything will work fine as long as the
> user never encounters anything but 7-bit ASCII, which maps to UTF-8
> without modification.
Then people will find out that the client is not doing its work
properly. They will either not use it or fix it. The beauty of open
> By explicitly specifying the charset we give clients the option to
> gracefully decline to display charsets they don't know about.
Think of two clients. One used for writing and one for reading. The
writing client uses "latin-1" charset to store a log message. The
reading client does only understand "US-ASCII". This means that the
reading client can't present any message at all to the user even if the
two used charsets are almost the same. Even if the stored text only
contains characters that are represented with the same numerical value
in the two charsets, the reader client can not show one single
character of the message to the user. Beacuse the reading client has no
knowledge at all about the similarities of the charsets. If the message
were stored as unicode/UTF-8, and the clients are able to convert
between their local charsets and unicode, the reading user would have
seen exacly the same message as was written originally with the writing
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun Jun 2 04:09:49 2002