Mysql - Umlaute speichern und auslesen

[Kermit]

Hallo,

ich habe folgendes Problemm:
auf mein localen Server speichere ich die Eingaben aus einem Formular mit PHP in eine mysql DB. Wenn ich jetzt Eingaben in phpMyAdmin mir einschaue, wurden die Umlauten mit andere Sonderzeichen ersetzt.
Beim auslesen aus der DB werden im Browser die Sonderzeichen auch angezeigt.

Wenn ich aber die Texte über phpMyAdmin in die DB speichere, werden die Umlauten richtig gespeichert und anschliessend beim auslesen in meine Webseite richtig dargestellt.

1. Was macht phpMyAdmin beim wegschreiben der Daten anders als ich?
2. Der gleichen Script auf einen externen Webserver funktioniert einwandfrei, d.h. die Umlauten werden richtig gespeichert und ausgelesen.

Ich suche seit Tage vergeblich nach eine Lösung, habe den mysqld auch mit --default-character-set=latin1_de und --default-character-set=german1 gestartet ... ohne Erfolg.

Wie kriege ich es hin das auch bei mir local funktioniert?

• entweder ändere ich mein Script so wie beim phpMyAdmin
• oder die Server/Mysql Konfiguration so wie auf dem anderen Server

[dedlfix]

echo $begrüßung;

Wie kriege ich es hin das auch bei mir local funktioniert?

• Finde heraus, unter welchen Versionen deine verwendeten MySQL-Server[*] laufen.
• Beschäftige dich mit dem Kapitel Character Set Support. (Ja, das ist sehr umfangreich. Es handelt sich aber auch nicht grade um ein einfaches Thema.)
• Auch dieser Artikel (Unicode and Other Funny Characters) dürfte für dich interessant sein.
• Finde heraus, welche Zeichenkodierungen der/die Datenbank-Server, die Datenbanken, die Tabellen und die einzelnen Felder verwenden, welche Kodierung zwischen Client und Server angewendet wird und welche Kodierung die Webseiten verwenden, die die Daten ausgeben sollen. Gegebenenfalls musst du Konvertierungen zwischen den Zeichenkodierungen vornehmen oder alle vorgenannten Kodierungen vereinheitlichen. Beachte dabei, dass Zeichensatz-Konvertierungen nicht in jeder Richtung verlustfrei möglich sind.

echo "$verabschiedung $name";

[*] Die Versionsanabe der Client-API ist nicht die Server-Version, auch wenn die Zahlenwerte gleich sein können.

[Kermit]

Hallo,

erstmals vielen Dank für deine Antwort.

hatt mich zumindest nachdenklich gemacht und mich dazu bewegt nicht nur  mysql und php in Betracht zu ziehen sondern auch den Browser und den Apache Server.

Und siehe da habe den Fehler nach 3 Tage herumstochern gefunden:

Lade meine Seite im Browser und schaue oben im Ansicht/Zeichensatz.
Hier stand utf8 ... d.h. der Browser verstand nicht das es sich um eine Deutsche Seite sich handelt. Habe kurz geändert auf iso-8859-15 und mein Formular abgeschickt. Jetzt wurde auch richtig in die DB gespeichert.

Um das dauerhaft zu ändern muste ich an die apache Konfiguration rann.
Für apache2 ist das in die Datei /etc/apache2/mod_mime-defaults.conf

hier muss der richtiger Zeichensatz geladen werden:
AddCharset ISO-8859-15 .iso-8859-15 ...

und default Zeichensatz geändert werden:
AddDefaultCharset ISO-8859-15

bei gelegenheit auch die LanguagePriority ändern:
LanguagePriority  de ....

schreibe das hier rein für die nächsten die danach suchen ... mich hat genug Zeit gekostet.

bis zum nächsten Bug
Kermit

[Sven Rautenberg]

Moin!

Lade meine Seite im Browser und schaue oben im Ansicht/Zeichensatz.
Hier stand utf8 ... d.h. der Browser verstand nicht das es sich um eine Deutsche Seite sich handelt. Habe kurz geändert auf iso-8859-15 und mein Formular abgeschickt. Jetzt wurde auch richtig in die DB gespeichert.

"Richtig" und "falsch" sind Definitionen, die stark vom eigenen Standpunkt abhängen.

Ich persönlich würde jegliche neu zu erstellende Datenbank und Website nach Möglichkeit immer in UTF-8 realisieren. Nur damit hat man die Möglichkeit, wirklich sämtliche eingebbaren Zeichen ohne den Umweg über Entities oder numerische Zeichenreferenzen direkt ein- und ausgeben zu können.

Dein verwendetes ISO-8859-15 enthält ja schließlich nur 255 mögliche Zeichen. Darin sind zwar die gebräuchlichsten Zeichen des westeuropäischen Sprachraums enthalten, aber beispielsweise kaum Zeichen für eine schönere typografische Darstellung.

Je nach Anforderungslage kann das egal oder dramatisch sein. Und da UTF-8 eigentlich recht einfach zu behandeln ist, sollte das im Prinzip kein Grund sein, auf die Möglichkeiten zu verzichten.

- Sven Rautenberg