Japanisch mit numerischen Entities / ISO-8859-1

[Stephan Siber]

Ich habe eine Frage an Sven Rautenberg und all die anderen Zeichensatz-Spezialisten hier im Forum:

Ist es jetzt eigentlich möglich, japanisch, koreanisch, chinesisch, russisch und arabisch mit dem Character Set ISO-8859-1 in numerischen Entities z.B.:  す auf einer HTML-Page darzustellen (und zwar ohne Einschränkungen), oder funktionieren nicht alle Zeichen?

Meiner Erfahrung nach funktioniert das nämlich (ich habe es mit japanisch, chinesisch bulgarisch und arabisch probiert), nur kann ich diesen Umstand schwer verifizieren, da ich keine dieser Sprachen spreche.

Gibt es irgendwo eine Tabelle, wo ersichtlich wäre, welche Zeichen(kombinationen)  "exotischer" Schriftsysteme mit diesen Entities nicht lösbar sind?

Vielen Dank für Eure Tipps,
Stephan

[Henryk Plötz]

Moin,

Ist es jetzt eigentlich möglich, japanisch, koreanisch, chinesisch, russisch und arabisch mit dem Character Set ISO-8859-1 in numerischen Entities z.B.:  す auf einer HTML-Page darzustellen (und zwar ohne Einschränkungen), oder funktionieren nicht alle Zeichen?

Natürlich. Das ist ja der Sinn der Sache. Du kannst über numerische Zeichenreferenzen immer alle Zeichen erreichen die Unicode dir zu bieten hat.

(Abzüglich selbstverständlich der Zeichen die im jeweiligen Font nicht enthalten sind, bzw. je nach Browser den Zeichen die in keinem Font enthalten sind.)

[Stephan]

Natürlich. Das ist ja der Sinn der Sache. Du kannst über numerische Zeichenreferenzen immer alle Zeichen erreichen die Unicode dir zu bieten hat.

Coole Sache, und was ist dann genau der Vorteil, wenn man als charset utf-8 anstatt ISO-8859-1 verwendet und dafür keine Entities?

Liegt der Vorteil nur darin, dass die Dateigrösse einer HTML-Datei kleiner bleibt, oder gibt es da noch andere Gründe? Welche Version ist die bessere, und warum?

Danke für Deine Tipps, Stephan

[Henryk Plötz]

Moin,

Liegt der Vorteil nur darin, dass die Dateigrösse einer HTML-Datei kleiner bleibt, oder gibt es da noch andere Gründe? Welche Version ist die bessere, und warum?

Zum einen natürlich die Dateigröße aber zum anderen kann man UTF-8 in vielen Editoren einfach so bearbeiten, bekommt also die eigentlichen Zeichen - und nicht deren Kodierung - zu sehen und kann sie auch direkt eingeben.

[Stephan]

Zum einen natürlich die Dateigröße aber zum anderen kann man UTF-8 in vielen Editoren einfach so bearbeiten, bekommt also die eigentlichen Zeichen - und nicht deren Kodierung - zu sehen und kann sie auch direkt eingeben.

Derzeit ist es ja auch so, dass die meisten Provider MySQL nur in der Version 3.23.49 anbieten und UTF-8 erst ab Version 4.1 funktioniert, oder? Das heisst doch, dass in Versionen vor 4.1 nur die Kodierung mit Entities sinnvoll ist, oder?

[Henryk Plötz]

Moin,

Derzeit ist es ja auch so, dass die meisten Provider MySQL nur in der Version 3.23.49 anbieten und UTF-8 erst ab Version 4.1 funktioniert, oder? Das heisst doch, dass in Versionen vor 4.1 nur die Kodierung mit Entities sinnvoll ist, oder?

Nein, der UTF-8-Support in der Datenbank bringt dir im Wesentlichen nur was für die Stringfunktionen damit die korrekt arbeiten, wenn sie zum Beispiel die Länge bestimmen oder einzelne Teile ausschneiden sollen. Wenn du das nicht hast kannst du die Strings (sinnvoll) in der Datenbank nur wie Binärbrei betrachten (Suchen - auch von Substrings - geht natürlich weiterhin!) und musst zeichenweise Operationen irgendwo ausserhalb machen.

