CFStringGetCString UTF8 to ISO-8859-1

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • CFStringGetCString UTF8 to ISO-8859-1

    Ich hatte ja vor einigen Wochen schon Mal nachgefragt wie ich von C++ auf die Resourcen zugreifen kann. Das hat soweit dann auch alles gut funktioniert. :thumbup:

    Jetzt stehe ich aber vor dem folgenden Problem:

    Ich möchte mit


    "cfString = CFBundleCopyLocalizedString(CFBundleGetMainBundle(), cfString, CFSTR("Error"), CFSTR("Localizable"));"


    eine String aus den Resourcen auslesen und in einen cString umwandeln

    "CFStringGetCString(cfString, buffer, 256, kCFStringEncodingWindowsLatin1);"



    Das funktioniert gut solange der String keine Umlaute enthält. Sobald Umlaute vorkommen sind statt deren "wirre Zeichen" im cString. Irgendwie habe ich das Gefühl, dass die Zeichen eben nicht in ISO-8859-1 (also ASCII von 0 bis 255) umgewandelt werden sondern weiterhin im UTF-8 Format sind. Habe für das "Encoding"-Format auch schon andere Werte ausprobiert, aber auch ohne ein passendes Ergebnis.


    Was mache ich falsch bzw. wie funktioniert es richtig? ?(

  • CFString bzw NSString speichern die strings immer im gleichen format (intern). folglich sollte es kein problem sein dir die daten als WindowsLatin1 geben zu lassen.
    Funktioniert es nicht, dann ist wahrscheinlich der string schon falsch in den CFString reingekommen. Also das CFBundle erwartet dass die loc-strings in UTF8 sind, du hast sie aber als MacRoman abgespeichert. somit liest er sie schon falsch ein. überprüf das mal!

  • macmoonshine schrieb:

    Zwischen WindowsLatin1 und ISO-8859-1 ist ein Unterschied. Das ist nicht der gleiche Zeichensatz.
    Stimmt, einen leichten Unterscheid gibt es da, mir würde zur Not aber auch WindowsLatin1 reichen. Ich brauche halt den erweiterten ASCII-Bereich von 0 bis 255 mit allen Umlauten.

    @gritsch: Müssen die Localisable.strings nicht in UTF-16 sein?
    Meine Localisable-Strings sind in UTF-8, ich habe es aber auch schon mit UTF-16 ohne Erfolg probiert.

    Das Ergebnis z.B. vom Wort "ändern" schaut als cString immer so aus: "\xe4ndern" :(


    Hat vielleicht noch jemand eine andere Idee?

  • RA/pdx schrieb:

    Das Ergebnis z.B. vom Wort "ändern" schaut als cString immer so aus: "\xe4ndern"

    Das die C-Escape-Syntax in Deinem C-String steht, ist äußerst ungewöhnlich. Was zeigt Dir denn das Programm xxd (1) für das Wort in Deiner Localizable.strings-Datei an?

    Es sollte ungefähr so aussehen:

    Quellcode

    1. 0000000: 626c 6120 696e 2062 6c75 6220 e46e 6465 bla in blub .nde
    2. 0000010: 726e 2e0a rn..

    (Beispieltext: bla in blub ändern.)
    „Meine Komplikation hatte eine Komplikation.“

  • gritsch schrieb:

    RA/pdx schrieb:

    So, habe es mal mit einem Hexeditor ausgelesen:

    22 C3 A4 6E 64 65 72 6E 22 "ändern"


    das ist aber kein UTF16 - so sollte es aussehen:

    fffe e400 6e00 6400 6500 7200 6e00 ....n.d.e.r.n.

    Stimmt, der Dump von RA/pdx ist UTF-8 meiner ist UTF-8.

    EDIT: Meiner ist natürlich ISO-8859-1 :sleeping:

    Es bleibt die Frage, warum der String ein C-Escape enthält. Was enthält der denn für eine Bytefolge?
    „Meine Komplikation hatte eine Komplikation.“

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von macmoonshine ()

  • macmoonshine schrieb:

    gritsch schrieb:

    RA/pdx schrieb:

    So, habe es mal mit einem Hexeditor ausgelesen:

    22 C3 A4 6E 64 65 72 6E 22 "ändern"


    das ist aber kein UTF16 - so sollte es aussehen:

    fffe e400 6e00 6400 6500 7200 6e00 ....n.d.e.r.n.

    Stimmt, der Dump von RA/pdx ist UTF-8 meiner ist UTF-8.

    Es bleibt die Frage, warum der String ein C-Escape enthält. Was enthält der denn für eine Bytefolge?


    ich denke das zeigt er nur bei der ausgabe an.

    sprich die lösung des problems wäre es die strings-datei nach utf-16 zu KONVERTIEREN.

  • RA/pdx schrieb:

    Ja, das war UTF-8, in UTF-16 schaut es allerdings genauso aus. Und das gibt auch das gleiche Ergebnis zum Schluss im cString.

    Hmm, oder liegt das am Hex-Editor (ich verwende Hex-Friend)?


    also von mir aus gesehen stimmt das ergbnis ja!
    du willst das ä als WinLatin1. das ist nunmal xe4 -> folglich stimmt ja dein cString.
    Nur die ausgabe wird eben nicht korrekt gemacht. wie gibst du es denn aus? mit printf?

  • Ausgegeben wird das ganze über eine Bibliothek die den Text als 3D-Objekte in OpenGL darstellt.

    Erwartet wird aber das jedes Zeichen genau ein Byte (0-255) groß ist und nur so können dann auch Umlaute mit dargestellt werden. Muss ich dann den C-String quasi erst noch per Hand konvertieren?

  • RA/pdx schrieb:

    Ausgegeben wird das ganze über eine Bibliothek die den Text als 3D-Objekte in OpenGL darstellt.

    Erwartet wird aber das jedes Zeichen genau ein Byte (0-255) groß ist und nur so können dann auch Umlaute mit dargestellt werden. Muss ich dann den C-String quasi erst noch per Hand konvertieren?


    der cString IST bereits WinLatin1 - nur die ausgabe ist falsch (erwartet wohl was anderes als WinLatin1)

  • macmoonshine schrieb:

    RA/pdx schrieb:

    Ausgegeben wird das ganze über eine Bibliothek die den Text als 3D-Objekte in OpenGL darstellt.

    Kann die Bibliothek überhaupt Umlaute darstellen?
    Ja, das kann sie definitiv (habe sie ja vor einiger Zeit für ein anderes Projekt selber geschrieben ;) ).

    Wenn ich einen cString im Programm mit "const char* text = "ändern" erzeuge und übergebe wird der Text auch korrekt dargestellt. Es funktioniert aber eben irgendwie nicht mit Texten die ich aus Localizable.strings auslese. Irgendwas geht da mit der Konvertierung schief...

  • RA/pdx schrieb:

    macmoonshine schrieb:

    RA/pdx schrieb:

    Ausgegeben wird das ganze über eine Bibliothek die den Text als 3D-Objekte in OpenGL darstellt.

    Kann die Bibliothek überhaupt Umlaute darstellen?
    Ja, das kann sie definitiv (habe sie ja vor einiger Zeit für ein anderes Projekt selber geschrieben ;) ).

    Wenn ich einen cString im Programm mit "const char* text = "ändern" erzeuge und übergebe wird der Text auch korrekt dargestellt. Es funktioniert aber eben irgendwie nicht mit Texten die ich aus Localizable.strings auslese. Irgendwas geht da mit der Konvertierung schief...


    dann wird aber auch nicht WinLatin1 verwendet:

    c3 a4 6e 64 65 72 6e