Mein Problem mit den Umlauten

[hirnfrei]

Mahlzeit!

Ich hoffe das ist okay wenn ich die Frage hier stelle, hat sie doch nicht soo viel mit Ki oder so zu tun.

Ich versuche aus einem Wort die Umlaute zu ersetzen. Bislang habe ich zum Ersetzen von Buchstaben in einem char String immer folgendes gemacht:

.
.
.
for(i=0;i<wortlang;i++)
{
    if(wort[i] == 'ä') wort[i] = 'a';
.
.
}
.
.
.

Doch mache ich das bekomme ich eine solche Meldung:

Warnung: multi-character character constant [-Wmultichar]

Schockiert mich irgendwie. Funktioniert das mit den Umlauten nicht oder wie?

[Peter(TOO)]

Hallo,

Schockiert mich irgendwie. Funktioniert das mit den Umlauten nicht oder wie?

Und gleich noch der nächste Schock:
Es gibt gar keine Buchstaben, nur Zahlen!

Eine CPU weiss rein gar nichts über Buchstaben!
Wir haben verschiedene Codes Entwickelt und die Buchstaben durchnummeriert.
Für dein Problem musst du dir des ASCII-Code und den Unicode ansehen.
Die Zuordnung für die Zahlen 0...127 ist dabei noch identisch, aber darüber wird es dann sehr unterschiedlich.
Da ASCII von den Amis stammt, hatten diese keinen Bedarf für Sonderzeichen.
Die Europäer haben dann einige, im Schriftverkehr wenig benutze, Zeichen mit den Umlauten belegt. Das waren z.B. "[" und "]". Listings sahen dann etwas komisch aus, vor allem auf dem Drucker.
Man hat dann die 7-Bit auf 8-Bit erweitert, da gibt es aber für die zweiten 128 Zeichen unterschiedliche Varianten, bekannt als Codepages.

Normalerweise arbeiten Tastatur und Monitor eines PCs mit dem selben Zeichensatz, da scheint dann auf dem Monitor alles normal.
Wenn dann der Drucker mit einem anderen Zeichensatz arbeitet, was früher oft der Fall war, kommt auf Papier was anderes raus.

PC arbeiten heute meistens mit Unicode, da werden Sonderzeichen intern mit 2 Bytes dargestellt und dein Editor legt dies auch so in der Datei ab.

Dein Compiler erwartet nun aber einen 8-Bit ASCII-Code und da passen die zwei Bytes nicht rein.

Du musst also entweder deinen Editor so einstellen, dass er nur ASCII-Code erzeugt oder deinen Compiler so einstellen, dass er Zeichen aus mehreren Bytes verarbeiten kann. Letzteres hat dann aber Einfluss auf die Bibliotheken und wenn du Textnachrichten wieder nach aussen sendest (Display, Schnittstelle).

MfG Peter(TOO)

[hirnfrei]

Also doch keine so lahme Sache wie ich gedacht habe. Wenigstens etwas .

Danke für die ausführliche Antwort!

[i_make_it]

Es kommt noch schlimmer.
ASCII Code - 1 Byte: 7 Bit je Zeichen (Erweitert: 8 Bit)
http://www.chip.de/ii/1/2/5/4/9/5/8/...e7009f26b0.png

ANSI Code - 1 Byte: 8 Bit je Zeichen
http://www.itwissen.info/bilder/zeic...ansi-codes.png

Undicode - 2 Byte je Zeichen
http://unicode-table.com/de/#control-character

[Mxt]

Hallo,

Ich hoffe das ist okay wenn ich die Frage hier stelle, hat sie doch nicht soo viel mit Ki oder so zu tun.

was glaubst du denn, warum mein Beispiel zu den Threads eine englische Ausgabe hatte ?

Aber im Ernst, ich denke da beschwert sich der Compiler über die Codierung des Quelltextes. Abseits von Raspi und Beaglebone bin ich nicht so der Linux Programmierheld, ich kann da nicht sagen, wie deine Entwicklungsumgebung das handelt.

Wenn man mit internationalen Texten im Programm zu tun hat, sollte man eigentlich nicht mehr mit char arbeiten. Das Problem ist, dass man dann Portierbarkeit verliert. Unter Windows hat man es dann normalerweise bei wchar_t mit UTF-16 (meistens zwei Byte, wie oben gesagt, aber nicht immer) zu tun, unter Linux entweder mit UTF-8 (ein bis vier Byte) oder UTF-32 (immer vier).

http://unicode.org/faq/utf_bom.html

[hirnfrei]

Also ich kann mich auf den Kopf stellen, ich bekomme kein äöü verglichen. Habe jetzt meine Funktion auch auf STRING umgestellt, hilft aber auch nicht. Auch locale hat nichts gebracht.

Lustig ist, wenn ich

printf("%d\n", 'ä');

verwende, dann bekomme ich in der Konsole

50084

zurück. Drehe ich den Spiess aber um mittels

printf("%c\n", 50084);

bekomme ich nur ein Symbol zurück.

Hätte ja nicht gedacht, dass drei so kleine Zeichen das Leben so schwer machen können. Zumal ich zu meinen Hochzeiten im Programmieren, das war auf dem Amiga mit StormC, damit nie Probleme hatte. Da hatte ich eine eigene Mailinglist aufgebaut, die auch nach Wörtern mit Sonderzeichen suchen konnte und das hat nie Probleme gemacht.

[Mxt]

printf("%d\n", 'ä');

das gibt bei mir unter Windows -28. Das (signed) char ist größer als 127 und wird in einen int umgewandelt, klingt plausibel.

Erzähl mal mehr über Editor, OS und Compiler.

[i_make_it]

Das Problem gibt es auch im gewerblichen Bereich öfters.
Der Mainframe spricht ASCII, der Middleware Server ANSI und das Webfontend Unicode.
Grade wenn das dann von 3 Verschiedenen Anbietern kommt (von denen keiner über den eigenen Tellerrand schaut) macht die Integration besonders viel spaß.
Üblicherweise einigt man sich dann auf eine Codierung und schreibt für die anderen beiden je einen Parser, der eine Umcodierung vornimmt bevor man mit der Verarbeitung beginnt.

Wenn der Text aus Dateien eingelesen wird, efentuell mal in den Metadaten der Dateien checken ob dort das Codierungsformat angegeben ist.
Ansonsten über das Dateiformat (nicht nur die Dateierweiterung des Namens) selektieren.

[hirnfrei]

Das ist eine Eingabe mit getchar(). Wird korrekt eingelesen und mit cout auch wieder korrekt ausgegeben.

OS: Gentoo Linux 64 Bit
IDE: Qt-Creator 3.4.2
Compiter; GCC 4.9.3 64 Bit

[Mxt]

Ja, wie schon gesagt, schein mir nicht der Wert zur Laufzeit das Problem zu sein, sondern die Konstante 'ä' im Quelltext. Das scheint ja die "multi character constant" zu sein.

Da es ja C++ ist, was liefert denn

int main()
{
    auto c = 'ä';
    std::cout << sizeof(c) << " " << typeid(c).name() << std::endl;

    return 0;
}

bei dir ?

Wirklich "1 char" ?