mySQL-Fulltext mit base-64 überlisten - gute Idee?

[Andreas-Lindig]

Hallo Forum,

die Volltextsuche in mySQL ist ja, was die Zeichenmenge angeht, ziemlich eingeschränkt: [a-zA-Z0-9äöüß'_] oder so ähnlich. Jedenfalls wohl nicht: [ðñÕÑÏ®­¬«ª©¨§¦¥¤£¢¡¿¾½¼»º¹].

Wie wäre es, wenn ich in PHP alles mit base64_encode() umwandle, die paar enstehenden Sonderzeichen noch maskiere (z.B. / - wenn ich nur wüßte wie, hehe) und diesen String speichere? Dann kann ich in mySQL nach normalen Buchstaben und Zahlen suchen. Hat da jemand Erfahrungen mit?

Gruß, Andreas

[Bio]

Sup!

Du koenntest es auch mit Base32 oder einer eigenen Kodierung versuchen, nur nehme ich an, dass bei fehlenden Wortluecken die Suche von mySQL auch die Graetsche machen wird.

Gruesse,

Bio

[Andreas-Lindig]

Hallo Bio,

Du koenntest es auch mit Base32 oder einer eigenen Kodierung versuchen

welche ist denn am sparsamsten? ich kenne mich da nicht so aus.

nur nehme ich an, dass bei fehlenden Wortluecken die Suche von mySQL auch die Graetsche machen wird.

Die müßten natürlich extra eingesetzt werden. Nach meinen Tests vermute ich, daß base64 für ein Leerzeichen immer g schreibt, bin mir aber nicht sicher.

Gruß, Andreas

[Bio]

Sup!

Die müßten natürlich extra eingesetzt werden. Nach meinen Tests vermute ich, daß base64 für ein Leerzeichen immer g schreibt, bin mir aber nicht sicher.

Ich denke, da Base64 8 Bit-Folgen in 7-Bit-Folgen kodiert, wird wohl kaum immer ein g rauskommen bei einem Leerzeichen...

Gruesse,

Bio

[Sven Rautenberg]

Moin!

Sup!

Die müßten natürlich extra eingesetzt werden. Nach meinen Tests vermute ich, daß base64 für ein Leerzeichen immer g schreibt, bin mir aber nicht sicher.

Ich denke, da Base64 8 Bit-Folgen in 7-Bit-Folgen kodiert, wird wohl kaum immer ein g rauskommen bei einem Leerzeichen...

Base674 codiert eine 24-Bit-Folge (3 Byte) in 6-Bit-Happen in eine 4-Zeichen-Folge (4 Byte) mit je 6 Bits pro Zeichen.

Die zur Codierung von je 6 Bits verwendeten Zeichen sind in dieser Tabelle http://media.it.kth.se/SONAH/ANALYSYS/acts/sonah/guide/mm_mail/mmm31.htm zu finden.

Dort ist nachzulesen, dass die 32 (der ASCII-Wert für das Leerzeichen) mit "g" übersetzt wird. Dies gilt allerdings nur für das ERSTE Leerzeichen einer Folge. Denn beim zweiten Leerzeichen passen die gewählten 6 Bits ja nicht mehr, sondern es wird byteübergreifend gruppiert.

00100000 = 0x20 = 32

00100000 00100000 00100000 = drei Leerzeichen.

Von Links nach rechts werden 6-Bit-Gruppen gebildet:
001000 000010 000000 100000

Die Übersetzung gemäß Tabelle:
G C A g

Mag sein, dass der Vorgang nicht mit dem MSB, sondern mit dem LSB beginnt, aber das Prinzip dürfte klar geworden sein: Drei Leerzeichen hintereinander sind keinesfalls immer derselbe Buchstabe in Base64.

- Sven Rautenberg

[Tom]

Hello,

die Volltextsuche in mySQL ist ja, was die Zeichenmenge angeht, ziemlich eingeschränkt: [a-zA-Z0-9äöüß'_] oder so ähnlich. Jedenfalls wohl nicht: [ðñÕÑÏ®­¬«ª©¨§¦¥¤£¢¡¿¾½¼»º¹].

Wie wäre es, wenn ich in PHP alles mit base64_encode() umwandle, die paar enstehenden Sonderzeichen noch maskiere (z.B. / - wenn ich nur wüßte wie, hehe) und diesen String speichere? Dann kann ich in mySQL nach normalen Buchstaben und Zahlen suchen. Hat da jemand Erfahrungen mit?

Wenn ich die Erläuterungen zu base64 richtig verstanden habe, kann man nicht einfach ein Stück rausschneiden und dann decodieren. Base64 ist eine Art Domino-Codierung. Wenn vorne eine Stück fehlt, bekommt man es hinten nicht mehr (einfach) dekodiert. Dieselben Zeichen findet man also im codierten Stream immer wieder mit vollkommen andere Rückübersetzung. Darauf lässt sich also nur mit Aufwand ein Index aufsetzen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Alexander Foken]

Moin Moin !

Wie wäre es, wenn ich in PHP alles mit base64_encode() umwandle, die paar enstehenden Sonderzeichen noch maskiere (z.B. / - wenn ich nur wüßte wie, hehe) und diesen String speichere? Dann kann ich in mySQL nach normalen Buchstaben und Zahlen suchen. Hat da jemand Erfahrungen mit?

Gute Idee, schlechter Algorithmus. Base64 verteilt 3x 8 Bit auf 4x 6 Bit (plus zwei mehr oder weniger konstante Bits, um es nach Text aussehen zu lassen), d.h. je nach Position im Text und umgebenden Zeichen hat ein beliebiges Zeichen diverse Codierungen.

Anderer Ansatz à la URL-encoding:

"Text speichern" ist: Ersetze im Text alle Zeichen, die nicht Leerzeichen, Buchstabe (A-Z,a-z) oder Ziffer (0-9) sind, durch Unterstrich, gefolgt von der hexadezimalen Darstellung des Zeichens (@ => _40, % => _25, _ => _5F). Speichere den veränderten Text.

"Text laden" ist: Ersetze Unterstrich gefolgt von zwei Hex-Ziffern (0-9A-Fa-f) durch das entsprechende Zeichen (WM_5FQUIT => WM_QUIT). Gebe den veränderten Text zurück.

"Text suchen" ist: Ersetze im Text wie oben alle Sonderzeichen wie in "Text speichern", suche mit dem veränderten Suchbegriff in der Datenbank.

Problem: Du nimmst hierbei explizit eine Codierung an (meistens wohl ISO-8859-1 oder -15). In der Regel stört das nicht, aber wenn das Projekt zu sehr wächst und mal nach Osteuropa muß, hast Du erstmal verloren.

Alexander

[Tom]

Hello,

das wird alles nicht gehne, da ein Index immer in Bezug zu seiner quantisierten Basis aufgebaut wird. Wenn die Quantisierungsbreite also 8 Bit ist, kann man die vorhandenen Index-Funktionen nicht dazu bewegen, plötzlich auf 9 Bit zu arbeiten oder auf "24 in 32"

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Bio]

