unicode

[Teschke]

Bernhard Eversberg schrieb:

> Es hat also gar keinen Sinn, hier bereits irgendwelchen Optimismus zu
> verbreiten.

Vielen Dank für die Klarheit dieser Auskunft.

> Koennen Sie uns Beispieldaten zukommen lassen? Vielleicht muss ja nur die
> Methodik der Anwendung der o-Tabelle modifiziert werden, wie es ja
> schon bei den p- und q-Befehlen einwandfrei funktioniert. Ist es nicht so:
> wenn ein Code oberhalb 160 vorkommt, bildet er zusammen mit dem naechsten
> Byte ein chinesisches Zeichen? Oder muessen zwei aufeinanderfolgende Bytes
> oberhalb 160 liegen, um chinesisch interpretiert zu werden (sonst wuerden
> ja die Umlautcodes sowieso nicht funktionieren - oder wie sind die wirklich
> dann codiert?)

Ersteres trifft zu: Zum Beispiel die ASCII-Kodes 105, 225 und 116 zuerst mit
ASCII in isstdt.jpg, und dann mit den Zeichensatz Big-5 in der angefügten
Grafik isstch.jpg.
Das zweite Zeichen hat einen Kode>160, also bildet es zusammen mit dem nächsten
ein Schriftzeichen. Der Kodebereich für das erste Byte ist in Big-5 161-254,
für das zweite 64-126 und 161-254.
Der höhere ASCII-Bereich fällt also in zwei Teile, der eindeutige Bereich bis
160, der nur für westliche Zeichen verwendet wird und der zweideutige Bereich,
der die Kodepositionen 161 und 254 umfasst, die für westliche Zeichen oder das
erste Byte eines chinesischen Schirftzeichens stehen können.
Jetzt macht es einen großen Unterschied, ob ich neben Big-5 nur ASCII oder
ASCII und ANSI verwende. In ASCII finde ich fast alle westlichen Zeichen, die
ich aus dem höheren Bereich verwende, im eindeutigen Bereich unterhalb von
Position 161. Das einzige Zeichen, das fehlt, ist das scharfe S, ASCII 225.
Bei ANSI aber stehen fast alle westlichen Zeichen, die ich aus dem höheren
Bereich verwende, im zweideutigen Bereich, ab Kode 161. In a99 kommt es daher
häufig zum "Illegale Mapping", weil der chinesische FEP diese westlichen
Zeichen zusammen mit dem darauffolgenden Byte als Schriftzeichen darstellt, z.
B.: "Ich möchte, daß mein Äuglein übt" in der angeügten Grafik ich_moechte.jpg,
siehe auch http://www.fak12.uni-muenchen.de/sin/hilfe/a99/chinesisch.htm. Wenn
ich nur ASCII und Big-5 verwende, kommt dieses Problem nur beim scharfen S vor,
s. o.
Ob ein Zeichen aus dem zweideutigen ASCII-Bereich ein westliches Zeichen oder
ein Schriftzeichen ist, wird durch die Kategorie, in der es steht, bestimmt.
Jede Kategorie hat nur einen Zeichensatz, z. B. in der angefügten bsp.plg:
#320 HST westlich, #321 HST in Schriftzeichen, #200 Verf. west., #90c Verf. in
Schriftzeichen.
Zur Methodik der o-Tabelle: Ich muß die o-Umkodierung ausschalten, sonst werden
die chinesischen Schriftzeichen bei der Eingabe auch umkodiert und in der
Datenbank steht Müll anstelle von Schriftzeichen.  Ich kann mir nicht
vorstellten, wie man die o-Umkodierung kategorie- oder zeichenweise aus- und
schalten könnte.
Mit freundlichen Grüssen
R. Teschke

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : isstdt.jpg
Dateityp    : image/jpeg
Dateigröße  : 1147 bytes
Beschreibung: nicht verfügbar
URL         : <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20000418/2314a5c4/attachment.jpg>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : isstch.jpg
Dateityp    : image/jpeg
Dateigröße  : 1105 bytes
Beschreibung: nicht verfügbar
URL         : <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20000418/2314a5c4/attachment-0001.jpg>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : ich_moechte.JPG
Dateityp    : image/jpeg
Dateigröße  : 4229 bytes
Beschreibung: nicht verfügbar
URL         : <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20000418/2314a5c4/attachment.jpe>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : Bsp.plg
Dateityp    : application/x-unknown-content-type-plg_auto_file
Dateigröße  : 219 bytes
Beschreibung: nicht verfügbar
URL         : <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20000418/2314a5c4/attachment.bin>