Ansi / Unicode
-
@unicoder
Ich würde sagen: Unicode ist 21 Bit breit...
0x00 - 0x10FFFF (oder war's 0x10FFFD?)
-
Okay, also angenommen man entwickelt ein neues Projekt. Dann wäre doch Unicode die bessere Wahl (wenn man Kompatibilität ignoriert)?
@unicoder:
Ja stimmt, aber ich bin jetzt von char und wchar_t unter Windows ausgegangen, deshalb die 1 und 2 Bytes.
-
wchar_t hat beim GCC bei mir unter Mac OS X z.B. 4 Byte.
-
Hab Windows 7, GCC und bei mir sind's zwei
-
Jetzt hätte ich doch mal die Frage, was denn genau der ANSI-Zeichensatz beinhaltet. Ich kenne den genormten ASCII-Satz von 128 Zeichen, ich kenne Unicode mit seinem 1 Millionen Drietindepief Zeichen, UTF-8, wo die Byteanzahl pro Zeichen auf 4 ansteigen kann, jedoch meistens mindestens 8 Bit aufweißt, zahlzeiche 8-Bit-Zeichensätze von ISO-8859-1-15, chinesische, japanische, tibetische, hebräische Zeichensätze, Windows-Codepages und, und, und ... ich habe gedacht, ANSI definiert lediglich, dass 8 Bit verwendet werden.
EDIT: Übrigens stimmt das so nicht ganz, dass Unicode langsamer ist. Der Kernel von Windows arbeitet intern mit Unicode, und bei Multi-Byte muss er umwandeln. Das kostet mehr Laufzeit als die Verwendung von zwei Ocktets (in der Realität kann ein Zeichensatz eh nur 65536 Zeichen abdecken, was anderes habe ich noch nicht gehört).
-
Der aus dem Westen ... schrieb:
(in der Realität kann ein Zeichensatz eh nur 65536 Zeichen abdecken, was anderes habe ich noch nicht gehört).
Und würde höchstwahrscheinlich auch keinen Sinn machen, glaub ich... vllt schon, aber nicht für den Alltagsprogger.
-
Mein MinGW:
`gcc-Version 4.6.1 (GCC)sizeof(wchar_t) == 2`
In den ersten 16 Bit (Unicode) sind praktisch alle derzeit verwendeten Zeichen aller gesprochenen/geschriebenen Sprachen enthalten. D.h. außer für exotische/wissenschaftliche Angelegenheiten reichen Windows' 16-Bit-wchar_ts vollkommen aus.
ANSI-Zeichensatz ist eine ungenaue/falsche Bezeichnung, es gibt mehrere. Wir hier in D verwenden Windows-1252(CP1252)
-
Caligulaminus schrieb:
Mein MinGW:
`gcc-Version 4.6.1 (GCC)sizeof(wchar_t) == 2`
Gleicher Compiler, selbes Ergebnis
Caligulaminus schrieb:
In den ersten 16 Bit (Unicode) sind praktisch alle derzeit verwendeten Zeichen aller gesprochenen/geschriebenen Sprachen enthalten. D.h. außer für exotische/wissenschaftliche Angelegenheiten reichen Windows' 16-Bit-wchar_ts vollkommen aus.
Caligulaminus schrieb:
ANSI-Zeichensatz ist eine ungenaue/falsche Bezeichnung, es gibt mehrere. Wir hier in D verwenden Windows-1252(CP1252)
Was sich aber kein Mensch merken will&kann. Wir sind in Deutschland, also ist ANSI ANSI, Basta.
-
Hacker schrieb:
Und würde höchstwahrscheinlich auch keinen Sinn machen, glaub ich... vllt schon, aber nicht für den Alltagsprogger.
Dank UTF-8 können sich auch Web-Programmierer darauf ausruhen, dass die Zeichen vernünftig dargestellt werden. Habe ich erst heute erfahren, als ich die tibetische Schriftunterstützung für UTF-8 installiert habe. Und Zeichenkompatibilität im Internet ist nun mal wichtig.
-
Hacker schrieb:
Gleicher Compiler, selbes Ergebnis
Gleiche Version?
Edit:
Ach ja...
Was sich aber kein Mensch merken will&kann. Wir sind in Deutschland, also ist ANSI ANSI, Basta.
*hüstel*
-
Erstaunlich wie wenig Leute hier Ahnung von Unicode haben. Unicode hat 0x10FFFF Zeichen (Codepoints). Diese Codepoints können nun auf unterschiedliche Weise in Programmen dargestellt werden. Es gibt einmal UTF-32 (32Bit, 4Byte. wchar_t unter Linux oder char32_t in C++11) dabei werden einfach die Codepoints übernommen und in 32 Bit verpackt. Es gibt aber auch Darstellungen die keine feste Länge nehmen. Einmal UTF-16 (16Bit, 2Byte. wchar_t unter Windows oder char16_t in C++11) bei dem zwei oder vier Bytes zur Darstellung verwendet werden und einmal UTF-8 (8Bit, 1Byte. char) bei dem ein bis vier Bytes zur Darstellung verwendet werden. (Gibt auch noch andere und bei denen mit mehr als ein Byte jeweils noch BE/LE.)
Bei den variablen Darstellungen muss man natürlich aufpassen, da ein Zeichen nicht einem Element des Strings entsprechen muss. (char16_t x[] = ...; x[10]; ist nicht das 11. Zeichen!) Das wird leider von vielen Programmierern nicht beachtet oder verstanden (wie man hier im Thread wieder sieht).
Aber man kann in char, char16_t, wchar_t (egal ob 2 oder 4 Bytes) und char32_t Unicode darstellen!
Wie bereits verlinkt: http://www.joelonsoftware.com/articles/Unicode.html
Ansonsten gibt es im Magazin auch ein Artikel zu dem Thema: http://magazin.c-plusplus.net/artikel/Einf�hrung in Codepages und Unicode
Die Unicode/UTF-8 FAQ: http://www.cl.cam.ac.uk/~mgk25/unicode.htmlSeit Boost 1.48 gibt es dort eine Bibliothek Boost.Locales die einiges an Unicode-Funktionalität anbietet (auf Basis von ICU) http://www.boost.org/libs/locale
Ansonsten gibt es natürlich noch ICU (ist aber sehr hässlich!): http://site.icu-project.org/
-
Caligulaminus schrieb:
Hacker schrieb:
Gleicher Compiler, selbes Ergebnis
Gleiche Version?
Jaja, wollte ich auch Schreiben.
Caligulaminus schrieb:
Ach ja...
Was sich aber kein Mensch merken will&kann. Wir sind in Deutschland, also ist ANSI ANSI, Basta.
*hüstel*
Edit: und
rüdiger schrieb:
(char16_t x[] = ...; x[10]; ist nicht das 10. Zeichen!)
Ja, sondern das 11te. (?)
-
rüdiger schrieb:
Bei den variablen Darstellungen muss man natürlich aufpassen, da ein Zeichen nicht einem Element des Strings entsprechen muss. (char16_t x[] = ...; x[10]; ist nicht das 10. Zeichen!) Das wird leider von vielen Programmierern nicht beachtet oder verstanden (wie man hier im Thread wieder sieht).
Meinst du nicht eher 'nicht das elfte Byte'? (Aua) Bei char16_t haben wir 2 Bytes pro Zeichen, machen 24 Bytes für 12 Elemente.
PS: auch die Moderatoren haben es manchmal mit dem Index ...
-
Ich denke rüdiger meinte x[10] ist nicht notwendigerweise das elfte Zeichen. Es könnte z.B. auch das zehnte sein, oder ein low surrogate (zweite Hälfte eines Codepoints > 0x10000). (Abgesehen von dem Flüchtigkeitsfehler im Index natürlich)
-
Hacker schrieb:
Edit: und
rüdiger schrieb:
(char16_t x[] = ...; x[10]; ist nicht das 10. Zeichen!)
Ja, sondern das 11te. (?)
Auch nicht das 11te
Aber Du hast recht. Das kommt davon, wenn man mal mit Programmiersprachen arbeitet, die ab 1 anfangen zu zählen (iiiiih!)@Der aus dem Westen ...
Nein, ich meine das Zeichen. Es geht doch überhaupt nicht um Bytes.
-
rüdiger schrieb:
Hacker schrieb:
Edit: und
rüdiger schrieb:
(char16_t x[] = ...; x[10]; ist nicht das 10. Zeichen!)
Ja, sondern das 11te. (?)
Auch nicht das 11te
Aber Du hast recht. Das kommt davon, wenn man mal mit Programmiersprachen arbeitet, die ab 1 anfangen zu zählen (iiiiih!)Welche denn? Ich muss die Erfinder lynchen
-
Da die Zeichen unterschiedlich lang sein können (bei UTF-16 eben 2 oder 4 Byte) mußt Du, um sicherzugehen, von Anfang an durchzählen...
EDIT:
Ah! Du beziehst dich auf die Programmiersprache(?)... Ich glaube, FORTRAN ist so ein Kandidat.
-
Ui, ich wusste nicht, dass UTF-16 auch 4 Bytes zur Darstellung verwenden kann. Wieder was gelernt.
Dann ergibt das auch Sinn. 10 kann dann alles mögliche sein, sogar mitten in einem Zeichen anfangen.
-
Es wird sogar noch interessanter. Selbst bei UTF-32, wo alle Codepoints in 32 Bit dargestellt werden, ist
char32_t x[] = ...; x[10];nicht unbedingt das 11. Zeichen. Der Begriff "Zeichen" ist halt ein bisschen schwammig (und wird daher im Unicode Standard nicht verwendet). Bei UTF-32 ist x[10] zwar der 11. Codepoint. Aber es gibt auch noch kombinierende Zeichen (http://en.wikipedia.org/wiki/Combining_character). Die haben jeweils ihren eigenen Codepoint. Aber werden zusammengesetzt dargestellt. Wenn man also mit Zeichen das Graphem meint, dann ist man auch bei UTF-32 in Schwierigkeiten und muss die vorhergehenden/nachfolgenden Codepoints anschauen. Noch komplizierter wird es, wenn man bedenkt das ein Graphem auf unterschiedliche Weise dargestellt werden kann (zB kann man Ä als Ä oder als ̈A (mit Combining Characters) darstellen). Deshalb braucht man dann noch Normalisierung.
-
Ich glaube, NT hat noch UCS-2 verwendet. Da konnte man sich mit sowas noch auf der sicheren Seite fühlen. Mit UTF-16/8 fährt man da schnell gegen die Wand. Wobei (wie oben schon erwähnt) in 16 Bit eigentlich alles (weltweit) gängige abgebildet ist. Das Risiko mit der Wand ist hier also sehr gering - aber trotzdem da.
Und dann gibt es ja noch zusammengesetzte Zeichen, womit meine Relativierung eben (die mit dem geringeren Risiko) wieder hinfällig wäre. (gilt auch für UCS-2)Edit:
2 Minuten! Mann bin ich langsam...PPS: Ich glaube, es ist: A ̈ == Ä