Sup!

Problem: Du nimmst hierbei explizit eine Codierung an (meistens wohl ISO-8859-1 oder -15). In der Regel stört das nicht, aber wenn das Projekt zu sehr wächst und mal nach Osteuropa muß, hast Du erstmal verloren.

Dann kann er ja die Codierung auch noch in der DB speichern.
Wird dann natürlich alles kompliziert, wenn er einen in 8859-1 Codierung angegebenen Suchstring in einem UTF-16 codierten Text finden will, dann braucht er jede Menge Umwandlungsfunktionen - vielleicht wäre es schlau, dann gleich alles als Unicode zu speichern oder gar eine Datenbank zu verwenden, die eine bessere Volltextsuche hat als mySQL.

Gruesse,

Bio

[Andreas-Lindig]

Anderer Ansatz à la URL-encoding:

[...]

gute Idee.

Problem: Du nimmst hierbei explizit eine Codierung an (meistens wohl ISO-8859-1 oder -15).

also, ich speichere im Moment in utf-8 ab. Der Datensatz der DB ist aber ISO-8859-1, wenn ich das richtig sehe. Also meine Umlaute stehen da jetzt in zwei bis drei Zeichen codiert...

In der Regel stört das nicht, aber wenn das Projekt zu sehr wächst und mal nach Osteuropa muß, hast Du erstmal verloren.

...müßte es bei utf-8 nicht auch mit den Ossis klappen?

