osteuropaeische Zeichensaetze

[Thomas Berger]

Liebe Frau Schoger,


> Ist folgendes Szenario denkbar?
> -Zeichensatz Ost-West (deckt die Mehrzahl der Datensaetze ab),
> kyrillisch und griechisch nach Unicode
> (z.B. А  durch Zeichenumwandlung beim Import erzeugt)

Evtl. bietet sich auch eine Speicherung in UTF-8 an:

griechische Zeichen sind dann Zweizeichenkombinationen
von 
0xcd 0xb0
...
0xcf 0xbf
bzw. (extended) Dreizeichenkombinationen von
0xe1 0xbc 0x80
...
0xe1 0xbf 0xbf

kyrillisch liegt im Bereich
0xd0 0x80
...
0xd3 0xbf

d.h. es gibt jeweils drei bis vier Praefixzeichen, die klar
machen, dass das folgende Zeichen griechisch bzw. kyrillisch
ist *und* es ist standard.

Problematisch ist allerdings, dass diese Codepositionen im 
Ostwest-Zeichensatz zum groessten Teil ausgerechnet durch
diakritische Zeichen belegt sind.

Andererseits ist es vermutlich ausserhalb der Allegro-Moeglichkeiten,
gerade die Form &#nnnnn; der Zeichen vernuenftig zu verarbeiten.

Mittels gewaltiger globaler Ersetzungslisten sollte
es im Prinzip moeglich sein, zumindest die in UTF-8
als Dweizeichenkombinationen darstellbaren Zeichen
(Unicode 0000 - 07FF, also Latin, Diakritika, Griechisch,
Kyrillisch, Armenisch, Hebraeisch, Arabisch, Syrisch
und Thaana) "vernuenftig" fuer die Indexierung kleinzukochen.


> -Jeder Datensatz bekommt eine Kategorie Zeichensatz
> (muss erzeugt werden)
> -Indizes und Kurztitel werden transliteriert nach RAK.
> D.h. Suchbegriffe werden transliteriert eingegeben,
> Kurztrefferlisten erscheinen einheitlich

Laesst sich automatisiert transliterieren?
Kennt der Ostwest-Zeichensatz alle Symbole, die fuer 
Transliterationen aus dem Griechischen und (russischen?)
Kyrillisch?

Evtl. bietet es sich an, die Transliterationen in eigenen
Datenfeldern zu hinterlegen, die bei Eingabe / Aenderung
der Hauptkategorien durch die Programmierte Validierung
generiert werden.


> -Jede Vollanzeige im Web stellt nur genau einen Datensatz dar,
> der META-Tag charset wird aus der Kategorie Zeichsatz erzeugt:
> z.B. Windows 1250, 1251, 1253.

das macht die Surfer mit Linux und Mäc auch nicht häppi...
Also entweder Meta-Tag UTF-8 (Browser der 4er-Generation sind
meist o.k.) oder fallweise 8859-1, -2, ... generieren.

Die Web-Praesentation ist jedenfalls die harmloseste Ihrer
Anforderungen...

 
> -Katalogiserung???
> vielleicht in drei verschiedenen Datenbanken nach Zeichensaetzen
> getrennt, mit geeigneten Importparametern fuer die gemeinsame
> Datenbank.

Mit den neueren MS-Office-Versionen gibt es m.E. Tools
zur einfacheren Umschaltung von Tastaturbelegungen auf
verschiedene Schriftsysteme und Sprachen. Funktioniert 
evtl. aber nur mit MS-Office. Hier sehe ich das Hauptproblem: 
Wie kyrillische Texte in einer Anwendung erfassen, so
dass in einem anderen Fenster immer noch die "deutsche"
e-mail funktioniert.

Anzeige unter Windows sollte auch bei einer gemeinsamen
Datenbank kein Problem sein (hier brauchen Sie dann
natuerlich Umcodierungen nach Windows 1250-53 :-).
Jedenfalls sollten sich nach der oben beschriebenen
Ersetzungsmethode leicht riesige Ersetzungstabellen
kreieren lassen, die fuer die Darstellung im RTF-
Fenster den WGL4-Umfang (Codepages 1250-54 ?) abdecken.

Die Anzeige im Kategorien- und Eingabefenster von
a99 wird natuerlich immer verheerend sein.

Die Eingabe von irgendetwas unicode-artigen ist wohl
so ziemlich aussichtslos: Selbst unter Windows NT kann
dies nur Notepad und nicht RichEdit. Hier wird es auf
lange Zeit immer nur die Loesung geben, aus a99 heraus
einen externen Editor zu starten, der UTF-8 oder eine
andere Unicode-codierung produziert und dies zurueck
nach allegro liest.

Also: Die Praesentation der Daten sollte mit einem
gewissen, nicht zu unterschaetzenden Aufwand machbar
sein, die Katalogisierung erfordert groessere Klimmzuege
und Zusatzsoftware.

HTH
Thomas Berger