Kann Windows Vista eigentlich endlich echtes Unicode also UTF-32 oder zumindest UTF-8
-
DEvent schrieb:
serious developer schrieb:
UTF-16 ist veraltet. Moderne Applikationen verwenden UTF-8 oder (seltener) UTF-32. Die WINAPI setzt aber nach wie vor auf das alte UTF-16. AFAIK kann das Terminal aber endlich mit UTF-8 umgehen. Die nach wie vor fehlende UTF-8/UTF-32 Unterstützung kann man aber ignorieren, wenn man moderne Toolkits wie gtkmm verwendet.
Hast du einen Link, wieso das veraltet ist und wieso man UTF-8/32 verwenden sollte?
Weil es alle anderen tun, aber das ist für Microsoft ja gerade erst recht einen Grund es so nicht zu machen.
-
Naja 8 hat gegenüber 16 den Vorteil, dass es in der Regel weniger Speicherplatz verbraucht, halt zwischen 8 und 32 Bits je Zeichen, anstatt 16/32
32 hat den Vorteil, dass jedes Zeichen immer die selbe Größe hat.
-
DEvent schrieb:
Hast du einen Link, wieso das veraltet ist und wieso man UTF-8/32 verwenden sollte?
UTF-16 ist veraltet, weil der Unicode Zeichensatz inzwischen schon derart mit Zeichen angestiegen ist, daß 16 Bit nicht mehr ausreichen.
UTF-32 ist daher inzwischen das Minimum für Unicode.
Und UTF-8 macht das Lauflängencodiert, daher hat UTF-8 keine Probleme alle Zeichen von UTF-32 darzustellen.UTF-16 gibt es im Prinzip also gar nicht mehr offiziell im Unicode Zeichenstandard.
-
Kann es sein, dass du UTF-16 mit UCS-2 verwechselst?
-
MFK schrieb:
Kann es sein, dass du UTF-16 mit UCS-2 verwechselst?
Wo soll da denn der Unterschied sein?
-
Nixchecker schrieb:
MFK schrieb:
Kann es sein, dass du UTF-16 mit UCS-2 verwechselst?
Wo soll da denn der Unterschied sein?
Q: What is the difference between UCS-2 and UTF-16?
A: UCS-2 is what a Unicode implementation was up to Unicode 1.1, before surrogate code points and UTF-16 were added as concepts to Version 2.0 of the standard. This term should be now be avoided.
When interpreting what people have meant by "UCS-2" in past usage, it is best thought of as not a data format, but as an indication that an implementation does not interpret any supplementary characters. In particular, for the purposes of data exchange, UCS-2 and UTF-16 are identical formats. Both are 16-bit, and have exactly the same code unit representation.
The effective difference between UCS-2 and UTF-16 lies at a different level, when one is interpreting a sequence code units as code points or as characters. In that case, a UCS-2 implementation would not handle processing like character properties, codepoint boundaries, collation, etc. for supplementary characters.
http://unicode.org/faq/basic_q.html#14
Und wenn wir schon dabei sind, der Busta:
http://unicode.org/faq/utf_bom.html#UTF16
-
Nixchecker schrieb:
MFK schrieb:
Kann es sein, dass du UTF-16 mit UCS-2 verwechselst?
Wo soll da denn der Unterschied sein?
ucs-2 hat pro zeichen immer 16 bits. und das wird auch im windosen-kernel benutzt. utf-16 kann mehr zeichen aufnehmen und ist deshalb variabel (2 oder 4 bytes). übrigens hat die winapi funktionen, um ucs-2 in utf-8 usw umzuwandeln, usw. also kein grund zur beunruhigung.
-
Aber dannn ist Java auch veraltet. Das benutzt intern auch UTF-16.
Übrigens finde ich es doch sehr seltsam, UTF-16 ein unechtes Unicode zu nennen. LOL
Achja, und warum brauche ich mehr als Zeichen als UCS2 darstellen kann? Mit UCS2 sind alle wichtigen Schriftzeichen abgedeckt. Keiner kann mir erzählen, das ich auf dem Windows-Desktop Klingonisch o.ä. brauche.
Und ds UTF-8 speicherplatzschonender ist, ist auch quatsch, sobald ich Chinesisch oder so verwende. Dann ist es sogar noch langsamer in der Performance, als das "unechte" Unicode von Windows. Weil bei UTF-8 nur solange weniger Speicher verbraucht wird, solange ich latin-Zeichen benutze. Aber hier zeigt sich mal wieder: über den Tellerrand schauen (auf andere Nationen) ist nich die Stärke von einigen. Es gibt ja nur Latin-zeichen auf diesem Planeten... und wozu brauche ich dann 16 Mio. Zeichentabellen?
Der Thread ist doch mal wieder typisches MS-Bashing...
-
Java-Freak schrieb:
Aber dannn ist Java auch veraltet. Das benutzt intern auch UTF-16.
[...]Schön, dass du, als Java-Freak, das einsiehst.
-
Java-Freak schrieb:
Mit UCS2 sind alle wichtigen Schriftzeichen abgedeckt. Keiner kann mir erzählen, das ich auf dem Windows-Desktop Klingonisch o.ä. brauche.
Klingonisch wurde nie in Unicode aufgenommen. Ändert natürlich nichts daran, dass in der Praxis 16 Bit nahezu immer völlig ausreichen.
-
Java-Freak schrieb:
Mit UCS2 sind alle wichtigen Schriftzeichen abgedeckt. Keiner kann mir erzählen, das ich auf dem Windows-Desktop Klingonisch o.ä. brauche.
Ja, alle "wichtigen", aber eben nicht Unicode. UCS-2 ist nicht mehr der aktuelle Unicode-Standard. Windows macht seit mindestens NT 4 intern UTF-16 und kann damit alle Unicode-Zeichen abdecken, hat also "echtes" Unicode. Alle UTF-Kodierungen sind "echtes" Unicode.
UTF-16 ist also nicht "veraltet" in dem Sinne, dass es nicht alle Unicode-Zeichen darstellen kann. Es ist allerdings in dem Sinne veraltet, dass es nichts halbes und nichts ganzes ist: Weder ist es speichersparend, noch ist ein Zeichen immer 2 Bytes.
-
Optimizer schrieb:
Windows macht seit mindestens NT 4 intern UTF-16 und kann damit alle Unicode-Zeichen abdecken, hat also "echtes" Unicode.
seit win2000 können irgendwelchen usermode-programme utf-16. im kernel ist immer noch alles ucs-2
-
UTF-16 ist natürlich nicht veraltet. Es verbindet aber die Nachteile von UTF-32 (Kostet zu viel Speicherplatz) mit denen von UTF-8 (Zeichen haben keine feste Breite).
Java-Freak schrieb:
Und ds UTF-8 speicherplatzschonender ist, ist auch quatsch, sobald ich Chinesisch oder so verwende.
Verbraucht UTF-8 nicht höchstens so viel Speicher, wie UTF-16? Und in vielen Fällen eben weniger. Bei UTF-8 gibt es ja nicht nur 1 byte und 4 byte, sondern auch 2 und 3 byte.
-
fricky schrieb:
Optimizer schrieb:
Windows macht seit mindestens NT 4 intern UTF-16 und kann damit alle Unicode-Zeichen abdecken, hat also "echtes" Unicode.
seit win2000 können irgendwelchen usermode-programme utf-16. im kernel ist immer noch alles ucs-2
Jetzt stellt sich mir aber doch die Frage, was hat der Kernel überhaupt mit Strings zu schaffen? Ok, irgendwelche String-IDs kann ich mir noch vorstellen, da kommt man wahrscheinlich auch immer noch mit ASCII aus, aber amsonsten war ich tatsächlich eher der Meinung dass exotische japanische Schriftzeichen hauptsächlich fürs GUI relevant sind.
-
dass exotische japanische Schriftzeichen hauptsächlich fürs GUI relevant sind
Dateinamen?
(Oder meint man, daß diese auch im Usermode auf IDs gemappt werden sollten?)
-
peterchen schrieb:
dass exotische japanische Schriftzeichen hauptsächlich fürs GUI relevant sind
Dateinamen?
(Oder meint man, daß diese auch im Usermode auf IDs gemappt werden sollten?)Ist auch lustig das Windows bis jetzt noch Case Insensitive fuer Dateinamen ist (oder hat sich das mit Vista geaendert?). Lustig ist dabei, dass intern der Kernel eh Case Sensitiv ist (weil byteweise 'A' was anderes ist als 'a'). Aber es wird exra (fuer wen auch immer) in Case Insensitiv umgewandelt.
-
DEvent schrieb:
peterchen schrieb:
dass exotische japanische Schriftzeichen hauptsächlich fürs GUI relevant sind
Dateinamen?
(Oder meint man, daß diese auch im Usermode auf IDs gemappt werden sollten?)Ist auch lustig das Windows bis jetzt noch Case Insensitive fuer Dateinamen ist (oder hat sich das mit Vista geaendert?). Lustig ist dabei, dass intern der Kernel eh Case Sensitiv ist (weil byteweise 'A' was anderes ist als 'a'). Aber es wird exra (fuer wen auch immer) in Case Insensitiv umgewandelt.
Vor allem nutzt unter Windows ja eh niemand mehr die Konsole, wenn man hier hört, dass selbst die Programmierer alle lieber Klickibunti-GUIs wollen. Und beim Anklicken ist es ja nun egal..
Und wer mit der Konsole arbeitet tippt den Namen eh so wie er lautet und nutzt kein case-insensitive. Könnte man also ruhig rauswerfen, aber ich will nicht wissen wie viele crappy Anwendungen danach nicht mehr laufen.
-
Das stimmt schrieb:
Und wer mit der Konsole arbeitet tippt den Namen eh so wie er lautet und nutzt kein case-insensitive.
Aber der Admin dann (per Telefon):
"Das Verzeichnis heißt weder 'AUTO' noch 'auto' sondern 'Auto'!"
-
Wer nennt seine Verzeichnisse auch auto ...
register, static und extern würd ich ja verstehen, aber auto?
-
Das stimmt schrieb:
Vor allem nutzt unter Windows ja eh niemand mehr die Konsole, wenn man hier hört, dass selbst die Programmierer alle lieber Klickibunti-GUIs wollen. Und beim Anklicken ist es ja nun egal..
Und wer mit der Konsole arbeitet tippt den Namen eh so wie er lautet und nutzt kein case-insensitive. Könnte man also ruhig rauswerfen, aber ich will nicht wissen wie viele crappy Anwendungen danach nicht mehr laufen.geht's noch?
Die Diskrepanz zwischen User- und Kernel hat natürlich Nachteile, ich frag' mich nur, was an einem case-insensitiven Dateisystem so schlimm sein soll. Für Nutzer ist das doch eher von Vorteil.