Das trifft so auch vollständig auf die Kodierung als Zeichenreferenzen zu da dort ein einzelnes Zeichen ja ebenfalls nicht immer gleich viele Bytes belegt. Im Prinzip gehen also sowohl UTF-8 als auch ASCII+Zeichenreferenzen gleich schlecht mit der alten Datenbank. (Nicht ganz: Zeichenreferenzen bereiten dir Probleme beim Suchen von Substrings.)

Aber: Unicode kann man ja zum Beispiel auch als UTF-32 bzw. UCS-4 speichern. Dann haben alle Zeichen die gleiche Länge (4 Bytes) und du kannst die Zeichenfunktionen wieder - mit der Ausnahme dass alle Zahlen mal vier gerechnet werden müssen - voll nutzen.

[Stephan]

Das trifft so auch vollständig auf die Kodierung als Zeichenreferenzen zu da dort ein einzelnes Zeichen ja ebenfalls nicht immer gleich viele Bytes belegt. Im Prinzip gehen also sowohl UTF-8 als auch ASCII+Zeichenreferenzen gleich schlecht mit der alten Datenbank. (Nicht ganz: Zeichenreferenzen bereiten dir Probleme beim Suchen von Substrings.)

Bezüglich der Byte-Thematik muss ich mich erst entsprechend einlesen, da weiss ich nicht genau, was du meinst. Unter http://dev.mysql.com/doc/mysql/en/Charset-Unicode.html steht jedenfalls, dass UTF-8 zum Speichern von Daten erst seit Version 4.1 funktioniert.

Ich habe es mit einer alten MySQL-Datenbank probiert und UTF-8 funktionierte nicht (also wenn ich über ein Formular mit charset=utf-8 Text an die Datenbank geschickt habe), ASCII + Zeichenreferenzen (wenn ich über ein Formular mit charset=ISO-8859-1 Text an die Datenbank geschickt habe) funktionierte hingegen schon...

Aber: Unicode kann man ja zum Beispiel auch als UTF-32 bzw. UCS-4 speichern. Dann haben alle Zeichen die gleiche Länge (4 Bytes) und du kannst die Zeichenfunktionen wieder - mit der Ausnahme dass alle Zahlen mal vier gerechnet werden müssen - voll nutzen.

Hast Du da einen Link, wo ich das genau nachlesen kann?

Thanxs, Stephan

[Henryk Plötz]

Moin,

Bezüglich der Byte-Thematik muss ich mich erst entsprechend einlesen, da weiss ich nicht genau, was du meinst.

Es geht einfach darum dass die natürliche Einheit für die Textspeicherung ein Byte ist. Das lässt sich sehr einfach addressieren ("gib mir das dritte Byte", "ich will das sechste bis neunte Byte", etc.) und benutzen. Allerdings kann ein Byte nur 256 verschiedene Werte annehmen, was viel zu wenig für alle möglichen Zeichen ist.

Unicode kennt erstmal keine Bytes sondern Codepoints, also einfach nur ganze Zahlen von Null bis zu einer Obergrenze (die ich mir nicht gemerkt habe weil sie sich eh schon ein paar mal geändert hat). Am Ende kann man aber doch nur Bytes speichern und muß sich etwas ausdenken um eine Folge von Unicode-Codepoints irgendwie in eine Folge von Bytes zu kriegen.

