UB BRAUNSCHWEIG
Symbolfoto
  • Impressum
  • Startseite
  • allegro-C von A-Z
  • Druckversion


allegro-C Unicode-Unterstützung ab V23



Demo-Datenbank
This text in English

Was ist Unicode?

Wenn man auf dem Bildschirm ein Zeichen sieht, was steckt dann wirklich dahinter?

Zwei Dinge muß man dazu wissen:

  1. Computer können nur mit Zahlen umgehen, d.h. alles muß mit Zahlen verschlüsselt werden. Aber es ist noch schlimmer:
  2. Alles, was gespeichert wird, muß in Zahlen von 0 bis 255 verwandelt werden. Eine solche Zahl nennt man ein "Byte". In Wirklichkeit, ganz tief drinnen, besteht so eine Zahl aus 8 Nullen oder Einsen - deshalb gibt es nur 256 = 28 mögliche Byte-Werte.
Seit Anbeginn der ernsthaften Computerei gibt es die Gleichung Zeichen = Byte, oder besser gesagt, die Gewohnheit, für jedes Zeichen ein Byte zu benutzen. Nehmen wir den Buchstaben A. Der wird in heutigen Computern immer mit der Byte-Zahl 65 verschlüsselt, B ist 66, C ist 67 usw. bis 90 für Z. Und die Kleinbuchstaben? Dafür kann man nicht dieselben Zahlen nehmen, das ist klar. Für das a wird die 97 genommen, für das b die 98, c ist 99 usw. bis 122 für das z. Warum gerade diese Zahlen? Das ist eine schon recht alte Konvention, sie ist ein Teil des sog. Industriestandards, der meistens ASCII genannt wird (American Standard Code for Information Interchange). Diese Konvention schreibt vor, daß die normalen Buchstaben, Ziffern und Satzzeichen alle mit Zahlen zwischen 32 und 126 verschlüsselt werden.
Für den "oberen" Bereich, 128-255, gibt es keine international einheitliche Festlegung.

(Eine umfassende und sogar unterhaltsame Geschichte der Computer-Codierungen schrieb Tom Jennings.)

Hier ist die vollständige ASCII-Tabelle:

ASCII-Tabelle

Diese Tabelle, aber sonst so gut wie nichts, haben bis heute alle Computersysteme gemeinsam.
Man sieht: die deutschen Sonderbuchstaben (Umlaute und ß) gehören nicht zum Standard.

Der Industriestandard betrifft nur die Werte bis 126, wie oben zu sehen, wobei die Werte 0 bis 31 und 127 Steuerfunktionen haben, also nicht für "richtige" Zeichen zur Verfügung stehen (und wenn, dann ungenormt). Die Codes 13 und 10 z.B. stehen traditionell für "Wagenrücklauf" und "Zeilenvorschub" - das stammt aus der Zeit der mechanischen Endgeräte (z.B. Fernschreiber und Zeilendrucker), aber noch immer dienen diese Zeichen als Zeilentrenner in vielen Dateien. Das soll hier nicht vertieft werden. Nur soviel: UNIX verwendet nur die 10, Windows die Kombination 13 10, Mac nur die 13.
Die obere Hälfte der 256 Codes, also 128-255, wurde von den diversen Herstellern von Hard- und Software unterschiedlich und in etlichen nationalen Ausprägungen verwendet, z.B. haben DOS und Windows nicht dieselben Zeichensätze und -codes. Da ist z.B. das ä in DOS-Dateien mit 132 verschlüsselt, in Windows-Dateien aber mit 228. Mit einer Konkordanztabelle kann man diese Unterschiede ganz gut überwinden. Aber leider reichen 223 Werte (nach Abzug der unteren 32 und der 127!) beiweitem nicht aus, um alle Zeichen zu verschlüsseln, die in den verschiedenen Sprachen vorkommen, selbst wenn man sich auf diejenigen beschränkt, die mit lateinischen Buchstaben schreiben. Nimmt man Griechisch und Kyrillisch hinzu, sind es schon viel mehr, und die ostasiatischen Schriften kennen viele tausend Zeichen.

Als Ausweg aus dem Dilemma gilt seit einiger Zeit das System "Unicode", das von einer internationalen Körperschaft, dem "Unicode Consortium", erarbeitet wurde und betreut wird: http://www.unicode.org.

