C++ | If-Abfrage funktioniert nicht und ich weiß nicht warum

Quiche Lorraine

@wpi
Mein liebstes UTF 16 Zeichen ist Malayalam: ഊ

In Hex Darstellung 0x0D0A. Es erinnert mich immer daran einzelne Zeichen immer abhängig von der aktuellen Kodierung zu interpretieren.

wob

@Quiche-Lorraine sagte in C++ | If-Abfrage funktioniert nicht und ich weiß nicht warum:

Mein liebstes UTF 16 Zeichen ist Malayalam: ഊ
In Hex Darstellung 0x0D0A.

Was ist ein UTF16-Zeichen? Ein Unicode-Zeichen in UTF16-Kodierung? Was ist "Hex-Darstellung" genau? Ich frage wegen BigEndian vs LittleEndian...

Eine Datei mit diesem Inhalt:

FF FE 0D 0A 0D 00 0A 00 0A 0D 0D 00 0A 00
      ^^^^^ unbekant    ^^^^^ dein Symbol

wpi

So besser? Ist man mit char16_t auf der sicheren Seite (Unicode)? Ich habe es nicht ausprobiert:

/**
 * This function reads from a file specified by the filename parameter and writes to another file.
 * It replaces all characters 'ä', 'ö' and 'ü' with their corresponding uppercase version.
 *
 * @param filename The name of the file to read from.
 *
 * @return void
 *
 * @throws None
 */
void readFromAndWriteToFile(std::string filename)
{
    std::unordered_set<char16_t> toReplace{(char16_t)'ä', (char16_t)'ö', (char16_t)'ü'};

    std::ifstream infile(filename);
    std::ofstream outfile(filename + ".out");
    std::string line;
    while (std::getline(infile, line))
    {
        for (int i = 0; i < line.size(); i++)
        {
            if (toReplace.find(line[i]) != toReplace.end())
            {
                char16_t before = line[i];
                line[i] = toupper(line[i]);
                // describe what you did:
                std::cout << "replaced " << before << " with " << line[i] << " at index " << i << "\n";
            }
        }
        outfile << line << std::endl;
    }
}

Was ist eigentlich mit der Fehler-/Ausnahmebehandlung? Gerade bei Dateioperationen kann doch alles schiefgehen, was schiefgehen kann ...

wob

@wpi sagte in C++ | If-Abfrage funktioniert nicht und ich weiß nicht warum:

Ist man mit char16_t auf der sicheren Seite (Unicode)?

Nein.

Unicode ist auch nicht gleich eine Kodierung von sich selbst. Und ein Unicode-Zeichen kann auch in UTF-16 aus 2 16-Bit-Werten bestehen.

wpi

@wob sagte in C++ | If-Abfrage funktioniert nicht und ich weiß nicht warum:

Nein.

Dann ist

@wpi sagte in C++ | If-Abfrage funktioniert nicht und ich weiß nicht warum:

{(char16_t)'ä', (char16_t)'ö', (char16_t)'ü'}

bestimmt auch Nonsense ...

*john 0

Wenn Du auf der sicheren Seite sein willst, müsstest Du UTF-32 nutzen. Das Problem ist nur, dass man das eigentlich nur auf einem UNIX/Linux nutzt, und man da gleich wchar_t nutzen kann. Auf UNIX wurden die beiden Formate UTF-8 und UCS-4 genutzt. Da aber Windows UTF-16 nutzt, und das Format nicht der Lage ist alle Codes aus UTF-8 bzw. UCS-4 zu kodieren wurde der Zeichenbereich im RFC 3629 eingeschränkt und das UCS-4 Format in UTF-32 umbenannt.

Wenn Du Zeichenketten mit einem Code pro Zeichen willst, kannst Du unter UNIX/Linux wchar_t nutzen, unter Windows musst Du jedesmal von/zu einem uint32_t konvertieren oder Du musst Dein Code so anpassen, dass er die Kodierung UTF-16 beherrscht.

hustbaer

@wob sagte in C++ | If-Abfrage funktioniert nicht und ich weiß nicht warum:

@Quiche-Lorraine sagte in C++ | If-Abfrage funktioniert nicht und ich weiß nicht warum:

Mein liebstes UTF 16 Zeichen ist Malayalam: ഊ
In Hex Darstellung 0x0D0A.

Was ist ein UTF16-Zeichen? Ein Unicode-Zeichen in UTF16-Kodierung? Was ist "Hex-Darstellung" genau? Ich frage wegen BigEndian vs LittleEndian...

Eine Datei mit diesem Inhalt:
FF FE 0D 0A 0D 00 0A 00 0A 0D 0D 00 0A 00
      ^^^^^ unbekant    ^^^^^ dein Symbol

Was soll Endianness da bitte für eine Rolle spielen? Ich denke es ist wohl ziemlich klar dass mit 0x0D0A der Unicode Codepoint U+0D0A gemeint war. Und der ist sowohl in UTF-16 als auch in UTF-32 immer als eine einzelne Code-Unit mit dem Wert 0x0D0A kodiert. Wenn man das so schreibt, dann ist das unabhängig von der Endianness. Genau so wie es unabhängig von der Endianness ist wenn ich schreibe dass ich irgendwo einen int mit Wert 0x12345 habe.

Also, ja, Klugscheissen schön und gut. Aber wenn, dann bitte richtig. Und nicht mit komischen Argumenten die in sich Quatsch sind.

firefly

@john-0 sagte in C++ | If-Abfrage funktioniert nicht und ich weiß nicht warum:

