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



Umcodierung


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

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.

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 ist Umcodierung.
Quelle kann aber auch eine Fremddatei sein und Ziel die eigene Datenbank (Programm IMPORT.EXE oder auch Umwandlung per FLEX).
Eine Umcodierung passiert aber nie für sich allein und sonst gar nichts, sie ist immer eingebettet als kleiner Bestandteil in einen insgesamt viel größeren Prozeß: eine Dateiproduktion, eine Indexierung o.a.

Anm.: Statt "Datenbank" kann es hier immer auch "Grunddatei" heißen, also eine kompatible , eigenständige Datei, die man direkt in die eigene Datenbank einmischen könnte.

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, und die Codes werden nicht immer als Zahlen dargestellt. 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 (S.182)

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 in anderen Sprachen "include itab.apt".

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. 11.2.2 (S. 258) im Systemhandbuch. IMPORT hat keinen include-Befehl, die Befehle müssen daher mit in der Importparameterdatei drinstehen.
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 - erzwungen durch den Erfindungsreichtum der Programmierer, die sich immer mal neue 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:

Im fliegenden Wechsel 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: d.h. 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 (geplant ist eine Unicode-Version).
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 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.

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 avanti. Wirksam sind sie vor allem in den Bereichen Auswahlfeld (links), Schreibfeld, Index- und Kurzlistenfenster. Im Anzeigefenster dagegen werden die p- und q-Befehle wirksam, die in den Anzeigeparametern stehen.
Die o-Befehle kommen auch zum Einsatz, wenn man die FLEX-Befehle
ansi und asci benutzt:
Wenn man z.B. in einem FLEX schreibt, und zwar mit einem DOS-Editor:
var "äöü"
ansi
mes

dann erscheint in der Message-Box korrekt die ANSI-codierte Meldung
äöü.

Hinweis: Wenn man in a99/alcarta oder avanti 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.

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 avanti 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.
Mehr dazu im Text zu Unicode.
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 Programm 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...

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 da gibt es inzwischen eine bessere Lösung:

Sequenzen
Ein besonderer Fall der Ersetzung von Zeichenfolgen liegt vor, wenn so etwas wie ä in den Daten vorkommen kann und am anderen Ende 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 Datensätzen, die mit in der Datenbank gespeichert werden und bestimmte Indexeinträge erzeugen, z.B. Einträge wie
ää
ÄÄ
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
Diese Methodik ist erheblich schneller als globale Ersetzung.

 



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