[Allegro] Ersetzungen

[Holger Becker]

Thomas Berger schrieb:

> Sie haben uebrigens noch nicht wirklich verraten, warum der
> OSTWEST-Zeichensatz Ihnen nicht ausreicht. 

Weil es Sonderzeichen gibt, die darin nicht vorkommen. Wenn ich mich
nicht vertan habe, fehlen folgende, die bei uns schon einmal vorgekommen
sind:
Großes D mit Hatschek
Großes E mit Ogonek
Große OE-Ligatur
Großes Z mit Hatschek

Das sind zwar weniger, als bei ISO-8859-15 fehlen, aber es wäre immer
noch keine genaue Lösung.

> Ansonsten ist es so,
> dass man auch dann, wenn in der Datenbank die Sonderzeichen "nativ"
> stehen (in irgendeiner Codierung, aber nicht a la TeX oder HTML oder ...
> escaped), Word-Makros normalerweise die schlechteste Wahl sind, um die
> Zeichen umzusetzen (weil Word oft beim Einlesen undurchsichtige
> Dinge treibt), Exporte mit allegro sind normalerweise die Methode
> der Wahl, z.B. nach Unicode.

Wie würde man das denn anstellen, wenn die Datenbank intern in Ansi ist?
Gibt es vorgefertigte Ersetzungstabellen für Unicode, in die man nur
noch die eigenen Sonderzeichencodierungen unterbringen muss? Das Problem
ist ja, dass sie bei uns eben nicht nativ stehen und ich eine
Möglichkeit suche, die Exporte sicher zu machen, aber die Datenbank
gleichzeitig lesbar zu halten. Vor einer Umstellung nach Unicode
schrecke ich zurück, weil ich den Arbeitsaufwand für gewaltig halte, den
Gewinn aber für nicht so entscheidend. Verlockend wäre allerdings die
Möglichkeit, auch IPA und gelegentliche arabische Schriftzeichen
darstellen zu können. Für den Index müsste man aber sowieso wieder
Tabellen schreiben, oder? Man kann ja nicht nach einem Schwa suchen,
weil man es ja nicht eingeben kann.

> 0x00F5 ist uebrigens nicht Unicode, sondern Unicode plus eine gewaehlte
> Codierung, wobei mir nicht klar ist, ob Sie darauf hinauswollen, dass
> die Bearbeiter mit aufgesetzter Binaerbrille auf dem Bildschirm die
> beiden Bytes 00 F5 ablesen sollen, oder ob in der Datenbank die
> 6 Zeichen "0", "x", "0", "0", "F" und "5" stehen. Beides ist im
> uebrigen keine schlaue Codierung, weil Unicode weit mehr Zeichen
> umfasst, als sich auf 65536 Codepositionen abbilden liessen...

Das war ein Fehler meinerseits. Wenn die Datenbank intern in Unicode
ist, braucht man natürlich keine Codierung mehr.

> Die Verlautbarung 163 beschreibt mit den V-Sequenzen einen ziemlich
> schmerzlosen Weg, um die Datenbank Unicode-faehig zu machen, d.h. die
> Codierung bleibt, wie sie ist, alle durch die Codierung nicht
> abbildbaren Unicode-Zeichen werden in der Datenbank als "&#....;"
> codiert und sind dank der VS-Methodik lesbar indexierbar und exakt
> darstellbar. Dazu muessen Sie in Ihrem Datenbestand nur alle "&"
> auf "&" umsetzen, um Ambiguitaeten zu vermeiden, ein paar
> Parameterdateien ueberarbeiten und die Unicode Character Database
> (http://www.unicode.org/Public/UNIDATA/) in Ihre Datenbank importieren.

Letzteres ist natürlich auch sehr verlockend. Was bedeutet denn "einige
Parameterdateien überarbeiten"? Wenn ich Zeichen wie "&#....." in der
Datenbank stehen habe, muss ich sie doch trotzdem per q-Befehl in den
Index bugsieren, oder? Dann habe ich doch Problem, dass mehrere
Buchstaben als erstes Argument nicht zugelassen sind. Dann bleibt nur
noch die Möglichkeit, mit
"q & 2" oder "q &# 2" (wobei letzteres nicht klappen wird)
zu arbeiten, dafür wären dann aber zu viele Buchstaben vorhanden. So
komme ich doch auch nicht weiter. Was übersehe ich?
Viele Grüße,
Holger Becker

-- 
Holger Becker
Wissenschaftlicher Mitarbeiter am Informationszentrum für
Fremdsprachenforschung (IFS)
Telefon: +49 (0)6421/28-23802; Fax: -25710; E-Mail:
beckerho at staff.uni-marburg.de; Web:
http://www.staff.uni-marburg.de/~beckerho;
Hans-Meerwein-Straße, 35032 Marburg, Deutschland