Also sind alle Strings im Windows Kernel und allen Winapi Funktionen usw.
endlich UTF-32 fähig oder wenigstens UTF-8 fähig?

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?

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.

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?

Wo soll da denn der Unterschied sein?

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

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.

Ü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...

Aber dannn ist Java auch veraltet. Das benutzt intern auch UTF-16.
[...]

Schön, dass du, als Java-Freak, das einsiehst.

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.

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.

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

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.

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?)

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.

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.

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'!"

register, static und extern würd ich ja verstehen, aber auto?

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.

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.

Eigentlich nicht. So wird z.B. README ganz oben in der Liste angezeigt und nicht irgendwo unten/mitte. Das liegt einfach daran das Grossbuchstaben in ASCII/UTF zuerst kommen (65 > 97). Aber in Windows muss man nicht nur zuerst das 65 in 97 (oder anderesherum) umwandeln, was Rechenleistung kostet, sondern mann muss z.B. _README machen. (ein anderes Problem ist naturlich das man als Windows Benutzer die Datei README gar nicht anzeigen lassen kann, weil keine Dateiendung vorhanden ist )

peterchen schrieb:

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.

Eigentlich nicht. So wird z.B. README ganz oben in der Liste angezeigt und nicht irgendwo unten/mitte. Das liegt einfach daran das Grossbuchstaben in ASCII/UTF zuerst kommen (65 > 97). Aber in Windows muss man nicht nur zuerst das 65 in 97 (oder anderesherum) umwandeln, was Rechenleistung kostet, sondern mann muss z.B. _README machen. (ein anderes Problem ist naturlich das man als Windows Benutzer die Datei README gar nicht anzeigen lassen kann, weil keine Dateiendung vorhanden ist )

Da hast du recht, hätte Notepad++ nicht diese schöne Kontext-Menü integration, dann könnte man solche Dateien ohne Endung nicht einmal öffnen, da man ihnen ja kein Default-Programm zuweisen kann (*lol*)