Einführung in Codepages und Unicode
-
kannst du zeigen wie man MultiByteToWideChar und WideCharToMultiByte richtig einsetzt? gibt es sonst noch wichtige konvertierungsfunktionen?
-
goleo schrieb:
kannst du zeigen wie man MultiByteToWideChar und WideCharToMultiByte richtig einsetzt?
Hab ein richtiges Beispiel dem Artikel hinzugefügt.
goleo schrieb:
gibt es sonst noch wichtige konvertierungsfunktionen?
Aus meiner Sicht nicht.
Ok, es gibt da noch die .NET-Funktionen zum Konvertieren (werde ich auch noch demnächst als Beispiele aufführen).
Es mag da noch im ICU Funktionen geben die ich mir aber noch nicht angeschaut habe.
Es gibt da dann auch noch die "mbtowc" und diverse "_mb*" Funktionen; ich würde sie aber nicht verwenden, da man nicht direkt eine locale (CP) angeben kann (nur bei der CRT8 geht dies mit dem "*_l" Funktionen. Diese greifen aber intern alle auf das MultiByteToWideChar (oder eben das Gegenteil) zurück. Kommt eben immer darauf an, ob man Platformunabhängig sein will (dann aber eher ICU).
-
@Jochen Kalmbach:
Was sollte man (unter Windows) für MBCS -> wide-char Konvertierungen verwenden, wenn man diese dem File System füttern will? Also welche Flags? Bei MultiByteToWideChar steht ja in der MSDN default ist MB_PRECOMPOSED - ich nehme daher an Windows verwendet bei der internen, automatischen CP_ACP -> UTF-16 Konvertierung (wenn ich z.B. CreateFileA verwende) auch MB_PRECOMPOSED. Weisst du zufällig ob dem so ist? Und nur damit ich sicher bin, MB_PRECOMPOSED müsste mir dann Normalform "C" ausspucken, oder?
Cooler Artikel im übrigen, danke schön
-
hustbaer schrieb:
wenn ich z.B. CreateFileA verwende
Das hängt ganz davon ab....
Du kannst es nämlich via API bestimmen, was verwendet werden soll:
Siehe:
- SetFileApisToANSI
- SetFileApisToOEM
-
Schöner artikel nur du hast 2 UNICODE Codierungen vergessen:)
Und zwar UCS-2 und UCS-4.
-
UCS ist kein Unicode. Unicode ist zu UCS kompatibel. So rum wird ein Schuh draus.
-
UCS ist keine Kodierung... UCS-2 war der erste (Fehlentwurf) der Unicode-Organisation... aktuell ist man jetzt bei UCS-4 (oder einfach nur Unicode-Version 5).
Unicode-Kodierungen beginnen i.d.R. mit UTF-x
-
Ok UCS ist keine Zeichenkodierung in dem Sinne.
Aber UCS(Universal Character set) spezifiziert einen Zeichensatz.Sprich UCS-2(16Bit) und UCS-4(32Bit) definieren die maximale anzahl der zeichen die darin gepeichert werden können.
Die ganzen UTF-X formate sind nichts anderes als "UCS Transformation Formate"
sprich es sind Formate, welche definieren, wie ein UCS-zeichen kodiert wird.z.b. UTF-8 sagt, das jedes Unicode-zeichen in eine folge von 8bit-blöcken kodiert wird.
UTF-16 ist vergleichbar mit UCS-2 sprich jeder UTF-16 2byte Wert entspricht einem zeichen in dem UCS-2 Zeichensatz.
Das selbe gilt für UTF-32 und UCS-4.
Das man UCS-2 als fehlentwurf ansieht finde ich auch falsch. UCS-4 ist im prinzip nur ne Weiterentwicklung von UCS-2 um den zeichenvorrat zu erhöhen.
Um z.b. damit auch Mathematische Formelzeichen im Zeichensatz ihren platz haben können.
Der UCS-2 Zeichensatz reicht normalerweise aus um 90-99%(Angabe dieses Wertes ohne Gewähr) der tagtäglich verwendeten Zeichen zu halten.
Also ist UCS schon ein teil von Unicode und zwar definiert es den Zeichensatz.
Und UTF-X sind nichts anderes als Spezifikationen, wie man die einzelnen Zeichen des Unicode Zeichensatz kodiert.
-
Vielen Dank für diesen echt wertvollen Beitrag Jochen!
Hat mir wirklich weiter geholfen ^^
-
Boost.Locale bietet Unterstützung für einige Unicode-Algorithmen an (auf Basis von ICU).
