Unicode, Codepages und ASCII

[Asiax]

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

[RHBaum]

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-16

Noe, 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 wenn

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

[Wutz]

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

[Christoph]

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:

1. Du machst es dir absichtlich unnötig kompliziert, entweder um dich selbst oder jemand anderen zu ärgern.
2. 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".

[RHBaum]

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

[Christoph]

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.

[RHBaum]

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

[Christoph]

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.

[RHBaum]

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

[Christoph]

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.

[RHBaum]

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

[Christoph]

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.

[Asiax]

Christoph schrieb:

Woher weißt du bei den nicht-asiatischen Sprachen denn vorher, welche Codepage du nehmen musst? Das ist doch dasselbe in grün.

Weil ich - wie schon mehrfach erwähnt - die Geometrien der einzelnen Zeichen auf meinem Device speichere. D.h. wenn jemand in DE mit seinem DE-Locale speichert, dann kommen in der Geometrietabelle eben Ä, Ö und Ü vor. Macht jemand das in Russland, dann stehen an der gleichen Stelle in der Tabelle halt andere Sachen (irgend sowas wie л, и und ц), da er sein russiches Locale bei der Konvertierung verwendet.

Setzt jetzt jemand auf diesem Embedded Device die nicht vorhersehbaren Texte, dann macht er das in jedem Fall in seiner Sprache und mit seinem Locale und erhält automatisch die richtigen Zeichen. Das klappt nur dann nicht mehr, wenn der Russe auf die Idee kommt, sein Device nach Spanien zu schicken - aber das ist eine Einschränkung, mit der ich leben kann.

Christoph schrieb:

Entscheide einfach vorher, welche Zeichen du brauchst, und dann nimmst du die rein: Fertig ist die Sache.

Auch das hatte ich schon erwähnt: ich weiß vorher nicht, welche Zeichen tatsächlich benötigt werden, da der User quasi beliebige Texte vorgeben kann. Und mal eben die Geometrien von 40000 Zeichen aller Sprachen und Schriften zu erzeugen und zu speichern, ist eben nicht machbar.

Christoph schrieb:

Für mich klingt das nach zwei Möglichkeiten:

1. Du machst es dir absichtlich unnötig kompliziert, entweder um dich selbst oder jemand anderen zu ärgern.
2. Du trollst.

Willst du jetzt provozieren oder was soll das? Aber das kann ich auch: Für mich klingt das auch nach zwei Möglichkeiten:

1. Es ist unmöglich, hier eine Frage zu stellen, weil die Vorbedingungen einfach ignoriert oder nicht gelesen werden
2. Hier weiß auch keiner eine Lösung

Christoph schrieb:

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

Na dann bin ich mal auf deine Lösung gespannt, zumal die technischen Einschränkungen einfach mal gegeben sind und ich eben NICHT aufrüsten kann (weder Speicher noch eine schnellere CPU):

Ich habe hier ein Gerät, das in Echtzeit CAD-Daten ausgibt (das Ausgabegerät ist dabei egal, Fakt ist jedenfalls, dass mein Device bei ca. 70% Systemlast die Anforderungen dieses Ausgabegerätes gerade so erfüllt). Die CAD-Daten sind dabei statische Vektordaten, welche von einer Speicherkarte gelesen und stumpf ausgegeben werden.

Jetzt sollen Teile dieses Vektorendatenstromes aber dynamisch werden (einfaches Beispiel: Datum/Uhrzeit bzw. frei wählbare und von außen setzbare Texte sollen dargestellt werden). Die Rechenzeit des Gerätes reicht NICHT, um aus Text- und Fontdaten die benötigten Vektordaten in der richtigen Größe neu zu erzeugen, dann reißt der Ausgabedatenstrom während der Berechnung ab, was nicht passieren darf. Also ist meine Idee, dass ich einfach eine Tabelle mit den vorberechneten Vektordaten aller Zahlen und Zeichen mit abspeichere und abhängig vom darzustellenden dynamischen Text die Elemente dieser Vektordatentabelle verwende. Die Addition des Offsets, der von Zeichen zu Zeichen dazukommt, ist machbar, dafür reicht die Rechenleistung.

