Mein Problem mit den Umlauten

[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" ?

[hirnfrei]

Da bekomme ich

Fehler: 'c' does not name a type
   auto c = 'ä';
          ^

zurück...

[Mxt]

Spannend.

Visual Studio 2015 hat ja zwei C++ Compiler. Wenn ich

auto c = 'ä';

mit Clang übersetze, produziert das 'ä' auch eine Warnung.

warning : illegal character encoding in character literal [-Winvalid-source-encoding]
auto c = '<E4>';

das ^ welches die Fehlerposition markiert, steht beim ersten '


Kombiniere, das 'ä' ist anscheinend nicht überall erlaubt und tut nicht was du meinst. Das muss ich auch mal weiter erforschen. Da ist mir was bisher entgangen.

- - - Aktualisiert - - -

=======

Ok,

die Meldung " 'c' does not name a type " kommt wohl eher daher, dass kein C++11 oder 14 eingeschaltet ist und hat somit nicht direkt mit dem Problem zu tun.

Ansonsten wollen g++ oder clang wohl lieber Unicode Quelltextdateien, wenn du da mit Umlauten in Literalen arbeiten willst. Ob einzelne oder doppelte Anführungszeichen macht wohl keinen Unterschied.

Dann nehm für deinen Vergleich halt das ä als Hexkonstante, so in der Art

const char c = 0xe4;

oder was immer der Code des Zeichens bei dir ist.

[hirnfrei]

Ich bekomme

1 c

zurück

[Mxt]

Das ist ok, der g++ ist bei typeid wohl nicht so ausführlich.

Aber dann ist c ein Byte groß und kann daher nicht 50000 sein, schau mal mit dem Debugger hinein.

Funktioniert es, wenn du das ä wie oben durch eine Konstante ersetzt ?

===

Nachtrag: Auf dem Raspi mit Raspian und vim als Editor ist die Ausgabe tatsächlich
4 i
das 'ä' wird dort also 4 Byte groß. Ein "file -bi dateiname" zeigt, dass die Datei als utf-8 gespeichert wird.

[HaWe]

wenn ich mich nicht irre, liest die C-read (scan, getc oder C++ << -) Funktion von stdin nicht einen unsigned char sondern ein int16_t. Man liest ja aus einem FILE * stream und da wird auch grundsätzlich bei eof() eine -1 zurückgegeben (erinnere mich dunkel an so etwas), also kann es kein uchar sein. Die Codierung deutscher Umlaute und Sonderzeichen jenseits ASCII 127 ist dennoch ungewiss.

[Mxt]

Ich habe jetzt auch noch in mehrere Bücher geschaut und außer "das ist implementierungsabhängig" nicht viel gefunden.

Meine Vermutung ist, bei

if(wort[i] == 'ä')

betrachtet der g++ die rechte Seite des Vergleichs als int, also wahrscheinlich einen etwas größeren Zahlenwert (228 ?). Wenn wort ein char Array ist, werden die Werte auf der linken Seite vor dem Vergleich nach int umgewandelt, da kommen dann nur Werte von -126 bis 127 raus, der Vergleich schlägt also immer fehl. (Da holt man sich auch noch wieder das Problem rein, dass auf ARM ein char vorzeichlos ist und auf Intel eines hat.)

Wenn ich meinen Raspi wieder mal auf Arch Linux umgesteckt habe, muss ich das mal mit einem aktuellen g++ 5.3.x vergleichen.

Wahrscheinlich ist man mit den Präfixvarianten für Stringkonstanten sicherer, also L"text", U"text" oder u"text", dann hat man aber immer Unicode in verschiedenen Varianten.

Sonst halt Zahlenkonstanten statt Zeichen, oder eben in Konsolenanwendungen immer englisch schreiben.

[Peter(TOO)]

Hallo,

Ich habe jetzt auch noch in mehrere Bücher geschaut und außer "das ist implementierungsabhängig" nicht viel gefunden.

Deshalb gibt es auch Manual zum Compiler.
Da steht dann in einem Anhang wie das genau ist und welche Parameter was übersteuern.

Meine Vermutung ist, bei

if(wort[i] == 'ä')

betrachtet der g++ die rechte Seite des Vergleichs als int, also wahrscheinlich einen etwas größeren Zahlenwert (228 ?). Wenn wort ein char Array ist, werden die Werte auf der linken Seite vor dem Vergleich nach int umgewandelt, da kommen dann nur Werte von -126 bis 127 raus, der Vergleich schlägt also immer fehl. (Da holt man sich auch noch wieder das Problem rein, dass auf ARM ein char vorzeichlos ist und auf Intel eines hat.)

Da ist halt wieder die Frage, wie char implementiert ist.

Wenn man sicher gehen will, verwendet man char gar nicht!
Sondern explizit unsigned char und signed char.

Ich habe in meinen Programmen vor 30 Jahren ein typedef für uchar und schar verwendet, dann muss ich nicht so viel tippen und es funktioniert mit jedem Compiler.
Mit ANSI-C wurden dann typen wie int8_t und uint8_t eingeführt, welche bei jeder Implementierung gleich sind, eingeführt.

Bibliotheken, welche mit unterschiedlichen Text-Codierungen zurecht kommen, haben meistens eigenen Datentypen, welche an Stelle von char verwendet werden sollten.

Ich habe viel Code geschrieben, welcher meistens auf PC und µC laufen musste (Vor allen Übertragungsprotokolle). Da kommt dann noch das Problem von Little und Big Endian hinzu. Aber wenn man ein paar Dinge berücksichtigt, geht das ganz gut und auch ganz ohne den Code doppelt zu schreiben und mit #if nur Teile zu Compilieren.


MfG Peter(TOO)