Zeichenkodierung
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
ausgabe
auslese
beispiel
browser
code
datenbank
datum
dokument
editor
header
http
kodierung
paar
problem
set
text
umlaut
url
verbindung
zeichen
-
Hallo Leute
Ich habe heute den halben Tag damit verbracht meine Seite in Sachen Zeichenkodierung zu fixen, mich dabei durch zahlreiche Foren gesucht und Seiten gelesen die einem vieles Wissen vermitteln, was aber letztlich doch irgendwie alles etwas unverständlich ist, daher möchte ich das ganze hier nochmal besprechen!
Es geht um die Zeichenkodierung im Web!
Standard an allen möglichen Ecken scheint ja UTF-8 zu sein, aber auch gängige ISO Formate wie zB ISO-8859-1 bzw ISO-8859-15, welche ja speziell auf westliche Kodierung ausgelegt sind.
Nun habe ich folgende Komponenten auf meiner Webseite:
HTML Elemente
PHP Elemente
Input Tags für Benutzereingaben
Javascript
MySQL
All diese Komponenten spielen ja in gewisser Weise zusammen und jede dieser Komponenten bedarf es einer Zeichenkodierung, dessen Zusammenspiel ich bisher nicht wirklich verstehe.
Zb habe ich eine Benutzereingabe mit Umlauten (ä,ö,ü) welche dann per AJAX-Request über ein JS-Script an eine PHP Datei gesandt wird und letztlich die Eingaben in eine MySQL-Datenbank überträgt.
Mein Problem derzeit ist, dass eine Eingabe mit Umlauten im JS noch richtig behandelt wird, im PHP Skript ebenfalls korrekt dargestellt wird, aber dann in der MySQL Datenbank keine korrekte Darstellung mehr besitzt.
Nun also die generelle Frage, welche Kodierung die beste/effektivste ist und wie ich das Zusammrenspiel der Komponenten gewährleiste. Weiterhin ist die Frage, wie ich das schreiben von HTMLEntities umgehen kann, da ich sehr viel Text auf meiner Seite habe, bei dem es eher umständlich ist alle Umlaute durch die entsprechenden Entities zu ersetzen...
-
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
also, wenn du die Umlaute nicht alle maskieren willst, dann würde ich utf-8 nehmen...
im HTML kann man das ja ganz einfach setzen... in PHP setzt du das dann mit
header( 'Content-Type: text/html; charset=UTF-8');
und bei MySQL kannst du eine entsprechende Kollation (utf8_unicode_ci)
lediglich JavaScript ist das problem, da suche ich gerade selbst nach einer Lösung, wie man das ganze auf utf-8 bekommt...
Gruß
technofan -
Nicht vergessen dass man dem mysql auch noch sagen muss mit welchem Zeichensatz man sich verbindet:
http://www.php.net/manual/de/function.mysql-set-charset.php
http://dev.mysql.com/doc/refman/5.1/de/charset-connection.html
Dann sollte es klappen mit mysql.
Javascript läuft im Browser, also auf dem Client. Welchen Zeichensatz dieser Browser verwendet kannst Du nicht vorhersehen.
Speziell in einem alert erlebt man da so manche Überraschung.
-
Also jetzt komme ich total durcheinander..
Ich hab in meinen PHP files folgende Kodierung gesetzt:
header( 'Content-Type: text/html; charset=UTF-8');
In der .htaccess ebenfalls
AddDefaultCharset UTF-8
Meine Datenbank in PHPMyadmin habe ich bei "Zeichensatz/Kollation der MySQL-Verdinung utf8_unicode_ci gesetzt.
Das Datenfeld in meiner DB, was als text deklariert ist, bekommt ebenfalls utf8_unicode_ci.
Eine Testeingabe mit einem Forumlar ergibt nun:
Formular: ä ü ö
Datenbank: ä ö ü
Ausgabe in HTML: ä ü ö
Weiterhin sind alle anderen Umaulte auf meiner Seite durch Fragezeichensymbole � ersetzt
Irgendwie komme ich mit diesem Konzept der Zeichenkodierung nicht klar..
Jetzt ist alles durcheinander...
Wenn ich jetzt im Browser manuell auf ISO-8859-1 schalte werden alle Umlaute wieder richtig angezeigt, aber die Ausgabe meines Forumlars via HTML ergibt dann wieder ä ö ü
Wie soll man da noch durchblicken???????
Beitrag zuletzt geändert: 9.5.2010 21:40:24 von beachteam -
PHP hat UTF-8-kodierte Daten gesendet. Jedoch hat MySQL unter der Annahme, es kämen Latin1-Daten die Bytesequenz eines UTF-8-Zeichens oberhalb von 0x7F als einzelne Zeichen betrachtet. Wenn die Feldkodierung auf UTF-8 eingestellt war, hat MySQL nun diese beiden vermeintlichen Latin1-Zeichen einzeln nach UTF-8 umkodiert und abgelegt. Ein LENGTH() sollte 4 Bytes zeigen, ein CHAR_LENGTH() hingegen 2 Zeichen, zuzüglich der Zeichen unterhalb von 0x7F.
Der PMA forderte auf seiner Verbindung UTF-8-kodierte Daten an. Beim Auslesen war also keine Umkodierung erforderlich. Deine Applikation hat nichts gesagt und damit galt Latin1. MySQL hat nun die UTF-8-kodierten Daten zurück nach Latin1 gewandelt. Bei den ehemals fehlerhaft eingelesenene Daten wurden aus den 4 UTF-8-Bytes wieder die zwei Latin1-Bytes, die du als UTF-8 interpretiert hast. Die ordentlich kodierten per PMA eingegebenen Zeichen wurden ebenfalls nach Latin1 umkodiert, wenn das betreffende Zeichen überhaupt in Latin1 verfügbar war. Ein einzelnes Latin1-Zeichen oberhalb von 0x7F ist aber keine gültige UTF-8-Bytesequenz, was dann zu dem auf der Spitze stehenden Fragezeichenquadrat führt.
Die Daten werden vielleicht vom Client als UTF-8 gesendet und erwartet, jedoch ist keine Verbindungskodierung ausgehandelt worden, weswegen der Systemdefaultwert Latin1 herangezogen wird. Der PMA hat seine Hausaufgaben gemacht und sendet und erwartet UTF-8, und hat dies für sich auch so ausgehandelt. Bei deinen unausgehandelten Verbindungen interpretiert MySQL die beiden Bytes eines UTF-8-kodierten ä als einzelne Latin1-Zeichen.
Lange Rede, kurzer Sinn: Feldtyp sollte Latin1 sein und mysql_set_charset() dürften dir dabei helfen, dein Problem zu lösen.
Da ich aber so ein "faules Kerlchen" bin, speichere ich meistens sämtliche Strings mit urlencode() und formatiere sie beim Auslesen wieder mit urldecode()
Beitrag zuletzt geändert: 9.5.2010 22:24:26 von fabo -
Hm also wenn ich mir deinen text vielleicht noch 3 mal durchlese und es nicht ganz so spät ist, dann könnte ich da die maximale information raus holen, im Moment verwirrt es mich eher!
Du sagst also ich soll zwar auf meiner Seite alles auf UTF-8, aber meine DB auf latin1 stellen? Ich dachte man sollte das einheitlich machen?
Bzw haben meine SQL Requests ja nichts damit zu tun, dass keine Umlaute auf meiner Seite (sondern als Fragezeichen) angezeigt werden, wenn ich auf meiner Seite UTF-8 wähle...
Wie gesagt, bin in dem Thema nicht wirklich fit... -
Das Problem, welches fabo anspricht, ist folgendes:
Du bekommst bei der PHP-Datei z.B. ein ä, das entspricht in UTF-8 dieser Bytestruktur: 0x00c3 0x00a4
und in LATIN1 dieser hier: 0x00e4
So wie gesagt bekommst du das rein als UTF-8.
Dein PHP sendet dass dann an MySql und MySql denkt es hantiert mit LATIN1, sprich es denkt es habe nicht 1 Buchstaben vor sich sondern 2 und zwar statt dem ä diese hier: ä
So und als diese speichert mysql das auch!
Als Kodierung in der MySql-Tabelle kann da stehen was will, denn es wird eh jedes Byte einzeln betrachtet, aber wenn es ausgeliefert wird, dann kommt die Kodierung zum Tragen, denn weil MySql dann alles als UTF-8 ausliefert, ohne wieder zurück zu formatieren, bekommt man 2 Zeichen statt einem.
Umgehen kannst du das auf 2 Wege;
1. Du veränderst nichts an den MySql-Einstellungen, da dann das Resultat egal, ist ja das selbe wie das was reinkam, oder;
2. du sagst MySql vorher bescheid, dass es mit anders kodierten Daten zu tun hat und das geht dann mit: mysql_set_charset()
Ich hoffe ich hab niemanden zu sehr verwirrt und hoffe dass ich einigermaßen Fehlerfrei geblieben bin, im versuch das Ganze etwas einfacher zu verpacken. -
Das klingt schon etwas einleuchtender!
Allerdings habe ich es ja hier mit zwei verschiedenen Problemstellungen zu tun.
Zum einen geht es ja darum, dass ich eine Benutzereingabe aus einer <textarea> mit Umlauten in meine MySQL Datenbank speichere, und dabei dann die entsprechenden fehlerhaften Ausgaben bekomme, wenn ich die Daten schließlich wieder auslese und per PHP ausgebe. Ihr sagt hier ich solle mysql_set_charset() verwenden, ist das verträglich mit PDO, da ich PDO benutze um die Kommunikation zwischen PHP und der DB zu gewährleisten!
Zum anderen allerdings habe ich einfache Umlaute in den Text meiner Seite direkt eingebaut. Also zum Beispiel direkt in einem <p>-Tag, ohne vorher irgendwelche Kommunikation mit einer Datenbank zu haben. Wenn ich hier nun aber wie gesagt im header UTF-8 und auch in der .htaccess UTF-8 angebe, dann werden die Umlaute als Fragezeichen dargestellt. Gibt es hier eine Möglichkeit das ganze mit UTF-8 zu regeln, oder muss ich generell auf ISO-8859-1 umschalten?
Hoffe es ist klar geworden welche zwei verschiedenen Problemstellungen ich meine! -
sach mal mit welchem Editor arbeitest du??
Speichert der die Dokumente per default als UTF-8? Notepad++ mach dies zum Beispiel nicht und der win Notepad kann das gar nicht.
Unter Linux speichern die Editoren das i.d.R. per default.
Wenn der Editor das auch als UTF-8 abspeichert, dann kannst du da auch das reinschreiben: 新ä情ö報üバルキリー ⇗↯↬⇶
(das ist irgendwas Japanisches ein paar pfeile und äöü), das sollte das Dokument nicht interessieren, das selbe wenn du den ganzen Kram in eine Datenbank schreibst, sofern du da nicht an den default Einstellungen verändert hast.
Und den character-set machst du mit PDO so:
$dbh->exec('SET CHARACTER SET utf8'); -
Ich schreibe meinen Quellcode mit Eclipse und dem entsprechenden HTML bzw PHP Plugin dazu, da kann man sicher auch einige Default-Werte einstellen, werd ich nachher mal genauer begutachten.
Das Problem ist halt das zusammenspiel der Komponenten.
Mit ISO-8859-1 wird meine Seite korrekt angezeigt, aber die DB-Ausgaben nicht
mit UTF-8 werden die DB-Ausgaben korrekt dargestellt, Umlaute auf der Seite aber nicht
Weiterhin schaue ich auch gerne in meine DB rein (da die Datenmengen sich in Grenzen halten) und würde da auch eher ungerne auf komisch formatierte Umlaute stoßen, auch wenn sie dann schließlich auf der Seite korrekt dargestellt werden, sucher daher nach einer Universallösung für alles. -
So mit der Aussage komme ich schon besser klar Eclipse ist schonmal eine gute Idee, ich selbst benutze Aptana.
Eclipse encodiert per default in UTF-8, deswegen weiß ich nicht warum die Zeichen im Quelltext bei UTF-8 falsch angezeigt werden, kannst du da mal eine Beispiel seite zeigen (ich wette 1€ darauf, dass die Dokumente in ISO-8859-1 gespeichert werden), dass die Datenbankdaten korrekt angezeigt werden ist ja schonmal ein Erfolg.
Beitrag zuletzt geändert: 10.5.2010 16:22:01 von nemoinho -
Also ich habe jetzt in Eclipse alles was ich konnte auf UTF-8 umgestellt, war vorher auf CP1252 eingestellt.
Das ganze sieht nun gut aus, wenn ich noch jeweils den PHP Header mit UTF-8 einfüge wird alles korrekt dargestellt, in der DB habe ich auch alle Kollationen auf UTF-8 Unicode gestellt. Allerdings funktioniert es hier noch nicht richtig.
Zwar wird die DB Ausgabe auf der Seite korrekt dargestellt, in der DB selbst werden aber immernoch die falschen Umlaute gespeichert.
Habe da noch ein paar Probleme mit dem Code bei
$dbh->exec('SET CHARACTER SET utf8');
das ganze muss ich nur einmal bein anlegen der Verbindung machen odeR?
Ich verwende
function MyBib() { try { $dbhost = 'mysql.lima-city.de'; $dbuser = 'USER156594'; $dbpass = '********''; $dbname = 'db_156594_1'; $this->db = new PDO("mysql:host=$dbhost;dbname=$dbname", "$dbuser", "$dbpass"); $this->db->exec('SET CHARACTER SET utf8'); return true; } catch (PDOException $e) { echo "Datenbank-Fehler: ". $e->getMessage(); return false; } }
Ist das so korrekt oder muss ich das vor jedem Query einfügen?
EDIT: Ok scheint zu klappen, ich teste noch ein wenig, sieht aber gut aus =)
Beitrag zuletzt geändert: 10.5.2010 20:58:40 von beachteam -
Jo, so wird das Characterset eingefügt,
scheint wohl an der Windows Variante von Eclipse zu liegen, dass es in CP1252 gespeichert, wurde (da sieht man mal wieder wie einfach man von ein paar Zahlen und Buchstaben auf ein OS schließen kann).
Und wie ich schon ein paar mal geschrieben habe ist es ziemlich egal was in der Datenbank gespeichert wird, solange die Ausgabe stimmt, deswegen stell ich da mittlerweile auch nichts mehr um, denn ich will die Daten ja nicht in phpmyadmin toll dastehen haben, sondern auf der HP
Aber das ist eine Ansichts- und auch Adminestrationssache, kommt halt drauf worauf man wert legt, und zur Not schreib ich mir mein eigenes Datenbankadminprogramm.
Schön nochmal zu erfahren dass ich helfen konnte. -
Hm ja da ich ständig an meiner Seite bastel ist es zum Überprüfen und Kontrolliren immer ganz gut sich das ganze direkt in der DB anzuschaun, statt extra eine Ausgabe zu schreiben
Dann aber trotzdem ein riesen Dankeschön hat mir sehr geholfen und nun funktioniert endlich alles wie es soll!
-
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
