Unicode, Codepages und ASCII

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.

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:

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

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:

Es ist unmöglich, hier eine Frage zu stellen, weil die Vorbedingungen einfach ignoriert oder nicht gelesen werden
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.