allegro und UNICODE   
   
Allgemeines   
Auf dem allegro-Webserver befindet sich eine `allgemeine Darstellung` zum Thema Unicode. Als Einstieg in das Thema sollte man diese zuerst lesen. Darin wird auch erklärt, was bei der Web-Anbindung zu beachten ist. Wichtig ist Unicode auch in Verbindung mit `XML`.
Hier soll es nur um die Frage gehen, wie man seine Datenbank befähigt, mit Unicode umzugehen.  
Es gibt dazu zwei Verfahren. 

`Verfahren 1:` Die bisherigen Daten bleiben unverändert, es wird nur die Möglichkeit geschaffen, weitere Sonderzeichen zu verwenden. Diese müssen allerdings in Form der HTML4-Entitäten-Codes erfaßt werden. 
Beispiel: &#193; für das A mit Akut (Á), das man sonst nur in der Form ´A eingeben kann. 
Für viele dieser Codes gibt es Stammsätze, die man als Erfassungshilfe benutzen kann. Diese werden mitgeliefert in der Datei vs.alg. Man holt sie über "Datei / Weitere Offline-Datei laden" in den Offline-Speicher und speichert sie dann mit "Datei / Offline-Datei -> Datenbank" in die eigene CAT-Datenbank. (Oder: unten Punkt 4.) Wer hauptsächlich mit DOS (PRESTO) oder Windows (a99) arbeitet, ist hiermit besser bedient. 

`Verfahren 2:` Man codiert die Daten um nach UTF-8 (Parameter dafür werden mitgeliefert). Wenn man nur über Web arbeiten will (`PHPAC`), ist dies das einfachere Verfahren. Wer aber PRESTO und/oder a99 noch braucht, kann hiermit weniger gut arbeiten. Für a99 besteht immerhin die Möglichkeit, Datensätze mit dem Programm Notepad zu bearbeiten und dabei alle verfügbaren UTF-8-Codes zu nutzen. Dafür gibt es den FLEX utf8edit.flx, siehe `Vb.168`. 
Ein anderes Verfahren zum Bearbeiten von Sätzen ist die Benutzung von `JanaS`. Als Beispiel suchen Sie sich einen Satz, den Sie bearbeiten wollen, und dann geben Sie mal ein: 
X htmform 
Der FLEX  htmform.flx  produziert ein HTML-Formular mit ausgewählten Daten und übergibt es an JanaS. Von dort werden die Inhalte an a99 zurückgeliefert über den FLEX  jax.flx (den man nicht verändern muß). Leicht kann man sich weitere solche Formulare gestalten, mit allen Freiheiten von HTML. 

Tip 1: Mit dem FLEX  `utf-ent.flx`  kann man UTF-Codes in dezimale Entitätenzahlen umrechnen und umgekehrt.