Wie wurde Unicode konstruiert?
Man ging zunächst einmal daran, noch ohne sich um Codes zu kümmern, einfach nur eine lange Liste sämtlicher Zeichen aufzustellen, die man zur Darstellung von Texten weltweit brauchen würde. Dabei kam man bis heute auf 95.221 Zeichen!

Man ordnete diese Zeichen dann sinnvoll in Gruppen, wobei an den Anfang die 128 Zeichen des ASCII-Codes gesetzt wurden, und zwar in derselben Reihenfolge. Dann numerierte man die Liste durch. Mit Bytes hat das noch nichts zu tun! Will man aber nun Texte speichern, die aus diesem Zeichenvorrat bestehen, dann muß man letztendlich doch alles irgendwie mit Hilfe von Bytes (mit je 8 Bit) ausdrücken – anders geht es nicht. Zwangsläufig muß man für jedes Zeichen zwei oder noch mehr Bytes verwenden - die alte Gleichung Zeichen=Byte ist untauglich.

Zum Verschlüsseln der vielen Nummern mit Hilfe von Bytes wurden verschiedene Möglichkeiten ersonnen:

1. Reine Unicode-Methode: Zwei Bytes für jedes Zeichen. Die Zeichen mit Nummern oberhalb von 65000 brauchen vier Bytes (bisher nutzt das aber niemand). Diese Codes werden oft in der Form U+nnnn angegeben, z.B. U+0041 für das A und U+20AC für das Euro-Zeichen €. (41 ist die hexadezimale Schreibweise von 65 (= 4x16 + 1), 20AC ist dezimal 8364.)
Nachteil: Alte, "ganz normale" Dateien ohne Sonderzeichen brauchen dadurch doppelt soviel Platz wie bisher.

2. Gemischte Methoden : Nur 1 Byte für die ASCII-Codes von 0 bis 127, mehr als eins für die anderen Zeichen.
Dazu gibt es zwei Varianten:

2a. Codierungen der Gestalt &#N; (sog. Entitäten, manchmal fälschlich UTF-7 genannt), N ist die Nummer des Zeichens: man nimmt also die Liste der Unicode-Nummern und speichert das Zeichen 128 als €, 129 als usw. Moderne Browser verstehen das und zeigen dann die korrekten Zeichen.
Das ä bekommt dabei den Wert ä, das Euro-Zeichen € hat € (=U+20AC) d.h. ein einzelnes Sonderzeichen wird mit 6 bis 8 Byte gespeichert. Programme, die damit umgehen, müssen immer auf die Kombination &# achten: diese leitet immer dann ein Sonderzeichen ein, wenn dahinter Ziffern stehen, beendet durch ein Semikolon. Wer will, kann die Nummern auch hexadezimal angeben, dann muß noch ein x davor. Der Euro kommt dann als € daher.
Für den Export in HTML-Dateien wird die Datei d-html4.apt bereitgestellt, die aus den OstWest-Codes die korrekten Entitäten macht.

2b. UTF-8 : Man stellt eine weitere Liste auf, wobei jeder Zahl jenseits 127 zwei Zahlen zugeordnet werden, die erste muß oberhalb 191, die zweite oberhalb 127 liegen. Das Zeichen 228 bekommt dabei dann die beiden Zahlen (195,164). So kann es in einer Datei, die ja immer aus lauter Byte-Zahlen besteht, keine Verwechslungen geben. Jedes Sonderzeichen wird auf diese Weise als 2 Byte gespeichert, einige Sonderzeichen (z.B. Euro = E2 82 AC) und alle ostasiatischen Zeichen bekommen 3 Bytes, darauf gehen wir hier nicht ein. Programme, die damit umgehen, müssen beachten, daß Codes oberhalb 191 immer mit dem nachfolgenden Code zusammen ein Zeichen bilden, Codes oberhalb 223 mit den zwei nachfolgenden Bytes. Die zweiten und dritten Bytes liegen immer zwischen 128 und 191.
Für den Export in HTML4- oder XML-Dateien wird die Datei d-utf8.apt bereitgestellt, die aus den OstWest-Codes die korrekten Byte-Zahlenpaare macht. Zum Errechnen dieser Werte für weitere Zeichen ist ein  JavaScript-Progrämmchen geeignet
.

