Demo-Datenbank

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

Zwei Dinge muss man dazu wissen:

1. Computer können nur mit Zahlen umgehen, d.h. alles muss mit Zahlen verschlüsselt werden. Aber es ist noch schlimmer:
2. Alles, was gespeichert wird, muss 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 = 2⁸ mögliche Byte-Werte.

Hier ist die vollständige 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 muss man letztendlich doch alles irgendwie mit Hilfe von Bytes (mit je 8 Bit) ausdrücken – anders geht es nicht. Zwangsläufig muss 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:

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, dass alle Programme auf 16bit-Zeichencodes umgestellt werden müssten 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üsste umgestellt werden.)

Die Methode 2a hat dagegen entscheidende Vorzüge, denn besonders in Web-Anwendungen lässt sich damit am leichtesten arbeiten: die heutigen Browser können diese Verschlüsselungen sofort verstehen und umsetzen. Will man 2b anwenden, muss 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 muss noch erwähnt werden: Wenn man Buchstaben mit Akzenten braucht, die im normalen Vorrat nicht vorkommen, dann ist es im OstWest-Code so, dass 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

• 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 umfasst! 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, dass 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.

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 muss 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

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.

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, dass 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 muss 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 Anschluss 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 muss also z.B. für die kyrillischen oder griechischen Zeichen keine u-Zeilen bereitstellen, das muss 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, muss 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 muss 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, dass 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, dass dabei eine automatische Umcodierung erfolgen kann. Man muss 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.

Kompromiss
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 zusammengefasst, 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. "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 muss.
• 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:

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