nicht angemeldet
Moin!
Gut, ich verwende mySQL-Front. Kann scheinbar nur ISO-8859-1.
Wenn das was browserbasiertes ist, dann nicht unbedingt. Eine Umstellung dürfte aber nicht unbedingt leicht werden.
Aber wofür brauche ich dann den Zeichensatz der DB? Es steht immer, der default-Zeichensatz von mySQL wäre ISO-8859-1. Wenn in dem Datensatz die utf-8-zwei-Byte-Folge für das ü (11000011 10111100) zum Beipiel abgespeichert ist, statt des ISO-8859-1-ein-Byte-Zeichens für ü (11111100) habe ich da doch eine neutrale Information, die erst später in meinem Programm in ein bestimmtes Zeichen umgewandelt wird.
Solange du bzw. die Datenbank die Texteingaben ganz wertneutral als Bytefolge von irgendwelchen Zeichen betrachtest, mit denen man außer verfälschungsfreiem Speichern und wieder Auslesen nichts zu muß, dann ist die Zeichensatzdefinition für die Datenbank vollkommen egal.
Wenn du die Datenbank aber beispielsweise fragst, wie lang der gespeicherte String denn nun ist, gibts zwei Möglichkeiten:
1. Die Datenbank gibt die Zahl der Bytes aus. Dazu muß sie, egal ob ISO oder UTF, einfach nur die Bytes zählen, und fertig.
2. Die Datenbank gibt die Zahl der ZEICHEN aus. Dann muß sie wissen, welche Bytekombinationen aus zwei und mehr Bytes denn für ein Unicode-Zeichen stehen, und das berücksichtigen. Dann ist es nicht mehr egal, ob du ISO oder UTF verwendest, denn bei ISO ist dein "ü" genau ein Byte lang, bei UTF-8 sind es zwei.
Und man kann sich noch einige andere Fälle vorstellen, wo es drauf ankommt, dass zwei oder mehr Bytes eines UTF-8-Zeichens als EIN Zeichen behandelt werden müssen. Beispielsweise bei regulären Ausdrücken. Da kannst du ja Zeichenklassen definieren: /[a-zA-Z]/ steht für exakt EIN Zeichen (kleine oder große Buchstaben von A bis Z). Wie kriegst du da jetzt noch Umlaute mit rein?
Bei ISO-8859-1 kein Problem: Die Umlaute sind auch nur ein Byte groß, /[a-zA-ZäöüÄÖÜ]/ sollte reichen. Bei UTF-8 aber gibts nicht nur Ein-Byte-Zeichen, sondern man muß auch nach Zwei-Byte-Zeichen suchen. Wie toll das geht, hängt extrem von der Implementierung der regulären Ausdrücke ab.
Oder als simples Beispiel: Die PHP-Funktion ord() gibt dir den ASCII-Wert eines einzelnen Zeichens zurück. Ein "ü" ist ein einzelnes Zeichen, aber in UTF-8 sind das zwei Byte. ord() wird hier also versagen, und dir bestenfalls (d.h. wenn du es programmtechnisch abfängst) nacheinander ZWEI Bytewerte geben. Umgekehrt liefert die Funktion chr() eben auch nur Zeichen für Bytewerte von 0 bis 255, aber nicht für Unicode-Zeichenwerte.
Wie gesagt: Wenn man nur irgendeine Zeichenkette speichern und wieder auslesen will, kann man mit Unicode sehr gut arbeiten. Und selbst wenn man die Zeichenketten irgendwie mal angucken will, ohne einen UTF-8-fähigen Editor zu haben, so wird man zumindest das normale Alphabet in Klarschrift lesen können, die Umlaute kann man sich dazudenken. Der Teufel liegt dann im Detail, wenn es an scriptgesteuerte Textbearbeitung geht.
das hieße also, ich müßte für jeden Datensatz den zugehörigen Zeichensatz mit abspeichern? Wenn ich das mache, brauche ich doch im Prinzip kein utf-8 mehr.
Wenn du KEIN UTF-8 verwendest, sondern jeder Datensatz in einer beliebigen Zeichencodierung vorliegen kann, mußt du zwingend die verwendete Zeichencodierung des Datensatzes mit abspeichern.
Wenn du durchgehend UTF-8 verwendest, dann mußt du das nicht mehr bei jedem Datensatz dazuschreiben, den du intern verwendest. Aber du mußt beim Kontakt mit der Außenwelt natürlich diese Information auswerten und weitergeben. Das bedeutet konkret:
-
Ausgegebene HTML-Seiten benötigen die Angabe "charset=utf-8", sinnvollerweise sowohl im HTTP-Header, als auch als Meta-Tag. (PS: Der Begriff "charset" ist eigentlich sachlich falsch, es ist ein encoding).
-
Formulareingaben müssen auf die korrekte Einhaltung und Verwendung von UTF-8 geprüft und validiert werden, ggf. ist eine Umcodierung notwendig, wenn kein UTF-8 verwendet wurde.
Und gerade dieser letzte Punkt ist kritisch bei den derzeitigen Browsern.
Glücklicherweise senden alle aktuellen Browser UTF-8, wenn sie eine selbst UTF-8-codierte Formularseite erhalten, und dort im <form> ebenfalls accept-charset="utf-8" drinsteht.
Wie es sich in diesem Punkt allerdings mit dem Netscape 4 und anderen eher unüblichen Browsern verhält, habe ich noch nicht getestet! Ich vermute schreckliches.
Opera ist in dieser Hinsicht vorbildlich. Selbst wenn man dem Browser mehrere Encoding-Möglichkeiten im Formular eröffnet (accept-charset="ISO-8859-1, UTF-8"), sendet der Browser die gewählte Zeichencodierung als Header im Request mit.
Andere Browser (IE, Mozilla) sind nicht so schlau. Die senden irgendein Encoding, geben aber keinerlei Auskunft darüber, welches Encoding sie denn gewählt haben. Das kommt dann zu Konflikten.
Und wie erwähnt: Wenn ein Browser UTF-8 noch gar nicht kennt, sondern trotz eindeutiger Anweisung still und leise ISO-8859-1 sendet, dann ist das Chaos programmiert.
Es empfiehlt sich daher, im Formular selbst ein paar Indikatorzeichen in Hidden-Feldern unterzubringen. Diese werden vom Browser natürlich ebenfalls mit dem von ihm gewählten Encoding gesendet. Setzt man beispielsweise das Euro-Zeichen und einen Umlaut hinein, kann man hinterher eindeutig prüfen, ob diese Zeichen korrekt UTF-8-codiert zurückkommen. Falls nein, kann man dem Benutzer eine Fehlermeldung geben - und vielleicht die Zeichencodierung noch zurechtbiegen.
Dein Beispiel oben wären in utf-8 ja auch gar nicht mehr 3 Zeichen, sondern anderthalb oder so.
Wenn ich in meinem Beispiel drei Umlautzeichen bzw. drei russische Zeichen UTF-8-codieren würde, würde jedes Zeichen in zwei Bytes codiert werden, der String insgesamt 6 Byte lang werden.
Also, wenn ich richtig verstehe: entweder ich speichere in utf-8 und nur meine Ausgabeprogramme müssen das wissen und ich habe (fast) alle Zeichen zur Verfügung. Oder ich speichere in einem herkömmlichen Zeichensatz und muß das in jedem Datensatz - oder vielleicht für die ganze Tabelle gültig - dazuschreiben.
Mit Unicode HAST du alle Zeichen aller standardisierten Alphabete zur Verfügung. Was fehlt, sind so exotische Dinge wie "ägyptische Bildersymbole" (solange sich selbst die Experten nicht einig sind, wieviele Symbole mit welcher Bedeutung es gibt, kann man da nichts standardisieren) und "Klingonisch" (das war vorgeschlagen, wurde aber wohl abgelehnt, weil es kein "echtes" Alphabet war). Die Alphabete der tolkienschen Sprachen aus "Herr der Ringe" hingegen sind im Unicode-Standard enthalten.
Und für den Gültigkeitsbereich des angegebenen Zeichensatzes habe ich eben auch nur die jeweiligen Zeichen zur Verfügung. Meinem Ausgabeprogramm muß ich den Zeichensatz dann immer jeweils mitteilen.
Richtig. Und das finde ich persönlich ziemlich lästig, deshalb würde ich nach Möglichkeit davon Abstand nehmen.
Wenn jetzt einer in Kyrillien das besagte k mit Haken (in ISO-8859-5 der gleiche Wert, wie in 8895-1 das ü) in das Formular tippt, dann wird je nach Betriebssystemeinstellung das k oder das ü im Forumlar-Eingabefeld angezeigt - und abegeschickt?
Nö. Wenn das k anzeigt wird, wurde das korrekte Unicode-Zeichen eingegeben und vom Betriebssystem erkennt. Es wird korrekt UTF-8-codiert abgeschickt werden.
Wenn das ü erscheint, wurde das Unicode-Zeichen "u-umlaut" erkannt und würde abgeschickt.
Oder anders gefragt: kann ich davon ausgehen, daß das, was der User in seinem Formular sieht, auch als korrekter utf-8 Wert übermittelt wird, also für ein k mit Haken ein anderer Wert als für ü?
Davon kannst du ausgehen, solange der Browser UTF-8 versteht. Wie erwähnt: Bei älteren Modellen ist mit Problemen zu rechnen - bei aktuellen Modellen (alle Mozillas ab 1, IE ab 5, Opera ab 5) nicht.
Du kannst ja schließlich unter Windows (würde mich wundern, wenn Linux da versagt) mehrere Tastaturtabellen gleichzeitig installieren und mit Mausklick (oder Tastenkombi)umschalten. Dann hast du eine russische Tastaturbelegung
Das würde mich ja mal intressieren. Wie geht das?
Gehe in die Systemsteuerung, Icon "Tastatur" (oder Keyboard). Dort sollte "Deutsch" als einzige Option angezeigt werden, du kannst dann mit "Hinzufügen" weitere Tastaturbelegungen installieren.
Und irgendwo dort gibts einen Haken, dass die Umstellmöglichkeit in der Taskleiste angezeigt wird.
solangsam geht mir was auf: Das Betriebssystem macht aus einer Taste ein eindeutiges Zeichen? Ein Osteuropäer hat eine betimmte Einstellung - "Windows-ost" oder so -, die ihm das auf den Bildschirm zaubert, bzw. an die Anwendung schickt, was auf seiner Tastatur steht?
Hat damit auch zu tun, daß, wenn ich meinen Rechner im Bios (oder wie das heißt) starte, die X- und Y-Taste vertauscht sind?
Richtig. Die Tastatur sendet im Prinzip nur "Taste gedrückt in Zeile 2, Spalte 7". Der Computer interpretiert das so, dass bei einer amerikanischen Tastatur das Y, bei einer deutschen Tastatur das Z gedrückt wurde. Da das BIOS nur amerikanische Tastaturen kennt, sind Z und Y eben scheinbar vertauscht.
- Sven Rautenberg