Und genau da falle ich dann in mein Problem mit den asiatischen Schriftzeichen.

Der Clou: Die verschiedenen dynamischen Elemente dieses Datenstromes können jeweils noch anders aussehen (anderer Zeichensatz, andere Skalierung), weswegen ich für jedes dynamische Element eine eigene Tabelle mit Vektordaten vorgeben müsste.

Wenn man das mal durchrechnet: sind beispielsweise 4 dynamische Elemente vorhanden, müsste ich in UTF-8 mindestens 4*40000 Zeichen abspeichern. Jedes Zeichen selbst bestehend dabei noch mal aus x Elementen an Vektordaten (bei bestimmten asiatischen Zeichen bzw. komplexen Fonts kann x dann schon mal in der Größenordnung von ein paar hundert Koordinatenwerten bestehen - die wiederum aus X,Y und Z in 16 Bit bestehen). Ich würde also auf größenordnungsmäßig ca. 50 MBytes allein für die Vektordatentabellen kommen - was leider komplett inakzeptabel weil dem User nicht zu vermitteln ist.

Also war meine Lösung ASCII/Codepages. Und jetzt kommst du.

[.filmor]

Vielleicht bin ich ein bisschen schwer von Begriff, aber ich sehe immernoch nicht, was dabei jetzt das Problem an UTF-8 ist…
Du musst ja keine vollständige Schrift abspeichern/mitschicken, jedes halbwegs sinnvolle Zeichen bekommst du in höchstens 3 Byte kodiert und du kannst es extrem schnell verarbeiten. Deine Schrifttabelle kann ja einfach ein Offset enthalten.

Ich verstehe insbesondere deine Rechnung am Ende nicht …

[hustbaer]

@Asiax
Du bist wirklich ein wenig schwer von Begriff.

Du kannst doch UTF-8 als Encoding verwenden, und dir trotzdem aussuchen für welche Zeichen du Vektordaten abspeichern willst und für welche nicht.
Wenn dann ein UTF-8 Zeichen vorkommt für welches du keine Vektordaten hast, dann gibst du einfach ne Fehlermeldung aus bzw. verwendest ein Ersatzzeichen dafür.

Der einzige Unterschied zu deiner Lösung mit Codepages it, dass du den Text eben nicht mit irgendeiner Codepage abspeicherst sondern mit UTF-8, und dass du nicht von einer Codepage eingeschränkt bist bezüglich welche Zeichen in Russland/... verfügbar sein sollen.

[Christoph]

Wenn du Chinesisch unterstützen willst, musst du unabhängig vom Encoding sowieso die Vektordaten von >5000 Zeichen vorberechnet haben, wenn du nicht vorher einschränken kannst, was für Zeichen auftreten können. Insofern musst du irgendwie dafür sorgen, dass du so viele Zeichen in den verschiedenen Stilen/Skalierungen speichern kannst, z.B. durch Komprimierung oder geringere Auflösung. Wenn das schon nicht geht, kannst du Chinesisch nicht unterstützen, völlig unabhängig vom Encoding.

Bei Japanisch hast du die Möglichkeit, dich auf die Silbenalphabete einzuschränken. Es ist zwar enorm hässlich, alles darin zu schreiben, und Japaner werden denken, dass dein Gerät aus den 80ern ist, aber auf die Weise bleibst du zumindest bei ca. 150 Zeichen insgesamt.

Wenn ein Gerät zu schwach ist, kann es aber einfach keine chinesischen oder japanischen Schriftzeichen darstellen, dafür sind diese Schriften zu kompliziert. Das Gerät muss zumindest in der Lage sein, viele tausend Zeichen auseinanderzuhalten.