Umcodierung

Was ist das?
Codierung ist das Ersetzen von Zeichen oder Zeichenfolgen durch andere. Als Spezialfall kann ein Zeichen oder eine Zeichenfolge auch beseitigt werden (d.h. durch nichts ersetzt). 

Wo, wann und warum muß das sein?
Weil die verschiedenen Umgebungen (DOS, Win, UNIX, Web) je nach Anwendung und Funktion unterschiedliche Codierungen brauchen. Die Welt ist in diesem Punkt nicht homogen, also muß ein Datensatz oder Text an unterschiedlichen Punkten der Welt unterschiedlich codiert sein, um verstanden oder korrekt verarbeitet oder angezeigt werden zu können. Doch auch wenn man überall einen und denselben Standard hätte, z.B. Unicode, man käme trotzdem nicht ganz ohne Umcodierung aus: z.B. beim Indexieren und Suchen muß immer etwas derartiges stattfinden, die Beispiele im folgenden Text weisen darauf hin. 

Zur Umwandlung von Textdateien kann man einen FLEX namens `filecode` verwenden. Dieser bietet eine Anzahl von `Codetabellen zur Auswahl`. 

Wie macht allegro das?
Je nach Aufgabe gibt es unterschiedliche Methoden, aber das einfache Grundprinzip ist die Tabelle oder Liste. 
Eine Umcodierung hat immer zwei Seiten, die wir Quelle und Ziel nennen. 
Quelle kann z.B. die Datenbank sein, genauer gesagt die darin gespeicherten Daten. 
Ziel kann eine Liste oder Tabelle sein, eine Anzeige im a99-Anzeigefeld oder im DOS-Anzeigebildschirm oder im Web-OPAC, es kann auch der Index der Datenbank sein: dort soll ja z.B. nicht A, sondern a stehen, und nicht ä, sondern ae - auch das fällt alles unter Umcodierung. 
Quelle kann aber auch eine Fremddatei sein und Ziel die eigene Datenbank (Programm IMPORT.EXE für das Konvertieren von Fremddaten, oder dnb.flx bzw. zc.flx). 

Anm.: Statt "Datenbank" kann es hier immer auch "Grunddatei" oder "Externdatei" heißen, also eine kompatible Datei, die man direkt in die eigene Datenbank einmischen könnte (Typ .ALG bzw. .ADT). 

Im einfachsten Fall wird jedem Zeichencode genau ein anderer zugeordnet. 
Darstellen kann man das am leichtesten, und das ist die Grundidee, durch eine Liste:

1 z1
2 z2
3 z3
4 z4
5 z5
... 
255 z255

wobei 1,2,3,...,255 die Codes der Quelldaten sind, z1,z2,...,z255  die der Zieldaten. In WIrklichkeit steht da kein Buchstabe z, der soll hier nur besagen, daß es ein variabler Wert ist. Beispiele kommen gleich. 
Es gilt dabei immer die Annahme: wenn i = zi, also i unverändert bleibt, dann kann die Zeile in der Liste entfallen. 
Anders gesagt: die Liste muß nur denjenigen Codes etwas zuordnen, die im Zielbereich anders codiert sein sollen. Wenn man z.B. die Zeile 
32 z32
wegläßt, bedeutet das also: Code 32 wird nicht geändert. 

Derartige Listen müssen aber immer eingebaut sein in die jeweilige Anwendung, und es gibt Listen für unterschiedliche Zwecke. Deshalb sehen sie nicht ganz so einfach aus wie oben gezeigt, es steht vielmehr immer ein Befehlsbuchstabe voran. Das sieht z.B. in den Exportparametern so aus: 

... 
p a A 
p b B 
... 
p ä "Ae" 

Dadurch würde dem a ein A zugeordnet, dem b ein B, dem ä die Kombination Ae. Soll mehr als ein Zeichen zugeordnet werden, muß man Anführungszeichen setzen. 
Es müssen hier also nicht die Zahlencodes stehen, sondern druckbare Zeichen können in der Liste als solche angegeben sein. 
Gleichwertig wäre aber (der Punkt sagt, daß eine Zahl folgt): 

p .97 65 
p .98 B 
p .132 "Ae" 

Beim Export braucht man gelegentlich nicht eine, sondern zwei Tabellen, deshalb kann man mit q statt p demselben Zeichen noch einen zweiten Wert zuordnen. Quelle sind beim Export immer die allegro-Daten oder Nutzereingaben, Ziel sind beliebige Ausgabeprodukte bis hin zur Indexdatei der Datenbank. Beispiele, in denen beides vorkommt, sind i.apt für die Indexierung mit den Standardparametern (CAT.API) und itab.npt für die Indexierung mit den Neutralformat-Parametern (BANK.NPI). 

