AW: AW: AW: AW: AW: [Allegro] Trick 74 : GlobaleDollarkrise (Den$globalersetzen)

[Thomas Berger]

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

Hallo Thomas,

(heute habe ich meine Reflexe besser im Griff)

>>> Trotzdem heißt das, dass schon bei
>>> set c0\var "#14 " #14\Ins
>>> eine o-Umwandlung greift, ich kann mir eigentlich nicht vorstellen, 
>>> dass das sinnvoll ist.
>>> Nur für eine Anzeige (z.B. mit mes) wäre das plausibel, aber da 
>>> passiert es gerade noch nicht:
>>> set c0\var "#14 " #14\mes\Ins
>>> zeigt noch das erwartete Härter.
>> passt http://bugzilla.gymel.com/show_bug.cgi?id=512 zu Ihren 
>> Beobachtungen?
> 
> Nein, ich glaube eher nicht.
> Das hat natürlich mit der A99-eigenen Vorgehensweise zum Erhalt der

oh sorry, ich hatte es fuer ein avanti-Problem gehalten.


> Kompatibilität mit DOS-ASCII-basierten Datenbanken zu tun. Wenn ich mit A99 in
> einem Datensatz ein ä durch ein ö ersetzen will, so muss an dieser Stelle ja
> umkodiert werden, wenn ich ANSI eingebe und DOS-ASCII verarbeite.
> Mein Problem ist wohl ein zweifaches:
> 
> 1. Sollte die Möglichkeit bestehen, diese Umkodierung bei einzelnen Aktionen
> gezielt auszuschalten (so hatte ich eigentlich "set c0" verstanden), um eine
> vollständige Kontrolle über die Zeichen zu erhalten.

Aber es geht um einen Flex, der die Ersetzung ausfuehrt, nicht wahr?
Hier benoetigt a99 eine Annahme bezueglich der Codierung des eigentlichen
Jobs, das [koennte natuerlich UTF-8 sein (am BOM erkennbar)] ist m.W.
stets die echte Codierung der Datenbank, daher darf man z.B. Flexe nicht
mit a99 erstellen / bearbeiten, sondern muss den X-Editor nehmen.

[Soweit die Theorie. Im Normalfall macht man es u.U. umgekehrt, denn
Umzucodierendes steht meistens in Dialogtexten, und die werden von a99
nicht automatisch umcodiert, d.h. Texte im Zeichensatz der Datenbank
muessen immer erst in die iV geladen und mit "ansi" vorverarbeitet werden]


> 2. Finde ich, dass die Kodierung des Textes eine Grundeigenschaft der
> Datenbank ist und eigentlich in der *.cfg angegeben werden sollte. Bei
> geeigneter Auswertung könnte das dann auch verhindern, dass unsinnige
> Umkodierungen vorgenommen werden; eine leere o.apt kann ich bestenfalls als
> Krücke bezeichnen.

Ich fand auf dem Expertentreffen interessant, dass die vorgestellten
Unicode-Anwendungen stets auf UTF-8 als internem Speicherformat beruhten,
und nicht auf den ebenfalls denkbaren Varianten CP850 oder ISO8859-1 jeweils
mit expliziten Entitaeten. Denn Umstieg von etwa OSTWEST auf UTF-8 erfordert
ja die tiefgreifendste Transformation der Daten.

Unbeantwortet ist immer noch die Frage nach der offizioesen Loesung fuer
die allmaehliche Migration von bisherigen Datenbanken "nach Unicode" (und
einige Nebenfragen, ob das dann noch $A heissen sollte oder nicht). Eine
.CFG-Einstellung fuer die Deklaration der Zeichencodierung der Daten
(zugreifbar in Export- und Flex-Sprache) koennte die Migration erleichtern.
(Oder waere ein Meta-Satz in der Datenbank ein konzeptuell noch besserer
Weg?)

viele Gruesse
Thomas Berger

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

iQCVAwUBSw+WUWITJZieluOzAQLa5QP/S87gKul2iWWFa+Gn7eMiqFeKdkHIhEPj
gek7iHAERoM/EhM5e/fAxikMgW6ddtTA0z2U2d9CXUyTMhnWR6Mm2OyJGF0oj14L
2ufvRitZpZA2WDqtcJ5RVxgoIqTWFH2rSV91HxcMrss3eKWKwLdTewvrw+g7pcfu
FSQ1LowuuKQ=
=qDy3
-----END PGP SIGNATURE-----