unicode

[Thomas Berger]

Teschke wrote:


> > Es hat also gar keinen Sinn, hier bereits irgendwelchen Optimismus zu
> > verbreiten.
> 
> Vielen Dank für die Klarheit dieser Auskunft.
> 
> > Koennen Sie uns Beispieldaten zukommen lassen? Vielleicht muss ja nur die
> > Methodik der Anwendung der o-Tabelle modifiziert werden, wie es ja
> > schon bei den p- und q-Befehlen einwandfrei funktioniert. Ist es nicht so:
> > wenn ein Code oberhalb 160 vorkommt, bildet er zusammen mit dem naechsten
> > Byte ein chinesisches Zeichen? Oder muessen zwei aufeinanderfolgende Bytes
> > oberhalb 160 liegen, um chinesisch interpretiert zu werden (sonst wuerden
> > ja die Umlautcodes sowieso nicht funktionieren - oder wie sind die wirklich
> > dann codiert?)
> 
> Ersteres trifft zu: Zum Beispiel die ASCII-Kodes 105, 225 und 116 zuerst mit
> ASCII in isstdt.jpg, und dann mit den Zeichensatz Big-5 in der angefügten
> Grafik isstch.jpg.
> Das zweite Zeichen hat einen Kode>160, also bildet es zusammen mit dem nächsten
> ein Schriftzeichen. Der Kodebereich für das erste Byte ist in Big-5 161-254,
> für das zweite 64-126 und 161-254.

Vor allem mit Blick auf WWW-Anwendungen denke ich, sollte
Allegro mittelfristig in die Lage gesetzt werden, UTF-8 
(Unicode)-Zeichen zu generieren. Dies sollte mit einer 
moderaten Umarbeitung der Ersetzungsmoeglichkeiten realisierbar
sein.

Auch jetzt ist es ja schon so, dass man (etwa fuer HTML- oder
RTF-Exporte nach ISO 8859) gewisse OSTWEST-Kombinationen aus
(Protyp-) Diaktritikum und Grundbuchstaben kombinieren koennte
(aus Sicht des Zielzeichensatzes), aber das entsprechende
Sprachkonstrukt (etwa Protyp-Ersetzungsbefehle wie sie
die Importsprache kennt) in der Exportsprache nicht vorhanden
sind. Ich behelfe mich in diesem Fall mit einer globalen
Ersetzung auf ein Hilfszeichen, das Hilfszeichen wird dann
durch die p-Tabelle umgesetzt. Damit kommt man bei 8-bittigen
Zeichensaetzen ziemlich weit, weil ISO 8859 etwa 32 unbesetzte
Zeichenpositionen hat...

Ich koennte mir vorstellen, dass in die Exportsprache eingebaut
werden koennte:

1) ein Laengenreservierungsbefehl fuer Protypen
   also eine Deklaration "das Zeichen ist Protyp, ein
   (bzw. n) nachfolgende Zeichen sind dazuzuziehen und
   duerfen nicht umcodiert werden

2) Protypabhaengige Ersetzungsbefehle die fuer jeweils
   eine Kombination eine Zielkombination angeben
   (also etwa "°a" -> "å"

Dies sollte Speicherplatzneutral sein, falls man keine
der Ersetzungen unter 2) in seine Parameter einbaut.

Unter 1) wuerde ich eine Reservierung von mehreren 
Zeichen vorschlagen, da man damit u.U. in der Lage
ist, in der Datenbank selber UTF-8-Zeichen abzulegen:
Mit dieser Transformation verhaelt es sich ja so,
dass alle Zeichen von 0-127 fuer sich selber stehen,
alle Zeichen von 192-223  von genau einem Zeichen gefolgt werden
alle Zeichen von 224-239  von genau zwei
alle Zeichen von 240-247  von genau drei
alle Zeichen von 248-251  von genau vier
alle Zeichen von 252-253  von genau fuenf

(254 und 254 sind illegal, Zeichen von 128-191 sind stets
Folgezeichen).

Diese "Vorsicht" birgt aber noch keine Loesung fuer
akzentuierte Buchstaben mit sich: Ein Z mit Hacek
z.B. ist in Unicode natuerlich ein kombiniertes
Zeichen, das aber auch (fuer Vergleichszwecke) als
Z gefolgt von (nonspacing) Hacek notiert werden kann
(generell folgen in Unicode die Modifier dem Grundbuchstaben,
anders als man es in der Bibliothekswelt gewoehnt ist).
Im Allegro-Ostwest-Zeichensatz hat man analog die
beiden Moeglichkeiten, das kombinierte Zeichen oder
Hacek gefolgt von Z einzeln zu erfassen. Der ISO 5426
Zeichensatz von MAB erlaubt wiederum nur letzteres,
die (noch nicht verabschiedeten) Spezifikationen 
fuer XML sehen m.W. vor, moeglichst nur die kombinierten
Zeichen zu erfassen.

Denkbar waere eventuell, dass Allegro bei der Eingabe
von Unicode-Zeichen eine Dekomposition vornimmt und
eine Transformation nach UTF-8, so dass fuer den 
Index und Sortierzwecke die Grundbuchstaben stets
klar erkennbar sind (und auch die Akzente als solche).
Fuer die Anzeige und Exporte koennten diese Daten
wohl meistens 1:1 ausgegeben werden (bzw. auch
einfach in 8-bittige Zeichensaetze uebertragen mit
den oben geschilderten Mechanismen) und nur selten
muesste ein nachgeschaltetes Programm die kombinierte
Form wiederherstellen. Am Problematischsten hierbei
ist wohl nur, den Uebergang zwischen der Praefix-
Notation bei bibliothekarischen Daten und der
Postfix-Notation fuer unicode-faehige Software
herzustellen.

Inwieweit das den "Kinesern" huelfe, ueberblicke ich
leider ueberhaupt nicht.

Insgesamt aber ist alles hierfuer noch etwas frueh:
Die neueren Browser koennen zwar alle UTF-8, also
Unicode, auch das Abspeichern der Quelle aus dem
(impliziten Notepad) funktioniert.
(Unicode anchecken). Mein Wordpad unter Windows NT
meldet mir dann aber sogleich: "Diese Version von
Wordpad unterstuetzt kein Unicode, bitte benutzen
Sie notepad). Anhand der Beschreibung in der
RTF-Spezifikation 1.6 (nur als HTML-Dokument online)
ist es mir gelungen, ein Unicode-aehnliches Dokument
zu erzeugen, das unter WordView 97 vernuenftig
angezeigt wird, nicht jedoch mit WordPad (NT,
neuestes ServicePack), das ja bekanntlich auf
dem Stand unterhalb von Word 6.0 stehengeblieben
ist. Die Unicode-Unterstuetzung in RTF sieht
zudem so aus, dass man die Codes zeichenweise als 
vorzeichenbehaftete(!) Dezimalzahlen ausrechnen 
und einzeln ins Dokument eintragen muss. Kann 
natuerlich sein, dass der ganze RTF-Weg sowieso
eine Sackgasse ist.

Fazit also: Ausser in Webbrowsern gibt es derzeit
wenig sinnvolle Darstellungsmoeglichkeiten fuer
Unicode.

viele Gruesse
Thomas Berger