>>68 is quite right.

To cite a concrete example, Java uses UTF-16 as its native string storage and the extra charsets are an optional part of the install. If you still install them, then everything still works fine unless you happen to run into one of those character sets.

>>64 seems to think that decoding a string at every single function is an efficient way to write code. You do understand that decoding has overhead. Right?

I don't really object to UTF-8 though. At the very least it's no better nor worse than UTF-16, as they both work in more or less the same fashion for characters which are outside the range that can be represented by a single code unit.

Oh yes, and DVDs work fine because the subtitles are stored as GRAPHICS. I think you will find that real subtitles require knowing the encoding of the subtitle file, whether it's standardised, stored in the file or somewhere else.