Konvertierungsproblem unter VC 6.0

Hallo zusammen,

das Problem ist folgendes, jedes mal wenn ich ein Ä, Ü, Ö oder eines der sonstigen Sonderzeichen einem BYTE (oder char) zuweise erhalte ich den falschen ASCII-Wert. Umgekehrt erhalte ich als Ausgabe das richtige Sonderzeichen wenn ich den richtigen ASCII-Wert Eingabe.

Für das Ä erhalte ich z.B. C4, richtig wäre aber 8E!
Für 8E erhalte ich dann allerdings das Ä!

Woran liegt das?

Gruß Jens

Hallo zusammen,

das Problem ist folgendes, jedes mal wenn ich ein Ä, Ü, Ö oder
eines der sonstigen Sonderzeichen einem BYTE (oder char)

Was denn nun? Byte oder Char oder doch was anderes?

zuweise erhalte ich den falschen ASCII-Wert. Umgekehrt erhalte
ich als Ausgabe das richtige Sonderzeichen wenn ich den
richtigen ASCII-Wert Eingabe.

Nein. ASCII ist nur eine 7 Bit Zeichentabelle (0-127 dezimal, 0-EF hex). Alles weitere hängt von der verwendeten Codepage ab. Es gibt mindestens so viele Codepages wie Mitarbeiter bei der Firma Microsoft.

Gruß

Fritze

Was denn nun? Byte oder Char oder doch was anderes?

BYTE natürlich, habe mit char nur ausprobiert ob es ein anderes Ergebnis bringen würde.

Nein. ASCII ist nur eine 7 Bit Zeichentabelle (0-127 dezimal,
0-EF hex). Alles weitere hängt von der verwendeten Codepage
ab. Es gibt mindestens so viele Codepages wie Mitarbeiter bei
der Firma Microsoft.

Laut der MSDN Library habe ich doch genau 256, also 0 bis 255, ASCII-Werte und ich möchte genau diese, dort abgebildeten Werte, nach der Zuweisung in meinem BYTE haben! Sprich für Ä also den Hex-Wert 8E!
Wo könnte ich denn die verwendete Codepage ändern? Hab das bis jetzt noch nie gebraucht!

Gruß Jens

Hallo,

Laut der MSDN Library habe ich doch genau 256, also 0 bis 255,
ASCII-Werte und ich möchte genau diese, dort abgebildeten
Werte, nach der Zuweisung in meinem BYTE haben!

Dann wirf die MSDN Library in die Tonne. ASCII hat 128 Zeichen (7 Bit). Ein Byte hat natürlich 8 Bit und damit 265 Werte und in den erweiterten Codepages von Micro$oft, ISO und anderen Gremien werden auch 256 Zeichen zugeordnet, aber das ist nicht ASCII!

In Westeuropa ist eigentlich ISO-8859-1 (oder mit Euro-Zeichen: ISO-8859-15) üblich. Dort ist ein „ä“ unter dem Wert 0xE4 und ein „Ä“ unter 0xC4 zu finden. Wie Du auf 0x8E gekommen bist, ist mir schleierhaft.

Wo Du bei Deinem Visual Dingsbums in welchen Bibliotheken die Codepages einstellen kannst, müsste in der Dokumentation enthalten sein. Da kann ich Dir leider nicht weiterhelfen.

Gruß

Fritze

Hallo Jens,

Nein. ASCII ist nur eine 7 Bit Zeichentabelle (0-127 dezimal,
0-EF hex). Alles weitere hängt von der verwendeten Codepage
ab. Es gibt mindestens so viele Codepages wie Mitarbeiter bei
der Firma Microsoft.

Laut der MSDN Library habe ich doch genau 256, also 0 bis 255,
ASCII-Werte und ich möchte genau diese, dort abgebildeten
Werte, nach der Zuweisung in meinem BYTE haben! Sprich für Ä
also den Hex-Wert 8E!

Ich muß Fritze schon recht geben. ASCII ist der „American Standard Code of Information Interchange“ und regelt wirklich nur die Werte 0-127 (00-7f). Die Werte darüber sind nicht standardisiert, daher auch das Konvertierungs-Chaos zwischen den Rechnern.

Zu deinem Problem: Soweit ich weiß, verwendet Windows intern inzwischen keinen ASCII-Code mehr, sondern legt alles in UTF-16 ab. Dabei werden Sonderzeichen (und zu diesen zählen Umlaute) in 16 Bit abgebildet. Wenn du nun irgendwie herumcastest, um aus UTF-16 ein Byte zu machen, so paß das offenbar nicht. MS bietet da irgendwo Methoden an, mit denen man zwischen verschiedenen Codierungen wechseln kann, wo genau, weiß ich aber nicht, da ich bloß mathematische Kerne programmiere! :wink:

Chris

Hallo,

Zu deinem Problem: Soweit ich weiß, verwendet Windows intern
inzwischen keinen ASCII-Code mehr, sondern legt alles in
UTF-16 ab.

Wenn dem tatsächlich so ist, dann ist das mal wieder typisch, denn es wäre eine denkbar schlechte Lösung. Warum das so ist, und warum UTF-8 die weit bessere Wahl wäre, dazu siehe:

http://www.tldp.org/HOWTO/Unicode-HOWTO-1.html

Insbesondere folgendes möchte ich mal zitieren:

The Microsoft Win32 approach makes it easy for developers to produce Unicode versions of their programs: You „#define UNICODE“ at the top of your program and then change many occurrences of char' to TCHAR’, until your program compiles without warnings. The problem with it is that you end up with two versions of your program: one which understands UCS-2 text but no 8-bit encodings, and one which understands only old 8-bit encodings.

vielleicht hilft ja der Hinweis.

Gruß

Fritze

Hallo,

danke für die Hilfe, aber ich habe jetzt eine ganz einfache Lösung gefunden. Die Klasse CString stellt mir eine Funktion AnsiToOem zur Verfügung, und nachdem ich die Funktion auf meinen String angewendet habe, bekomme ich tatsächlich die richtigen Hex-Werte!

MfG Jens Hauger