nicht angemeldet
Moin!
Definiere "Hex-Zeichen"?
Na ja, nachdem ich mit phpmyadmin hinzugefügt habe. Stehen anstatt der griechischen - solche Zeichen in der DB: Ӓ, etc.
Dein Browser wandelt die griechischen Zeichen in Entities, weil er sie nicht gültig im Formularzeichensatz codieren kann (der vermutlich ISO-8859-1 ist).
Das ist böse - hatte ich aber schon ausführlich beschrieben. :)
MySQL 4.1 hingegen berücksichtigt diese Problematik und legt das Feld im Zweifel etwas länger an. Wenn du aber (was sinnvoll erscheint) TEXT oder BLOB als Spaltentyp für deinen Text nutzt, stört das relativ wenig.
Aha. So ist das also gemeint. Dann benutze ich halt für alle Felder den Typ "text".
Nein, so war das nicht gemeint. TEXT und BLOB haben andere Aufgaben als CHAR und VARCHAR. Sie sind bei Suchoperationen langsamer, weil in der eigentlichen Datenbank nur Zeiger auf Speicher stehen, der sich ganz woanders auf der Platte befinden kann.
Was ich schon immer wissen wollte und nie verstanden habe ist: Wozu ist das Feld "blob"?
TEXT ist für Text ohne Berücksichtigung der Klein/Großschreibung, BLOB für Text MIT Berücksichtigung - und für Binärdaten.
Die Sache mit Klein-/Großschreibung gilt allerdings für eine UTF-8-unfähige Datenbank nicht für dein griechisch.
Die einzelnen Browser verhalten sich leider höchst ekelhaft, wenn das Formular nicht mit 'accept-charset="utf-8"' arbeitet.
Wo stellt man das denn ein ? Weißt Du vielleich wie man das bei phpmyadmin ändern kann?
Ich habs noch nicht nachgeschaut, aber du hast ja den kompletten Quellcode von PHPMyAdmin da. Suche nach "<form" und prüfe, was da jeweils ausgegeben wird - ändere es ggf. um.
Vielleicht gibts auch eine zentrale Option dafür - ein Blick in die Config-Datei wäre sicher lohnend.
Nein, nein. Der wandelt den Text nicht in Fragezeichen um, es bleibt griechisch, wenn ich es in ein "text"-Feld bei phpmyadmin einfüge. Wenn ich aber dann auf "OK" klicke und die Tabelle browser, dann habe ich halt nur solche numerischen entities in der Tabelle. Ist das Unicode ?
ALLES ist Unicode. Unicode ist die Grundlage von SGML, und damit von HTML und XML. Unicode kann man aber ohne zugehörige Codierung nicht wirklich "anfassen" bzw. speichern. Unicode ist zunächst mal eine abstrakte Zuordnung von existierenden Zeichen zu Zahlenwerten. Das deutsche "A" kriegt die 65, das griechische Alpha die 913.
Und jetzt kommt dein Browser ins Spiel. Du gibst ein griechisches Alpha ein. Das läßt der Browser noch zu. Aber beim Abschicken stellt er fest, dass er ISO-8859-1 schicken soll - und in dieser Zeichencodierung ist ein griechisches Alpha nicht enthalten. Was also tun?
Möglichkeit 1: Den Benutzer drauf hinweisen, dass sein Formular Zeichen enthält, die nicht gesendet werden können. Das tut leider kein Browser.
Möglichkeit 2: Die uncodierbaren Zeichen in Fragezeichen umwandeln und abschicken. Dann werden beim Benutzer hoffentlich auch Fragezeichen auftreten, aber immerhin sind alle gesendeten Zeichen in der Codetabelle enthalten.
Möglichkeit 3: Die uncodierbaren Zeichen in HTML-Entities umwandeln und senden. Das funktioniert dann ganz gut, wenn sich niemand um den Zeichensatz kümmert, aber es hat extreme Nachteile, WENN man sich drum kümmert.
Möglichkeit 3 wirkt so: Du kriegst das ISO-codierte Formular zusammen mit der Zeichenfolge Α anstelle des Alphas. Das speicherst du in deiner DB, und gibst es irgendwann als Zeichenfolge in deiner Seite aus. Wenn du nichts weiter codierst oder in Entities umwandelst, wird im Quelltext 1:1 die Zeichenfolge Α stehen, und das bewirkt die Ausgabe eines großen Alphas.
Wenn du aber vernünftig vorgehst, dann wirst du dem Benutzer erlauben wollen, den Text 1:1 einzugeben, was bedeutet, dass er auch <, > und & direkt eingeben darf, ohne es als Entities schreiben zu müssen. Du speicherst diese Zeichen dann 1:1 in der Datenbank, aber bei der Ausgabe läßt du htmlspecialchars() oder htmlentities() drüberlaufen. Das bedeutet: alle &-Zeichen werden zu "&" umgewandelt, und der Browser zeigt dann ein einzelnes &-Zeichen an.
Wenn du aber in deinem gesendeten Formular das Alpha eingegeben hast, der Browser das aber in Α umgewandelt hat, dann wird die Datenbank diese Zeichenfolge auch wieder ausspucken - htmlspecialchars() wird das &-Zeichen erkennen und ein "&" draus machen, und das Quelltext-Resultat "&#913;" wird im Browser eben NICHT als Alpha angezeigt.
Jetzt könnte man natürlich schlau sein und alle Entities vor dem Speichern in die Datenbank oder nach dem Auslesen z.B. in UTF-8 wandeln. Aber was ist, wenn der Benutzer die Zeichenfolge "Α" ins Formular und damit in die Datenbank geschrieben hat. Beispielsweise in dem Satz "Das griechische wird als Entity Γ geschrieben." Ich denke, du erkennst die Problematik.
Deswegen führt kein Weg dran vorbei, alle Formulare als UTF-8 (oder einer anderen Unicode-Codierung) zu versenden. UTF-8 hat den Vorteil, dass es 8-Bit-ASCII-kompatibel ist, man also in Umgebungen, die mit ISO-8859-1 zurechtkommen, im Grundsatz nichts ändern muß - bis eben auf die Details, die ich jetzt nicht noch mal aufzähle. :)
Habe es nämlich noch nicht mittels php wieder aus der DB herausgeholt und in einer html Seite dargestellt.
Es wird scheinbar funktionieren, dich aber nicht 100% glücklich machen. Und den Besucher auch nicht. Mindestens weil die Seiten durch die Entities ziemlich aufgebläht sind.
- Sven Rautenberg