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

Mo Okt 15 11:03:45 CEST 2007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg, liebe Liste,

> Fußnote zur Umcodierung
> =======================
> Wenn man im FLEX schreibt:
> var "xyz"\ins #nnn
> was passiert dann?
> Dann wird der Text, der in der iV steht, so behandelt, als hätte man
> ihn gerade im Schreibfeld eingegeben. Und was ist das Problem?
> Was man im Schreibfeld eingibt, das ist intern immer ANSI-Code.
> Im FLEX kann es aber sein, wenn er z.B. mit X-Editor erstellt
> wurde oder wenn man ASCII-Daten bearbeitet, daß der iV-Inhalt nicht
> ANSI ist, sondern ASCII. Was per Schreibfeld eingegeben wurde,
> das wird per o-Tabelle der Indexparameter in den internen Daten-
> bankcode gewandelt, normalerweise also von ANSI nach ASCII.
> Deshalb wird im Normalfall unser ASCII-"xyz" VOR der Übergabe an
> die Verarbeitung noch per o-Tabelle nach ANSI gewandelt - um dann
> sofort wieder zurückverwandelt zu werden. Na schön, dann ist es

Dieses Verhalten war mir bislang nur bei Avanti aufgefallen (oder
hatte ich es bei a99 nur verdraengt), sollte aber abgeschafft werden,
weil es unsauber ist:

Ich stelle mir die Interaktion der verschiedenen Komponenten als
auf verschiedenen Ebenen liegend vor:

0. Die Repraesentation der Zeichen in der Datenbank, also wie
  sie in den .ald-Dateien konkret gespeichert sind.
  Diese ist nicht klar geregelt. Sie kann (A.CFG) CP437 oder CP850
  oder allegro-OSTWEST sein, ohne dass irgendjemand weiss, welches
  von den dreien. Sie kann (etwa Neutralformat) allegro-Windows
  oder CP1252 oder ISO8859-1 sein, oder UTF-8 oder eine beliebige
  andere Codetabelle.

1. Die Repraesentation bei der Vearbeitung eines Datensatzes, also
  waehrend er im Arbeitsspeicher ist.
  Diese ist identisch mit der vorigen, denn allegro sieht keine
  globalen Einlese- bzw. Wegschreibefilter vor.
  Auch Anwendervariable unter Kontrolle von Parameterdateien,
  insbesondere #u1 in den Sonderabschnitten #-1, #-2 etc. der
  Indexparameterdatei sehen Benutzereingaben nicht wie eingegeben,
  sondern in den Zeichensatz der Anwendung gewandelt.

