Zeichsatz-Codierung Formulare<->PHP<->mySQL

lupusoft

lupusoft

Aktives Mitglied
Thread Starter
Dabei seit
05.01.2004
Beiträge
250
Reaktionspunkte
4
Moin,
ich habe gesehen, dass das Thema zwar in einigen threads angeschnitten wird, aber mir ist da einiges generell unklar. Meine Ausgangsbasis ist also ein XAMP, sprich Apache, PHP, mySQL. Der Indianer liefert u.a. Seiten mit Formularen, die per POST an PHP gehen, das wiederum eingegebene Texte in der mySQL Bank speichert. Die Web-Clients können natürlich unterschiedlichster Herkunft sein und haben entsprechend unterschiedliche Codierungen. Probleme hab ich nun an allen Ecken und Enden:

1) PHP baut in die Seiten fixe Textfragmente ein, die es teilweise aus der mySQL Bank holt. Wenn ich diese Textvorlagen (meist mit CocoaMySQL) direkt mit Umlauten schreibe, kommt Murks raus. Das scheint auch unabhängig davon zu sein, was ich als Codierung in CocoaMySQL angebe. Meine momentane Lösung ist, dass ich die Textfragmente in der Bank schon html-codiert eingebe (also &auml; statt ä usw.).
2) Gibt ein User Umlaute in ein Formulartextfeld ein und ich baue das später wieder in eine Ausgabeseite ein, kommt ebenfalls Murks raus. Das gilt auch für gespeicherte Texte in der Bank, die ich mir mit CocoaMySQL direkt anschaue.
3) Teilweise frage ich die mySQL Einträge von einem OS9 Programm aus ab. Ist klar, was da rauskommt, gelle?

Also prinzipiell ist mir bewusst, dass ich eine Codierung festlegen muss, nur wie und wo? Ich schätze mal, es gibt die Möglichkeiten:

a) MySQL - in my.cnf ??? In den Vorlage-Konfigurationsdateien habe ich nichts gefunden. Woran dreht denn CocoaMySQL wenn man das "Encoding" popup benutzt?
b) PHP - in php.ini gibt es da was
Code:
; As of 4.0b4, PHP always outputs a character encoding by default in
; the Content-type: header.  To disable sending of the charset, simply
; set it to be empty.
;
; PHP's built-in default is text/html
default_mimetype = "text/html"
default_charset = "iso-8859-1"
iso-8859 müsste das gleiche sein wie iso-latin-1, oder? Wenn ich iso-latin-1 in CocoaMySQL einstelle, bringt das nix. Spielt es denn eigentlich eine Rolle in welcher Form ich die .php Datei selber abspeichere? Da kann ich ja auch wieder reinen Text oder UTF8 oder was weiss ich wählen.
c) Die Header der HTML-Dateien - also sowas
Code:
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
Wenn ich php.ini in b) richtig verstanden habe, dann müsste er das ja sowieso reinbauen. Tut er aber nicht (Quelltext im Browser). Das kann aber möglicherweise daran liegen, dass ich HTML-Templates arbeite.
d) Apache - soweit ich das bei den endlosen Optionen überblicke, kann man in httpd.conf nur den default MIME type einstellen, oder???

Hat irgendwer den Überblick bei den ganzen Encoding-Sachen und kann mir weiterhelfen? Dank an alle, die sich schon mal mit dem Lesen bis hier durchgekämpft haben ;-)

Gruss, Lupus
 
Hui, da hast du eines der schwierigsten Themen des WebDesigns angesprochen! Da gibt es ne Menge Faktoren, die da mit reinspielen können.

Was CocoaMySQL bei der Encoding-Einstellung macht, ist nur die Art, wie die aus der Datenbank geholten Daten interpretiert oder geschrieben werden. Schreibst du mit ISO-Latin-1 ein "Ä" rein, dürfte es auch das nächste Mal so rauskommen, wenn du wieder ISO-Latin-1 eingestellt hast. Stellst du ein anderes Encoding ein, dann klappt das nicht und es kommt Müll zurück. Das heißt, es kann sein, dass nach deinem Probieren da jetzt schon gemischte Umlaute in verschiedenen Encodings drin stehen.

