[Allegro] Teilfelder, UTF-8 und Windows 7

[Fischer, Thomas]

Hallo Herr Eversberg,

> Bernhard Eversberg
> Gesendet: Montag, 9. Dezember 2013 12:21
> An: Allegro-C Diskussionsliste
> Betreff: Re: [Allegro] Teilfelder, UTF-8 und Windows 7
>
> Am 09.12.2013 12:12, schrieb Fischer, Thomas:
> >
>>>> Ich habe Bedenken, das Zeichen in meiner UTF-8-Datenbank auf ASCII
>>>> 178 abzubilden

>>> Warum?

>> weil ich nicht ausschließen kann, dass 178 als Teil einer UTF-8-Codierung
>> auftritt und mir dann bei der Umcodierung hässliche Dinge passieren
>> könnten.
>> Das ist im Prinzip der Grund, warum ich mit leerer o-Tabelle arbeite.

> Aus genau dem Grunde hatten wir für die CFG den Befehl C eingeführt:
>
> CU
>
> bewirkt, daß Code-Sequenzen, die mit einem Wert >191 bzw. >224
> beginnen,
> mitsamt des nachfolgenden bzw. der zwei nachfolgenden Codes nicht
> per o-Tabelle gewandelt werden. Das stand in Vb.251

meine Bedenken haben sich jetzt insoweit bestätigt, als ich mit der Konstellation
A99 V. 34.2,  Standard O-Datei, Setzung von CU in der Konfigurationsdatei
Probleme habe, meine Datenbank zu bearbeiten.

Vorher (leere O-Datei) konnte ich UTF-8-codierten Text als ISO-Latin-1 aufrufen und so in das Bearbeitungsfeld einfügen.
Das geht mit dieser Konstellation nicht, es findet eine Umcodierung statt, die die Daten unleserlich macht.
Bei leerer O-Datei zeigt das Datenfenster die Latin-1-Codierung an, mit der obigen Konstellation  wird dort umcodiert.
Wenn ich das Feld so wie angezeigt eintrage, werden Sonderzeichen zerstört.
Allerdings ist mein Eindruck, dass die Setzung von CU darauf keinen Einfluss hat.

Konkret bekomme ich im Auswahl- und Schreibfeld mit Standard-O. at PT (mit oder ohne CU in der Konfiguration)
#14 v. Braunmhl, Prof. (Mnchen)
und mit leerer O.GPT
#14 v. Braunmühl, Prof. (München)
, bei beiden natürlich
#14 v. Braunmühl, Prof. (München)
in der Anzeige.

Kann es sein, dass CU noch gar nicht implementiert ist oder in Version 34 wieder herausgefallen ist?

Mit freundlichen Grüßen
Thomas Fischer