Wie das genau zusammenhängt und welche Möglichkeiten es sonst noch gibt, das steht in Kap. 10.2.4.1/.2 (S.182ff) 

Bei den Export- und Indexparametern kann man die Codierungslisten auslagern in Tabellendateien des Typs .cPT, also z.B. i.apt und itab.npt. Eingebunden in die Parameterdatei werden sie dann mit dem t-Befehl: ti bzw. titab, d.h. eine Zeile wie 
titab 
sagt soviel wie "include itab.apt"  (nur daß man es in dieser Form eben nicht hinschreiben kann). 

Beim Import dagegen gibt es nur eine Umwandlungsliste, deren Zeilen mit y beginnen: 

y A a 
y B b 
... 
Quelle sind die Fremddaten, Ziel sind allegro-Daten in Form einer Grunddatei. 
Wie das genau zusammenhängt und welche Möglichkeiten es sonst noch gibt, das steht in Kap. `Kap.11.2.2` (S. 258). IMPORT hat keinen include-Befehl, die Befehle müssen daher mit in der Importparameterdatei stehen. 
Ab V27.2 können solche Befehle auch in einem FLEX stehen und mit `xcode y` auf den Text der internen Variablen angewendet werden. 
Hinweis: IMPORT kann daneben im selben Durchlauf eine Export-Parameterdatei verwenden, die beliebige p- und q-Befehle enthalten kann! Manchmal muß man zwei Umcodierungen geschickt kombinieren - eine Folge des Erfindungsreichtums der Programmierer, die sich Datencodierungen ausdenken. 

Die Befehle p, q und y wirken jeweils nur in eine Richtung, von der Quelle zum Ziel. Anders ist das bei den o-Befehlen: 