Du könntest mal phpMyAdmin (http://www.phpmyadmin.net) installieren und dann mal bequem schauen, wie die Encodings von der Datenbank und den Tabellen sind. Das geht dort besser als über die Kommandozeile oder über CocoaMySQL.

Weiterhin solltest du unbedingt in deine HTML-Seiten das Encoding über folgende META-Angabe im Head einstellen:
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">

Wenn du es über eine so formatierte Seite reinschreibst und rausliest, sollte auch immer dasselbe drin stehen.

Wie sehen denn die falschen Zeichen dann aus? Werden es Fragezeichen, oder Ornamente, oder ganz was anderes?

Mac OS9 braucht aber in jedem Fall ziemlich sicher eine Sonderbehandlung, die das ganze auf Mac OS Roman umwandelt, das geht mit ISO-Latin eher schlecht. Oder du steigst komplett auf Mac OS Roman um, das musst du dann nur in der Meta-Angabe einstellen.

Das war jetzt ganz schön viel, aber das ist eben auch ein sehr komplexes Thema …

Viele Grüße,

Simon
 
Hallo Simon,

danke erstmal für die prompte Antwort.
WizardS schrieb:
Hui, da hast du eines der schwierigsten Themen des WebDesigns angesprochen! Da gibt es ne Menge Faktoren, die da mit reinspielen können.
Joo, den Eindruck hab ich auch gewonnen...
Was CocoaMySQL bei der Encoding-Einstellung macht, ist nur die Art, wie die aus der Datenbank geholten Daten interpretiert oder geschrieben werden. Schreibst du mit ISO-Latin-1 ein "Ä" rein, dürfte es auch das nächste Mal so rauskommen, wenn du wieder ISO-Latin-1 eingestellt hast. Stellst du ein anderes Encoding ein, dann klappt das nicht und es kommt Müll zurück. Das heißt, es kann sein, dass nach deinem Probieren da jetzt schon gemischte Umlaute in verschiedenen Encodings drin stehen.
Ach ja, gut zu wissen.
Du könntest mal phpMyAdmin (http://www.phpmyadmin.net) installieren und dann mal bequem schauen, wie die Encodings von der Datenbank und den Tabellen sind. Das geht dort besser als über die Kommandozeile oder über CocoaMySQL.
Da bin ich bis jetzt vor zurückgeschreckt, weil ich CocoaMySQL eigentlich recht gelungen und übersichtlich finde. Ein phpMyAdmin muss man sicherlich erst wieder einbruchsicher machen, oder gibt es eine einfache Möglichkeit es für Abfragen von aussen zu blocken? Das Teil besteht doch selbst nur aus PHP-Seiten dachte ich. Aber davon ab: wie kann phpMyAdmin denn feststellen in welchem Encoding die Einträge gemacht wurden? Das wird doch nirgends in den records gespeichert, oder?
Weiterhin solltest du unbedingt in deine HTML-Seiten das Encoding über folgende META-Angabe im Head einstellen:
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
Ja, das hab ich echt verpeilt. Böse aufgestossen ist mir das Sache eigentlich auch nur, weil ein Kunde sein password mit irgendwelchen kryptischen Zeichen aufgepeppt hat und ich es nicht mehr dechiffrieren kann (password reminder Funktion). Wenn ich jetzt die login-Seite mit einem Meta-tag versehe, klingelt hier wahrscheinlich das Telefon Sturm (über 1000 Kunden). Bin aber nur teilschuldig, weil die Seiten eigentlich von wem anders geschrieben wurden,
Wie sehen denn die falschen Zeichen dann aus? Werden es Fragezeichen, oder Ornamente, oder ganz was anderes?
Oh, durchaus unterschiedlich, jenachdem von wo ich gucke, z.B. in der Art §gRKl0uß in CocoaMySQL oder ßgRKl0u und ein Kästchen für ein nicht-darstellbares Zeichen in Mac OS9.
Mac OS9 braucht aber in jedem Fall ziemlich sicher eine Sonderbehandlung, die das ganze auf Mac OS Roman umwandelt, das geht mit ISO-Latin eher schlecht. Oder du steigst komplett auf Mac OS Roman um, das musst du dann nur in der Meta-Angabe einstellen.
Dass OS9 (oder eigentlich 8.6) rumzickt, merke ich auch immer beim Mailen mit Eudora. Hab schon zig mal irgendwelche Translator plug-ins eingebaut und trotzdem sieht alles murksig aus, was von unserem Linux Mailserver kommt. Selbst Mails, die man an sich selber schickt. Aber das ist wieder ein anderes Thema. Geht das denn überhaupt, dass man den Windoof Browsern sagt, die Seiten wären in MacRoman codiert?
Das war jetzt ganz schön viel, aber das ist eben auch ein sehr komplexes Thema …
Yep, danke nochmal, dass Du es in Angriff genommen hast.

Gruss, Lupus
 
phpMyAdmin ist eigentlich relativ sicher …

Du kannst sehr einfach über eine htaccess-Datei einfach das Verzeichnis davon schützen.

Ich habe, gerade was Encoding-Problematik betrifft, nicht die besten Erfahrungen mit cocoamysql gemacht. Daher mein Vorschlag. phpMyAdmin ist wesentlich flexibler und hat mehr Funktionen.

Hast du vielleicht mal einen Link, wo man das ganze sehen kann?

Ich fürchte ja fast, dass dadurch, dass von verschiedenen Systemen Leute Daten eingegeben haben, jetzt ein Codierungs-Mischmasch in der Datenbank ist.
Ich könnte mir vorstellen, dass abhängig vom Client-System in der jeweiligen Codierung die Daten gespeichert wurden und dann auf anderen Clients eben falsch dargestellt wird.

Aber alles nur Vermutungen, dafür müsste man es mal sehen!

Viele Grüße,

Simon
 
Vereinfache die Sache zunächst mal. Versuche erstmal

Mysql <-> Apache/PHP <-> Browser

hinzubekommen. Und zwar mit neuen Daten. Ein Charset bestimmt nur die *Interpretation* der bestehenden Daten. Wenn da ein "A" als Zeichen 123 statt 65 gespeichert ist, ändert sich durch ein anderes Charset nichts daran.

Charset in Browser und Mysql müssen übereinstimmen. Der Charset der PHP Datei (hat nichts mit den php.ini Einstellungen zu tun, sondern wie dein Editor die Datei kodiert) ist nur relevant für die drin enthaltenen festen Strings.

Apache/PHP schickt eine Webseite mit einem bestimmten Charset an den Browser. Kannst es am einfachsten mit einem <meta> Tag festlegen.

Welchen Charset nehmen?

ISO-8859-15 (nicht -1, weil -1 kein Eurozeichen enthält)

Bei internationalen Sachen utf-8, da hängt aber ein weiter Rattenschwanz an Dingen dran.

Dann den Mysqlserver auch auf den Charset stellen.

Speichern und Abrufen der Daten über PHP sollte dann funktionieren.

Theoretisch. Alles hängt davon ab, ob und wie gut die Browser die Charsetangabe befolgen.

Opera und Mozilla machen keine Probleme. Nicht wirklich überraschenderweise hält sich aber der Internet Explorer unter Windows nicht daran. Der schickt fröhlich windows-1252 kodieren Text. Bei Umlauten macht das keinen Unterschied, aber er schickt Gedankenstriche, typographische Anführungszeichen etc., die es in ISO-8859-15 garnicht gibt. Mozilla und Opera schicken brav Entities.

Alle weiteren Verwaltungsprogramme sollten mit den neuen Daten dann auch funktionieren.

Und dann kommt der üble Teil: die alten Daten auf ISO-8859-15 migirieren. Das ist übel, weil man den Daten nicht so ansieht, in welcher Kodierung sie an mysql geschickt wurden.

a) MySQL - in my.cnf ??? In den Vorlage-Konfigurationsdateien habe ich nichts gefunden.

Siehe Mysqldokumentation.

iso-8859 müsste das gleiche sein wie iso-latin-1, oder?

Ja.

Wenn ich php.ini in b) richtig verstanden habe, dann müsste er das ja sowieso reinbauen. Tut er aber nicht (Quelltext im Browser).

