AW: [Allegro] Die wichtigsten Umwandlungstabellen

[Thomas Fischer]

Hallo Herr Eversberg,

schönen Dank für die Übersicht.
Was die Namen angeht, so finde ich insbesondere
> UTF-8 -> ASCII		du.apt
> UTF-8 -> ANSI		du.npt
sehr störend, das passt zu meiner Vorstellung, dass alle diese Tabelle
eigentlich völlig unabhängig von der benutzten Konfiguration sein sollten.

Die Umwandlung
> UTF-8 -> RTF		du-rtf.apt
interessiert mich wegen meiner Datenbanken mit interner UTF-8-Speicherung.

Da muss meines Erachtens noch unterschieden werden, wofür das benutzt wird:
- Intern ist *keine* Umwandlung für das Anzeigefeld von A99 nötig, da der
entsprechende Modul direkt UTF-8 darstellen kann; sehr schön wäre eine
optionale Umwandlung für das Auswahlfeld und für das Schreibfeld (hier
bidirektional wie bei den o-Tabellen).
- Extern kann RTF seit Version 1.7 alles mögliche an Unicode verarbeiten und
mit geeigneter Schrift (z.B. Arial Unicode MS oder Lucida Sans Unicode) auch
darstellen. Für diesen Zweck sehe ich dann nicht, warum nicht einfach
durchgängig auf diesen Mechanismus gesetzt wird und alle
UTF-8-Hexadezimal-Paare in dezimale Unicode-Nummern umgesetzt werden, also
z.B.
P 206 166 \u934? 	[03A6] -- &#934
statt
P 206 166 PH  	[03A6] -- &#934 
und
P 196 128 \u256?	[0100] -- &#256
statt
P 196 128 A   	[0100] -- &#256

Eine Umwandlung auf eine lokale Codepage führt z.B. Wordpad (andere
RTF-Editoren müsste ich prüfen) auch intern durch - auf die
Standardcodepage, wenn keine andere mitgeteilt wird - so dass auch
P 195 132 \u196? 	[00C4] -- &#196
statt
P 195 132 Ä  	[00C4] -- &#196
keinen Schaden anrichten sollte.
Das würde also eine bidirektionale Umwandlung leicht möglich machen (hilft
natürlich nicht bei Anzeige- und Schreibfeld, solange diese kein RTF
darstellen können).

Schließlich:
Ihr
> Hinweis: Beim Import kann man zwei Umwandlungen 
> hintereinanderschalten, also z.B.
> Pica -> ASCII -> ANSI : Import mit pica.aim, Export mit 
> asciansi.apt Also braucht man nicht noch extra  Pica -> ANSI!
stimmt allgemein natürlich nur, wenn die erste Wandlung verlustfrei ist, was
ich bezweifle.
Konzeptionell wäre es am schönsten, einen "universellen" Code (= Unicode?)
zu haben, in den alles gewandelt verlustfrei gewandelt werden kann und aus
dem heraus dann das mögliche für den entsprechenden Zeichensatz herausgeholt
wird (aber das wissen Sie ja selbst).

Mit freundlichen Grüßen
Thomas Fischer