Als Referenz gibt es eine Amtliche Liste , in der alle verschiedenen Codes stehen, die zu den Zeichen unseres OstWest-Repertoires gehören. Dieser bei allegro-Anwendern bewährte Zeichensatz umfaßt die am häufigsten vorkommenden ost- und westeuropäischen Buchstabenzeichen, es gibt eine Codeliste für Windows und eine kompatible für DOS.

Tip: Geben Sie in a99 den Befehl h chara  ein, dann sehen Sie die bisher intern verwendeten Codes.

Welche Methode ist die beste?

Das kommt auf die Daten an, die man zu verarbeiten hat. Bestehen diese überwiegend aus normalen Buchstaben, Ziffern und Satzzeichen, dann ist es Methode 2b. Hat man vorwiegend ostasiatische Zeichen, dann Methode 1.

Der Platzbedarf gilt heute nicht mehr als gravierend, es kommt aber auch auf die Probleme der Verarbeitung an. Methode 1 würde bedeuten, daß alle Programme auf 16bit-Zeichencodes umgestellt werden müßten und alle Dateien wären zu konvertieren, jede Daten- oder Indexdatei würde sich dabei in der Größe verdoppeln. Es ist jedoch wegen des hohen Programmieraufwands illusorisch, allegro auf diese Methode umzustellen. (In den Programmen wird mit vielen 8-bit-Zeichenkettenvariablen gearbeitet, und viele Funktionen gehen damit um. Dieses alles müßte umgestellt werden.)

Die Methode 2a hat dagegen entscheidende Vorzüge, denn besonders in Web-Anwendungen läßt sich damit am leichtesten arbeiten: die heutigen Browser können diese Verschlüsselungen sofort verstehen und umsetzen. Will man 2b anwenden, muß in allen HTML-Dateien die folgende Zeile im <head>-Bereich stehen:

<meta http-equiv="content-type" content="text/html; charset=UTF-8">

Dann werden aktuelle Browser die meisten Zeichen richtig anzeigen (Netscape 4.x nicht!), und zwar sowohl die Codierungen der Methode 2b wie auch 2a! Jedoch: wenn man mit einem HTML-Formular eine Eingabe speichert, d.h. zu einem Server abschickt, kommen Codes nach Methode 2b dort an. Wenn man auf der Seite des Servers wenig Arbeit haben will, sind also diese Codierungen von Vorteil.

Soll man aber tatsächlich künftig jedes ä in der Datenbank als &#228; speichern oder als (195,164)? Das wäre wenig erfreulich, auch weil das erstere deutlich mehr Bytes braucht als vorher: 6 statt einem für jeden Umlautbuchstaben. Schlimmer noch, weil es in beiden Fällen viel schwieriger ist, daraus für den Index wieder "ae" zu machen oder in der PRESTO- bzw. a99-Anzeige ein ä, zu schweigen vom Eingeben und Bearbeiten in diesen Programmen. Indexierung und Anzeige konnten dennoch sowohl für 2a wie 2b gelöst werden: siehe dazu "VS-Methode" bzw. "P/Q-Tabelle".

Eine Besonderheit muß noch erwähnt werden: Wenn man Buchstaben mit Akzenten braucht, die im normalen Vorrat nicht vorkommen, dann ist es im OstWest-Code so, daß man das diakritische Zeichen VOR den Buchstaben setzt. Unicode will es umgekehrt, wobei aber fast alle Kombinationen schon als Einzelzeichen definiert sind, sogar sehr viele Buchstaben mit zwei Diakritika!
 

Unicode aus bibliothekarischer Sicht
Im anglo-amerikanischen  Bibliothekswesen wurde natürlich schon längst über Unicode nachgedacht und geschrieben.  Eine kleine Abhandlung  von Joan Aliprand (Stanford) erschien 1999 zur IFLA-Konferenz in Bangkok und wurde auch auf Deutsch veröffentlicht.
 
 

Die zwei Varianten der Unicode-Anwendung in allegro-Datenbanken (ab V23.2)
Verfahren 1 : Interne Codes unverändert, zusätzliche Zeichen als "HTML4-Entitäten"
Verfahren 2 : Intern alles in UTF-8 codiert, was nicht Standard-ASCII ist

