Home Standaarden voor lettertekens / Standards for character encoding Back to the future [2] Unicode troubles

Back to the future [3]

Op de Unicode mailinglist worden vaak zeer interessante discussies gevoerd waaraan ook employees van MicroSoft, Netscape resp. Apple Inc. deelnemen. Dat de discussies soms hoog oplopen zal niemand verbazen.

In een discussie over diacritische tekens - accenten e.d. - werd duidelijk dat er een grote weerstand is ontstaan tegen de toevoeging van nieuwe combinaties van lettertekens met diacrieten. Met name wordt moeilijk gedaan over de wensen van Vietnamezen en Litouers!

Wie zulke combinaties nodig heeft moet maar een reeks van lettertekens + de diacrieten gebruiken en het aan de software overlaten om daarvan iets moois op scherm of papier te brouwen. Kortom terug naar US-ASCII met 127 tekens en daarbij slechts een groot aantal diacritische tekens. Het probleem van hoe de lettertekens gesorteerd moeten worden zou dan ook voor programmeurs eenvoudiger te zijn op te lossen. Komt de 'a+acutus' [] nu direct na de 'a' of ergens achteraan in het alfabet? Per taal zou dat dan ook nog wel eens kunnen verschillen!

Een tweede discussie waarbij MicroSoft direct de volle laag krijgt is het feit dat op het Internet al zeer veel teksten aanwezig zijn gecodeerd volgens Windows 1252. Windows 1252 lijkt zeer sterk op ISO-8859-1 [ofwel Latin 1] maar heeft een aantal extra lettertekens weggestouwd in het gebied C1: 128-159 wat eigenlijk is voorbehouden aan controle-tekens zoals ook het gebied C0: 0-31. Waar over dat laatste geen discussie is wordt het leeglaten van 128-159 in de ISO-codepages als verspilling gezien. Gebruikers van niet-PC's klagen over het vastlopen van hun computers als zo'n bericht binnenkomt:


Frank Cruz vs Doug Ewell:

> ... that terminal-host communication
> relies on character sets that comply with 4873 and 2022, and it implies,
> quite in contrast to the misguided who believe that terminals don't
> matter, that terminals are the ONLY thing that matter!
>

It all matters. But why should there be two different 8-bit character sets for terminal-host communication and for Web browsing in the "Latin-1 languages", when a single standard one one would do?

Some have suggested that those who read their email with terminals or emulators should "upgrade" their email clients to "properly" handle CP1252 and other private code pages. That's absurd. If I write or buy an email client that obeys all the rules, I should not need to change it constantly as creative new ways are found to break the rules.

Others have suggested that it is the responsibility of end users to take defensive measures to prevent nonstandard character sets from hanging or confusing their terminals or emulators. That's not right either. Our terminals and emulators *use* the C1 controls in valid, real-life, standards-conforming applications. I do not know in advance if a particular email message is going to fry my terminal, especially if its character set is not announced. Anyway, what if I have a real terminal, such as a VT420? In that case, there is no recourse - whenever such a message arrives, the terminal becomes useless and must be reset. The message can not be read unless you put the terminal into debug mode, in which case it will show C1 Control Pictures in place of "smart quotes" (and for that matter, C0 Control Pictures in place of CR, LF, Tab, etc).


MicroSoft verdedigt zich [enigszins terecht] tegen beschuldigingen met het verweer dat de 1252 codepage al bestond voor dat de ISO-Latin 1 standaard werd. De angst met name uit de Unix-hoek - waar Unicode al min meer standaard ingebakken zou zijn - is dat Win1252 als de facto standaard de ISO standaard en misschien ook de Unicode zou kunnen verdringen.

Doug Ewell poneert dan ook:

Here's what I have to contribute to this hot topic.

  • Tagging CP1252 text as "ISO-8859-1" is evil.

Don't do it. It should not be hard for either e-mail software or Web tools to determine if the source text contains characters in the range 0x80 to 0x9F and to apply a Windows-1252 tag if it does. For that matter, it should apply a US-ASCII tag if there are no characters above 0x7F. If you create Web pages tagged as 8859-1 that contain 1252 characters, your pages have a problem and users should not have to second-guess your tag; and if you write software that tags e-mail or Web pages incorrectly, shame on you.

  • "CP1252 is not a standard."

Oh, but it is. True, it's not an ISO or ANSI standard, not a de jure standard, but it IS a de facto standard. It is an industry standard. It is used by a LOT of people.

The difference between a de jure standard and a de facto standard is sort of like the difference in American law between direct evidence and circumstantial evidence. Any judge in the U.S. will tell you that circumstantial evidence IS evidence, although of a lower "quality" than direct evidence. Similarly, a de jure standard is usually preferable to a de facto standard, but the latter is still a standard.


Terecht wordt dan ook geopperd dat alle ISO-8859 codepages slechts tijdelijke oplossingen zijn en dat het wachten is op het beschikbaar komen op grote schaal van op Unicode gebaseerde software. Als het zover is dan maakt het ook niet echt uit of je converteert van Win1252 of van ISO-Latin 1.

Doug besluit met een wijze opmerking die ook wel eens van toepassing zou kunnen zijn op de Atari-gelederen:

  • "Does anyone else find it bizarre that we engage in so much internecine warfare on this list, when the whole purpose we are on it is to further the cause of Unicode?"

No, this is typical. I am on other Internet mailing lists, and most of them that support a cause have some sort of bickering between list members about who is more devoted to the cause or who represents the "true" solution or what is best for the cause. People are like that. That is why there are family squabbles, civil wars, and battles among and between religious groups.


Copyright © Rein Bakhuizen van den Brink
Last updated on 21 november 2001

Home Standaarden voor lettertekens / Standards for character encoding Back to the future [2] Unicode troubles