STM32, CooCox CoIDE, GCC, merkwürdiger Effek t mit Umlauten

May 24, 2013 10 Replies
S

Hallo, ich habe hier einen merkwürdigen Effekt mit der CooCox CoIDE festgestellt.



wenn ich



---------------------- unsigned char b; b = 'ä'; // b = umlaut a



----------------------



ausführe, hat b anschließend nicht den Dezimalwert 132, wie erwartet, sondern 228.



Wenn ich im Editorfenster der IDE 132 eingebe, erscheint wie erwartet das kleine 'ä'.



Irgendwie scheint der Compiler da den Zeichensatz zu verwurschteln.



Wir können und jetzt behelfen, indem wir


------------------- if (b=='ä') b=132;



-------------------



aufrufen, aber das finde ich irgendwie bescheuert. Mit den anderen Umlauten haben wir ein vergleichbares Problem.



Gibt es da eine Option im Compiler, oder in der IDE?



Gruß



Stefan



Vote
Twitter Facebook LinkedIn
C

Stefan schrieb:

228 ist doch der Code für 'ä' in ISO 8859(-1) und in Windows-1252. Bestimmt speichert die IDE den Quellcode in dieser Zeichencodierung. Warum sollte sie irgendeine MS-DOS Codepage verwenden, in der 'ä' einmal 132 war?

Christian

Christian Zietz - CHZ-Soft - czietz (at) gmx.net WWW: http://www.chzsoft.de/ PGP/GnuPG-Key-ID: 0x6DA025CA
Vote
Twitter Facebook LinkedIn
S

Am 24.05.2013 08:42, schrieb Christian Zietz:

Ich war davon ausgegangen, dass der Editor wenn ich 132 eingebe und der Editor ein 'ä' anzeigt, dieses auch als Zeichen 132 gespeichert wird.

Gruß

Stefan

Vote
Twitter Facebook LinkedIn
E

Stefan schrieb:

Das ist bestimmt ein Vorzeichenproblem, was passiert denn, wenn Du "b" als "int" deklarierst? Normalerweise sind Zeichen ja "char" und nicht "unsigned char" und als char kann 'ä' nicht den Dezimalwert 132 annehmen, weil der Wertebereich von -127 bis +128 geht.

Vote
Twitter Facebook LinkedIn
S

Am 24.05.2013 09:02, schrieb Edzard Egberts:

Nein, als unsigned char geht der Wertebereich von 0-255.

Die Antwort von Christian war schon korrekt. Offenbar arbeitet GCC bzw. die CooCox CoIDE mit dem ISO 8859 Zeichensatz.

Gruß

Stefan

Vote
Twitter Facebook LinkedIn
C

Stefan schrieb:

Windows übersetzt aus Kompatibilitätsgründen diese Eingaben aus MS-DOS-Zeiten in die jeweilige Zeichencodierung. Gib mal 0228 ein...

Christian

PS: Die 'ä' in Deinem Posting sind auch alle als 228 codiert. Oh nein!

Christian Zietz - CHZ-Soft - czietz (at) gmx.net WWW: http://www.chzsoft.de/ PGP/GnuPG-Key-ID: 0x6DA025CA
Vote
Twitter Facebook LinkedIn
E

Stefan schrieb:

Vertan, -128 bis 127 ist richtig.

Das ist mir schon klar, ich dachte z.B. an so etwas:

unsigned char b= 'ä'; if (b == 'ä') // ist immer false, weil bei der Zuweisung gecastet wurde

Die Arbeit mit "unsigned char" kann tückisch sein, wenn man mit "signed char" mischt.

Okay, in die falsche Codepage geguckt, ist natürlich die ganz einfache Lösung. ;o)

Vote
Twitter Facebook LinkedIn
A

Stefan schrieb:

vielleicht hilft Dir das weiter:

mit >ALT 132< kommt das ascii - ä raus. mit >ALT 0228< kommt das ansi - ä raus.

Gruß Andreas

Vote
Twitter Facebook LinkedIn
W

Andreas Fecht schrieb:

Interessant, wie stellt man das den bei einem 7-Bit-Code wie ASCII dar? ASCII-ä war nach ISO-646 in Deutschland 123.

Gruß Willi

Vote
Twitter Facebook LinkedIn
T

Willi Marquart schrieb:

Andreas hat nur ASCII mit DOS verwexelt - was für viele Leute scheinbar

synonym ist.

(und ISO-646 mit seinen unzähligen Ländervarianten kennt heute eh kau m noch jemand...)

Tilmann

Vote
Twitter Facebook LinkedIn
M

Wieso (immer)?

Hint: es gibt Architekturen, wo "char" unsigned ist.

cu Michael

Vote
Twitter Facebook LinkedIn

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required