Ich habe noch nicht ganz verstanden, welches Problem Du meinst. Bleistift: Ich speichere ü als _FC. In Kyrillisch ist das so'n k mit Haken drauf. Wenn das Projekt aber in Kyrillien benutzt wird, dann würde doch von vornherein die Maskierungsfunktion auf die entsprechenden Zeichen umgestellt. Also schon beim reinschreiben nicht "ersetze ü durch _FC", sondern "ersetze k mit Haken drauf durch _FC".

Btw., weil ich mich im Moment soviel mit diesen Zeichensatzgeschichten beschäftige: wenn ich hier auf deutschem Grund und Boden in meine Tastatur ein ü hacke, schickt die Tastatur dann an meinen Rechner ein ü oder eine 252? Und wenn sie eine 252 schickt, schickt dann nicht die Tastatur des Kyrilliers, wenn er auf dieses k mit Haken haut, auch eine 252 ab? Wenn es mir also gelingt immer die Zahl zu speichern, die wirklich abgeschickt wurde, bin ich dann nicht aus dem Schneider?

Gruß, Andreas

[Sven Rautenberg]

Moin!

Problem: Du nimmst hierbei explizit eine Codierung an (meistens wohl ISO-8859-1 oder -15).
also, ich speichere im Moment in utf-8 ab. Der Datensatz der DB ist aber ISO-8859-1, wenn ich das richtig sehe. Also meine Umlaute stehen da jetzt in zwei bis drei Zeichen codiert...

Die Frage ist: Was kann dein Editor darstellen? Versteht der UTF-8, oder nur ISO-8859-1? Die meisten Freeware-Editoren verstehen leider kein UTF-8 (und auch sonst kein Unicode), weshalb dir anstelle deutscher Umlaute immer ein großes A-Tilde zusammen mit einem weiteren Zeichen angezeigt wird. Andere Zeichen aus fremden Sprachen werden wohlmöglich sogar drei oder vier seltsame Zeichen je Buchstabe auswerfen.

In der Regel stört das nicht, aber wenn das Projekt zu sehr wächst und mal nach Osteuropa muß, hast Du erstmal verloren.
...müßte es bei utf-8 nicht auch mit den Ossis klappen?

UTF-8 ist, da es den gesamten Unicode-Zeichensatz adressieren kann, die Lösung für alle möglichen Zeichenprobleme auf der ganzen Welt. Mehrsprachliche Projekte ohne verpflichtende UTF-8-Codierung zu beginnen, würde ich als grob fahrlässig bezeichnen. In der Theorie ist man mit UTF-8 alle Probleme los. Leider ist da noch die Praxis... :)

Ich habe noch nicht ganz verstanden, welches Problem Du meinst. Bleistift: Ich speichere ü als _FC. In Kyrillisch ist das so'n k mit Haken drauf. Wenn das Projekt aber in Kyrillien benutzt wird, dann würde doch von vornherein die Maskierungsfunktion auf die entsprechenden Zeichen umgestellt. Also schon beim reinschreiben nicht "ersetze ü durch _FC", sondern "ersetze k mit Haken drauf durch _FC".

Diese Vorgänge passieren, wenn du beispielsweise mit ISO-8859-1 (Westeuropa) und ISO-8859-5 (kyrillische Zeichen) arbeitest. Diese Zeichensätze haben neben den bekannten und identischen ASCII-Zeichen (Bytewert von 0 bis 127) unterschiedliche Zeichen für dieselben Bytewerte von 160 bis 255 definiert.

Es ist also grundsätzlich möglich, dass du folgendes abspeicherst:
"Ein ISO-8859-1-String mit den Bytewerten 196, 230 und 164"
Das steht für die drei Zeichen "Äæ¤" (A-Umlaut, ae-Ligatur und Currency-Symbol).