2. Das Zeichenmodell der Flex-Sprache, sowohl in a99 als auch in Avanti:
  Sprachkonstrukte der Flex-Sprache sind in 7-bit-ASCII. Spezielle
  Flex-Komponenten wie die iV und $-Variable werden bei der Interaktion
  mit Kategorien im Arbeitsspeicher keiner Wandlung unterzogen (also
  etwa "var #20" oder "var $otto\ins #20" loest keine implizite
  umcodierung aus) folgerichtigerweise sind Zeichenkonstanten, die im
  Flex-Quelltext eingebettet sind als *im Zeichensatz der Datenbank*
  codiert zu betrachten: var "Müller".
  An dieser Stelle greift das oben in der Fussnote beschriebene
  Verhalten, das solche "Müller" zweimal wandelt, bis guenstigstenfalls
  der Originaltext genommen wird, unguenstigenfalls etwas, das niemand
  kennt.
  [Vage erinnert: Gab/Gibt es nicht ein Umcodierungsproblem mit der
  "zweiteiligen" Form qrix "von at bis", oder lag das nur auf der Ebene
  der Parameterdatei (Umcodierungsabschnitt wurde fuer den Endebegriff
  nicht ausgefuehrt?]

3. Interaktion mit Ein- und Ausgabe:
  Die DOS-Module nehmen hier keine Wandlung vor.
3a.  Eingaben im Schreibfeld (und in der Suchbefehlszeile) von a99
  muessen global mittels o.apt in den Zeichensatz der Anwendung
  umgewandelt werden und dann abgearbeitet (als Belegung einer Kategorie
  oder als Flex). Die Fussnote oben legt nahe, dass dies nicht ganz
  genau so passiert, sondern dass zunaechst an den Trennzeichen "\"
  zerlegt und dann in den Zeichensatz der Datenbank gewandelt wird.
  Ausserdem gab/gibt es (nur Avanti?) Probleme mit dem Zeichen 255 der
  Windows-Codetabelle (y mit Trema), die es eigentlich nicht geben
  sollte. Diese Behandlung mittels o.apt erfolgt in a99 automatisch,
  also "transparent"
3b. Ausgaben und Eingaben in den beiden Indexfenstern, im
  Formularfenster und im Kurzlistenfenster und Views erfolgen ebenfalls
  transparent, d.h. es erfolgt eine automatische Wandlung hin- und
  zurueck mittels o.apt zwischen der Zeichencodierung der Datenbank
  und der der Benutzeroberflaeche.
3c. Ausgaben im Anzeigefeld erfolgen unter Kontrolle der Parameterdatei
  und den *head.rtf und erfordern beachten der Umcodierung (etwa durch
  einbinden von d.apt). Direkte Schreibaktionen ins Anzeigefeld mittels
  "show" erfordern vorherige explizite Umcodierung (Flex-Befehl "ansi")
3d. Anzeige von (DOS-)Hilfetexten in Alertboxen unterwirft diese einer
  impliziten Umcodierung
3e. Alertboxen (mess, yesno) und Abfragen (select) erfordern eine
  explizite Wandlung des anzuzeigenden Textes sowie (select) eine der
  Benutzereingabe
3f. Fenstertitel und Ergebnismengennamen (set i) muessen explizit
  gewandelt werden, bei Fenstertiteln mit grosser Vorsicht, weil hier
  der Systemzeichensatz (typischerweise CP1252) getroffen werden muss
  und nicht die o.apt-gewandelte Windows-Repraesentation des Datenbank-
  zeichensatzes.
3g. RTF-Hilfedateien und eingebettete Flips sind wie im RTF-Header
  angegeben codiert (naja, sie geben normalerweise "\ansi\ansicpg1252"
  an, obwohl sie allegro-Windows-codierte Fonts benutzen. Zu testen
  waere, wie eingebettete Flexe codiert werden muessen, wenn man eine
  "\ascii"-codierte RTF-Datei nutzen will)
3h. In den Flip-Sondervariablen sind sowohl die Flips #uX* und #uZ*,
  als auch die Fangtexte #uY* in der Codierung der Datenbank (das ist
  konsistent mit 1. oben)
[noch etwas vergessen?]

Strenggenommen gibt es keinen Grund, warum (3e und 3f, ueber "show"
liesse sich streiten) fuer die Anseteuerung des GUI die notwendigen
Umcodierungen explizit erfolgen muessen und nicht alles transparent
wie bei den anderen GUI-Elementen ablaeuft.

4. Es gibt nun noch Codierungsbefehle in der Flex-Sprache,
4a. set c0/c1 bzw. switch coding
   Ganz alte Versionen von avanti etwa verstanden den gesamten Job
   (also das aktuelle Flex-Programm) als "ANSI"-codiert, mit "switch
   coding" konnte man das aendern. Bereits bei Avanti 1.7. jedoch
   war das Default wie bei 2. beschrieben. Diese Form der Globalitaet
   ist eher problematisch, weil der Befehl ja nicht ausserhalb der
   Flexdatei steht, auf die er wirkt und diese bereits teilweise
   abgearbeitet ist.
   set c0/c1 bezieht sich lt. Dokumentation v.a. auf folgende
   Dateioperationen (Einlesen und Wegschreiben), die dann bei
   set c1 einer Umcodierung durch o.apt unterworfen werden.
   Zu klaeren waere noch, ob sich "set c" ueberhaupt noch auf im
   Flex eingebettete Stringkonstanten (qrix PER "Müller")
   bezieht, bzw. ob hier Unterschiede zwischen a99 und avanti
   bestehen bzw. zwischen "set c" und "switch coding"
4b. set U0/U1/U2
   bezieht sich auf die Unicode-Semantik, jedoch nur auf "insert"-
   Befehle. Ein und Ausgabe sind also nicht betroffen!
[  In (live generierten) avanti-Jobs darf man daher nicht erzeugen
   lassen
qrix PER "$Benutzereingabe"
   sondern muss diese von avanti wandeln lassen:
set U1
#u22 PER "$Benutzereingabe"
set U0
var #u22
switch coding 0
qrix
switch coding 1
  (switch coding 1 hier korrekt?). Das ist zwar etwas umstaendlich,
  dafuer aber gut kontrollierbar.
]

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHEyzxhKFJT0F1FsoRApAxAJsGCsBpA+22DusvDgHk63u5QeGj6QCeLWCo
KriXmyyvhyOnS/tDA8Wa4Vw=
=hXYL
-----END PGP SIGNATURE-----