Wenn Du auf der sicheren Seite sein willst, müsstest Du UTF-32 nutzen. Das Problem ist nur, dass man das eigentlich nur auf einem UNIX/Linux nutzt, und man da gleich wchar_t nutzen kann. Auf UNIX wurden die beiden Formate UTF-8 und UCS-4 genutzt. Da aber Windows UTF-16 nutzt, und das Format nicht der Lage ist alle Codes aus UTF-8 bzw. UCS-4 zu kodieren wurde der Zeichenbereich im RFC 3629 eingeschränkt und das UCS-4 Format in UTF-32 umbenannt.

Wenn Du Zeichenketten mit einem Code pro Zeichen willst, kannst Du unter UNIX/Linux wchar_t nutzen, unter Windows musst Du jedesmal von/zu einem uint32_t konvertieren oder Du musst Dein Code so anpassen, dass er die Kodierung UTF-16 beherrscht.

Das stimmt auch nur bedingt das ein UTF-32 Codepoint = ein Zeichen ist. Denn Unicode kennt auch Elemente, wo ein Zeichen aus mehreren codepoints besteht.
Wobei das für die meisten Sprachen nicht von relevanz ist. AFAIK trifft man auf solche Zeichen meist aus dem Bereich der Emoji wo die zusätzlichen codepoints für modifier genutzt werden.
z.b. der Hautton für eine Hand
waving hand: (U+1F44B)
waving hand: light skin tone: (U+1F44B U+1F3FB)
https://unicode.org/emoji/charts/full-emoji-modifiers.html

wob

@hustbaer sagte in C++ | If-Abfrage funktioniert nicht und ich weiß nicht warum:

Was soll Endianness da bitte für eine Rolle spielen? Ich denke es ist wohl ziemlich klar dass mit 0x0D0A der Unicode Codepoint U+0D0A gemeint war.

Genau nicht. Da stand ja gerade nicht "Codepoint", sondern "UTF-16 Zeichen in Hex-Darstellung". Ich fand das ganz und gar nicht eindeutig. Es fängt ja schon mit der Frage an, was genau ein "UTF-16 Zeichen" ist. Hex-Darstellung könnte der als Zahl interpretierte Wert sein (das wäre dann Endianness-Unabhängig) oder eben die beiden Bytes direkt hintereinander. Um auch gerade den Unterschied zu "UTF-8 Zeichen" (auch hier, was ist das? Aber wenn es ein UTF-16-Zeichen gibt, dann auch ein UTF-8-Zeichen) klar zu machen, kann eigentlich nicht U+... gemeint sein, sondern die direkte Darstellung in der Kodierung.

Ich wollte eigentlich nur darauf aufmerksam machen, dass UTF-16 noch das Endianness-Problem hat und ich daher ein großer Fan von UTF-8 bin. Gut, das konnte man aus meinem Post nur mit viel gutem Willen herauslesen

*john 0

@firefly sagte in C++ | If-Abfrage funktioniert nicht und ich weiß nicht warum:

Das stimmt auch nur bedingt das ein UTF-32 Codepoint = ein Zeichen ist.

Sorry, für die falsche Nomenklatur. Ich meinte Codepoint und nicht Zeichen.

hustbaer

@wob sagte in C++ | If-Abfrage funktioniert nicht und ich weiß nicht warum:

@hustbaer sagte in C++ | If-Abfrage funktioniert nicht und ich weiß nicht warum:

Was soll Endianness da bitte für eine Rolle spielen? Ich denke es ist wohl ziemlich klar dass mit 0x0D0A der Unicode Codepoint U+0D0A gemeint war.

Genau nicht. Da stand ja gerade nicht "Codepoint", sondern "UTF-16 Zeichen in Hex-Darstellung". Ich fand das ganz und gar nicht eindeutig. Es fängt ja schon mit der Frage an, was genau ein "UTF-16 Zeichen" ist.

Ich sag ja nicht dass es gut formuliert ist. Aber ich denke es gibt nur eine sinnvolle Auslegung, und das ist "Unicode Zeichen das in UTF-16 als 0xXXXX dargestellt wird".

Hex-Darstellung könnte der als Zahl interpretierte Wert sein (das wäre dann Endianness-Unabhängig) oder eben die beiden Bytes direkt hintereinander.

Hm. Ich finde das nicht unklar. Wenn da 0x1A2B steht, dann ist für mich klar dass die Zahl 0x1A2B gemeint ist, und nicht zwei Bytes 0x1A, 0x2B. Wenn man nur 1A2B schreibt ist es mMn. nicht klar. Und 0x1A, 0x2B ist auch nicht super eindeutig - eben weil ohne Kontext nicht klar ist wie die Reihenfolge der beiden Bytes zu verstehen ist.

Um auch gerade den Unterschied zu "UTF-8 Zeichen" (auch hier, was ist das? Aber wenn es ein UTF-16-Zeichen gibt, dann auch ein UTF-8-Zeichen) klar zu machen, kann eigentlich nicht U+... gemeint sein, sondern die direkte Darstellung in der Kodierung.

Die direkte Darstellung der Kodierung ist bei UTF-16 für Zeichen in der BMP halt gleich. Wie gesagt, ich sag nicht dass es gut formuliert war. Speziell für Leute die noch nicht sehr sattelfest in der Materie sind also schlecht, weil sie sich dann u.U. diese ungenaue Ausdrucksweise aneignen. Ich sag nur dass es, wenn man sich auskennt, eigentlich ziemlich eindeutig war.