Ich erhalte bei der Prüfung eines Chars die obige Warnung (avr-gcc 4.8.1). Mein Code dazu:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
Aber warum? Wo genau ist da das Problem? Irgendwie sehe ichs nicht.
Gast
#4877082
M. K. schrieb: > Aber warum? Wo genau ist da das Problem? Irgendwie sehe ichs nicht. du hast eine Unicode Datei erzeugt. eine 'ü' abhängig von der Codepage. kann auf jeden System etwas anders sein.
Davon hab ich mal wieder keine Ahnung aber du hast recht, Peter. Habs auf non-lossy ASCII umgestellt und das Warning ist weg.
M. K. schrieb: > if (c != 'ü') Weil in dem von dir gewählten Charset 'ü' mehr als 1 Byte belegt, etwa wie in > if (c != 'ab') 'ab' (nicht: "ab") ist gemäß C eine "multi-character character constant".
Hintergrund:
Der Quelltext ist mit utf-8 codiert. Zeichen, die nicht in den
7-Bit-ASCII-Zeichensatz passen, werden mit (mindestens) zwei Bytes
codiert.
Damit ist die "char"-Konstante 'ü' größer als ein Byte.
Es gibt auch 8-Bit-Codierungen, in denen Umlaute verwendet werden
können, eine verbreitete ist "Windows-ANSI", auch "ISO8859-1", "Latin-1"
oder "CP 1252" ("CP" steht für code page) genannt.
Wenn der Quelltext statt mit utf-8 in dieser Codierung vorliegen würde,
wäre die "char"-Konstante 'ü' ein Byte groß.
Wenn man allerdings mit "code pages" arbeitet, muss auch das Zielsystem
mit der gleichen "code page" arbeiten. Die Windows-Konsole verwendet aus
historischen Gründen standardmäßig aber die DOS-Codepage 850 bzw. 437,
in der Umlaute komplett anders codiert sind.
Jetzt muss man entweder im Programm mit der Win32-API-Funktion
SetConsoleOutputCP die gewünschte Codepage einstellen oder aber das
von Hand vor dem Aufruf des Programmes in der Konsole machen (mode con
cp select=nummer).
Das Resultat kann aber trotzdem bescheiden aussehen, wenn in der
Windows-Konsole ein Pixelfont verwendet wird (Standard in allen
Windows-Versionen vor Windows 10). Dieser kann nur die Zeichen aus der
DOS-Codepage darstellen ... Umlaute funktionieren, aber komplizierteres
wie die hochgestellte 3 sind nicht möglich.
Damit das geht, muss man die Konsole dazu bringen, eine Truetypeschrift
zu verwenden (Lucida Console oder Consolas).
Auf Englisch nennt man das resultierende Thema aus gutem Grund "a can of
worms".
Rufus Τ. F. schrieb: > Es gibt auch 8-Bit-Codierungen, in denen Umlaute verwendet werden > können, eine verbreitete ist "Windows-ANSI", auch "ISO8859-1", "Latin-1" > oder "CP 1252" ("CP" steht für code page) genannt. Wobei seit der Einführung des Euro eher ISO-8859-15 gebräuchlich ist, weil das das Euro-Symbol enthält. > Wenn der Quelltext statt mit utf-8 in dieser Codierung vorliegen würde, > wäre die "char"-Konstante 'ü' ein Byte groß. Nicht der Quelltext muss in dieser Codierung vorliegen, sondern sie muss als execution character set gewählt sein. Es gibt in C eine Trennung zwischen dem "source character set", in dem der Quellcode verfasst ist und dem "execution character set", das zur Laufzeit auf dem System genutzt wird, wo der Code ausgeführt wird. Bei gcc kann man diese beiden mit den Optionen -finput-charset und -fexec-charset angeben. Für den obigen Fall würde man also
1 | |
den Compiler-Optionen hinzufügen.
Danke für die Vervollständigung.
Rolf M. schrieb: > Bei gcc kann man diese beiden > mit den Optionen -finput-charset und -fexec-charset angeben. > Für den obigen Fall würde man also-finput-charset=utf-8 > -fexec-charset=iso-8859-15 > den Compiler-Optionen hinzufügen. Das ist ja interessant, das werde ich mal bei Gelegenheit ausprobieren. Meine IDE legt nämlich neue Dateien automatisch als UTF-8 an, ich kam noch nicht dazu zu schaun wo ich das ändern kann.