Home Unicode UTF_8 Tahoma en Lucida Sans Unicode

UTF_7 en de 7/8-bits economie

Net als op de mailinglist van [atari-nederland] komt bij andere lijsten/groepen van tijd tot tijd het probleem van de meertaligheid van computerprogramma's [onder Windows, waar anders!] ter sprake. De groep van de Unicode.org is in dit verband de lijst bij uitstek maar ook daar blijken de meningen zeer verdeeld. De lijst van Nederlandse vertalers [vertalers@MailingList.net] resp. van Poolse vertalers [polish-translation] staat bij tijd en wijle vol van discussie over UTF, ISO e.a.

Terwijl je van de beroepsgroep van vertalers mag verwachten dat ze blij zijn met de geboden opties [of ontevreden bij het ontbreken ervan] valt de groep volgens een paar lijnen te splitsen:

  • de groep die Nederlands met Engels/Frans/Duits/Spaans en Italiaans doet
  • de groep met Hongaars, Roemeens, Pools, Hebreeuws erbij.


De eerste groep heeft nergens een boodschap aan. De tweede groep ziet de noodzaak, maar weet niet altijd hoe ze het moeten aanpakken.

Een ander lijn is die van b.v. mail-programma's:

  • Eudora gebruikers
  • MicroSoft Outlook [Express]

Eudora is een gratis, eenvoudig programma zonder veel toeters en bellen, Outlook is MS met alle voor en tegens. En dat laatste wordt veelvuldig naar voren gebracht door de talrijke fervente MS-haters. En het zijn uitgerekend de multilinguale eigenschappen van de MS programma's die me ertoe brengen om in de mailinglist MS te promote'n. Dat dit leidt tot nogal felle reacties laat zich indenken.

De bekendheid met de problematiek wordt voor de meesten afgedaan met 'onder welke toetsen zitten de accenten', bij een 'amerikaans' of 'uitgebreid amerikaans' toetsenbord.

In de Poolse vertalers lijst kwam recent de suggestie weer boven drijven om die lastige Poolse letters maar onder de tafel te schuiven want je kreeg toch allemaal maar 'hekjes'. De 'booswicht' had zich bedient - niet van ISO Latin 2 - maar van UTF-7.


UTF-7 is een broertje van UTF-8 m.a.w. een manier om van een 16-bits letterteken 7-bits letters te maken. US-ASCII ofwel de tekens 0-127 blijven onveranderd en al het andere wordt omgezet naar een korte [3 of meer] reeks US-ASCII tekens, die beginnen met een '+' en eindigen met een '-':

Content-Type: text/plain; charset="utf-7"
Content-Transfer-Encoding: 7bit

Bez kontekstu jest trudno+ACE- Jako t+ALM-umacze wiemy, +AL8-e w tak pe+ALM-nym fleksji j+AOo-zyku jak polski, nie da si+AOo- podstawi+AOY- gotowych okre+AVM-le+APE-. Dlatego te+AL8- nasz+ALk- prac+AOo- nie +ALM-atwo jest wyprze+AOY- komputerami... Je+AVM-li odnosi si+AOo- to np. do przedsi+AOo-biorstwa, to mo+AL8-na by powiedzie+AOY-: ... wzrost warto+AVM-ci gospodarczej, odpowiednio przeinaczaj+ALk-c, np. ... wzrasta(j+ALk-cej) warto+AVM-ci .....itp., by odpowiednio umiejscowi+AOY- w kontek+AVM-cie. +AK8-ycz+AOo- powodzenia

Het lijkt een beetje op UTF-8, het heeft ook wel iets weg van Quoted Printable [met =E'hex. waarde'] maar leesbaar is het natuurlijk niet. En als je mailer geen UTF-7 aan kan?

Het voordeel van UTF-7 en UTF-8 is dat je niet meer hoeft stil te staan bij de diverse 8-bits codepages en rustig in je tekst zowel Hongaars als Albanees en Grieks kunt schrijven.

Aan de Atari kant is er tot op heden maar één programma dat UTF-8 kan produceren, maar daar staat tegenover dat geen enkel programma UTF-8 kan lezen...

De Tsjechische programmeur Petr Stehlik heeft uit een unix-omgeving een programma ge-port waarmee teksten van MS Word 8 [of 97/98] omgezet kunnen worden naar het HTML-formaat: MSWordView 5.1. Het 'nadeel' echter is wel dat alles omgezet wordt in UTF-8. Het voordeel is - zie boven - dat het 7 of 8-bits characterset onafhankelijk is. Ik heb Petr al geschreven en gevraagd of hij de 2/3 bytes UTF-8 codes niet kan omzetten [optioneel] naar de notatie 〹 Deze laatste notatie is namelijk goed leesbaar met Papyrus! Petr reageerde met de belofte dat hij het zal overwegen, maar tot nu toe heb ik nog geen nieuwe versie van MSWordView gezien.


In de Unicode mailing list brandde een discussie los over het niet meer geldig zijn van de UTF-7 codes. Natuurlijk zijn ze nog wel geldig alleen er is geen enkele noodzaak meer. Waar over het net nog met 7-bits werd gewerkt is dit in een snel tempo aan het veranderen. En hoe is dat zo gekomen? Heel simpel, of om de woorden van Markus Kuhn te gebruiken:

> Most [email MTA] environments are now 8-bit safe, and more are moving
> that way all of the time.

Agreed. In fact, I would go even further: there is NOT A SINGLE non-8-bit-transparent email message transfer agent connected the Internet today that does not also have a well-known security vulnerability. All the old sendmail etc. versions that caused the 7-bit transparency problems have also turned out to have severe security problems and they were very quickly replaced to stop hacking breakins. If you find still a 7-bit sendmail installed somewhere, I'd be happy to delete it from here ... ;-) Thanks to the many security-related updates of email software, both quoted-printable and utf-7 have become several orders of magnitude faster completely obsolete than the pessimists in the MIME committee believed would be possible. Internet email is 8-bit transparent today and both quoted-printable and utf-7 are obsolete. My special thanks to the Internet hacking community for killing this one so quickly.

Markus

> AFAIK sendmail still can not handle 0x80-0x9F bytes
> in headers. Though 8bit bytes in headers is not allowed by RFC's,
> it's widely accepted practice.

Agreed. And for headers, UTF-8 wrapped into base64 as you used it nicely in your message seems to be perfectly appropriate to me. No reason to introduce an extra hack such as UTF-7 that doesn't really fit into the MIME distinction between "charset" and "encoding". Size really does not matter much in headers, as we are only talking about single short lines here anyway and not about bulk text. (Actually, size doesn't even seem to matter in bulk text either: the difference between UTF-2 and UTF-4 is eaten up by compression, or even just Moore's law every 18 months. The bandwidth plague of the Internet today is multimedia content and not the comparatively tiny amount of plain text that is transmitted between the huge volumes of JPG data, RealAudio data, and blown-up zero-filled Word97 doc headers.)

UTF-7 is dead and is today only implemented by a few large vendors who's managers desperately have to find ways to keep their oversized programming teams busy and therefore prefer monstrous feature fetish over a careful simple-is-beautiful design. Nobody really needs UTF-7.

Markus

Kortom, dank zij de 'hackers' raken we van de 7-bits verlost en dankzij de 'multimedia' is het zuinigheidsargument tegen 16 [of meer] bits niet meer te hanteren.

Wie het niet met hem eens is kan terecht bij:

Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email mkuhn at acm.org
WWW


Copyright © Rein Bakhuizen van den Brink
Last updated on 26 december 2000

Home Unicode UTF_8 Tahoma en Lucida Sans Unicode