unvollständige MultiByte-Zeichen erkennen [erledigt]

[himitsu]

So, da ich bei meiner XML-Klasse, die Datei nunmal Stückchenweise eingelesen wird, kann ich da auf ein kleines Problemchen stoßen.

Also wie erkenn ich ein Multibyte-Zeichen, bwz. dessen Anfang, wenn ich den Zeichensatz selber nicht kenn?
bzw. wie erkenn ich, ob das letze Zeichen im String zu einem MultiByte-Zeichen gehört, dessen Fortsetzung ich noch nicht mit eingelesen hatte und ich somit noch etwas nachladen müßte.

Dieses hier liefert mir zwar die Zeichenlängen, aber sobald ein MultiByte-Zeichen defekt/abgeschnitten ist, liefert es nur 1
CharLen := CharNextExA(CodePage, Char, 0) - Char Oder muß ich mir da die Zeichensätze zerlegen und eine Prüfung selber bauen,
also über 'ne Mustertabelle mit den existierenden MultiByteZeichen?


PS: für UTF-8 hab ich es schon selber implementiert, da dort CharNextExA immer 1 liefert, was für die interne Positionsbestimmung recht unpraktisch ist.

[Satty67]

Multibyte? Das sind Zeichenketten, die aus einem Standard-SingleChar-Zeichensatz bestehen, wovon ein/mehrere Sonderzeichen definiert sind, die nachfolgende Chars zur Bildung des erweiterten Zeichens brauchen?

Wenn zumindest bekannt ist, dass die vorherigen Chars eine abgeschlossenen Zeichenkette bilden, dann auf Sonderzeichen prüfen.

Wenn quasi mitten in die Zeichenkette reingepickt wird, dann solange zurück lesen, bis eine bekannte Char-Kombination (oder String-Anfang) gefunden wurde. Daraus lies sich dann schließen, ob das ausgepickte Zeichen alleine steht oder Vorzeichen/Nachzeichen hat.

Jaaaa... ich kenne mich überhaupt nicht aus, wenn meine Idee Blödsinn war, dann sehe es als kreativen Push

[himitsu]

Zitat:

Multibyte? Das sind Zeichenketten, die aus einem Standard-SingleChar-Zeichensatz bestehen, wovon ein/mehrere Sonderzeichen definiert sind, die nachfolgende Chars zur Bildung des erweiterten Zeichens brauchen?

jupp

z.B.:
ISO-2022-JP (CodePage 50220), EUC-JP (CodePage 51932) und SHIFT-JIS (CodePage 932)
http://en.wikipedia.org/wiki/Shift-JIS
http://de.wikipedia.org/wiki/Shift_JIS


Nur ich möchte nicht unnötig massig Zeichen verwerfen, nur weil ich nicht "sicher" erkennen kann, ob die vollständig sind.

oftmals sind es ja nur 2-Byte-Zeichenfolgen, aber so muß es nicht immer.

z.B. UTF-8 ist sozusagen auch ein Multibyte-Zeichensatz und da können theoretisch bis zu 9 Zeichen in Folge zusammengehören. (Praktisch dort ist allerdings, daß man aus dem ersten Zeichen direkt über dessen Bits auslesen kann wieviele Folgezeichen dazugehören und die Folgezeichen auch alle ein ganz bestimmtest Bitmuster enthalten, welches sie als Solches erkennen läßt)

Meist ist es aber so, daß ein Trailing-Byte (Folgezeichen) nicht einzeln als solches erkennbar ist und auch das Leadingbyte (Startzeichen) selbst keine Auskunft gibt wieviel noch folgt und es auch keine Endmarkierung gibt.


[add]
So, ich laß grad mal 'nen Test über alle 1-4 Byte-Kombinationen laufen ud mir je Byte-Komination die Länge ermitteln.

Und das für die aktuell 23 wichtigsten Codepages ... aber schon seit dem 3. Durchgang mit der Pseudo-Unicode-Codepage (Codepage: 1200) läuft es voll langsam ... da die Funktion CharNextExA dort gut 1000 Mal langsamer ist, als den vorherigen UTF-7 und UTF-8 ... mal sehn was danach der Rest macht

