[Allegro] Trick 57: Sauberes Filtern (Ohne Umcodierung)

[Bernhard Eversberg]

Thomas Berger schrieb:

> 
> D.h. wenn ich im Schreibfeld eingebe (Flip)
> 
> x var "Müller"\ins #20
> 
> dann passiert folgendes:
> 
> 1. Umwandlung ANSI->ASCII, danach habe ich - wie auch im
> Fall einer Flex-Datei - DOS-codiert
> 
> var "Müller"
> ins #20
Ja. Von dem Punkt ab ist ein direkt eingegebener und ein
aus Datei eingelesener FLEX völlig gleichwertig.

> 
> 2. Bei "ins #20" passiert aber ein merkwuerdiger Schlenker der
> eine Vereinheitlichung mit dem Fall direkter Eingabe
> #20 Müller
> im Schreibfeld bewirken soll, d.h. die iV wird ANSI-codiert,
> in ein Protostadium von #20 eingetragen und das Resultat
> sofort ASCII-codiert und als #20 im Arbeitsspeicher abgelegt?
Ja.

> 
> 
> D.h. "ins" sollte im allgemeinen auch ganz ohne Magie das
> gewuenschte tun (wie auch in Flexe eingebettete direkte
> Zuweisungen bzw. "update"-Daten
> #kkf ...
> ) und man koennte doch - oder ist es dazu zu spaet - die "ins"-Magie
> von set U umbauen in einen Wandlungsbefehl der iV in sich selbst,
> so wie "ascii" und "ansi" das tun.
> 
Wenn man "set U1" gegeben hat, ist davon auszugehen, daß der dann
folgende und mit "ins" einzuspeisende TEXT unverfälschtes UTF-8 ist und
nicht etwa eine ASCII-Variante von UTF-8 oder so etwas, was es ja auch
gar nicht gibt. (Direkteingabe per Schreibfeld können wir für solche
Fälle ja wohl auch ausschließen!)
Folgerichtig unterbleiben nach "set U1" die o.apt-Wandlungen.
Wird eine UTF-8-Zeichenfolge gefunden, für die es keinen u-Befehl
gibt, wird sie in eine Entitaet &...; gewandelt, bei "set u2"
unterbleibt dies und die Kombination somit unverändert.


B.E.