Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

utf8 + character classification

1 view
Skip to first unread message

Markus Schaaf

unread,
Nov 17, 2021, 9:01:00 AM11/17/21
to
Hallo,

ich schreibe gerade ein paar Minitools, die XML-Dateien lesen.
Ich möchte keine der üblichen Parser-Libs benutzen. Die sind viel
zu komplex und schwergewichtig. Mir reichen mmap(), memchr() und
memcmp(). XML ist per Default UTF-8, und ich bräuchte ein
Unicode-fähiges isalpha(), um Element-Namen zu prüfen, unabhängig
vom Locale. Was ist da die empfehlenswerte Variante, wenn ich
etwas haben will, das fast überall verfügbar ist, oder
leichtgewichtig genug, um es mitzubringen? Letztlich würde mir
eine Liste mit Code-Points, die ich eincompiliere, auch reichen.
(Spielen Combining-Characters eine Rolle für XML-Tags? Oder
müssen die immer in Normalform sein?)

Danke & MfG

Markus Schaaf

unread,
Nov 17, 2021, 9:12:30 AM11/17/21
to
Oder man setzt einfach voraus, dass en_US.UTF-8 installiert ist,
und schaltet die Locales lustig hin und her? Meinungen?

Michael Bäuerle

unread,
Nov 17, 2021, 10:35:50 AM11/17/21
to
Markus Schaaf wrote:
>
> XML ist per Default UTF-8, [...]

Hier steht für XML 1.1 was anderes:
<https://www.w3.org/TR/2006/REC-xml11-20060816/#charsets>
|
| [...]
| All XML processors MUST accept the UTF-8 and UTF-16 encodings of Unicode
| [...]

> [...] (Spielen Combining-Characters eine Rolle für XML-Tags?
> Oder müssen die immer in Normalform sein?)

Ich lese es so, dass sie das sein /sollen/, aber nicht sein /müssen/:
<https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-normalization-checking>
|
| All XML parsed entities (including document entities) SHOULD be fully
| normalized [...]
|
| However, a document is still well-formed even if it is not fully normalized.

Das "fully normalized" bedeutet indirekt Unicode Normalization Form C.

Christian Schumacher

unread,
Nov 17, 2021, 11:18:09 AM11/17/21
to
Markus Schaaf schrieb:
> Oder man setzt einfach voraus, dass en_US.UTF-8 installiert ist,
> und schaltet die Locales lustig hin und her? Meinungen?

~ $ locale -a
C
C.utf8
de_DE.utf8
POSIX


--
Gruß, Christian

»Es ist nicht so, dass ich den Montag hassen würde. Es ist vielmehr der
Trennungsschmerz meiner wunderbaren Beziehung mit dem Wochenende…«

Markus Schaaf

unread,
Nov 17, 2021, 1:03:00 PM11/17/21
to
Am 17.11.21 um 16:35 schrieb Michael Bäuerle:

> | All XML processors MUST accept the UTF-8 and UTF-16 encodings of Unicode

Kommt bei mir nicht vor, aber gut zu wissen.

> | All XML parsed entities (including document entities) SHOULD be fully
> | normalized [...]

Ist für mich gut genug.

Danke!

Markus Schaaf

unread,
Nov 17, 2021, 1:10:41 PM11/17/21
to
Am 17.11.21 um 17:17 schrieb Christian Schumacher:

> ~ $ locale -a
> C
> C.utf8
> de_DE.utf8
> POSIX

Finde ich völlig irrelevant, was Du auf einem System hast. :-)
Genauso hätte ich schreiben können, dass ich expat benutze, und
Du zeigst mir dann ein System ohne.

MfG

Stefan Reuther

