Unicode, Codepages und ASCII
-
Hi,
ich habe hier eine Applikation, in der man Texte eingeben kann, die dann auf einer Art Zeichenfläche angezeigt werden. Da diese Software weltweit benutzt wird, wird intern alles in UTF-8 behandelt. Der Teil funktioniert ganz problemlos.
Jetzt kommt allerdings ein Speichermedium ins Spiel, bei dem ich sehr begrenzt bin. Sprich ich kann nicht alle möglicherweise vorkommenden Zeichen und ihre Geometrien dort ablegen, sondern muss mich prinzipiell auf eine gewisse Anzahl begrenzen. Dafür bietet sich nun die gute, alte 8 Bit ASCII-Tabelle an.
Prinzipiell ist das kein Problem: ein Benutzer konvertiert beim Speichern den UTF-8-Text auf Basis seiner lokalen Eigenheiten, genau so wird die Geometrietabelle gespeichert. Auf Grund der jeweils verwendeten Codepage passt das Ergebnis: Wo in unserer ASCII-Tabelle beispielsweise ein "Ü" stehen würde, steht in einer anderen Sprache irgend ein kyrillischer Krickel und in wieder einer anderen Sprache sonst was lustiges - im Ergebnis sieht aber jeder User jeweils die richtigen Zeichen (ein länderübergreifender Export der Geometrietabellen kommt nicht vor).
Nun aber mein Problem: was ist mit Sprachen, die kein Alphabet haben, sondern für jeden Begriff ein eigenes Zeichen? Die kommen mit einer 8 Bit ASCII-Tabelle (255 minus 32 nicht darstellbare Zeichen) ja niemals aus.
Was hat man in solchen Fällen vor der Einführung von Unicode gemacht? Wie konnte in diesen Ländern überhaupt Text am Computer dargestellt werden?
Bevor jetzt hier Vorschläge kommen, doch Unicode zu verwenden weil ja in TTF-Fonts sowieso alles drin ist: nein, das geht nicht, erstens können keine normalen Fonts verwendet werden, zweitens schließt dieses bereits erwähnte Speichermedium all diese Möglichkeiten aus (und nein, ich kann das Speichermedium nicht einfach ersetzen).
-
Ernsthaft: Wie viel Platz sparst du durch die Verwendung von irgend einer Codepage gegenüber UTF-8? Das dürfte doch gerade bei westlichem Text minimal sein. Die asiatischen Encodings sind schon immer Multibyte wie UTF-8 (zB Shift JIS für japanisch).
-
rüdiger schrieb:
Ernsthaft: Wie viel Platz sparst du durch die Verwendung von irgend einer Codepage gegenüber UTF-8?
Für den gewünschten Einsatzzweck: enorme Mengen. Es macht halt einen Unterschied, ob ich für einen Zeichensatz eine fünfstellige Anzahl Geometrien speichere (weil ein bestimmter Font eben für alle Sprachen und Schriftzeichen die Daten enthält) oder mich auf die 220 Stück beschränke, die am Einsatzort sowieso maximal benötigt werden.
-
Asiax schrieb:
Für den gewünschten Einsatzzweck: enorme Mengen. Es macht halt einen Unterschied, ob ich für einen Zeichensatz eine fünfstellige Anzahl Geometrien speichere (weil ein bestimmter Font eben für alle Sprachen und Schriftzeichen die Daten enthält) oder mich auf die 220 Stück beschränke, die am Einsatzort sowieso maximal benötigt werden.
Das ist kein Argument, beim Speichern nicht mit Unicode zu arbeiten.
Wenn am Einsatzort nicht alle Zeichen benötigt werden, würde ich einfach die Zeichen aussortieren, die nicht benötigt werden. Die benötigten Zeichen werden danach ganz sauber unter ihren Unicode-Codepoints gespeichert.
Ich halte es für Blödsinn, sich mit Codepages und veralteten Encodings abzuquälen, wenn man nicht aus reinen Kompatibilitätsgründen dazu gezwungen ist. Speicher sparst du, indem du nur das speicherst, was du auch brauchst, nicht dadurch, dass du irgendein veraltetes Encoding benutzt.
-
DU mixxt hier ne ganze Menge Zusammen, was nicht zusammen gehoert ^^
Codepages ist nicht utf8, haben damit nix zu tun, sondern das ist tiefstes ANSI
utf ist sprachuebergreifend ....sprich ein utf - Ü ist immer ein Ü, egal auf welchen Computer und welche "einstellungen".
Das ist ja das "tolle" an utf, du brauchst nicht im text zwischen Russisch(kyrillisch) und arabisch und chinesisch hin und her schalten, sondern du kannst einfach chinesische kyrillische und arabische zeichen kreuz und quer verwenden.Du hasst eher das Problem, das gescheit darzustellen ... WIndows z.b. hat von haus aus keine utf unterstützung, sondern die können nur UNICODE nativ.
Sprich das umschalten der Zeichensaetze zum korrekten darstellen des UTF-8 Textes muss die App uebernehmen. Sprich die App muss utf koennen, und muss alle benötigten Schriftstaetze finden / mitbringen ....Und bein der Eingabe hasst das Problem, nen geeignetes gerät zu finden, welches gleichzeitig kyrillisch, arabisch und chinesiche zeichen anbietet.
Aber dafuer gibts auch virtuelle tastaturen ...Nun aber mein Problem: was ist mit Sprachen, die kein Alphabet haben, sondern für jeden Begriff ein eigenes Zeichen? Die kommen mit einer 8 Bit ASCII-Tabelle (255 minus 32 nicht darstellbare Zeichen) ja niemals aus.
utf8 kann nahezu 2^32 zeichen gleichzeitig, dass sollte langen ...
Die frage ist eher, wie geben deine Benutzer die Texte dann ein ?
In ner App, ueber formulare ? wenn die utf kann, nichts falsch konvertiert wird, dann sind die Texte die da rausgehen auch gleich richtiges utf8 ....Beispielsweisse Qt arbeitet intern mit utf16, kann nach utf8 konvertieren. Wenn damit Texte eingeben laesst, kommen die auch richtig konvertiert an.
Bei der eingabe (windows) faengst du entweder die Tastaturanschlaege ab (keycode) und wandelst es entsprechend der eingestellten Page (bei virtueller tastatur) oder der systemPage(Standard eingabe bei windows z.b.) um. DH Keycode * page = eindeutiges Zeichen, und nen eindeutiges zeichen kann in utf8 gewandelt werden ...
Nen texteditor der utf kann, wird auch deine Texte gescheit un utf rendern ... nen ASCII/ANSI/Unicode editor zeigt natuerlich nicht alles richtig anAuf nem System wo keine "chinesische" Page installiert ist, wirst auch in utf kein chinesisches zeichen ueber die Hardware-Tastatur bekommen, weil es nicht per keycode erzeugen kannst.
Du kannst es aber manuell (zeichencode) oder ueber transformation aus anderen zeichensaetzen erzeugen ...Was hat man in solchen Fällen vor der Einführung von Unicode gemacht?
ASCII systeme koennen nur ascii ! d.h. rein englischer Sprachsatz ohne Sonderzeichen !
ANSI Systeme (windows 3.x + ) konnten alle Zeichensaetze die mit 2^8 (255) zeichen auskommen konnten. sprich latainische, kyrillische usw. Es konnte aber immer nur 1 zeichensatz aktiv sein, man hat quasi das ganze system umgeschalten !
Unicode koennen dementsprechend mehr ... 2^16 Zeichen (windows) bzw 2^32 zeichen Unix (size_of(wchar_t))
Damit lassen sich schon die meisten sprachen europaeischen sprachen mixxen, und viele exotische Zeichensaetze fast komplett darstellen ....
Das Grundalphabet der Japaner Chinesen und der Araber kommen mit 16K Zeichen aus. Nur ganz exotischer Dinge eben nicht.Uebrigens hat z.b. Japan, und ich denk china auch, ne eigene Schreibweisse fuer Ihre Sprache die nur auf Latainische Buchstaben besteht ^^ Eben Wegen Computer, und damit Ausländer die Worte wenigstens auseinader halten koennen, wenns sie nicht schon verstehen !!!
-
rüdiger schrieb:
Ernsthaft: Wie viel Platz sparst du durch die Verwendung von irgend einer Codepage gegenüber UTF-8?Für den gewünschten Einsatzzweck: enorme Mengen. Es macht halt einen Unterschied, ob ich für einen Zeichensatz eine fünfstellige Anzahl Geometrien speichere (weil ein bestimmter Font eben für alle Sprachen und Schriftzeichen die Daten enthält) oder mich auf die 220 Stück beschränke, die am Einsatzort sowieso maximal benötigt werden.
Rofl ^^
Text der nur aus latainischen buchstaben + standard Satzzeichen besteht, ist in utf8 und in ascii genau aehm ... gleichlang !!!
In utf16 / Unicode(windows) waer er doppelt so gross
in Unicode (linux) 4 mal so gross100 chinesische Schriftzeichen werden wahrscheinlich (kenn die codierung ned) um die 400 byte brauchen (in utf-8 und utf-16)^^
Waeren in unicode vielleicht mit der haelfte darstellbar, aber du muesstest die codepage mitspeichern, und umschalten ...sprich kein latainischer/kyrillischer Text zwischendrin möglich.Schau dir mal genau an, wie utf-8 funktioniert.
Das ist eben grad dafuer designt, alle zeichen parallel darstellen zu koennen, und bei standard schriftzeichen (latein + Standardzeichen) trotzdem keinen Overhaed gegenueber ascii zu erzeugen ....
Auserdem auf transportschicht zu ascii Kompatibel, was das programmieren mit dem Zeugs recht angenehm macht ....Ciao ...
-
RHBaum schrieb:
DU mixxt hier ne ganze Menge Zusammen, was nicht zusammen gehoert ^^
Du verwechselst aber auch ein bisschen was.
RHBaum schrieb:
Codepages ist nicht utf8, haben damit nix zu tun, sondern das ist tiefstes ANSI
utf ist sprachuebergreifend ....Codepages sind auch sprachübergreifend und das hat mit dem ANSI überhaupt nichts zu tun.
RHBaum schrieb:
sprich ein utf - Ü ist immer ein Ü, egal auf welchen Computer und welche "einstellungen".
Welches UTF meinst du? Es gibt mehrere davon
RHBaum schrieb:
Du hasst eher das Problem, das gescheit darzustellen ... WIndows z.b. hat von haus aus keine utf unterstützung, sondern die können nur UNICODE nativ.
Das ist durcheinandergeworfen
UTF-8 wird nativ nicht unterstützt (wobei das nur relevant ist, wenn du was mit den Windowsfunktionen anzeigst), das was du UNICODE nennst ist UTF-16 und die abartigste Kodierung überhaupt, die zusätzlich per Konstruktion auch noch den Raum der kodierbaren Zeichen einschränkt.RHBaum schrieb:
Sprich das umschalten der Zeichensaetze zum korrekten darstellen des UTF-8 Textes muss die App uebernehmen. Sprich die App muss utf koennen, und muss alle benötigten Schriftstaetze finden / mitbringen ....
Bla. Du musst nur von UTF-8 nach UTF-16 umwandeln können. Und das ist simpel (und millionenfach implementiert).
RHBaum schrieb:
utf8 kann nahezu 2^32 zeichen gleichzeitig, dass sollte langen ...
UTF-8 /könnte/ signifikant mehr, per Konstruktion. Aber UTF-16 ist halt Mist, deshalb gehen derzeit maximal 1.114.112 (bis U+10FFFF). Passt zwar, weil bisher nur etwas über 100k Codepoints tatsächlich benutzt werden, bescheuert ist es trotzdem
RHBaum schrieb:
ASCII systeme koennen nur ascii ! d.h. rein englischer Sprachsatz ohne Sonderzeichen !
ANSI Systeme (windows 3.x + ) konnten alle Zeichensaetze die mit 2^8 (255) zeichen auskommen konnten. sprich latainische, kyrillische usw. Es konnte aber immer nur 1 zeichensatz aktiv sein, man hat quasi das ganze system umgeschalten !
Unicode koennen dementsprechend mehr ... 2^16 Zeichen (windows) bzw 2^32 zeichen Unix (size_of(wchar_t))UTF-16 ist auch eine Multibyte-Kodierung, kann deshalb auch genauso viele Zeichen kodieren wie UTF-32 (nämlich besagt Millionen).
Sorry für das Geklugscheiße, aber ich bin grantig :schland:
-
Christoph schrieb:
Asiax schrieb:
Für den gewünschten Einsatzzweck: enorme Mengen. Es macht halt einen Unterschied, ob ich für einen Zeichensatz eine fünfstellige Anzahl Geometrien speichere (weil ein bestimmter Font eben für alle Sprachen und Schriftzeichen die Daten enthält) oder mich auf die 220 Stück beschränke, die am Einsatzort sowieso maximal benötigt werden.
Das ist kein Argument, beim Speichern nicht mit Unicode zu arbeiten.
Wenn am Einsatzort nicht alle Zeichen benötigt werden, würde ich einfach die Zeichen aussortieren, die nicht benötigt werden.
Aha. Nur weiß ich vorher leider nicht, welche Zeichen dort benötigt werden. Das können 5 Schriftzeichen von 12000 sein, es können aber auch ein paar hundert sein - aber in keinem Fall weiß ich vorher, welche das sind.
Es ist ja schön, dass mir hier jede Menge andere Lösungen vorgeschlagen werden, aber wenn es irgend was in der Art gäbe, was bei den gegebenen Einschränkungen funktionieren könnte, würde ich nicht nach dem Codepage-Gedöns fragen.
-
Asiax schrieb:
Nur weiß ich vorher leider nicht, welche Zeichen dort benötigt werden.
Dann funktioniert das mit in eine andere Codepage rechnen ja auch nicht
Aber bitte: libiconv kann genau was du haben willst: konvertierung zwischen unterschiedlichen Zeichenkodierungen. Damit du kein ASCII oder sowas mehr brauchst.
Es stellen sich natürlich jetzt viele Fragen - weil dein Vorhaben nämlich ziemlich unpraktisch klingt... Wozu willst du zB Unicode verwenden wenn du es eh nicht speichern willst? Warum nicht direkt in der korrekten locale arbeiten?
Warum frisst Unicode zuviel Speicherplatz. Wenn du nur Text speicherst ist ein zippen der fertigen Datei enorm effektiv. etc.
-
Shade Of Mine schrieb:
Asiax schrieb:
Nur weiß ich vorher leider nicht, welche Zeichen dort benötigt werden.
Dann funktioniert das mit in eine andere Codepage rechnen ja auch nicht
Japp! Genau das ist ja mein Problem! Zumindest bei asiatischen Sprachen, bei den üblichen, auf Buchstaben basierenden Sprachen komme ich mit den Codepages ja prima aus.
Shade Of Mine schrieb:
Es stellen sich natürlich jetzt viele Fragen - weil dein Vorhaben nämlich ziemlich unpraktisch klingt... Wozu willst du zB Unicode verwenden wenn du es eh nicht speichern willst? Warum nicht direkt in der korrekten locale arbeiten?
Warum frisst Unicode zuviel Speicherplatz. Wenn du nur Text speicherst ist ein zippen der fertigen Datei enorm effektiv. etc.
Kurze Antwort: dieses erwähnte Speichermedium ist optional und genau genommen ein Embedded Device. Und wenn es eingesetzt wird, dann eben mit den dadurch entstehenden Beschränkungen wie z.B. ein Unicode. Und so lustige Sachen wie ZIP fallen auf Grund mangelnder Rechenpower komplett aus. Des weiteren wird nicht nur der Text gespeichert, sondern die kompletten Geometrien aller möglichweise benötigten Buchstaben (das hatte ich auch schon mal erwähnt).
Jetzt warte ich nur noch drauf, das irgend ein Schlaumeier nach der CPU fragt (Cortex M3) und dann mit dem tollen Tipp kommt, dass ich doch einfach einen höher getakteten M4 nhemen soll :-o
-
Codepages sind auch sprachübergreifend und das hat mit dem ANSI überhaupt nichts zu tun.
Dachte schon, das ANSI die Umschaltung per Codepage definiert !
Es gibt ja nicht den ANSI-Zeichensatz, sondern die ANSI Kompatiblen Codepages ...Welches UTF meinst du? Es gibt mehrere davon
Doch egal, meine Aussage gilt fuer utf-8 genau so wie für utf-16, oder nicht ?
das was du UNICODE nennst ist UTF-16Noe, das was ich UNICODE nenne ist das, was die Windows API unter Unicode versteht. Und das ist ein zeichensatz mit fixer zeichenbreite von 2 byte, und codepageumschaltung. glaub die korrekte bezeichnung ist UCS-2 (2-byte Universal Character Set). Und fuer utf-16 hat windows definitiv keine unterstuetztung. Gib mal nen richtigen utf-16 text mit nem ordentlichen zeichenmix an die winapi, und du wirst sehen, windows plottet müll ^^
Sorry für das Geklugscheiße, aber ich bin grantig ...schland!
Ja ich verstehe ...
Ich werd die naechsten 2 wochen auch nur noch RIndfleisch essen !!!
@Asiax
Denk schon das utf-8 für dich nen gangbarer weg ist.
Latainische Zeichen wir er mit 1 byte pro character speichern, und denk das ist der haeufigste Fall, oder nicht.Und wenn einer mit mandarin oder so anfaengt, und da 100 seiten prosa eingibt, dann wirst das niemlas in 10 byte unterbringen. Schlimmstenfalls brauchst du eben mal 5 byte pro zeichen, wenn es denn uebel exotisch ist.
Irgend einen Tod musst du sterben ....
der vorteil von utf8 waere, er kann auf seinem system chinesich eingeben, und auf nem latainisch eingestellten system bei ordentlicher Implementierung wuerde tortzdem chinesich zu lesen sein.
Verwendest du UCS-2 oder so, brauchst zwar nur noch 2 byte pro zeichen, aber nen chinesischer Text auf nem latainisch eingestellten System wuerde nur müll printen, und du muesstest dir erst ne chinesische windows version besorgen , bzw umschalten ...wenn du aufn embedded system bist, kann es aber scho problematisch werden, muesstest erst schaun ob es utf-8 compatible libs (libiconv) auch fuer dein system gibt ....
Allerdings wennDa diese Software weltweit benutzt wird, wird intern alles in UTF-8 behandelt. Der Teil funktioniert ganz problemlos.
solltest du eh keine probleme mit der darstellung haben, oder ???
Was ist eigentlich nu genau dein Problem ?
DU speicherst deine Texte doch scho in utf-8
Du hasst scho ne App, bzw code der das correkt anzeigt ....
Wo genau hasst du noch probleme ?Ciao ...
-
RHBaum schrieb:
Und fuer utf-16 hat windows definitiv keine unterstuetztung.
Quatsch.
UTF-16 ist die (Standard)Codierung für den Basisdatentyp wchar_t der Windows-CRT.
Und wchar_t (bzw. seine CRT-Entsprechungen TCHAR,*PWSTR,...) ist der Basiszeichensatztyp bei eingeschaltetem Unicode, immer, weil in der CRT so implementiert (Win95 u.ä. mal außen vor).
-
Asiax schrieb:
Shade Of Mine schrieb:
Asiax schrieb:
Nur weiß ich vorher leider nicht, welche Zeichen dort benötigt werden.
Dann funktioniert das mit in eine andere Codepage rechnen ja auch nicht
Japp! Genau das ist ja mein Problem! Zumindest bei asiatischen Sprachen, bei den üblichen, auf Buchstaben basierenden Sprachen komme ich mit den Codepages ja prima aus.
Woher weißt du bei den nicht-asiatischen Sprachen denn vorher, welche Codepage du nehmen musst? Das ist doch dasselbe in grün. Entscheide einfach vorher, welche Zeichen du brauchst, und dann nimmst du die rein: Fertig ist die Sache. Heute Programme abzuliefern, die mit irgendwelchen veralteten Codepages rumfrickeln, ist wirklich nicht mehr akzeptabel. Ich bin ehrlich gesagt sehr froh, dass die Zeiten der Codepages hinter uns liegen.
Für mich klingt das nach zwei Möglichkeiten:
- Du machst es dir absichtlich unnötig kompliziert, entweder um dich selbst oder jemand anderen zu ärgern.
- Du trollst.
Übrigens schafft sogar mein 3-4 Jahre alter MP3-Player (der Vorgänger von diesem hier), Glyphen für alle gängigen in Unicode darstellbaren Sprachen anzuzeigen, einschließlich aller asiatischen Sprachen. Entweder sagst du also deinen Nutzern, dass sie ihre Anforderungen runterschrauben müssen und asiatische Sprachen aus technischen Gründen nicht möglich sind, oder du sorgst dafür, dass dein embedded device genug Speicher zur Verfügung hat.
Ich finde übrigens sehr schön, dass mein MP3-Player japanische Schriftzeichen in mp3-Tags korrekt anzeigen kann, *obwohl* ich ein Produkt für den deutschen Markt in Händen halte. Natürlich hätte der Hersteller sagen können "japanische Schriftzeichen bekommt nur die japanische Version dieses Players", aber damit hätten sie mich als Kunden verloren, denn ich möchte japanische Schriftzeichen haben, obwohl ich ein deutsches Produkt kaufe.
edit: Beschreib doch mal in klaren Worten, was genau du erreichen möchtest. Und zwar nicht wie du das erreichen möchtest, sondern was du erreichen möchtest. Zum "wie" hast du dich schon genug geäußert: Mit Codepages. Das "was" ist aber völlig unklar. In der Erklärung zum "was möchtest du erreichen?" darf "codepage" nicht vorkommen, sonst bist du wieder beim "wie".
-
Quatsch.
UTF-16 ist die (Standard)Codierung für den Basisdatentyp wchar_t der Windows-CRT.Die Standard Codierung ist ucs-2
Auf Transportebene macht es keinen unterscheid ob ucs-2 oder ut-f16
Nur in der Darstellung ...woran machst Du also utf-16 Unterstuetzung fest ?
meinst du, das TextoutW & co utf-16 rendern kann ??? Kannst es ja mal probieren, aber dann wirklich mit texten wo nen unterschied zwischen ucs-2 und utf-16 zu sehen ist ^^kennst du ne andere funktion oder ne entsprechende locale wo du mit size_t wcslen_l(const wchar_t *str,_locale_t locale); wirklich die anzahl der darzustellen Zeichen von utf-16 bekommst ?
Ciao ...
-
RHBaum schrieb:
Quatsch.
UTF-16 ist die (Standard)Codierung für den Basisdatentyp wchar_t der Windows-CRT.Die Standard Codierung ist ucs-2
Auf Transportebene macht es keinen unterscheid ob ucs-2 oder ut-f16
Nur in der Darstellung ...Das war früher mal aktuell, so bis zur Zeit von Windows 2000 rum. Windows unterstützt meines Wissens nach schon lange utf16, sonst wär das ja echt völlig unbrauchbar. Siehe auch http://en.wikipedia.org/wiki/UTF-16#Use_in_major_operating_systems_and_environments .
Nur ganz generell, falls du mit "Darstellung" die Zuordnung zu Glyphen meinst: Unicode hat mit den Glyphen nichts zu tun, das arbeitet auf einer völlig anderen Ebene. Und konkrete Encodings haben sogar noch weniger mit der Darstellung zu tun.
Was du mit "Transportebene" meinst, ist mir auch nicht klar, denn das ist kein üblicher Begriff, der im Zusammenhang mit Unicode fällt. Kompatibilitäten sind klar spezifiziert, alles was darüber hinausgeht, ist Zufall und unspezifiziert.
-
Was du mit "Transportebene" meinst, ist mir auch nicht klar
Damit meine ich, alles was den Text nicht darstellen braucht.
Für alle funktionen, egal ob winapi oder sonstwas, gibts keinen unterschied zwischen utf-16 und ucs-2, solange sie den Text nicht plotten muessen / die richtige Anzahl der darzustellenden Zeichen ausrechnen muessen.D.h. nur der der die utf-16 zeichen erzeugt, und der der sie darstellen muss, muss utf-16 koennen, fuer den rest isses wurscht, die muessen nur unicode / ucs-2 koennen.
Ich denke das meinst du damit
Windows unterstützt meines Wissens nach schon lange utf16
windows kann mit ucs-2 umgehen. Solange es das auch nicht darstellen muss, ist utf-16 dann auch kein problem.
Bleibt die Frage, wann kann man davon reden, das ein BS utf-8 utf-16 unterstuetzt. Theorethisch kann man auch sagen, das windows 98 schon utf-8 konnte. utf-8 und ANSI (8 bit chars theorethisch ucs-1) verhalten sich genau so ... windows 98 haette einfach müll geplottet, aber kann utf-8 texte genau so speichern und wiederherstellen wie ANSI. Es wuerde kein unterschied merken.
Aber zum vergleichen,
Nimm man nen utf-16 faehigen editor (ja da gibts welche unter windows, aber notepad geht da nicht) und schreib nen Folge von wenigen Buchstaben, bestehend aus chinesischen, kyrillischen und arabischen Buchstaben. Wird im Editor sicher dann korrekt dargestellt.
Dann kopier die zeichenfolge in die Zwischenablage, und erzeug nen neuen "Folder" / Ordner, und kopier den Inhalt der Zwischenablage als namen rein !
Wirst sicher Müll bekommen oder ? Auch Benutzernamen koennen nie gleichzeitig kyrillisch, chinesisch und co Zeichen haben.
Mit internen Mitteln kann es kein utf-16 darstellen. Das Notepad kanns auch nicht.
Der IExplorer kann es aber. will ich unter windows utf-8 / utf-16 texte darstellen, aka plotten, muss ich das IE-BrowserElement nutzen oder auf 3d party libs zugreifen.Wuerdest du unter diesen Umständen sagen, das windows wirklich utf-16 unterstützt?
Dann hol dir mal nen aktuelles Linux. Stell die locales auf utf-8, glaub utf-16 locales sind noch selten.
Dann mach die nummer mit den Text und erzeug mal system-Objecte mit den gemixxten namen.
DU wirst feststellen, das sogar in der Konsole gleichzeitig die untzerschiedlichen buchstaben rendern kannst.
Also nen cat auf ne utf-8 datei wird dir den text ordentlich darstellen.Mach das mal unter windows mit cmd ^^
Ciao ...
-
RHBaum schrieb:
Was du mit "Transportebene" meinst, ist mir auch nicht klar
Damit meine ich, alles was den Text nicht darstellen braucht.
Für alle funktionen, egal ob winapi oder sonstwas, gibts keinen unterschied zwischen utf-16 und ucs-2, solange sie den Text nicht plotten muessen / die richtige Anzahl der darzustellenden Zeichen ausrechnen muessen.Also ist "Transportebene" für dich die Byteebene? Auf dieser Ebene ist aber natürlich alles äquivalent, ANSI, UTF8, UTF16, und so weiter. Es ist deswegen doch etwas witzlos, auf dieser Ebene von "Äquivalenz" zu reden.
Ich hab keine Zeit, auf die anderen Punkte in deinem Posting einzugehen, aber vielleicht macht das ja jemand anderes. Von der Darstellung von Unicode-Codepoints redest hier irgendwie nur du. Der Thread handelt aber von Unicode-Encodings, was mit der Darstellung überhaupt nichts zu tun hat.
edit: Die "Betriebssystem-Unterstützung" sieht man bei Windows zum Beispiel daran, dass man den Titel von existierenden Fenstern abfragen kann und etwas utf-16-kodiertes erhält.
-
Von der Darstellung von Unicode-Codepoints redest hier irgendwie nur du
Wenn die Darstellung irrelevant ist, warum machst du dann ueberhaupt nen Unterschied zwischen ucs-2 und utf-16 ?
Ciao ...
-
RHBaum schrieb:
Von der Darstellung von Unicode-Codepoints redest hier irgendwie nur du
Wenn die Darstellung irrelevant ist, warum machst du dann ueberhaupt nen Unterschied zwischen ucs-2 und utf-16 ?
Weil es ein anderes Encoding ist, das unterschiedlich behandelt werden muss: In erster Linie bei der Erkennung, ob ein String gültig kodiert ist oder nicht. In den alten Encodings mit Codepages war das nämlich nie ein Problem, da war einfach jede Folge von Bytes ein korrekt kodierter String. Bei ucs2 und utf16 ist nicht mehr jede Folge von Bytes ein korrekt kodierter String. Hier unterscheiden sich ucs2 und utf16 auch, völlig unabhängig von der Darstellung.
-
Bei ucs2 und utf16 ist nicht mehr jede Folge von Bytes ein korrekt kodierter String.
Glaub hier kann ich noch hinzulernen ....
checkst Du die z.b. PUA auf Serialization-Ebene ab? Klar gibt es nicht darstellbare zeichen, aber das zu erkennen, gehoert das nicht zur "Darstellung" ?
Hier unterscheiden sich ucs2 und utf16 auch, völlig unabhängig von der Darstellung
So sehr unterscheiden die sich gar nicht.
gültiges ucs2 ist auch gültiges utf16, glaub in ucs2 sind die Supplementary Signs eh auch nicht definiert / benutz. ucs2 bildet genauso die BMP ab wie utf16, ohne supplementary chars.Andersrum, nur supplementary chars in utf16 wuerden in ucs2 etwas "verwirrung" sorgen.
Ciao ...
-
RHBaum schrieb:
Bei ucs2 und utf16 ist nicht mehr jede Folge von Bytes ein korrekt kodierter String.
Glaub hier kann ich noch hinzulernen ....
checkst Du die z.b. PUA auf Serialization-Ebene ab? Klar gibt es nicht darstellbare zeichen, aber das zu erkennen, gehoert das nicht zur "Darstellung" ?
Nein, mit der private use area hat das nichts zu tun. Es gibt einfach bestimmte Bytefolgen, die in utf-16 nicht auftreten dürfen. Mit der Darstellung hat das auch nichts zu tun: Wenn so eine Bytefolge auftritt, ist der String nicht mehr in utf-16 kodiert und das Programm muss zusehen, wie es damit weiterarbeitet. Den String als utf-16 behandeln ist nicht mehr möglich: Es muss mit einem Fehler abbrechen, den String an der kaputten Stelle abschneiden oder versuchen, die kaputte Stelle herauszuschneiden oder durch Fragezeichen o.ä. zu ersetzen. Mit dem Zeichensatz und den darstellbaren Zeichen hat das auch nichts zu tun: Es existiert keine Abbildung mehr von dem Byte-String auf eine Folge von Unicode-Codepoints.