Weil er es in die HTTP Header packt, wo die Charset Deklaration auch reingehört. Das "http-equiv" heißt nichts anderes als "bitte behandele das hier äquivalent zu einem HTTP-Header.

In Opera kannst du im Info Panel den Charset sehen, im Firefox unter Tools -> Page Info.

d) Apache - soweit ich das bei den endlosen Optionen überblicke, kann man in httpd.conf nur den default MIME type einstellen, oder???

Nein. http://httpd.apache.org/docs/mod/mod_mime.html#addcharset
 
Hallo, da möchte ich mal anknüpfen.

Ich habe hier ein Kontaktformular, was 5-sprachig (europäisch) ist. Jetzt hab ich diese ganzen Société, s'il te plaît, señoras und weiß der Teufel was.

Am Ende hängt ne MySQL-Datenbank. Bis jetzt läuft's über 8859-15, da sind die Zeichen ja alle drin.

Kann ich den Quelltext auch sowas schreiben wie:
Code:
<input value="J'ai un déjà vue">
oder so ähnlich, auf alle Fälle:

Verstehen das die Browser weltweit wenn ich die richtigen meta encodings in die HTML Seite schreibe?
Danke.
 
Eigentlich sollten die Navigatoren das verstehen, ja.
Die besten Erfahrungen habe ich allerdings bisher mit UTF-8 gemacht, durch die Bank weg: Bei der SQL-Datenbank gesetzt und für die HTML-Datei. Damit kommen alle Eingaben, sogar „exotische“ asiatische Zeichen einwandfrei an und werden auch einwandfrei ausgegeben. Außerdem kann ich so direkt in HTML Umlaute schreiben, ohne daß sich ein aktueller Navigator oder der W3C-HTML-Prüfer daran stören würden. :)
 
Ich hatte im Kopf, dass Unicode mit manchen Browsern Probleme bereitet?
 
Zuletzt bearbeitet:
Jakob schrieb:
Ich hatte im Kopf, dass Unicode mit manchen Browsern Probleme bereitet?
Jein, der IE bockt bei einigen Zeichen, aber eigentlich hat bei mir bisher die gesamte europäische Palette geklappt. Habe das neulich mit Safari / KHTML, Camino / Gecko und dem IE 6 getestet.
Es gibt da so eine Seite, die Navigatoren listet. (Das bezieht sich zwar eigentlich auf die IPA-Lautschrift, die ist aber ein Teil von Unicode)
 
Zurück
Oben Unten