Moin!

Ich erinnere nochmals an die Intention von Dieter, der lokal verfügbare Dateien klassifizieren wollte u.a. nach ihrer Codierung. Da gibt es ja nicht nur UTF-8

Richtig, aber die Welt der Zeichencodierung zerfällt - zumindest in der Welt von (X)HTML - sehr eindeutig in zwei Teile:
1. Codierungen, die den gesamten Bereich der Unicode-Zeichen abdecken.
2. Codierungen, die nur eine Teilmenge der Unicode-Zeichen abdecken.

Zur Gruppe 1 gehören Codierungen wie UTF-7, UTF-8, UTF-16 und UTF-32.

Zur Gruppe 2 gehören Codierungen wie US_ASCII, ISO-8859-1, ISO-8859-15, Windows-1252 (für den westeuropäischen Bedarf), Big5, ISO-2022-CN (für Chinesisch), ISO-8859-6, Windows-1256 (für Arabisch) - und so weiter.

Kennzeichnend für alle Codierungen der zweiten Gruppe ist, dass sie für sich genommen keinerlei Methode bieten, Unicode-Zeichen, die nicht enthalten sind, doch irgendwie zu codieren. Als Hilfsmittel ist deshalb für HTML der Umweg über Entities (ä = ä, Α = griechisches Alpha) und numerische Zeichenreferenzen (𝄞 für den Violinenschlüssel).

Die sinnvolle Klassifizierung sollte Aufschluss über den Aufwand bei der weiteren Ver-/Bearbeitung geben können.

Meine Praxiserfahrung: Der Aufwand des Weiterverarbeitens von "echtem UTF-8" (bzw. dem, was man als solches einfach mal nimmt) ist ziemlich gering, solange man nicht versucht, aus dem UTF-8 irgendwas anderes zu machen, z.B. das Encoding zu wechseln.

Will man das Encoding wechseln, setzt man (was auch sehr geringen Aufwand verursacht) entsprechende Bibliotheken ein, die das erledigen. Kann man entsprechende Bibliotheken nicht einsetzen, so hat man automatisch großen Aufwand, weil man mindestens mal eine Codetabelle (256 Zeichencodierungen z.B. von ISO-8859-1) mit deren Unicode-Entsprechungen definieren muß.

Hat man diese Codierung aber definiert, so benötigt man die Information "ist ein Zeichen mit 2 Bytes in UTF-8" nicht, sondern man erstellt ganz simpel einen Mechanismus, der jedes Unicode-Zeichen (auch die mit 3 und mehr Bytes) komplett dekodiert und somit den Unicode-Codepoint ermittelt, um damit dann das umcodierte Zeichen des Ziel-Encodings zu finden. Dabei gehen unter Umständen große Teile des im String enthaltenen Zeichenraumes verloren, weil es keine Entsprechung gibt, und man in irgendeiner Form gegensteuern muß.

Aber zu keiner Zeit in diesen Mechanismen ist es von irgendeiner Relevanz, wieviele Byte tatsächlich zur Bildung eines UTF-8-Zeichens benötigt werden. Es klassifiziert jedenfalls nichts, was bei der Problemstellung irgendwie hilfreich sein könnte.

Ich würde es daher begrüßen, wenn auch Du nicht nur gegenhältst, sondern vielleicht auch ein paar Untersuchungen in Richtung "wie könnte man das zweckmäßig umsetzen" machen würdest.

Vielleicht solltest du auch nicht nur gegenhalten, sondern mal deutlich machen, wo du denkst, dass man deine "UTF-8-Stufe" denn tatsächlich benötigt.

---- only philosophy ----
Das Vorhaben habe ich als äußerst sinnvoll eingestuft, da unser Babylon schließlich auf vielen getrennten Wegen unaufhaltsam näher rückt, und eines Tages unbarmherzig zuschlagen wird.

Unicode hilft dabei. Alle Anwendungen, die heutzutage neu erstellt werden, insbesondere webbasierte Lösungen, sollten unbedingt unicodefähig sein - entweder als einzige Codierungsform, oder mindestens alternativ.

Word beispielsweise macht in deutscher Einstellung sehr heftigen Gebrauch von Unicode - Gedankenstriche, Anführungszeichen - sind alles Zeichen, die in ISO-8859-1 nicht darstellbar sind, und immer wieder zu Problemen führen.

- Sven Rautenberg