Hin und zurück zwischen den Welten
Es gibt eine Methodik, die in beiden Richtungen wirken kann - anders gesagt: Ziel und Quelle können die Rollen tauschen. 
Wenn bei zuerst Hin- und dann Rückwandlung wieder dasselbe rauskommen soll wie vorher, muß die Liste ein-eindeutig sein: sie darf nicht zwei Codes denselben Zielcode zuordnen, sondern zwei Quellcodes müssen zwei unterschiedliche Zielcodes zugeordnet bekommen. Die wichtigste Liste von o-Befehlen steht in der Datei o.apt (darin Kommentar), sie vermittelt zwischen den DOS- und Windows-Versionen des OstWest-Zeichensatzes. 
Der Anwendungsbereich dieser Methode ist vor allem der Wechsel zwischen internen und externen Daten in den Windows- und Web-Anwendungen. Denn intern haben die Datenbanken noch weitgehend, weil alles kompatibel sein soll, DOS-Codes. (Nur der neue Standard "Neutralformat" arbeitet von vornherein im Windows-Code. 
 
Extern, im Windows-Fenster oder im Web-Formular, müssen aber die Zeichen im ANSI-Code (ISO 8859) aufscheinen, bei Rückgabe zum Speichern muß wieder DOS-Code draus werden. Die Umwandlung in beiden Richtungen leisten die o-Befehle: 

o .132 228    ä 
... 
o .142 196    Ä 

Hiermit wird das DOS-ä (132) dem Windows-ä (228) zugeordnet und zugleich umgekehrt. Die FLEX-Befehle asci und ansi kann man nutzen, um diese Tabellen gezielt anzuwenden, ansonsten wirken sie an vielen Stellen automatisch, z.B. beim Anzeigen von Hilfetexten, die in DOS-Code erstellt wurden. 
o-Befehle können in die Indexparameter und in die Anzeigeparameter eingebaut werden. Sie wirken sich dann so aus: 
Anzeigeparameter: Umcodierung ASCII<->ANSI: vor allem automatisch für Viewlisten und DOS-ASCII-Dateien. Anwendung im FLEX mit den Befehlen `ansi / ascii`. 
	Dafür am besten eine Kopie der o.apt benutzen und in die Anzeigeparameter einbinden. 
Indexparameter: Umcodierung der eigenen Interncodes in ANSI zwecks Anzeige im Index- und Kurzlistenfenster und Schreibfeld. 
	Wer nicht mit A.CFG arbeitet, muß eine eigene o-Tabelle anlegen und in seine Index- und Anzeigeparameter einbinden. 

Die p-, q- und o-Zeilen müssen übrigens nicht sortiert sein. Wenn allerdings ein Wert zweimal auftritt, gilt nur der letzte: 

p ä "Ae" 
... 
p ä "ae" 

würde dem ä das "ae" zuordnen! 
Vorsicht: die Syntax und die Möglichkeiten sind wegen unterschiedlicher Randbedingungen bei p/q und o bzw. y nicht genau gleich. Diese "Randbedingungen" betreffen z.T. die internen Strukturen, mit denen  die Listen im Programm gespeichert und gehandhabt werden, und diese Dinge kann der Anwender nicht intuitiv einsehen, da liegt ein gewisses Problem. EIne Grundregel ist aber: Eine Tabellenzeile darf nicht mit Leerzeichen beginnen, und zwischen den Teilen eines Tabellenbefehls muß immer genau ein Leerzeichen stehen. Sobald zwei Leerzeichen oder mehr aufeinander folgen, gilt der Rest der Zeile als Kommentar, sowie auch jede mit Leerzeichen beginnende Zeile insgesamt keine Wirkung hat. Die in den o-Zeilen oben zu sehenden Buchstaben ä und Ä haben also keine Funktion, sondern stehen da zur zur Verdeutlichung. 

Die o-Befehle (s. 10.2.4.5, S.185) haben keine Wirkung in den DOS-Programmen, nur in a99/alcarta und acon. 
Hinweis: Wenn man in a99/alcarta oder acon merkwürdige Probleme hat, bei denen anscheinend Zeichen vom Programm mutwillig geändert werden, kann o.apt dahinterstecken. Wenn die eigene Datenbank nicht mit DOS-Code arbeitet, ist die Original-o.apt nicht sinnvoll. Deshalb die Empfehlung: auf das eigene Datenverzeichnis eine leere Datei mit dem Namen o.apt legen und schauen, ob's dann klappt. Wenn nicht, ist o.apt nicht dran schuld. 

Indexcodes
In Indexparametern kann eine weitere Liste auftreten, deren Zeilen mit i beginnen: die Indexcodes (10.2.4.5, S. 185). Diese Befehle verändern aber keine Zeichen, sie ordnen ihnen nur einen anderen Sortierwert zu. Das kann nötig sein, wenn die Reihenfolge der Zeichen im Index eine andere sein soll als die der Codewerte. Z.B. könnte man das türkische i ohne Punkt zwischen i und j einordnen wollen; es würde sonst weit hinter z landen. 

Unicode
In Windows- und Web-Umgebungen werden u.U. noch weitere Listen gebraucht. Mehr dazu in dem Text zu Unicode  (h unicode  eingeben). 
Es geht dabei nicht um Ersetzung von Einzelzeichen, sondern von ganz bestimmten 2- und 3-Byte-Kombinationen: 

P- und Q-Befehle
Die Befehlszeilen beginnen mit P und Q und sind nur dann vonnöten, wenn man intern in der Datenbank UTF-8-Codierungen verwendet. Diese bestehen aus je 2 oder 3 Codes oberhalb 128. Solchen Zeichenkombinationen kann man andere Werte (einzelne oder mehrere Zeichen) zuordnen, was vor allem für die Indexierung wichtig ist, aber auch bei Exporten nötig werden kann. 
Beispiele sieht man in der mitgelieferten Datei  iu.apt (darin Kommentar), etwa diese: 
P 195 132 AE   [00C4] -- &#196 
P 195 133 A    [00C5] -- &#197 
Eine Liste der UTF-Codierungen mit den Unicode-Namen findet man in ucodes.apt
Die P/Q-Befehle haben Priorität vor den p/q-Befehlen, d.h. sie werden beim Abarbeiten einer Exportzeile zuerst ausgeführt. 
Mehr dazu in der `Unicode-Dokumentation`. Als Referenzliste findet man dort die "Amtliche Tabelle", in der alle Codes des OstWest-Codes mit allen Werten zusammengestellt sind. 

u-Befehle
Diese machen etwas Ähnliches wie die P/Q-Befehle: sie ordnen aber einer UTF-Sequenz einen ASCII- oder ANSI-Code zu, also einen einzelnen Code. Sie wirken nur an der Stelle, wo man dem Programm acon oder a99 Daten mit dem FLEX-Befehl insert übergibt. Wenn dies UTF-Daten sind, werden daraus intern ASCII- oder ANSI-Daten. Diese Befehle kommen also zum Einsatz, wenn man eben intern keine UTF-Codes hat, sondern ASCII oder ANSI. 
Beispiele sieht man in der "großen" Version der Demodatenbank-Indexparameterdatei cat.api, Grundlage ist ebenfalls die Liste in ucodes.apt

Sonderfall: Volltextsuche
NUR das Konsolprogramm SRCH.EXE und seine UNIX-Version srch machen Gebrauch von einer Liste, die in der Datei `s1.asp` steht. 
Beschreibung; Kap. 4, S.119  (h ac4  eingeben). Gesucht wird sie auf dem Startverzeichnis, bei Mißerfolg auf dem Programmverzeichnis. 
Diese Liste hat vorn kein Befehlszeichen! Typische Einträge sind diese: 

A/Z a     gross -> klein, A->a, B->b, ... 
Ç c 
ü ue 
é e 
â a 
ä ae 
à a 

Diese Liste ermöglicht das Finden von Müller, Mueller, MÜLLER und MUELLER mit einem und demselben Suchwort, nämlich "mueller". Wenn der Nutzer z.B. Müller eintippt, wird nichts gefunden! Nicht die Nutzereingabe wird umcodiert, sondern nur die Daten, und sie werden dann nach Umcodierung verglichen mit der unveränderten Nutzereingabe - das ist alles. 
Hinweis: Die Volltextsuche per FLEX (Export-Komfortmenü) arbeitet nicht mit dieser Datei! Sie benutzt vielmehr die p-Befehle der Indexparameter, um sowohl die Nutzereingabe als auch die Daten umzucodieren, bevor es sie vergleicht. Warum arbeitet SRCH nicht so? Weil es auch ALG-Dateien durchsuchen können muß, wenn gar keine Indexparameter vorhanden sind. SRCH stammt aus einer Zeit, als es noch keinen Index gab... Mit dem FLEX-Befehl `srx` wird ab V27.1 ermöglicht, die Volltextsuche per FLEX auf neue Art zu erledigen, wobei die Möglichkeiten der Umcodierung noch umfangreicher sind. Seit V32 gibt es einen 32bit-Ersatz für SRCH.EXE namens srch.exe, und dieses Programm beherrscht ebenfalls die srx-Technik der sog. "regulären Ausdrücke". 

FLEX-Umcodierung
Es gibt ab V27.2 einen FLEX-Befehl  `xcode` mit dem man die Tabellen in den Parameterdateien jederzeit gezielt auf den Inhalt der internen Variablen anwenden kann. So z.B. wird mit  xcode u  die Wandlung von Unicode UTF-8 in den Interncode ausgelöst.
Als Werkzeug wird bereitgestellt der FLEX `filecode.flx`, mit dem man Textdateien umcodieren kann. Darin kann man die Anwendung des besagten Befehls beispielhaft sehen. 

Holzhammermethode: Globale Ersetzung 
Wenn es nicht um Einzelzeichen geht, die zu ersetzen sind, gibt es manchmal keine andere Wahl als die globale Ersetzung, die bei Import wie Export wahlweise auf einen ganzen Datensatz oder auf bestimmte Felder anwendbar ist. Mehr dazu: Export: 10.2.4.6, S. 186 bzw. Import: 11.2.2, S. 258. 
Generell ist die globale Ersetzung weniger effizient, also langsamer. Dadurch Einzelzeichen ersetzen zu wollen ist eine schlechte Idee, man sollte die Methode auf Zeichenfolgen begrenzen. Aber auch dafür gibt es inzwischen eine bessere Lösung: 

Sequenzen
Ein besonderer Fall der Ersetzung von Zeichenfolgen liegt vor, wenn so etwas wie &auml; in den eigenen Daten vorkommen kann und beim Export ein ä (Code 132 oder 228) erscheinen soll. Dazu wurde die Methodik der `Sequenzen-Ersetzung` geschaffen, die ebenfalls im `Unicode-Papier` beschrieben ist. Sie arbeitet mit Hilfsdatensätzen, die mit in der Datenbank gespeichert werden und bestimmte Indexeinträge erzeugen, z.B. Einträge wie 
&auml;ä 
&Auml;Ä 
Spezialbefehle in den Index- oder Exportparametern bewirken dann, daß die Sequenzen ersetzt werden durch das, was im Index dahinter steht. Man muß in die Parameter diese zwei nichtintuitiven Befehle schreiben: 
ib=59 
p & 9
Es kann beliebig viele solche Sequenzen geben, trotzdem ist diese Methodik erheblich schneller als globale Ersetzung. Auch das 32bit srch.exe beherrscht diese Methode, wenn es Zugriff auf eine Datenbank hat (mittels Option -b), in der solche Sequenzen definiert und indexiert sind. 

?Unicode-Dokumentation=h unicode 
?xcode=h xxcode 
?Unicode-Papier=h unicode 
?srx=h xsrx 
?Sequenzen-Ersetzung=h vb164 
?xcode y=h xxcode=xcode y 
?ansi / ascii=h xansi 
?s1.asp=h s1.asp 
?filecode.flx=h filecode.flx 
?filecode=X filecode 
?Codetabellen zur Auswahl=x View codetab 
?Kap.11.2.2=h ac11-1=11.2.2  Globale