Verfahren 1
  • Alle bisherigen Codes des OstWest-Zeichensatzes bleiben innerhalb der Datenbank unverändert bestehen. Das gilt auch für akzentuierte Zeichen, die nicht als Einzelzeichen existieren: Diakritiscsehe Zeichen werden VOR die Buchstaben gesetzt. Es ändert sich somit intern nichts. Sogar die DOS-Programme bleiben verwendbar.
  • Bisher schon möglich: Weitere Zeichen, die man bislang nicht darstellen konnte, können nach Methode 2a codiert werden. (Methode 2b kann nicht verwendet werden, weil ja der OstWest-Satz viele Codes oberhalb 127 umfaßt! Bei Verfahren 2  ist das anders.) Zwar nicht komplett in a99, aber zumindest bei Web-Anwendungen können diese Zeichen dann korrekt angezeigt werden. Zur Unterstützung der Eingabe (Finden und Kopieren der Codierungen) kann z.B. ein besonderes Register verwendet werden oder auch eine ViewListe.
  • NEU: Eine neue Methodik, die der sog. "Verschlüsselungs-Sequenzen" (kurz VS-Methode) ermöglicht es, daß man die 2a-Codierungen brauchbar indexieren oder für sonstige Zwecke ausgeben kann: aus  &#193; (steht für Á) kann damit ein a oder A oder ´A gemacht werden. Die VS-Methode wird in Verlautbarung 164 beschrieben (h vb164 eingeben in a99).
  • Unicode spielt ansonsten nur bei der Kommunikation mit der Außenwelt eine Rolle: bei Export und Import. Dafür gibt es neue Funktionen.
Zum zweiten Punkt: Für die VS-Methode gibt es eine Datei vs.alg mit über 300 Sequenzen für akzentuierte Buchstaben und für die kyrillischen Zeichen. Diese kann man, geeignete Ergänzung der Indexparameter vorausgesetzt, in seine Datenbank einmischen. Siehe auch unten: "Eingabe-Unterstützung". In der Demo-Datenbank von V23: siehe als Beispiel Eintrag unter "zz unicode-testsatz" im Register 1.
Die PHP-Schnittstelle PHPAC ist ab 17.3.2003 auf Unicode umgestellt, funktioniert aber auch noch mit den normalen Codes.

Export

