Re[2]: question about Unicode

[Alen Ladavac <alenl-ml@...>]

> Just a note, not an argument against UTF-8--not being able to desync
> the stream by losing a byte, endianness-independence, and scaling to
> high Unicode ranges cleanly are good reasons to use it, too.

And the most important thing, most probably the reason for its
invention in the first place, is that it is backwards compatible with
most of the legacy functions and even applications that just transform
ASCII/ANSI strings. I.e. you can sprintf() it, strstr() a sub-string,
strrchr() to find path separators, and various other things without
even being aware if the string is UTF8 or just plain 8-bit ASCII. When
we switched to multi byte from single byte support in our
applications, we went for UTF8 simply because we only had to change
the text output and the interfaces with the system (file open, etc).
99% of the application code didn't even notice the difference. Heck
even most command line text-file parsing applications still work with
no changes.

FWIW,
Alen