Einführung in Codepages und Unicode



  • SideWinder schrieb:

    Lässt einem aber auhc hart auf den Boden fallen: Wann endlich ein Zeichensatz um sie alle zu knechten? 🙂

    Ich muss sagen, ich verstehe den Kommentar nicht ganz 😕
    ADD: Ach so... so langsam verstehe ich den Kommentar... ich muss sagen, ich hab die Bücher nie gelesen 😞



  • Ich möchte ergänzen, dass die im Artikel erwähnte International Components for Unicode Library (ICU http://icu.sourceforge.net/]) auch ausgezeichnet unter Windows funktioniert.
    Desweiteren werden in dieser Library auch folgende Themen behandelt:

    * Reguläre Ausdrücke
    * Lokalisierung
    * Tranformation
    * Wortgrenzen (siehe auch "CJKV Information Processing" http://www.oreilly.com/catalog/cjkvinfo/index.html)

    Wenn man portablen Code schreibt, so ist der Einsatz dieser unter der "Open Source License" stehenden Komponente allemal empfehlenswert.

    Gruesse,
    Gerhard



  • 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).


Anmelden zum Antworten