main + unicode
-
Windows ruft die "main" oder "wmain" nie auf... das macht alles dir CRT... um es also ganz genau zu erfahren, musst Du Dir einfach nur den Source der CRT anschauen....
Die CRT verwendet intern einfach "GetCommandLineA"; und Windows verwendet normal für die Konvertierung immer CP_ACP...WARUM verwendest Du nicht einfach "GetCommandLineW"????
-
Nash26 schrieb:
ich weiß der richtige weg ist mit winmmain und wchar zu benutzen,
Ansichtssache, ich würde sagen main/wmain ist für Commandline-Utilities der bessere Weg.
aber in welche codierung bekomme ich die zeichenkette bei char, in irgendwas muss windows das ja konvertieren.
In der die im System eingestellt ist. Die "Language for non-Unicode applications" oder wie die Einstellung auch immer heisst.
Auf deutschen Windosen üblicherweise CP1252.Die Frage die sich dann stellt ist, kann ich den char string dann nach unicode wieder richtig konvertieren?
Nur wenn der ursprüngliche String verlustfrei in die System-Codepage konvertiert werden konnte. Was natürlich nicht immer der Fall ist, CP1252 "kann" ja nur ein paar wenige Zeichen.
Wenn die nötigen Daten noch da sind kannst du MultiByteToWideChar() verwenden mit CP_ACP als Quell-Codepage. Dann bekommst du wieder UTF-16 raus.
Aber wie Jochen schon schreibt: du kannst immer GetCommandLineW verwenden, egal wie der Entry-Point deines Programmes heisst. Damit bekommst du immer die Original-Commandline in UTF-16.
-
okay kleines Beispiel:
ich bin auf einem japanischen system und übergebe meiner Applikation einen japanische zeichenkette. Windows konvertiert nun den utf16 string nach der lokalen codepage(die ich annehme auf japanisch ist), kann es dann sein, das da zeichen verloren gehen, also die Konvertierung nicht korrekt ist?Ich würde sagen ja, da eine codepage nur 255 zeichen enthält und japanisch, keine Ahnung Tausend zeichen? Somit kann die Konvertierung nur im wenigen fällen funktionieren.
-
Schon mal was von MBCS gehört?
-
Wer hat dir gesagt, dass eine Codepage 255 Zeichen fasst? Dem würde ich gerne mal in die Eier treten.
Die mitteleuropäische Codepage 1252 fasst 256 Zeichen, das stimmt. Aber was machen wohl die Chinesen (hier ein besseres Beispiel, japanisch kann man auch in Hiragana und Katakana umschreiben, da sind wir bei ~50 Zeichen pro Schrift mal 2 = 100 Zeichen, latainisches Alphabet dazu plus Kleinschreibung sind noch mal 52 (also insgesamt 152) 32 Steuerzeichen (184) und von 256 abgezogen bleiben immer noch 72 Zeichen, die man nach Lust und Laune codieren kann, das kann auch ASCII nicht besser treffen)? Die müssen vor Unicode ja richtig gelitten haben (hier kann man nichts umschreiben außer ins lateinische Alphabet) - oder haben Zeichensätze verwendet, die über 255 Zeichen hinausgehen, das nennt man dann 'Multi-Byte-Character-Set' oder 'MBCS'. Ein Bereich des 8-Bit-Blocks wird als 'Gehe-Weiter'-Marker angesehen - taucht das auf, wird auch das nächste Zeichen noch für die Darstellung beachtet.
-
okay, aber meine Frage wurde jetzt nicht beantwortet.
Gehen zeichen verloren, wenn ich von Unicode nach lokaler codepage konvertiere?
Vorrausgesetzt die Codepage ist korrekt eingestellt.
-
Wenn lokal alles korrekt eingestellt dann geht nix verloren.
Wenn Du aber Chinesisch auf einem Deutschien System mit der CP_ACP konvertiert, dann geht sehr wohl was verloren....Man kann es also nicht definitiv sagen, wenn Du uns nicht die Zeichen sagst die Du konvertieren willst und das entsprechende Zielencoding...
-
Das ist eigentlich genau das was ich wissen wollte.
Windows kann also verlustfreit von einem utf16 string nach einer codepage konvertieren, vorrausgesetzt die richtige ist eingestellt.Anbei eine kleine zusatzfrage, windows benutzt ja wchar_t für unicode zeichen,
diese sind unter Windows ja 2 byte groß.
Das heißt ca. 65K zeichen können dargestellt werden und alles was über 65K ist kann nicht dargestellt werden, da Unicode momentan bei ca 100K codepoints angekommen ist, heißt das doch Windows ist nicht mehr 100% unicode kompatibel, weil 2Byte nicht ausreichen? Korrekt?
-
Nein.
Windows verwendet UTF-16, damit können alle Unicode Zeichen dargestellt werden.
-
-