Schon mit den bisherigen Mitteln (p/q-Befehle) lassen sich sowohl "Entitäten" wie auch UTF-8-Codes erzeugen.
Empfehlung: die bereitgestellte Tabelle d-utf8.apt in Anzeige- oder Ausgabeparameter einbinden.
Das einzige Problem ist das der Akzente. Hierfür wurde ein Unterprogramm erstellt, das in gleicher Weise, nur umgekehrt, beim Import eingesetzt werden kann: es setzt das diakritische Zeichen jeweils hinter das nachfolgende Zeichen bzw. umgekehrt. Ausgeführt wird es innerhalb der Exportparameter mit #da  bzw.   #dA vorwärts bzw. rückwärts., im FLEX: dow a  bzw.  dow A   (Beispiel: edrec.php im PHPAC-System)
Das wirkt auf den gesamten Arbeitsspeicher + Hintergrundspeicher (#u-Variablen)!
Die Akzentliste muß in einer der Export-Parameterdateien hinterlegt sein, sie ist dann intern global. Der Standard sieht so aus (Liste aller DOS-Codes der diakritischen OstWest-Zeichen):

pa=181 182 183 184 189 190 198 199 207 208 209 210 211 212 219 222 223 232 

Empfehlung: Kopieren Sie diese Zeile in Ihre Indexparameter, dann gilt sie überall da, wo es drauf ankommt. Bei Verwendung in IMPORT.EXE: Einbau in die benutzten Exportparameter.
(In der Liste der DOS-Akzentcodes findet man die Bedeutung dieser Zahlen.)

Anzeigeparameter

Die heutigen Browser zeigen UTF-8-Codes korrekt an, d.h. hier ist angenehm wenig zu tun, es ist keine Umwandlungstabelle nötig. (PHPAC arbeitet in jedem Fall mit UTF-8, braucht deshalb für den OstWest-Code eine Tabelle: d-utf8.apt ).
In a99 muß man in die Anzeigeparameter die Datei  
du-rtf.apt einbinden, damit man wenigstens im Anzeigefeld z.B. echte kyrillische Zeichen zu sehen bekommt.
Darin stehen Zeilen wie
P 208 144 "\u1041?"    [0411] -- &#1041
womit das kyrillische Б in RTF codiert werden kann. Im Datensatz wird dadurch die Bytekombination 208 144 durch \u1041? ersetzt. Die 1041 ist dieselbe Zahl, die in der HTML4-Entität  &#1041;  auftritt.

Import

Damit man damit keine Probleme hat, sind folgende Vorkehrungen nötig:

  • Das genannte Unterprogramm, das die getrennt stehenden Akzentzeichen mit dem vorangehenden Zeichen vertauscht (rückwärts)
  • Ein Unterprogramm, das diejenigen UTF-8-Codes in einzelne Bytes verwandelt, die im OstWest-Zeichenvorrat vorkommen. (Das Umgekehrte kann die Exportsprache mit den p/q-Befehlen schon immer leisten, s.o.)
  • UTF-8-Codes, die keine Entsprechung im OstWest-Vorrat haben, werden durch ihre HTML4-Entität ersetzt.
Diese Dinge wurden für V23 programmiert, und zwar auch für die DOS-Programme. Folgendermaßen sind diese Funktionen zu nutzen:

Die umzuwandelnden UTF-Codes müssen in u-Befehlen stehen, ebenfalls in einer der verwendeten Export-Parameterdateien. (Empfehlung für a99: Indexparameterdatei, denn diese wird in jedem Fall geladen.) Diese u-Zeilen, es können bis zu 800 Stück sein, sehen so aus:


u 195 161 160
u 226 130 172 221
u 195 129 065 181
u 195 163 097 232
LATIN SMALL LETTER A WITH ACUTE á
EURO SIGN
LATIN CAPITAL LETTER A WITH ACUTE Á
LATIN SMALL LETTER A WITH TILDE ã
Die Namen rechts stehen nur als Kommentar da, sie haben keine Funktion.
Die allgemeine Struktur ist diese, alle Zahlen (3 bis 5 je Zeile) sind 3stellig dezimal anzugeben, genau 1 Leerzeichen dazwischen:

u zzz yyy xxx bbb aaa    Kommentar

zzz yyy xxx sind die dezimalen UTF-8-Codes des Zeichens. Wenn zzz<224 ist, dann fehlt xxx, was bedeutet, daß es sich um einen 2-Byte-UTF-8-Code handelt. 
Zum Ausrechnen dieser 3stelligen Zahlen steht ein JavaScript-Progrämmchen bereit. Man tippt nur die 2-Byte-Unicode-Hexzahl ein, z.B. 20ac, und erhält die UTF-8-Codes in Dezimal (nur diese werden gebraucht) und als Zugabe in Hex. Das Progrämmchen kann aber gleich einen ganzen Block von 256 Zeichen als Codeliste ausgeben, die man sich dann kopieren kann [funktioniert nur mit IE, nicht Netscape].
Achtung: Ab V23.2 kann man statt der Dezimalzahlen direkt die UTF-8-Zeichen hinschreiben, für bbb und aaa die DOS-Zeichen, jeweils ohne Blank dazwischen.

bbb ist der OstWest-DOS-Code, aaa wird nur angegeben, und muß dann einer der DOS-Akzentcodes sein (siehe oben im pa-Befehl), wenn auf allegro-Seite der akzentuierte Buchstabe als Einzelzeichen nicht existiert, wie z.B. Á und  ã.

Die u-Befehle werden nur für die Umwandlung von Fremddaten benutzt, nicht für den Export. Also i.d.R. beim Einlesen einer ADT-Datei, die in UTF-8 codiert ist, bzw. beim Übergeben von HTML-Formulardaten an den avanti-Server, oder auch im DOS-Konvertierprogramm IMPORT.EXE.

Im FLEX setzt man vor die Befehle zum Einlesen der Daten den Befehl  set U1 , dahinter set U0. Achtung: Das Vertauschen von Akzenten und Buchstaben erfolgt dabei automatisch im Anschluß an das Umwandeln der Codes (beim FLEX-Befehl insert) .
Beispiel: siehe  write.php im PHPAC-System.

Für das Programm IMPORT setzt man die u-Befehle in die dabei benutzten Exportparameter (!), dann passiert die Umwandlung ganz automatisch, und zwar jeweils beim Einordnen eines fertigen Datenfeldes in den entstehenden Datensatz. Außerdem gehört in die Exportparameter der Befehl #dA. Die Befehle in den Paragraphen der Importparameter "sehen" deshalb noch die nicht umgewandelten Daten!

Wir haben dank der Hilfe von Thomas Berger eine u-Liste von ca. 300 akzentuierten Buchstaben erstellt, die als Datei ucodes.txt mit V23 mitgeliefert wird. Berger hat auf seinem Server weitere empfehlenswerte Materialien und relevante Dokumentationen: weitere u-Codes findet man in mit Kommentar in einer Datei  uc-ow.cpt. Oder man benutzt das besagte Progrämmchen.

Nicht berücksichtigt sind Kombinationen von Buchstaben mit zwei Diakritika, deren es im Unicode durchaus etliche gibt. Solche werden also in die Entitäts-Darstellung verwandelt.
Generell werden Zeichen, die in der u-Liste nicht vorkommen, in die Entitätenform &#N; umgewandelt. Das Programm errechnet den Wert N aus dem UTF-Code. Man muß also z.B. für die kyrillischen oder griechischen Zeichen keine u-Zeilen bereitstellen, das muß man nur für solche Zeichen, denen man eine Entsprechung in seinem eigenen Codesystem zuordnen will (in der Regel also OstWest-Code).

Export

Wenn man "Entitäten" in den eigenen Daten (innerhalb der Datenbank also) verwenden will, sollte man die "Stammdatei" vs.alg zuerst einmischen. Damit diese Daten korrekt indexiert werden, muß man die entsprechenden Abschnitte aus cat.api in die eigenen Indexparameter übernehmen (darin Kommentar "V23").
In den betroffenen Exportparametern wäre dann zu setzen:
i6=10     Ersetzungsreg. ist Nr. 10
dx=1      Codierungen ausführen (wichtig bei Anzeigeparametern)
p & 9     Zeichen & ist zuständig für VS-Ersetzungen
ib=59     ; ist das Endezeichen der Entitäten

In den Exportparametern wird man normalerweise #dV  setzen (zu empfehlen in Indexparametern), dann werden alle Ersetzungen zu dem Zeitpunkt auf einmal ausgeführt, und nachfolgende Exportbefehle sehen nur noch die ersetzten Zeichen!
Der entsprechende FLEX-Befehl heißt  dow V . Dabei werden die VS-Ersetzungen genutzt, die in den Indexparametern stehen. Dort muß also u.a. der Befehl p & 9 vorkommen.

Export mit dem  Befehl "write ..."  ( in a99 und avanti)
Der FLEX- bzw. avanti-Befehl write ... wirkte bislang so, daß die Zeichenkette, die er produziert, unverändert in die Ausgabedatei geschrieben wird. Daher konnte man mit "write" keine Umcodierung vornehmen, das ging nur über die Exportfunktion "download", weil dabei eine Parameterdatei zum Einsatz kommt. Deshalb wurde
write so erweitert, daß dabei eine automatische Umcodierung erfolgen kann. Man muß nur zwei Dinge tun:

1. in die benutzten Exportparameter diesen Abschnitt einbauen:

zl=0       kein Zeilenumbruch
dx=1       damit Umcodierung ausgefuehrt wird
td-utf8    Tabelle d-utf8.apt laden
#-X        Sprungmarke
#u1        die von write erzeugte Zeichenkette ausgeben
#+#        Ende

2. Im FLEX vor dem "write"-Befehl diese Befehle einbauen
dow wX     Abschnitt #-X in den Exportparametern aktivieren
dow a      Akzente verschieben
write ...
write ...
dow A      Akzente zurück (nur nötig, wenn der Satz anschließend gespeichert werden soll.

Hinweis: Ab V27.2 kann man parametrierte Umcodierungen in FLEX auch mit dem Befehl xcode ausführen.


Kompromiß

Es gibt Zeichen, wie z.B. Á und ã, die in Unicode als Einzelzeichen existieren, in OstWest aber nicht. In einer allegro-Datenbank werden sie traditionell als ´A bzw. ~a eingegeben und gespeichert. Beim UTF-8-Export werden diese nicht zusammengefaßt, sondern es werden zwei Zeichen daraus: Buchstabe+Akzent, also umgekehrt. Dies ist in der Unicode-Welt eine korrekte Alternativ-Darstellung, aber besser wäre natürlich der Export in der Form des korrekten Einzelzeichens. Wenn andererseits die Eingabe über ein Web-Formular erfolgt, können dort zwar die Einzelzeichen eingegeben werden, aber was in der Datenbank ankommt (Anwendung der u-Befehle!) , ist die Kombination Akzent+Buchstabe, nicht die "Entitäts-Darstellung" des kombinierten Zeichen. Wichtig ist das deswegen, weil damit ganz leicht die korrekte Indexierung in der Datenbank möglich ist: dabei wird einfach der Akzent weggelassen, aus Á und ã wird a. (Im Index würden Akzente die Sortierung stören, deshalb müssen sie  wegfallen!) In einer Unicode-Datei kann ferner auch ein Buchstabe mit zwei nachfolgenden Diakritika vorkommen. Dies wird korrekt behandelt: in der allegro-Datei kommen beide vor dem Buchstaben an, das Akzentvertauschungs-Unterprogramm regelt das in beiden Richtungen.

Eingabe-Unterstützung für Verfahren 1

Die VS-Stammsätze dienen zugleich dazu, Indexeinträge bereitzustellen, die man zum Suchen und Übernehmen der "Entitäten" verwenden kann. Im Übernahme-Register steht dann z.B. unter u diese Liste:
     u a BREVE+ACUTE _&#7855;
     u a BREVE+DOT BELOW _&#7863;
     u a BREVE+GRAVE _&#7857;
     u a BREVE+TILDE _&#7861;
     u a CARON _&#462;
     u a CIRC+ACUTE _&#7845;
     u a CIRC+DOT BELOW _&#7853;
     u a CIRC+GRAVE _&#7847;
     u a CIRC+TILDE _&#7851;
     u a DOT ABOVE _&#551;
     u a DOT ABOVE+MACRON _&#481;
     u a DOT BELOW _&#7841;
     u a MACRON _&#257;
     u a RING ABOVE+ACUTE _&#507;
     u a TILDE _&#227;
     u a TREMA+MACRON _&#479;
     u ae ACUTE _&#509;
     u ae MACRON _&#483;
     u b DOT ABOVE _&#7683;
     u b DOT BELOW _&#7685;

     u kyr B _&#1041;   nur als Beispiel: kyrillischer Großbuchstabe
Б

Man gibt z.B.  "u a"  ein, wenn man ein a mit irgendeinem Akzent sucht. Dann erscheint diese Liste. Balken auf die richtige Zeile setzen, den Button [Kopie] drücken (Alt+k) - die Sequenz wird in die Eingabe kopiert.

Man gibt z.B. "kyr a" ein, um zu dem Abschnitt der kyrillischen Kleinbuchstaben zu kommen.

In die Standard-Parameter cat.api sind die nötigen Zusätze eingebaut, kommentiert mit "V23", damit man sie leicht findet und in andere Indexparameter übernehmen kann.

Verfahren  2

  • Alle bisherigen Codes oberhalb 127 des OstWest-Zeichensatzes müssen in UTF-8 umcodiert werden (Methode 2b). Dazu gibt es eine Parameterdatei i-1u.apr, die das automatisch durchführt, incl. Akzentvertauschung. 
  • Das Bearbeiten unter DOS und Windows wird dadurch leider erschwert, denn sogar die Umlaute sind nicht mehr direkt erkennbar.
  • In a99 kann man jedoch mit dem FLEX utf8edit.flx einen Datensatz extern bearbeiten, und zwar im Unicode-fähigen NotePad.
    Dazu eingeben: X utf8edit, oder diesen FLEX auf einen der Flip-Buttons legen.
  • Kein Unterschied zu Verfahren 1 bei der Web-Formularbearbeitung.
  • Günstiger im Platzbedarf als Verfahren 1 nur dann, wenn man einen hohen Anteil von nichtlateinischen Zeichen hat, etwa Kyrillisch oder Griechisch.
  • Wenn Eingabe und Bearbeitung ausschließlich per Web-Formular erfolgen sollen, ist dieses Verfahren vorzuziehen, weil man sich um die DOS- und Windows-Codes nicht mehr kümmern muß.
  • Codierungen nach Methode 2a können zwar neben UTF-8 verwendet werden, sehr sinnvoll ist das jedoch nicht.

Für das Umwandeln von UTF-8-Codes in Entitätenzahlen für RTF- oder HTML-Dateien gibt es ab V29.3 einen FLEX-Befehl 

xcode U...     (Geben Sie in a99 ein  h xcode)

Dabei kommen intern einige einfache Formeln zum Einsatz, die im Anhang dokumentiert sind.

Web-Schnittstelle (für beide Verfahren gültig)
Zum Eingeben in einem Web-Formular, z.B. bei PHPAC, und auch in NotePad und anderen Windows-Programmen kann man das MS-Programm CHARMAP verwenden. Das sieht z.B. so aus:

Hilfsprogramm charmap

Dies ist die XP-Version! Unter NT und '98 gibt es erheblich weniger Möglichkeiten.

Tip: Es gibt eine TTF-Schrift namens MS Arial Unicode, die eine größere Menge von außereuopäischen Schriften umfaßt als die normalen TTF-Schriften.

 
Anhang  : Umrechnung  UTF-8 -> Dezimal-Entitätencode E
Normalerweise machen Programmierer das mit geschickten Bitmanipulationen, weil die intern schneller gehen. Z.B. bedeutet "-128" dann soviel wie das Wegnehmen des siebten Bits, und "*64" ist ein Verschieben um 6 Bit nach links. Hier wird statt dessen gezeigt, wie man es in anschaulich schlichter (dafür intern viel langsamerer) Weise mit Dezimalzahlen machen kann.

Situation: Bei zeichenweiser Abarbeitung eines Unicode-Textes von links nach rechts trifft man plötzlich auf einen Code a >193, dann:
  
Wenn   a>193 und a<224           U+0080 - 07ff
Dann ist  127 < E < 2048               128 - 2047 

  Mit dem auf a folgenden Zeichen b zusammen ergibt sich:
     (Wert b ist stets >127 und <192)
 +--------------------------------+
 |  E = (a-196)*64 + b-128 + 256  |
 +--------------------------------+
      und damit RTF:  \uE?  bzw,  HTML4: &#E;

Beispiele:
Die niedrigste Entitätenzahl ist 128
          a   b

         194 128
E= (194-196)*64 +(128-128) +256  =   128 = U+0080

Die höchste der zweistelligen UTF-Codes ist 2047:
          a   b
         223 191
E= (223-196)*64 +(191-128) +256  =  2047 = U+07ff
 
Das gilt nur bis  a=223. Danach kommen die 3-Byte-Codes:

Wenn  223 < a < 240    ( ab U+0800  )
Dann ist   2047 < E < 65536

Man nimmt dann die ZWEI auf  a  folgenden Codes  b, c,
  wobei  127 < b,c < 224  gelten muß.

          a   b   c 
         224 160 128   bis   239 191 191    0800 - ffff
          e0  a0  80          ef  bf  bf    2048 - 65535

  E = (a-224)*4096 +(b-128)*64 +(c-128)
         0            32           0     = 2048

z.B. Euro-Zeichen:
     226 130 172                U+20ac 
    2*4096 + 2*64 + (172-128) =  8364

Hilfreiche Adresse:
  http://titus.uni-frankfurt.de/indexd.htm?/unicode/unitest.htm


Umgekehrte Rechnung: Entitätenzahl -> UTF-8

Gegeben ist eine Dezimalzahl E
Im folgenden wird beim Dividieren stets nur der ganzzahlige Teil genommen, mit % wird der Divisionsrest gebildet:

1. Fall
127 < E < 256:

   a = (E-256-63)/64 + 196
   b = E%64 + 128 (Divisionsrest)

2. Fall
127 < E < 2048:

   a = (E-256)/64 + 196
   b = (E-256)%64 + 128 (Divisionsrest)

3. Fall
2047 < E < 65536

   a = E/4096+224
   b = (E-(a-224)*4096)/64 +128
   c = (E-(a-224)*4096-(b-128)*64)+128

z.B. E = 8364:
   a = E/4096 +224 = 2 + 224                     = 226

   b = (E-2*4096)/64 +128 = 172/64 +128 = 2 +128 = 130

   c = (E-2*4096 -2*64) +128 = 44 + 128          = 172

(1) Jennings, Tom: ASCII: American Standard Code for Information Infiltration. 2001

[i] zuletzt aktualisiert: 02.05.2011
Email: ub@tu-bs.de