Also jetzt mal Klartext (wfstream)
-
Sorry, aber die wide-char Version funktioniert einfach nicht. Ich kann nicht total bescheuert sein.
Wenn ich mit << L"isuldgf" was in ne Datei schreibe, steht es trotzdem im ANSI Format drin.
Wenn ich Unicode auslese, hab ich trotzdem "H A L L O W E L T" ausgelesen.
Das saugt einfach, jetzt darf ich wieder die WinAPI dafür benutzen. Der erste, der mit Standard C++ das Unmögliche möglich macht, nämlich Dateien im Unicode Format zu bearbeiten, kriegt von mir einen Keks.
-
Optimizer schrieb:
Wenn ich mit << L"isuldgf" was in ne Datei schreibe, steht es trotzdem im ANSI Format drin.
Wie findest du heraus, dass es im ASCII-Format ist (ANSI ist was anderes)?
Wenn du ein Unicode-Text mit Notepad öffnest kannst du nicht merken, dass es Unicode ist, außer man sieht arabische, japanische oder sonstige asiatische Zeichen.
Wenn du mit dem Hex-Editor nachsiehst, und es steht sowas wie "50 00 20 00 38 00" (<- Im zweiten Byte steht immer nur 0x00 wenn ASCII Zeichen in Unicode Zeichen umgewandelt werden), dann kannst du sicher sein, dass es Unicode ist.Optimizer schrieb:
Wenn ich Unicode auslese, hab ich trotzdem "H A L L O W E L T" ausgelesen.
Das saugt einfach, jetzt darf ich wieder die WinAPI dafür benutzen. Der erste, der mit Standard C++ das Unmögliche möglich macht, nämlich Dateien im Unicode Format zu bearbeiten, kriegt von mir einen Keks.Das Problem mit den Abständen zwischen den Zeichen habe ich schon selber erlebt, und auch irgendwie gelöst, jedoch weiß ich nicht mehr wie ich das gemacht habe...(ich hab da aber mit C-Funktionen gearbeitet, fopen, fclose etc.)
Erst kürzlich hatte ein User, das selbe Problem mit wfstreamS geschildert. Scheint weitläufig zu sein, das Problem, aber ich überlege noch ob ich versuchen werde es zu lösen. Du kannst nur hoffen
-
Aziz schrieb:
Wenn du ein Unicode-Text mit Notepad öffnest kannst du nicht merken, dass es Unicode ist, außer man sieht arabische, japanische oder sonstige asiatische Zeichen.
Vertrau mir, ich kann das rausfinden.
Und das Problem mit den Abständen rührt daher, dass er einzelne Bytes (also ANSI Code) ausliest und damit bei jedem normalen Text jedes zweite Byte ein nicht druckbares Zeiten (nämlich 0) ist.
wfstream ist ganz offensichtlich nicht dazu in der Lage, Dateien im Unicode Format zu bearbeiten. Korrigiert mich, wenn ich (hoffentlich) falsch liege...
-
Kann das ein Locale-Problem sein?
-
Wie meinen?
-
Aziz schrieb:
Erst kürzlich hatte ein User, das selbe Problem mit wfstreamS geschildert. Scheint weitläufig zu sein, das Problem, aber ich überlege noch ob ich versuchen werde es zu lösen. Du kannst nur hoffen
ja, und ich warte immer noch ganz sehnlichst auf ne Antwort
btw. @Optimizer, kanns sein das ich dir mit meinem Problem den Anstoß zu dem Thread gegeben hab ?
-
Welches Encoding verwendest Du?
-
Hallo,
Aziz schrieb:
Wenn du mit dem Hex-Editor nachsiehst, und es steht sowas wie "50 00 20 00 38 00" (<- Im zweiten Byte steht immer nur 0x00 wenn ASCII Zeichen in Unicode Zeichen umgewandelt werden), dann kannst du sicher sein, dass es Unicode ist.
genauer steht in den ersten zwei Bytes (oder im Extremfall vier) die sogenannte "Byte-Order mark"(BOM), die über die verwendete Codierung und über Little/Big Endian-Format Auskunft gibt:
BOM:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_42jv.aspAnwendungen können über das Auslesen und Interpretieren dieser Bytes die entsprechenden (Dekodierungs-)Maßnahmen treffen
MfG
-
-
hm, das is doch UTF-16 oder täusch ich mich da jetz komplett ?
-
Ähm ja, 2 Bytes halt. *g*
:hier ist ein Smiley, dass sich an die Stirn haut:
