Seltsames Detail um get/ansi/ins/write herum

[Thomas Berger]

Lieber Herr Allers,

> a ä ö ü Ä Ö Ü ß z
> 
> (also: a, a-, o-, u-, Ä-, O-, U-Umlaut, scharfes s, z). Diese Zeile 
> lese ich ein und gebe sie aus in die rtf-Datei aus.rtf, die ich dann 
> zeigen lasse; all das macht folgende Flexdatei:
> 
> 
> 
> xport f aus.rtf\write Fdisphead.rtf
> open ein.txt\get\ansi
> 
>   //Variante 1 (funktionierend):
> write\write n
>   //Variante 2 (nicht für A-Umlaut funktionierend):
>   ins #ux2\write #ux2 n
> 
> write "}"\close\close x
> h aus
> 
> 
> 
> Das riesige Rätsel, das sich mir stellt, ist, warum Variante 1 für 
> _alle_ Zeichen der Eingabedateizeile funktioniert, bei Aktivierung von 
> Variante 2 dagegen (Deaktivierung von Variante 1) das Ä (A-Umlaut) 
> _nicht_ richtig (also nicht als Ä) dargestellt wird!!!

Einen aehnlichen Effekt bekommen Sie hin, wenn Sie folgendes
eingeben: x var "äöüÄÖÜ"\ansi\ansi\asci\show IV
oder x var "äöüÄÖÜ"\asci\ansi\ansi\show IV
d.h. einmal zuviel von Windows nach DOS konvertieren und das
dann Rueckgaengig machen wollen.

"Ä" ist das einzige dieser Zeichen, dessen Windows-Code bei
nochmaliger Anwendung der o-Tabelle nicht eineindeutig
auf das Zeichen 127 abgebildet wird [und ausserdem durch
Zufall das einzige Zeichen aus der Liste, das nicht Ziel
einer Umsetzung durch die o-Tabelle ist]. Das polnische L,
das man in Ihrem Beispiel anstelle des "Ä" sieht, ist das
letzte Zeichen, das per o-Tabelle auf 127 abgebildet wird.

D.h. korrekte Behandlung des "Ä" ist ein prima Indikator
dafuer, ob nicht einmal eine ueberfluessige (und wie wir
gesehen haben auch schaedliche) Umwandlung mittels o-Tabelle
hin und zurueck erfolgt.

Konkret an Ihrem Beispiel laesst sich die Angelegenheit auf
folgenden Flex verkuerzen:
x open ein.txt\get\ansi\mess\ins #ux2\var #ux2\mess

beim ersten "mess" ist das "Ä" noch korrekt, beim zweiten
nicht mehr. Betrachtet man #ux2 im Hintergrundspeicher, so
ist dies schon nicht korrekt. Es wird also beim "ins"-Befehl
eine Ueberfluessige (und schaedliche) Leer-Umwandlung
iv -> ANSI -> ASCII -> #ux2 durchgefuehrt, ein klarer Bug
von a99 [Dass es nicht ASCII -> ANSI ist, kann man mittels
des Zeichen 228 entscheiden: Das a mit Breve (188) wird hier
in #ux2 ebenfalls zerstoert:
x var "äļ"\ansi\ins #ux2\mess\var #ux2\mess

viele Gruesse
Thomas Berger