UTF-8 ist eine solche Möglichkeit wobei jeder Codepoint durch ein bis vier (oder waren's sechs?) Bytes dargestellt wird. UCS-4 bzw. UTF-32 ist eine andere Möglichkeit wobei jeder Codepoint durch 4 Bytes repräsentiert wird.

Unter http://dev.mysql.com/doc/mysql/en/Charset-Unicode.html steht jedenfalls, dass UTF-8 zum Speichern von Daten erst seit Version 4.1 funktioniert.

Nein, da steht dass die Datenbank ab der Version UTF-8 versteht und intern als Zeichensatz (blöde Benutzung des Wortes) benutzen kann. Das bringt dir wie gesagt hauptsächlich dass solche Funktionen wie "gib mir das dritte Zeichen" zuverlässig das tun was sie sollen.

Ich habe es mit einer alten MySQL-Datenbank probiert und UTF-8 funktionierte nicht (also wenn ich über ein Formular mit charset=utf-8 Text an die Datenbank geschickt habe), ASCII + Zeichenreferenzen (wenn ich über ein Formular mit charset=ISO-8859-1 Text an die Datenbank geschickt habe) funktionierte hingegen schon...

Das hat damit vermutlich wenig zu tun. Dass mein Perpetuum mobile nicht funktioniert liegt tendentiell auch eher nicht daran dass der Joghurt den ich benutzt habe schon über dem Haltbarkeitsdatum war. Genauso könntest du auf andere Probleme gestoßen sein. Insbesondere das Kapitel der Unterstützung durch Browser ist ein sehr dunkles. Schau mal auf der deutschen Wikipedia, die haben kürzlich auch auf UTF-8 umgestellt und zu dem Zweck diverse Browser getestet und andere Informationen dazu.

Hast Du da einen Link, wo ich das genau nachlesen kann?

http://www.unicode.org/ erscheint mir ein guter Ansatzpunkt zu sein. Ebenso http://www.cl.cam.ac.uk/~mgk25/unicode.html.

[Christian Kruse]

Hallo Henryk,

UTF-8 ist eine solche Möglichkeit wobei jeder Codepoint durch ein
bis vier (oder waren's sechs?) Bytes dargestellt wird.

Es waren sechs.

Grüße,
 CK

[Henryk Plötz]

Moin,

Es waren sechs.

Wie ich schon sagte, die Obergrenze schwankte ein bisschen und es sind jetzt tatsächlich nur vier: http://de.wikipedia.org/wiki/UTF-8 und RFC 3629.

[Christian Kruse]

Hallo Henryk,

Es waren sechs.

Wie ich schon sagte, die Obergrenze schwankte ein bisschen und es
sind jetzt tatsächlich nur vier: http://de.wikipedia.org/wiki/UTF-8
und RFC 3629.

Siehe https://forum.selfhtml.org/?t=86668&m=513750

Grüße,
 CK

[Sven Rautenberg]

Moin!

Derzeit ist es ja auch so, dass die meisten Provider MySQL nur in der Version 3.23.49 anbieten und UTF-8 erst ab Version 4.1 funktioniert, oder? Das heisst doch, dass in Versionen vor 4.1 nur die Kodierung mit Entities sinnvoll ist, oder?

Nein, es hängt davon ab, was die Datenbank tun soll.

UTF-8 ist eine sehr gut ausgedachte Codierungsform. Alle dabei entstehenden 8-Bit-Codes sind voll kompatibel zu allen Mechanismen, die eigentlich nur dafür gedacht sind, irgendein ASCII o.ä. (auch ISO-8859-1 etc.) zu verarbeiten, weil die durch UTF-8 entstehenden Bytecodes zum einen eben immer 8-Bit-Einheiten sind (von denen eine, zwei, drei oder vier zu einem Unicode-Zeichen zusammengehören), zum anderen aber auch immer darstellbare ASCII-Zeichen ergeben, niemals unsichtbare Steuerzeichen. Und außerdem kann man UTF-8 zumindest nach der "Zeichennummer" auch sortieren, ohne zu verstehen, welche Zeichen man da vor sich hat.

Wenn du in der Datenbank also nur Strings speicherst und wieder ausliest, die Datenbank selbst aber mit dem String nichts anfangen muß, kannst du eigentlich jede Datenbank nehmen, die nur irgendwie in der Lage ist, 8-Bit-Zeichen zu speichern. Notfalls nimmst du ein BLOB-Feld, da rein kannst du nämlich alle Bytes von 0 bis 255 speichern - also auch UTF-8.

Problematisch wird's nur dann, wenn es beim Datenzugriff auf Einzelzeichen ankommt.

Beispiel: Um ein alphabetisches Register aller gespeicherten Namen erstellen zu können, verwendet man vielleicht sowas hier:
SELECT ersterbuchstabe_aus(namensspalte) AS anfangsbuchstabe FROM tabelle GROUP BY anfangsbuchstabe

Das ist ein Problem. Die deutschen Umlaute sind UTF-8-codiert zwei Zeichen (das erste ist ein großes A-Tilde). Wenn die Datenbank UTF-8 nicht erkennt, wird bei den normalen ASCII-Zeichen (Bytewert kleiner 127) alles funktionieren, aber das Ä, Ö und Ü würde nicht geliefert werden können - das würde alles zu "A-Tilde" zusammengefaßt.

In solch einem Fall hast du mit der Datenbank ein Problem, weil die Datenbank dann wissen muß, wieviele gespeicherte Bytes denn nun zu einem Unicode-Zeichen dazugehören, andernfalls arbeitet die Zeichenabschneidefunktion falsch.

Das gleiche Problempotential bilden einige reguläre Ausdrücke, die z.B. mit Zeichenklassen operieren. /[a-zA-ZäöüßÄÖÜ]+/ findet mindestens eines der genannten Zeichen. Aber wenn die RegEx-Engine nicht in der Lage ist, die UTF-8-Umlaute als EINEN Buchstaben zu behandeln, sondern nur vom ISO-8859-1-Encoding ausgeht, werden die Umlaute niemals gefunden.

Weil UTF-8 eine eigentlich sehr nette Erfindung ist - jeder sollte es heutzutage eigentlich verwenden, wenn er eine Seite macht, egal ob die nur deutsch oder sogar mehrsprachig ist -, grundsätzlich bis auf oben genannte Feinheiten auch kompatibel zu UTF-8-unverständlichen Umgebungen ist, wesentlich kleinere Dateigrößen ergibt im Vergleich zu den numerischen Entities, und auch beim Formularversand der Browser die beste Lösung ist, wenn alle eingebbaren Zeichen auch tatsächlich auf dem Server ankommen sollen, spricht eigentlich nur noch die mangelnde Unterstützung durch die Texteditoren gegen eine Verwendung.

Aber die Entwicklung geht auch dort weiter. Als Freeware-Editor mit bescheidenen, aber funktionierenden Quelltext-Highlightingfunktionen kann ich "UniRed" empfehlen. Ansonsten können ziemlich viele kommerzielle Programme mittlerweile auch mit UTF-8 so umgehen, dass man tatsächlich das original eingegebene Zeichen angezeigt bekommt: Dreamweaver, Textpad, UltraEdit, Frontpage, Word,...

Ich empfehle http://www.alanwood.net/unicode/utilities_editors.html für eine Auflistung der Marktlage (UniRed ist dort einer der recht seltenen Freeware-Editoren, die auch wirklich komplett funktionieren), sowie die ganze Site für generelle Informationen zu Unicode.

- Sven Rautenberg

[Christian Kruse]

Hallo Sven,

UTF-8 ist eine sehr gut ausgedachte Codierungsform. Alle dabei
entstehenden 8-Bit-Codes sind voll kompatibel zu allen
Mechanismen, die eigentlich nur dafür gedacht sind, irgendein
ASCII o.ä. (auch ISO-8859-1 etc.) zu verarbeiten,

Nein, das stimmt nicht. Es macht spaetestens bei Funktionen wie
fputc() oder aehnlichem Probleme. Nicht umsonst gibt es die w*-
Funktionen.

[...] weil die durch UTF-8 entstehenden Bytecodes zum einen eben
immer 8-Bit-Einheiten sind (von denen eine, zwei, drei oder vier
zu einem Unicode-Zeichen zusammengehören),

Falsch. 1 bis 6 Byte ergeben eine Unicode-Sequenz.

Wenn du in der Datenbank also nur Strings speicherst und wieder
ausliest, die Datenbank selbst aber mit dem String nichts anfangen
muß, kannst du eigentlich jede Datenbank nehmen, die nur irgendwie
in der Lage ist, 8-Bit-Zeichen zu speichern.

Ja.

Grüße,
 CK

[Sven Rautenberg]

Moin!

[...] weil die durch UTF-8 entstehenden Bytecodes zum einen eben
immer 8-Bit-Einheiten sind (von denen eine, zwei, drei oder vier
zu einem Unicode-Zeichen zusammengehören),

Falsch. 1 bis 6 Byte ergeben eine Unicode-Sequenz.

Wenn wir von UTF-8 reden, ist noch 1 bis 4 Byte korrekt. Ich hatte gerade vor zwei Tagen in das Dokument von unicode.org geschaut.

Bei UTF-16 sind es, je nach Zeichen, übrigens 2 oder 4 Byte. UTF-32 ist dagegen wirklich langweilig. :)

Wieso du auf 1-6 Byte kommst, würde mich interessieren.

- Sven Rautenberg

[Christian Kruse]

Hallo Sven,

[...] weil die durch UTF-8 entstehenden Bytecodes zum einen
eben immer 8-Bit-Einheiten sind (von denen eine, zwei, drei
oder vier zu einem Unicode-Zeichen zusammengehören),

Falsch. 1 bis 6 Byte ergeben eine Unicode-Sequenz.

Wenn wir von UTF-8 reden, ist noch 1 bis 4 Byte korrekt.

Kommt drauf an, welches UTF-8 du meinst. Redest du von ISO/IEC 10646,
sind es 1-6 Byte. Redest du von UTF-8, wie es in RFC 3629 definiert
ist, sind es 1-4 Byte. Allerdings heisst es in der RFC auch:

Another security issue occurs when encoding to UTF-8: the ISO/IEC
   10646 description of UTF-8 allows encoding character numbers up to
   U+7FFFFFFF, yielding sequences of up to 6 bytes.  There is
   therefore a risk of buffer overflow if the range of character
   numbers is not explicitly limited to U+10FFFF or if buffer sizing
   doesn't take into account the possibility of 5- and 6-byte
   sequences.

Heisst, sie sollten in jedem Fall beruecksichtigt werden (habe ich
in meinem »UTF-8 to Unicode«-Decoder uebrigens auch getan :-).

Bei UTF-16 sind es, je nach Zeichen, übrigens 2 oder 4 Byte.

Ja.

Wieso du auf 1-6 Byte kommst, würde mich interessieren.

Es gibt zwei UTF-8-Definitionen. Einmal vom ISO (ISO/IEC 10646) und
einmal per RFC definiert. Der ISO-Standard definiert eine UTF-8-
Sequenz als bis zu 6 Byte lang.

Grüße,
 CK

[Stephan]

Nein, es hängt davon ab, was die Datenbank tun soll.

Dank eurer Tipps bin ich jetzt schon um einiges weiter gekommen, habe aber noch eine Frage:

Ich habe ein Formular, über welches japanischer Text in die Datenbank geschrieben werden soll mit charset=UTF-8 versehen und wenn ich den japanische Text über einen Browser ausgebe (wieder mittels charset=UTF-8) so sehe ich die korrekten Zeichen.

Wie kann ich jetzt mit PHP MyAdmin einen korrekten Export der Datenbank in ein CSV-File machen? PHP MyAdmin benutzt als charset ISO-8859-1, daher werden die japanischen Zeichen dort nicht richtig dargestellt und der Export ist "verhunzt"...

CU Stephan

[Stephan]

Zum einen natürlich die Dateigröße aber zum anderen kann man UTF-8 in vielen Editoren einfach so bearbeiten, bekommt also die eigentlichen Zeichen - und nicht deren Kodierung - zu sehen und kann sie auch direkt eingeben.

Kann Excel eigentlich UTF-8 lesen? Wenn ja, ab welcher Version (Mac, Windows)? Wäre interessant für CSV-Exports aus der Datenbank (über PHP MyAdmin), um Datensätze hinzuzufügen bzw. zu löschen...

CU Stephan