[Allegro] Ersetzungen

Fr Aug 17 12:26:07 CEST 2007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Becker, liebe Liste,

[eine lange Mail erfordert eine lange Antwort]

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

"xy mit Hacek" sind in OSTWEST darstellbar (nur nicht praekombiniert
vorhanden): Es handelt sich um einen Zeichensatz mit isolierten
Akzenten als "Modifier", die per Konvention dem Grundbuchstaben
vorangestellt werden.

OE-Ligaturen (und von vielen vermisst: das Sterbezeichen) sind nicht
abbildbar, da haben Sie recht (Der OSTWEST-Zeichensatz war leider
etwas zu Ost-lastig geraten).

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

"Ansi" sollte man nicht sagen, wenn man sich ernsthaft ueber
Zeichensaetze unterhaelt. "ANSI"-Zeichensatz ist eine
alternative Microsoft-Bezeichnung fuer die Windows-Codepage 1252, die
im Laufe der Jahre gewisse Erweiterungen (zuletzt um das Euro-Zeichen)
erfahren hat.

["ASCII" ist der 7-bit-Zeichensatz, der von der Koerperschaft ANSI
definiert wurde. Schlampig sagt man "ASCII-Zeichensatz", wenn man
irgendwelche DOS-basierte Zeichensaetze meint, wie etwa Microsoft
zunaechst mit CP437, dann ab DOS 6 mit CP850. Allegro setzt noch
einen drauf, indem "ASCII" der OSTWEST-Zeichensatz sein soll und
"ANSI" der durch die o-Tabelle implizit existierende Windows-
Zeichensatz. Hauptproblem ist oft, dass die impliziten
Umcodierungen nicht kompatibel sind:
Wenn Sie ein Zeichen aus OSTWEST haben, das von CP850 abweicht,
dann gibt es eine Umcodierung mittels o-Tabelle zu einem
allegro-Windows-Codepunkt. Jegliche Windows-Software unternimmt
jedoch eine implizite Umcodierung vom CP850-Codepunkt zum
entsprechenden CP1252-Codepunkt (zumindest wenn der Rechner
auf "Mitteleuropa" eingestellt ist). Das ist typischerweise
ein anderer Codepunkt als der ueber die o-Tabelle errechnete,
da hilft es dann auch nicht, einen allegro-Font einzustellen...]

Sinnvolle Interne Codierungen fuer allegro-Datenbanken sind m.E.

CP850
OSTWEST
ISO-8859-1
UTF-8

Offiziell unterstuetzt wird m.W. nur OSTWEST (das Neutralpaket
beruht m.W. den nicht dokumentierten, unbenannten Zeichensatz
"Allegro-Windows"). Von UTF-8 als Internformat ist bekannt,
dass man diese Datenbanken weder mit den DOS- noch den Windows-
Modulen von allegro sinnvoll bearbeiten kann.

Aufsetzend auf diesen Grund-Zeichensatz koennen Sie mit dem
Instrumentarium von VB 163/164, also V-Sequenzen und Texel-Technik
(oder primitiver mit dem von Ihnen bereits entdeckten Umcodierungswert
"2") noch eine oder mehrere Codierungsebenen draufsetzen, etwa
fuer bescheidenes Markup oder akzidenzielle oder systematische
Zeichensatzerweiterungen.

> Gibt es vorgefertigte Ersetzungstabellen für Unicode, in die man nur
> noch die eigenen Sonderzeichencodierungen unterbringen muss? Das Problem

"vorgefertigt" und "eigene" beissen sich, finde ich.
Unter http://www.gymel.com/charsets/ gibt es einen Link auf "Rohmaterial
fuer Umsetzungstabellen".

> 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

mit Bidi-Support (LR-Umschaltung) ;-?

> Tabellen schreiben, oder? Man kann ja nicht nach einem Schwa suchen,
> weil man es ja nicht eingeben kann.

Eingabe ist nicht das Problem, aber wie sollen die Zeichen sortieren?
Allegro ist da ja sehr primitiv, indem alles, das sicht- und eingebbar
ist, einen Sortierwert bekommen muss.

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

*Das* ist jetzt erst Ihr Fehler: Wenn die Datenbank Unicode "ist",
muessen die Daten immer noch irgendwie codiert sein, denn Unicode ist
kein "Character Set".

Z.B. sind (valide) XML-Dateien immer "Unicode", auch wenn sie nicht in
UTF-8 codiert sind: Lt. Spezifikation sind alle Codierungen erlaubt
(und nur diese), die sich abstrakt auf Unicode abbilden lassen,
z.B. auch die Codierungen A und &#x41; fuer "A".

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

Meinen Listenbeitrag "v23 getestet" vom Juni?
http://sun250.biblio.etc.tu-bs.de/pipermail/allegro/2007-June/026183.html

Die Idee bei den V-Sequenzen bzw. der VS-Methodik ist, dass im *Index*
mehrere Saetze von Umcodierungen hinterlegt sind, halt die, die man
braucht, etwa fuer Anzeige unter DOS, unter a99, Export in diverse
gaengige Unicode-Codierungen wie UTF-8 oder XML-Entitaeten,
diverse Drucker (wohl etwas schwierig wegen niedriger Binaerzeichen,
hier braucht es zusaetzlich noch eine echte Umcodierungstabelle und
die V-Sequenzen indexieren nur ein Zwischenformat) etc.
Dazu kann man noch Schluessel hinterlegen, die per expliziter
Parametrierung fuer die Umcodierung der Benutzereingabe oder eine
implizite Normierung bei der Dateneingabe (Hilfsabschnitt der .cPI)
wirken sollen.

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGxXe+hKFJT0F1FsoRAoQlAJ94BtHBa+v+YqOB3n74s0bcuc2ctgCfcE2r
6CU0ZffgDSLRQPVMFwyNmbI=
=9QJc
-----END PGP SIGNATURE-----