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

[Thomas Berger]

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

Lieber Herr Eversberg,


>> Dieses Verhalten [ASCII -> ANSI -> ASCII  beim insert-Befehl]
>> war mir bislang nur bei Avanti aufgefallen ...
>> ..., sollte aber abgeschafft werden,
>> weil es unsauber ist:
>>
> Einfach schlankweg abschaffen können wir es nicht, weil dann
> womöglich etliche FLEXe nicht mehr korrekt funktionieren.

Mir ist das nicht einleuchtend:

Ihrer "Fussnote" ist doch zu entnehmen, dass jeglicher Text
aus Flexdateien zunaechst einmal via o.apt in die Windows-
Codierung gebracht wird, um anschliessend wie eine Eingabe
im Schreibfeld zurueck in die DOS-Codierung gebracht und
ausgefuehrt zu werden. Allerhoechstens set c bzw. switch
coding interferieren damit insofern, dass derzeit evtl.
"gesetzt" bedeutet, dass der zweite der obigen Schritte
abgeschaltet wird, waehrend es nach einer Optimierung
bedeuten wuerde, dass der erste der obigen Schritte dennoch
ausgefuehrt wird (ich kann aber nicht entscheiden, ob
set c1 nicht bereits jetzt eine dreifache Umcodierung
bedeutet)

Es gibt allerdings den Fall, der momentan zu Prolemen fuehrt
und nach einer Saeuberung sich daher u.U. anders verhaelt:
Angenommen, ich bin ein Fan von Notepad und bette meine
Stringkonstanten daher (konsequent oder fallweise, etwa vor
"select") Windows-codiert in die Flex-Dateien ein, wobei ich
sorgfaeltig darauf achte, sie vor Benutzung ggfls. mit "ascii"
explizit in die benoetigte Codierung zu wandeln:
Derzeit erfolgt damit dann folgendes:
a Text im Flex (Windows-codiert)
b implizite Anwendung von o.apt (doppelt-Windows-Codiert,
  d.h. gewisse Zeichen gehen auf 127)
c implizite Rueck-Anwendung von o.apt (obige Zeichen gehen
  auf 217)
d "ascii"-Kommando: Nochmalige Rueck-Anwendung von o.apt
  (obige Zeichen gehen auf 242)
[Prominentestes Beispiel ist das Grosse Ae "Ä").


> Es wird aber ein  set c2  geben, womit man die jetzt stets
> aktive Umcodierung  ANSI -> ASCII auch noch abschalten kann.

set c0/c1 beziehen sich auf Datei Ein- und Ausgabe (Default c0)
und funktionieren gut. Set c2 wuerde mit seiner Wirkung wo
ansetzen?

> (Nun ja, mit Set U2 kann man sie auch jetzt schon abschalten,
> wenn's denn unbedingt sein muß und es keine Kollisionen mit
> Unicode geben kann - das nur nebenbei)

> Nachzudenken ist natürlich auch, ob die interne Codierung der Datenbank
> nicht irgendwo stehen sollte - und wo sonst, wenn nicht in der CFG?
> Eine FLEX-Variable sollte dann zumindest darüber informieren.
> Als Kommentar reinschreiben kann man es jederzeit, das ist klar.

Ob eine Datenbank OSTWEST-, CP850-, oder CP437-codiert ist, kann niemand
entscheiden (ich habe vor Jahren einmal existierende Datenbanken
statistisch ausgewertet und konnte es selbst dann nicht entscheiden,
im Zweifelsfall ist es ein Mix oder eine noch nicht entscheidbare
Frage, weil ueberhaupt kein fuer den Unterschied relevantes Zeichen
vorkommt). Die Parameterdateien verhalten sich seit Version 13 so, als
sei die Datenbank OSTWEST-codiert (bzw. nach dem Vorlaeufer "VGAFONT").
Solange nicht auf allen Ebenen die Semantik festgehalten wird (also
die allgegenwaertigen Umcodierungstabellen jede fuer sich sagen, von
wo nach wo sie konvertieren), bringt eine Systemsetzung des
Zeichensatzes keinen Mehrwert (sondern ist nur eine tendenziell
wiederspruechliche Notiz mehr). Zwei Setzungen hingegen koennten eine
Wirkung zeitigen (Setzung 1: Speicherformat ist x, Setzung 2:
Verarbeitungsformat ist y), damit koennte zwischen den Ebenen 0. und 1.
aus meiner Darstellung eine Konversion eingebaut werden. Aber welchen
Nutzen hat eine .ALD-Datei im Format UTF-8, wenn jegliche Verarbeitung
(insbesondere Eingabe) erst nach Wandlung von/nach OSTWEST ansetzt?
Umgekehrt waere es als Migrationshilfe denkbar: Mit UTF-8 Parametern
Alt-Datenbanken verarbeiten. Aber es gibt bekanntlich keine Plaene,
das GUI Unicode-tauglich zu machen, insofern sind UTF8-Parameter und
Flexe nichts, was funktionieren koennte...


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

iD8DBQFHEz9IhKFJT0F1FsoRAvDrAJ9+D8RwPR0QRJqOxe+bDWgZp6bbfwCggBj4
XJNnjHeMxZWlB96pGqqo+R8=
=Mu9T
-----END PGP SIGNATURE-----