Tip 2: Wenn man eine RTF-Datei mit {\urtf1 beginnt statt mit {\rtf1, dann können im RTF-Text auch Unicode-Zeichen in der UTF-8-Codierung stehen und a99 wird sie "richtig" anzeigen.

In beiden Fällen sind als Minimum Eingriffe nötig in Anzeige- und Indexparameter. Darüber hinaus in alle möglicherweise betroffenen Export-Parameter. Es handelt sich jedoch fast nur um den Einbau von vorbereiteten Tabellen. 

Welche Dateien werden gebraucht, wo muß man eingreifen?   

Verfahren  1
Index-Parameter   
Hier können Sie als Beispiel die Datei  cat.api  nehmen, die auf dem Verzeichnis DEMO2 Ihrer Installation liegt. Die Zeilen, auf die es ankommt, sind kommentiert mit V23.   
   
Die wichtigen Punkte sind diese:   

1. Liste der Diakritika-Codes (Befehl pa): 
  Wenn intern ASCII:
pa=181 182 183 184 189 190 198 199 207 208 209 210 211 212 219 222 223 232   
  bzw. intern ANSI:
pa=180 145 136 149 168 166 227 179 186 175 215 171 184 191 161 173 247 150 
  
ib=59       für Sequenzen-Ersetzungen (Endecode = Semikolon = 59)  (seit V23, siehe h`vb164`)
   
2. Codes für Sonderzeichen Entitäten  
Punkte 2-5 nur nötig, wenn man in der eigenen Datenbank Codes der Form &#nnn; für solche Zeichen verwenden will, die nicht im OstWest-Code vorkommen. (Siehe Demo-Datenbank unter "zz unicode...".)  
Im Abschnitt für die Kurzanzeige (meistens unter der Sprungmarke #-0)   
...   
#bp & 9    wegen V23 Unicode   
#bq & 9   
#dV        V23: VS-Ersetzungen im gesamten Satz   
...   
   
3.   
Abschnitt für die Indexierung der VS-Datensätze: (neuer Abschnitt beginnt mit #9AU)   
#9A +#9AU y0 i4,U e"¶" p"|;SYS"       UNICODE VS-Saetze   V   
...   
#9AU
#9A f"U" =vs e0   
#-ó   
#uvs e"¶" e":" y0 p{ 8 "|:" }   
#uvs e"¶" b":" y0 p{ 8 "|:u " }       Eintrag unter u im Reg. 10   
#uvs e"¶" e":" y0 p" _" e";" P";"   
#uvs +ó b"¶" =vs   
#+#   
   
Wenn Sie nicht Reg.10 für die V14-Ersetzungen verwenden, sondern z.B. 9, dann |9 einsetzen statt |: .   
   
4.   
Dann die Datei vs.alg mit den Sequenz-Definitionssätzen in die eigene Datenbank einmischen (oben schon kurz erklärt):   
Wenn Sie nicht $A.CFG, sondern eine Konfiguration x.cfg verwenden: zuerst vs.alg umbenennen in vs.xlg 
Wenn Ihre CFG 3-stellig ist: vs.xlg ändern, und zwar aus 9A eine dreistellige Kategorienummer machen, die in Ihrem System ansonsten nicht verwendet wird, aber diese Nummer muß in Ihrer CFG deklariert sein.   
z.B. #9AV   In Ihre x.cfg dann eintragen:   
  
#9AV"VS-Sequenzen"   
  
am Ende der Deskriptorenliste (das sind die Zeilen, die mit # beginnen).  Der Indexparameter-Abschnitt (s. oben) muß dann 9AV statt 9A enthalten!   
Das Einmischen der Sequenz-Datensätze geht dann mit:  
   
upd -fm01 -d<datenverz.> -bcat -uvs.alg -n248 -kx -F   
   
(Normal also -kA statt -kx). Danach sind im Reg. 10 die Einträge für die Sonderzeichen unter & zu finden.   
   
5. u-Liste an die Indexparameter anhängen  
Nur nötig, wenn Fremddaten mit UTF-8-Codes eingelesen oder importiert werden sollen, oder auch wenn man per Web-Schnittstelle Daten eingibt oder bearbeitet (denn der Webserver übergibt dann UTF-8-Codes). Das gilt auch, wenn man mit JanaS Daten in HTML-Formularen bearbeitet.
An das Ende der Indexparameterdatei fügt man die Liste `ucodes.apt` an:   

Entweder einfach diesen Befehl anfügen  (dann Kopieren auf ucodes.xpt, wenn Sie x.CFG verwenden.) 
tucodes   
oder die Datei selber hinten anhängen. Sie beginnt so:   
   
      V23: u-Befehle nur für a99 bei Einlesen von Fremddaten   
      und für avanti bei Schreibfunktion   
u 000           macht schon vorhandene u-Befehle ungültig!   
u 194 163 156        POUND SIGN   
u 194 164 216        CURRENCY SIGN   
u 194 167 021        SECTION SIGN   
   bedeutet: Codefolge 194 167 in den Eingabedaten ersetzen durch Code 21
...   
Diese Liste muß ebenfalls angehängt werden an die Exportparameter (!), die man bei einer Konvertierung von UTF-8 nach OstWest-Code einsetzt. In dieselben Exportparameter setzt man den Befehl  
#dA  
zur Vertauschung der Akzentcodes der eingelesenen Daten.  
Sonderfall: Wenn die dritte Zahl die 1 ist, wird das Zeichen weggelassen. Beispiel:
u 205 143 001        COMBINING GRAPHEME JOINER
   
Anzeige-Parameter für a99   
Vorlage hierfür: d-wrtf.apr  oder  d-krtf.apr + d-k.apt (auf Ihrem allegro-Verzeichnis)   
Ebenfalls kommentiert mit "V23".   
Im einzelnen ist folgendes zu tun:   
   
i6=10         Ersetzungsregister ist Nr. 10 (falls das noch nicht drinsteht)   
   
  Am Anfang der Kategorieliste, vor der ersten auszugebenden Kategorie, diese Zeilen:   
#bib=59       59 = ; ist der Endecode der Zeichensequenzen ( &#nnn; )   
#bp & 9       V23 Ersetzungen einschalten   
#dV           Ersetzungen der Sequenzen im gesamten Satz ausführen   
   
Im Abschnitt für die Internanzeige, meistens unter Sprungmarke  #-(     
#bp & &       V23-Ersetzungen gelten in diesem Abschnitt nicht   

Exportparameter   
In andere Exportparameter muß man nur einsetzen:   
tad-utf   
   um die Tabelle ad-utf.apt zu laden.    
  Machen Sie davon eine Kopie  ad-utf.xpt, wenn Sie nicht a.cfg verwenden.   
Ansonsten nur diese Zeilen einsetzen:   
   
p & 9   
q & 9   
ib=59   
   
wenn die Sequenz-Ersetzungen ausgeführt werden sollen.   

Und an den Anfang der Ausgabebefehle (die mit # oder ! beginnenden Zeilen) setzt man 
#da
Dann werden die Diakritika (Akzentzeichen) hinter die Buchstaben gesetzt, wie es Unicode will.  

Import von Unicode-Daten mit FLEX
Wenn man per FLEX fremde Daten aus Dateien oder aus dem Internet einlesen will, und diese Daten sind in UTF-8 codiert, kann man sie auf einfache Weise in den eigenen Interncode umwandeln. Sagen wir, es wird mit  read  aus einer Datei gelesen, und die gelesene Zeile soll jeweils in eine Variable  #uyx. Dazu reicht: 
... 
read 
xcode u 
export A 
ins #uyx
... 

   
FLEXe : Befehl "write"   
Vorbereitung:   
  a) Bereitstellen einer Parameterdatei p-unicode.xpr   
      Das kann eine Kopie von p-unicode.apr sein. Wichtig ist nur:    
      es muß einen Abschnitt #-X zum Erzeugen der Ausgabe geben.   
      In diesem Abschnitt muß die Variable #u1 verwendet werden.   
  b) Laden und Aktivieren dieser Parameter im FLEX mittels Befehl   
      export p p-unicode  Lade p-unicode.apr   
      export wX           Aktiviere darin Abschn. #-X
      export a            Akzentzeichen mit den nachfolgenden Buchstaben vertauschen 
  Alternativ: wenn ohnehin eine Export-Parameterdatei benutzt wird, 
  kann man auch den Abschnitt #-X darin einbetten. 
  Mit  exp wa  kann man JEDEN Abschnitt #-a zum write-Abschnitt erklären, nicht nur #-X.   
  Mit  exp w0  schaltet man die Funktion wieder ab. Die Schaltung   
  gilt nur für die Dauer des FLEXes, bei jedem Start eines FLEXes ist sie abgeschaltet.   

Mit diesen Vorbereitungen läuft's dann so:   
Befehl  write  produziert zuerst einen Arbeitstext. Erst wenn die  write-Zeile zu Ende ist, wird der Arbeitstext als Variable  #u1 an die Parameterdatei übergeben. 
Das Einfachste ist, den Abschnitt  #-X  so zu schreiben:   
   
#-X   
#u1   
#+#   
tad-utf     dieser Befehl kann auch woanders stehen   
   tad-aw       wenn statt dessen Output im Windows-Code entstehen soll   
   
Dadurch wird der Arbeitstext mit der Tabelle  ad-utf.apt umgewandelt.   
Alternativ kann man  ad-htm.apt  nehmen, darin kommen Entitätenzahlen zum Einsatz.
Im Prinzip aber kann jede beliebige Umwandlung vorgenommen werden, die mit der Exportsprache möglich ist.   
Ferner ist es möglich, unterschiedliche Abschnitte vorzubereiten und dann mit dem Befehl  exp wa  mal diesen, mal jenen einzuschalten, im Extremfall für jeden write-Befehl einen anderen.   
Im FLEX sollte man, wenn es wirklich um Unicode geht, außerdem VOR den write-Befehlen  dow a  sagen und hinterher  dow A, um die Akzentvertauschung einzubeziehen.   
Wir haben eine Parameterdatei  p-unicod.apr  als Muster vorbereitet, ferner die PHP-Dateien  ask.htm und show.php. Letztere ist zugleich ein Muster für eine minimale PHP-Datei, in der man sehen kann, aus was so eine Datei bestehen muß. Man kann sie als Startbeispiel nehmen, wenn man mit PHP beginnen will!   

Verfahren  2
Das Paket  demou.zip  enthält die nötigen Parameterdateien. Zum Teil sind das Varianten der Standarddateien. Folgende Schritte sind zu tun: 

Vorbereitung: Daten exportieren mit den Parametern  i-1u.apr. Dazu gehört die Tabelle ad-utf.apt. Beide kann man für andere Kategoriesysteme x.CFG übernehmen: einfach umkopieren auf i-1u.xpr bzw. ad-utf.xpt. Dann die gesamte Datenbank damit exportieren in eine "Grunddatei" (Typ .xLG). Diese muß dann neu indexiert werden, aber vorher muß man die Index-Parameter vorbereiten: 

Konfiguration [$a.cfg]
Einziger Unterschied: Zeile  N96  (`) statt  N170 (¬) für das Nichtsortierzeichen. 

Index-Parameter [cat.api]
1. Statt i.apt die Datei iu.apt einbinden (bzw. Kopie iu.xpt); also Befehl  tiu  statt  ti . 
Der wichtigste Teil in  iu.apt  ist die Tabelle der Zuordnungen UTF-8 -> ASCII (P/Q-Befehle, s.u. bei Export) 
2. o.apt aus dem DEMOU-Paket nehmen (enthält nur wenige Zuordnungen von Sonderzeichen) 
3. In der  cat.api  der DemoBank sind am Ende einige wenige u-Befehle, die man übernehmen muß, wenn eine Web-Datenbank einzurichten ist. 
4. Einen Befehl pa=... darf es nicht geben, denn die Akzente stehen bei Verfahren 2 auch innerhalb der Datenbank HINTER dem betroffenen Buchstaben. 

Anzeige-Parameter
Für DOS [d-1.apr]: Die Tabelle utf-ad.apt muß hinein.  
Für a99 [d-krtf.apr, d-khtm.apr]: Normalerweise utf-rtf.apt.
Empfehlung:  Verwenden Sie d-krtf.apr statt d-wrtf.apr. Für den Web-Katalog: d-khtm.apr . Diese Dateien können Sie kopieren auf  d-krtf.xpr  bzw.  d-khtm.xpr  für X.CFG. Dazu gehört die Datei  d-k.apt.  Für X.CFG muß man sich nach deren Vorbild eine Datei  d-k.xpt  selber erstellen! 

Druckparameter
Hierzu kann  p-w.apr  verwendet werden wie bei ASCI, aber mit utf-rtf.apt als Codetabelle. 

Export-Parameter
Sollen die Exportdaten in UTF-8 codiert sein, muß man für die Zeichencodierung nichts tun! Sollen DOS- oder Windows-Daten herauskommen, sind Tabellen notwendig, in denen die neuen P/Q-Befehle vorkommen. 
Vorhanden sind  utf-ad.apt  für ASCII und  utf-aw.npt  füe Win-ANSI. 
Die allgemeine Form ist 

P zzz yyy xxx abc 
  mit zzz yyy xxx = Dezimalcodes des UTF-8-Zeichenwertes 
        abc = Was dafür einzusetzen ist (direkte Zeichen) 
  Alternativ: 
P xyz abc 
   mit  xyz = direkte UTF-8-Zeichen 
Genauso für Q. Die P/Q-Werte werden eingesetzt, wenn die Umcodierung in den Exportparametern erfolgt. Wenn kein P/Q-Befehl greift, treten die p/q-Befehle in Kraft. 
Die besondere Eigenheit von UTF-8 ist berücksichtigt: wenn xxx zwischen 192 und 223 liegt, wird erwartet, daß zzz nicht angegeben ist. 
Wenn xxx>223 ist, muß zzz besetzt sein, d.h. man hat eine 3-Byte-Kombination. abc können ihrerseits auch UTF-8-Zeichen sein! Z.B. ist das wichtig, wenn man statt kyrillischer Zeichen die Transliteration anzeigen will, in der es ja Buchstaben mit Diakritika gibt. 

WICHTIGE REGEL: Alle P-Befehle müssen vor dem ersten Q-Befehl stehen.

Dimensionierung
Wichtig, wenn man sehr viele P/Q-Befehle hat: 
Ps=N
wobei N die Anzahl Bytes ist, die man für die Speicherung der P/Q-Befehle reservieren will. 
Default ist N=10000, wenn der Befehl Ps nicht vor Beginn der P/Q-Befehle angetroffen wird. 
Jede P- und jede Q-Zeile kostet intern 4 oder 5 Byte, je nachdem, ob xxx gegeben ist oder nicht. 
Sind es nur wenige solche Zeilen, kann man den Wert niedriger als 10000 setzen, um Platz zu sparen, doch ist dies nur für die DOS-Programme von Bedeutung. 
Ist der Bereich aber zu klein dimensioniert, kann es leider zum Absturz kommen. 

?ucodes.apt=h ucodes.apt  
?allgemeine Darstellung=x jan http://www.allegro-c.de/doku/unicode 
?Verfahren 1:=h =Verfahren  1 
?Verfahren 2:=h =Verfahren  2 
?Vb.168=h vb168 
?XML=x jan http://www.allegro-c.de/axml.htm 
?utf-ent.flx=X utf-ent 
?JanaS=x janas http://www.allegro-c.de/janas 
?PHPAC=h phpac 
?vb164=h vb164