Unicode - von wegen ...
-
Hallo!
Ich muss mal ein wenig meinem Ärger Luft machen.
Die Unicode-Unterstützung von C++ ist wirklich ein Unding. Die Größe von wchar_t ist nicht festgelegt, bei VC++ sind es nur 2 Byte (was nicht reicht, um alle Unicode-Zeichen darzustellen), bei anderen Compilern sind es 4 Byte.
Dann denkt man, man könnte mit wcout oder wofstream Unicode in die Konsole bzw. in eine Datei schreiben - Fehlanzeige. Schreibt einfach mal einen wchar_t-String in einen wofstream - nicht einmal da ist festgelegt, wie das nun in die Datei kommt. Bei mir nimmt jedes Zeichen einfach 1 Byte ein statt sizeof(wchar_t), und alles über 255 wird einfach nicht dargestellt - ein Reinfall. Und das selbst dann, wenn ich den Stream binär öffne!
Was soll das?
Was haben "die" sich dabei gedacht?
Das bringt doch keinem was und macht nur unnötigen Ärger!Mit std::locale komme ich auch nicht weiter. Bei mir gibt es keine locale für UTF-8, UTF-16, UCS-2 oder UCS-4.
Kennt jemand eine gute Library oder sonstige Hilfestellungen?
Danke.
Qbert²
-
Java
-
Troll
-
Qbert² schrieb:
Mit std::locale komme ich auch nicht weiter. Bei mir gibt es keine locale für UTF-8, UTF-16, UCS-2 oder UCS-4.
Das ist ein Problem deiner Umgebung. Zwar ist Unicode-Unterstützung in C++ nicht standardisiert, aber das bedeutet auch, dass man sie dennoch anbieten kann. Und genau das tun andere Compiler z.B. der gcc unter Ubuntu. Dort stellt dank Locales wie z.B. de_DE.UTF8 sowohl das Auslesen als auch das Schreiben von UTF-8 mit Standard-Klassen wie wofstream überhaupt kein Problem dar. Dein Ärger sollte sich also nicht nur gegen den Standard sondern auch gegen Microsoft richten. Denn offenbar nutzt du ja den VC++
Allerdings solltest du mit Suchbegriffen wie "codecvt" und "facet" Google genug entlocken können, um selbst ein entsprechendes Locale nachzuliefern.
-
Der Standard schreibt die Möglichkeit für verschiedene Codierung vor. Im Standard steht nirgends, das z.B. UTF-8 in einer Standard-Lib funktionieren muß. Also ist deine Aufregung unberechtigt.
Du benutzt den MSVC? Gut, dieser hat die Dinkumware C++ Standardlib dabei. MS macht da selber nichts. Sie kaufen die Lib bei Dinkumware ein. Und in dieser MSVC-Variante fehlt halt der UTF-8-Support. Ja, das ist schade aber legitim, da damit der Standard trotzdem erfüllt wird.
Lösung? Einfach ein UTF-8-Codierung hinzufügen. Die C++-Streams sind Plugin-fähig, und zwar mittels codecvt. Von Boost gibts kostenlos eine utf8-codecvt. Habe ich aber nicht ausprobiert.
Oder du kaufst bei http://www.dinkumware.com die KOMPLETTE C++-Dinkumware-Lib-Implementierung mit allen möglichen Codierungen ein. Wenn du UTF-8 u.a. unbedingt brauchst, sind dir diese auch das Geld wert?! Kostet glaub ich 99 US$.
Hier eine Übersicht:
http://www.dinkumware.com/manuals/default.aspx?manual=compleat&page=index_cvt.html
Und die möglichen Codierungen:
http://www.dinkumware.com/manuals/default.aspx?manual=compleat&page=index_cvt.html#Code ConversionsIch finde, da ist einiges mit C++ möglich.
-
Qbert² schrieb:
Die Unicode-Unterstützung von C++ ist wirklich ein Unding. Die Größe von wchar_t ist nicht festgelegt, bei VC++ sind es nur 2 Byte (was nicht reicht, um alle Unicode-Zeichen darzustellen), bei anderen Compilern sind es 4 Byte.
Vielleicht schaust du dir mal die folgende Seite an, ich kann dir aber nicht genau sagen was das Projekt alles abdeckt, da ich bislang nur maginal damit beschäftigt habe: http://www.icu-project.org/
Initiert von IBM und wohl von einigen großen Projekten verwendet.
cu André
-
wchar_t hat nichts mit unicode zu tun. wchar_t soll laut standard nur groß genug sein, um ,soweit vorhanden, den erweiterten Zeichensatz der Systeme enthalten zu können(also mehr als char, welches nur die im standard festgelegten zeichen anzeigen muss) und damit kompatibel mit den BS spezifischen funktionen ist. Wenn das Betriebssystem kein Unicode kann, muss es wchar_t auch nicht können.
Die iostream locales sind dann noch ein ganz anderes Paar schuhe.
Wer unicode support will, muss sich dafür selbst eine lib bauen(und darf dann auch nicht auf wchar_t aufsetzen)
-
"Glib::ustring" in der glibmm behauptet von sich selbst, UTF-8 zu nutzen und liefert auch nen << und >> für streams mit.
-
otze schrieb:
Wer unicode support will, muss sich dafür selbst eine lib bauen(und darf dann auch nicht auf wchar_t aufsetzen)
Insofern hat Qbert² ja Recht, C++ unterstützt Unicode definitiv nicht zur vollsten Zufriedenheit
-
otze schrieb:
Wenn das Betriebssystem kein Unicode kann, muss es wchar_t auch nicht können.
Das stimmt. Und der Witz daran ist, dass Windows selbst intern Unicode verwendet und da wchar_t kein Multibyte-Zeichen sein darf, müsste Microsoft - würde es sich an den Standard halten - wchar_t vier Byte groß machen und UCS-4 implementieren
Die iostream locales sind dann noch ein ganz anderes Paar schuhe.
Grundsätzlich schon. Aber wenn die Umgebung entsprechende UTF-8-taugliche Locales bereitstellt und dazu noch UCS-4 als wchar_t, dann ist das schon ziemlich Unicode-tauglich und praktisch
-
otze schrieb:
Wer unicode support will, muss sich dafür selbst eine lib bauen(und darf dann auch nicht auf wchar_t aufsetzen)
So ein Quatsch! Ich kann mir auch eine fertige nehmen!
-
Artchi schrieb:
otze schrieb:
Wer unicode support will, muss sich dafür selbst eine lib bauen(und darf dann auch nicht auf wchar_t aufsetzen)
So ein Quatsch! Ich kann mir auch eine fertige nehmen!
Theoretisch: richtig. Praktisch: kennst du eine Gute?
(Bitte jetzt nicht wieder ICU, ich meine *gut* ... im Sinn von "kein Mist")
-
Theston schrieb:
"Glib::ustring" in der glibmm behauptet von sich selbst, UTF-8 zu nutzen und liefert auch nen << und >> für streams mit.
-
hustbaer schrieb:
Artchi schrieb:
otze schrieb:
Wer unicode support will, muss sich dafür selbst eine lib bauen(und darf dann auch nicht auf wchar_t aufsetzen)
So ein Quatsch! Ich kann mir auch eine fertige nehmen!
Theoretisch: richtig. Praktisch: kennst du eine Gute?
(Bitte jetzt nicht wieder ICU, ich meine *gut* ... im Sinn von "kein Mist")Was wollt ihr eigentlich konkret? Geht es um das rein und raus schreiben von UTF-8-Strings? Ob die Strings im RAM als UTF8 oder wchar_t liegen ist doch egal.
Wenn ihr keine codecvtl-Implementierung für UTF-8 kennt, tut es mir echt leid! Es gibt von Boost eine UTF-8-codecvt, jeder der boost auf seiner Platte hat, hat diese auch im Zugriff. Von boost.serialize und boost.filesystem wird diese auch genutzt.Hier wird mal wieder gegen C++ Sturm gemacht und das völlig ohne Grund.
Wem Boost zu unseriös ist, kann auch bei Dinkumware eine umfangreiche C++-Std-Lib-Implementierung kaufen, die diverse Codecs unterstützt:
http://www.dinkumware.com/manuals/default.aspx?manual=compleat&page=index_cvt.html#Code Conversions (arbeitet problemlos mit wstring zusammen!)Selbst bauen zeugt nur davon, das man sich nicht informiert hat, was der C++-Herstellermarkt so anbietet.
-
Naja... entweder hab ich's übersehen, oder das Teil ist nicht sehr vollständig. So korrekte "line break" Punkte ermitteln, Shaping, BiDi, das gehört für mich alles zu UNICODE dazu.
-
@Artchi hier wird nicht sturm gemacht. Das C++ Commitee sagt selbst zum Thema Unicode, dass sie nicht planen, was an der unicode unterstützung zu ändern. das ist ein Fakt.
Und defacto musst du dir für private interessen eine eigene lib bauen, denn es gibt keine gute freie, die mit den bestehenden C++ mitteln zusammenarbeitet.(iostreams, basic_string etc)
Was wollt ihr eigentlich konkret? Geht es um das rein und raus schreiben von UTF-8-Strings? Ob die Strings im RAM als UTF8 oder wchar_t liegen ist doch egal.
nein, ist es nicht. denn du musst immer wissen, welche codierung dein wchar_t hat, und deshalb ist eine "einfache" plattformunabhängige Lösung mit wchar_t nicht möglich. Natürlich, wer nur für windows compiliert, dem wird das alles nicht schwer fallen, aber wer eine allgemeine Lösung will, sitzt ziemlich auf dem trockenen.
-
Artchi schrieb:
Hier wird mal wieder gegen C++ Sturm gemacht und das völlig ohne Grund.
--> http://de.wikipedia.org/wiki/Paranoia
(schleichende Entwicklung eines dauernden, unerschütterlichen Wahnsystems)