Weiterhin kannst du auch abspeichern:
"Ein ISO-8859-5-String mit den Bytewerten 196, 230 und 164"
Das steht dann für die drei Zeichen F, z und E (wenn ich das man frei übersetze, was mir http://de.selfhtml.org/inter/zeichensaetze.htm so verrät.

Ich hoffe, du erkennst das Problem: Ohne die Angabe "Ein ISO-irgendwas-String" sind die Bytewerte vollkommen wertlos, weil diese ja in allen ISO-8859-X-Definitionen mit irgendeinem sinnvollen Zeichen belegt sind. Man kriegt nur dann raus, welches der vielen Zeichen tatsächlich gemeint ist, wenn man die Zeichentabelle kennt, auf der die Codierung basiert.

Aber auch wenn man UTF-8 verwendet, muß man das angeben. Denn es könnte ja irgendeinen Irren geben, der keinen deutschen Umlaut meinte, sondern tatsächlich "ä" schrieb. Das Auftreten von A-Tilde ist kein markantes Kennzeichen von UTF-8, es ist nur ein möglicher Indikator für menschliche Intelligenz - die fehlt dem Computer bekanntlich vollkommen.

Btw., weil ich mich im Moment soviel mit diesen Zeichensatzgeschichten beschäftige: wenn ich hier auf deutschem Grund und Boden in meine Tastatur ein ü hacke, schickt die Tastatur dann an meinen Rechner ein ü oder eine 252? Und wenn sie eine 252 schickt, schickt dann nicht die Tastatur des Kyrilliers, wenn er auf dieses k mit Haken haut, auch eine 252 ab? Wenn es mir also gelingt immer die Zahl zu speichern, die wirklich abgeschickt wurde, bin ich dann nicht aus dem Schneider?

Die Tastatur schickt an den Rechner Scancodes. Diese werden mit Sicherheit durch diverse Treiber und Codetabellen geschickt, um am Ende ein (bei unicodefähigen Betriebssystemen) eindeutiges Unicode-Zeichen zu produzieren, welches der Applikation übergeben wird, die auf den Tastendruck wartet. 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, dir fehlen dann leider die passenden Tastenbeschriftungen. Aber russisch tippen kann man damit trotzdem (wobei man zum Russisch-Tippen wohl die osteuropäischen Tastaturlayouts installiert haben muß - nur falls du es direkt ausprobieren willst). Einunddieselbe Taste sendet dann immer noch denselben Scancode, aber der wird vom Betriebssystem in ein vollkommen anderes Unicode-Zeichen gewandelt.

- Sven Rautenberg

[Andreas-Lindig]

Hallo Sven,

Die Frage ist: Was kann dein Editor darstellen? Versteht der UTF-8, oder nur ISO-8859-1?

Gut, ich verwende mySQL-Front. Kann scheinbar nur ISO-8859-1. 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.

Es ist also grundsätzlich möglich, dass du folgendes abspeicherst:
"Ein ISO-8859-1-String mit den Bytewerten 196, 230 und 164"
Das steht für die drei Zeichen "Äæ¤" (A-Umlaut, ae-Ligatur und Currency-Symbol).

Weiterhin kannst du auch abspeichern:
"Ein ISO-8859-5-String mit den Bytewerten 196, 230 und 164"
Das steht dann für die drei Zeichen F, z und E (wenn ich das man frei übersetze, was mir http://de.selfhtml.org/inter/zeichensaetze.htm so verrät.

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. Dein Beispiel oben wären in utf-8 ja auch gar nicht mehr 3 Zeichen, sondern anderthalb oder so. 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. 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.

Ich hoffe, du erkennst das Problem: Ohne die Angabe "Ein ISO-irgendwas-String" sind die Bytewerte vollkommen wertlos, weil diese ja in allen ISO-8859-X-Definitionen mit irgendeinem sinnvollen Zeichen belegt sind. Man kriegt nur dann raus, welches der vielen Zeichen tatsächlich gemeint ist, wenn man die Zeichentabelle kennt, auf der die Codierung basiert.

Also: Es geht bei meinem Projekt ja um ein Internet-Forum. Von der DB bekomme ich den utf-8 Wert für ein Zeichen. In der Webseite steht die Codierung "charset=utf-8". Der Brauser zeigt an und verschickt (Formular) also in utf-8. Er zeigt bisher alles richtig an, wenn ich z.B. ISO-8859-1 angebe, zeigt er mir eben diese ä-Folgen für Umlaute. 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? 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 ü?

Aber auch wenn man UTF-8 verwendet, muß man das angeben. Denn es könnte ja irgendeinen Irren geben, der keinen deutschen Umlaut meinte, sondern tatsächlich "ä" schrieb.

Ja, verstanden. Die Angabe habe ich aber in meinem Programm, wenn ich die Seiten entsprechend codiere, oder?

Die Tastatur schickt an den Rechner Scancodes. Diese werden mit Sicherheit durch diverse Treiber und Codetabellen geschickt, um am Ende ein (bei unicodefähigen Betriebssystemen) eindeutiges Unicode-Zeichen zu produzieren, welches der Applikation übergeben wird, die auf den Tastendruck wartet.

aha, also: bei unicodefähigen Betriebssystemen kann ich davon ausgehen, daß der richtige Wert an meine Anwendung weitergereicht wird. Die Anwendung (hier der Brauser) muß jetzt nur noch den Zeichensatz interpretieren können.

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?

Einunddieselbe Taste sendet dann immer noch denselben Scancode, aber der wird vom Betriebssystem in ein vollkommen anderes Unicode-Zeichen gewandelt.

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?

Gruß, Andreas

[Sven Rautenberg]

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

[Andreas-Lindig]

Gut, ich verwende mySQL-Front. Kann scheinbar nur ISO-8859-1.
Wenn das was browserbasiertes ist, dann nicht unbedingt.

nö, ist ein richtiges Programm. Seeehr praktisch.

Aber wofür brauche ich dann den Zeichensatz der DB?

Wenn du die Datenbank aber beispielsweise fragst, wie lang der gespeicherte String denn nun ist
[...] 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?
Der Teufel liegt dann im Detail, wenn es an scriptgesteuerte Textbearbeitung geht.

*grrrmpf* - dann kann ich mir das ganze mit utf-8 jetzt abschminken oder was? Ich suche einiges mit Regulären Ausdrücken. Ich weiß jetzt nicht, ob ich z.B. alles von  [abcü] auf a|b|c|(ü) umstellen kann - meine Suche ist sehr umfangreich. "mySQL kann zur Zeit nur mit ein-Byte-Zeichensätzen umgehen" - d.h. utf-8 kann ich dort nicht intern verwenden. Wie paßt das denn jetzt mit Deiner Empfehlung weiter unten zusammen, besser konsequent bei utf-8 zu bleiben?

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.

hehe, ich meine CK hätte mal gesagt, daß das keine richtige Lösung sei. Ich habe das nicht ganz verstanden, weiß deshalb auch die Details nicht mehr. Er macht das ja auch in diesem Formular hier: da steht im hidden-Feld "&#255;&gt; ". Leuchtet mir noch nicht ganz ein. "&#255;" wird in utf-8 zu zwei Byte ("ÿ"), aber wozu dienen "&gt;" und " "?
Ich kann also am ersten Zeichen zumindest prüfen, ob utf-8 verschickt wurde, indem ich prüfe, ob es zwei Byte geworden sind und ggf. auch noch die zwei einzelnen Bytes auf "Ã" und "¿" prüfe. Aber, wenn _nicht_ utf-8 verschickt wurde, weiß ich ja immer noch nicht, _welcher_ Zeichensatz es denn nun war oder? "&#255;" würde dann doch immer als 255 oder xFF oder \377 - wie auch immer, aber immer mit diesem einen Byte-Wert verschickt oder? Und ob ich diese 255 nun in ISO-8859-1 oder ISO-8859-5 abspeichern muß, weiß ich doch immer noch nicht.

Die Alphabete der tolkienschen Sprachen aus "Herr der Ringe" hingegen sind im Unicode-Standard enthalten.

das finde ich sehr praktisch ;-)

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.

hab ich mal gemacht. Eins verwirrt mich aber noch: man kann für eine neu installierte Sprache dann noch die "Eigenschaften" ändern. In diesem Popup stellt man das "Tastaturlayout" ein. Im Effekt heißt das, daß auf der einzelnen Taste wieder unterschiedliche Zeichen liegen. Wozu muß ich einerseits die Sprache auswählen und andererseits die Zeichen auf der Tastatur nochmals festlegen? Ich habe zum Beispiel Russisch installiert. Und wenn ich in diesen besagten "Eigenschaften" Deutsch auswähle, bekomme ich auf den UmlautTasten tatsächlich kyrillische Zeichen. Wenn ich aber eine andere Sprache wähle, bekomme ich andere Zeichen, z.T. auch kyrillische. Russisch kann ich da z.B. gar nicht wählen. Habe ich jetzt den gleichen Zeichensatz, nur anders auf der Tastatur verteilt? Auf dem Mac kann man die Tastaturbelegung auf dem Bildschirm sichtbar machen - gibt's bei Windows da auch ein Programm für?

Gruß, Andreas
-- <img src="http://was-ist-das.andreas-lindig.de/was_ist_das_fetzen.jpg" border="0" alt="">
hier könnte auch ruhig mal'n neues Bild stehen.