unread,
Nov 18, 2021, 11:48:44 AM11/18/21
to
Am 17.11.2021 um 15:00 schrieb Markus Schaaf:
> ich schreibe gerade ein paar Minitools, die XML-Dateien lesen. Ich
> möchte keine der üblichen Parser-Libs benutzen. Die sind viel zu komplex
> und schwergewichtig. Mir reichen mmap(), memchr() und memcmp(). XML ist
> per Default UTF-8, und ich bräuchte ein Unicode-fähiges isalpha(), um
> Element-Namen zu prüfen, unabhängig vom Locale. Was ist da die
> empfehlenswerte Variante, wenn ich etwas haben will, das fast überall
> verfügbar ist, oder leichtgewichtig genug, um es mitzubringen? Letztlich
> würde mir eine Liste mit Code-Points, die ich eincompiliere, auch
> reichen.

Wenn du dich für die "Liste mit Code-Points" entscheidest, da sollte
sich aus der UnicodeData.txt mit ein paar regulären Ausdrücken was
generieren lassen.

awk -F ';' '$3 ~ /L/ {print "case 0x" $1 ":"}' < UnicodeData.txt

Die Frage wäre: muss man in einem "Minitool" wirklich die Element-Namen
prüfen? Mir reicht ja, die Daten an Metazeichen (<>"&=) und Leerzeichen
aufzuspalten, und ob das, was da zwischen den <> steht, nur ein
unbekannter oder gar ein ungültiger Tag-Name ist, ist mir egal. Da
braucht's dann nur eine Liste der gültigen Leerzeichen, die ist deutlich
übersichtlicher.


Stefan

Bonita Montero

unread,
Nov 18, 2021, 2:32:59 PM11/18/21
to
Am 17.11.2021 um 15:00 schrieb Markus Schaaf:
> Hallo,
>
> ich schreibe gerade ein paar Minitools, die XML-Dateien lesen.
> Ich möchte keine der üblichen Parser-Libs benutzen. Die sind
> viel zu komplex und schwergewichtig. ...

Du kannst davon ausgehen, dass das Selbstmachen mehr Aufwand macht
als sich in so eine Lib einzuarbeiten. Außerdem sind die meistens
ziemlich effizient, das muss man auch erstmal schlagen.

Markus Schaaf

unread,
Nov 18, 2021, 3:22:24 PM11/18/21
to
Am 18.11.21 um 17:42 schrieb Stefan Reuther:

> awk -F ';' '$3 ~ /L/ {print "case 0x" $1 ":"}' < UnicodeData.txt

Danke.

> Die Frage wäre: muss man in einem "Minitool" wirklich die Element-Namen
> prüfen?

Ich habe kein Problem damit, Programme zu schreiben, die nur die
benötigten Teilmengen der Funktionalität von XML abdecken.
Allerdings will ich, dass das Programm meckert, wenn es an seine
Grenzen stößt, und nicht einfach Blödsinn macht. Ich erkenne
<?xml, <!--, </, <![CDATA[ und eben < gefolgt von Buchstabe oder
Unterstrich. Bei allem anderen will ich meckern, und nicht so
tun, als wäre es ein Element. Zumal ich selbst es bin, der
schnell mal <%, <# oder <{ einbaut und es dann vergisst.

MfG

Markus Franzke

unread,
Nov 21, 2021, 5:14:00 AM11/21/21
to
Am 17.11.21 um 15:00 schrieb Markus Schaaf:
Hi.

Ich konnte nicht feststellen, mit welcher Sprache du arbeitest, und gehe
mal von C aus.

Ich nutze die C-Version von ezxml (momentan ezxml-0.8.6 - schon älter),
die dir Elemente und Attribute recht simpel zugänglich macht.

Ich lese damit relativ kleine XMLs ein, die komplett im Speicher liegen.

Ob man, wie bei anderen Libraries, Callback Funktionen vorsehen kann, um
größere XMLs in einem Durchgang zu verarbeiten, kann ich spontan nicht
sagen. Falls ja, nutze ich es so nicht.

Das 'Werk' ist jedenfalls sehr klein.

M
0 new messages