[himitsu]

ok, hab es jetzt auch mal über GetCPInfo versucht ...

Code:

.                        von GetCPInfo:
Encoding      CodePage   MaxCharSize  LeadBytes

UTF-7            65000   5            -
UTF-8            65001   4            -
UTF-16               0   unbekannt    -
ISO-10646-UCS-2   1200   unbekannt    -
ISO-8859-1       28591   1            -
ISO-8859-2       28592   1            -
ISO-8859-3       28593   unbekannt    -
ISO-8859-4       28594   1            -
ISO-8859-5       28595   1            -
ISO-8859-6       28596   1            -
ISO-8859-7       28597   1            -
ISO-8859-8       28598   1            -
ISO-8859-9       28599   1            -
ISO-2022-JP      50220   5            -
EUC-JP           51932   unbekannt    -
SHIFT-JIS          932   2            129..159, 224..252
WINDOWS-1250      1250   1            -
WINDOWS-1251      1251   1            -
WINDOWS-1252      1252   1            -
WINDOWS-1253      1253   1            -
WINDOWS-1254      1254   1            -
WINDOWS-1255      1255   1            -
WINDOWS-1256      1256   1            -
WINDOWS-1257      1257   1            -
WINDOWS-1258      1258   1            -

UTF-7 und UTF-8: gut, das MaxCharSize stümmt soweit, aber sonst wird von CharNextExA immer nur 1 geliefert

UTF-16: na OK, das ignorier ich eh

ISO-10646-UCS-2: hier sollte eigentlich immer 2 rauskommen, aber gut ... erstens behandle ich es eh schon selber und da Windows dazu keine Codepage-Infos bereitstellt ... kein Wunder, daß es dazu nix gibt

ISO-8859-3: hmmm ... aber egal, da ISO-8859-1 bis ISO-8859-9 eh nur Single-Byte-Codepages sein sollten

ISO-2022-JP: gut, die maximale Länge von 5 Byte pro Char wird schonmal angegeben, aber sonst nix und auch CharNextExA meint immer nur 1

EUC-JP: kennt mein Windows nicht

SHIFT-JIS: hier ist mal alles OK und so wie ich's brauch

WINDOWS-1250 bis WINDOWS-1258: hier stimmt es auch ... alles nur Single-Byte-Codepages ^^


Fazit:
eigentlich kann ich alles so lassen, aber ISO-2022-JP (CP: 50220) und EUC-JP (CP: 51932) macht zicken und außer alles selber zu implementieren fällt mir erstmal nix mehr ein

[himitsu]

sooo, EUC-JP (Extended UNIX Coding) werd ich wohl nicht unterstützen können, da es von Windows nicht unterstützt wird und ich keine rießige Codetabelle mitführen kann und will.

ISO-2022-JP ist meinem Windows zwar bekannt, aber leider fehlen da die Infos von CharNextExA.
außerdem hätte ich probleme beim Schriettweisen dekodieren und noch schlimmer, wenn mal Sprünge in der XML-Datei vorgenommen werden sollen, dann ist es "recht" aufwändig da den Überblick über die aktuelle Codierung zu erlangen.
dieses Ganze umgeschalte über Escape-Sequenzen ist schon recht happig ...
siehe http://de.wikipedia.org/wiki/ISO-2022-JP#ISO-2022-JP


oder ist hier wer der Meinung, mein XML-Parser müßte diese beiden Codierungen UNBEDINGT lesen können?
(schreiben wäre kein Problem)


im Grunde hab ich all diese Codierungen (abgesehn von UTF-7, welches nur drin ist, weil es "gratis" schon verfügbar war) aktuell nur drin, weil es laut XML-Standard "schön" wäre, wenn ein Parser mindestens diese Codierungen verstehn könne.



Also wenn hier keiner Einwände hegt, daß ich dieses (zumindestens Lesend) einfach nicht unterstütze, dann hat sich dieses Problem hiermit ungelößt erledigt