Umlaute in mysql

[Bene]

Hallo,

folgendes Problem:
ä, ü, ö weden nicht richtig gespeichert. So wird z.B. ein Ü als ü ausgegeben.

Die Kollation war general_swedish, wobei ich gelesen habe, das die Kollation nur für die Sortierung wichtig ist. Ist das richtig?

Eine Lösung wäre als Kollation utf8_general_ci anzugeben und in php alles zu kodieren und beim auslesen wieder dekodieren( mit den Funktionen utf8_decode bzw. utf8_encode ). Gibt es da keine andere Lösung?

Vielen Dank und beste Grüße
Bene

[Sven Rautenberg]

Moin!

ä, ü, ö weden nicht richtig gespeichert. So wird z.B. ein Ü als ü ausgegeben.

Du hast ein Zeichencodierungsproblem.

Das, was du als verunglücktes Ü siehst, ist die UTF-8-Darstellung des Ü, wenn man KEIN UTF-8 anzeigen läßt, sondern z.B. ISO-8859-1.

Kontrolliere genau, welche Zeichencodierung du auf jeder HTML-Seite verwendest. Alles muß identisch sein!

- Sven Rautenberg

[Bene]

Hallo,

danke für die Hilfe.

Auf einer Seite hatte ich als charset=iso-8859-1 angegeben. Es hat nicht funktioniert. Mit utf-8 funktioniert es.
Wobei sich für mich folgende Fragen stellen:

• Hat die Angabe im HTML-header Einfluss darauf wie die Zeichen im Quellcode dargestellt werden?

• Im Quellcode (charset=utf8) steht jetzt ein Ü. Müsste das nicht als Ü im Quellcode stehen, damit alles korrekt ist?

• gibt es einen Weg, damit die Zeichen bei charset=iso-8859-1 korrekt angegeben werden? Sind hier die php funktionen utf8_decode bzw. utf8_encode richtig?

Danke
Bene

[Sven Rautenberg]

Moin!

Auf einer Seite hatte ich als charset=iso-8859-1 angegeben. Es hat nicht funktioniert. Mit utf-8 funktioniert es.

Logisch, diese Angabe muß übereinstimmen mit der tatsächlich gewählten Zeichencodierung im Dokument.

Wobei sich für mich folgende Fragen stellen:

• Hat die Angabe im HTML-header Einfluss darauf wie die Zeichen im Quellcode dargestellt werden?

Es gibt zwei Stellen, an denen die Zeichencodierung stehen kann:
1. Priorität hat der HTTP-Header.
2. Wenn dieser keine Angaben macht, gilt das HTML-Meta-Tag <meta http-equiv="content-type" content="text/html; charset=...">

Server können den HTTP-Header entweder fest eingestellt oder auch basierend auf der im HTML enthaltenen Angabe im HTTP-Header setzen. Deshalb ist es niemals verkehrt, in HTML korrekte Angaben zu machen (die wirken außerdem auch dann noch, wenn kein HTTP benutzt wird, also z.B. bei Seiten auf Festplatte).

• Im Quellcode (charset=utf8) steht jetzt ein Ü. Müsste das nicht als &Uuml; im Quellcode stehen, damit alles korrekt ist?

Nein, das Ü ist korrekt. Du hast ja schließlich keine Entity in den Text geschrieben. Entities sind nicht zwingend notwendig, man kommt prima ohne sie aus.

• gibt es einen Weg, damit die Zeichen bei charset=iso-8859-1 korrekt angegeben werden? Sind hier die php funktionen utf8_decode bzw. utf8_encode richtig?

Die Frage ist doch, warum du ISO-8859-1 willst? Ich empfehle immer dringend, eine durchgehend einheitliche Zeichencodierung zu verwenden. Das gibt am wenigsten interne Probleme.

- Sven Rautenberg

[Tom]

Hello,

• Hat die Angabe im HTML-header Einfluss darauf wie die Zeichen im Quellcode dargestellt werden?

Nein.
Wenn Du die übermittelten Codes immer mit einem Hex-Editor anschaust, hat der Header auf dessen Darstellung keinen Einfluss.

Allerdings reagieren die Browser darauf. Was ich persönlich nicht in Ordnung finde ist, dass der IE6 auch bei der Darstellung des Quellcodes darauf reagiert. Der sollte mindestens die Möglichkeit geben, "Bytecode-Glyphen" und alternativ UTF-8-Glyphen darzustellen.

Tut er mWn aber nicht nicht.

Der IE5.5 zeigt den Quellcode noch in "Bytecode-Glyphen".

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

Tom

[Sven Rautenberg]

Moin!

Allerdings reagieren die Browser darauf. Was ich persönlich nicht in Ordnung finde ist, dass der IE6 auch bei der Darstellung des Quellcodes darauf reagiert. Der sollte mindestens die Möglichkeit geben, "Bytecode-Glyphen" und alternativ UTF-8-Glyphen darzustellen.

Tut er mWn aber nicht nicht.

Der IE5.5 zeigt den Quellcode noch in "Bytecode-Glyphen".

Sicher, dass du da nicht die Unfähigkeiten oder Fähigkeiten des Windows Notepads beobachtest?

Win2000-Notepad kann UTF-8, die Windowsse, zu denen IE 5.5 paßt, konnten es noch nicht (Win9x).

Abgesehen davon argumentierst du, ein Editor solle einen Zeichenstrom absichtlich nicht als das interpretieren, was er ist (nämlich UTF-8-codiert), sondern was du dir drunter vorstellst (nämlich ISO-8859-1 oder ähnliches). Was bringt das?

- Sven Rautenberg

[Bene]

Hallo,

danke, jetzt bin ich schon ein gutes Stück weiter.

Ich habe gelesen, dass man mit der Angabe des ISO-8859-1 Zeichensatzes keine Umlaut-Kodierung braucht, und bin deswegen davon ausgegangen, dass bei utf-8 die Kodierung nötig ist, was offensichtlich falsch ist.

Ich habe mich jetzt entschlossen, alles in utf-8 zu kodieren.

1 Punkt ist für mich jetzt noch offen:

• meine Seite liegt bei einem Massenprovider. Würde es Sinn machen, zur Sicherheit mit dem php header Befehl den Content-Type auf utf-8 zu setzen?

grüße
Bene

[Sven Rautenberg]

Moin!

Ich habe gelesen, dass man mit der Angabe des ISO-8859-1 Zeichensatzes keine Umlaut-Kodierung braucht, und bin deswegen davon ausgegangen, dass bei utf-8 die Kodierung nötig ist, was offensichtlich falsch ist.

Stimmt. Wenn du die richtige Codierung angibst, brauchst du keinerlei Sonderzeichen in Entities zu schreiben.

UTF-8 empfiehlt sich, weil man damit wirklich alle Schriftzeichen direkt benutzen kann - was sich in deutschen Texten meist darauf reduziert, dass man das Eurozeichen sowie typographische Anführungszeichen und sonstige Interpunktionszeichen benutzen kann, ohne sie codieren zu müssen, jedenfalls im Vergleich zu ISO-8859-1.

1 Punkt ist für mich jetzt noch offen:

• meine Seite liegt bei einem Massenprovider. Würde es Sinn machen, zur Sicherheit mit dem php header Befehl den Content-Type auf utf-8 zu setzen?

Es ist mit Sicherheit nicht falsch, sich nicht auf eine Standardeinstellung (die sich ja auch mal ändern kann) zu verlassen, sondern alle Parameter selbst zu definieren. Umso weniger Probleme gibt es, wenn du den Hoster mal wechselst und irgendwas ist beim neuen Hoster anders, als beim alten.

- Sven Rautenberg

[Bene]

Hallo,

eine weitere Frage:
in phpmyadmin wird mir jetzt der Eintrag der Datenbank als Buchstabensalat angezeigt, wenn es sich um Umlaute handelt.

Sowohl im html meta tag als auch im http-header ist utf-8 als Content-Type angegeben, deswegen verstehe ich diese Anzeige nicht?

könnt ihr mir sagen ob da was falsch läuft, oder ob das üblich ist.
Ansonsten klappt alles einwandfrei.

Danke
Bene

[Sven Rautenberg]

Moin!

könnt ihr mir sagen ob da was falsch läuft, oder ob das üblich ist.
Ansonsten klappt alles einwandfrei.

Da ist irgendwas falsch, üblich wäre, dass PHPMyAdmin die Umlaute korrekt darstellt. Das hängt allerdings auch etwas von der Version ab. Aktuell für PHPMyAdmin wäre so grob 2.7.0.

- Sven Rautenberg

[Bene]

Hallo,

habs mit phpmyadmins auf verschiedenen Server bzw. lokal (alle unter Version 2.7) versucht, dabei immer die falsche Darstellung gehabt, so dass ich von einem phpmyadmin Fehler ausgehe.

Danke nochmal für die wertvolle hilfe.
Bene

Moin!

könnt ihr mir sagen ob da was falsch läuft, oder ob das üblich ist.
Ansonsten klappt alles einwandfrei.

Da ist irgendwas falsch, üblich wäre, dass PHPMyAdmin die Umlaute korrekt darstellt. Das hängt allerdings auch etwas von der Version ab. Aktuell für PHPMyAdmin wäre so grob 2.7.0.

• Sven Rautenberg

[Tom]

Hello,

Kontrolliere genau, welche Zeichencodierung du auf jeder HTML-Seite verwendest.

Alles muß identisch sein!

Hier widerspreche ich erstmal.

Identisch muss es nur an der entsprechenden Stelle im Pfad sein.
UTF-8 aus der Webseite lässt sich in der DB trotzdem als ASCII abspeichern.
Man muss dann nur dran denken, dass man den SELECT dann wieder als UTF-8 ausgibt,
nicht jedoch in UTF-8 umwandelt, denn es _ist_ dann ja schon UTF-8

Ob das für die DB damit auch sinnvoll ist (Sortierung, Indizierung, Funktionen) habe ich damit ausdrücklich _nicht_ ausgesagt :-)

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

Tom

[Sven Rautenberg]

Moin!

Kontrolliere genau, welche Zeichencodierung du auf jeder HTML-Seite verwendest.

Alles muß identisch sein!

Hier widerspreche ich erstmal.

Identisch muss es nur an der entsprechenden Stelle im Pfad sein.
UTF-8 aus der Webseite lässt sich in der DB trotzdem als ASCII abspeichern.

Nicht ohne Zeichenverlust!

ASCII ist definiert von 0x00 bis 0x7F, alles darüber hinaus ist damit nicht codierbar, auch keine Umlaute. Derartige Zeichen müssen bei solch einer Konvertierung zwangsläufig verloren gehen.

Was schlägst du da vor?

Man muss dann nur dran denken, dass man den SELECT dann wieder als UTF-8 ausgibt,
nicht jedoch in UTF-8 umwandelt, denn es _ist_ dann ja schon UTF-8

Ich halte die Herangehensweise für irreführend, ASCII mit UTF-8 gleichzusetzen. Das mischt etwas, was man nur in diesem ganz speziellen Sonderfall (wirkliche echte ASCII-Zeichen kleiner 0x7F - wann hat man sowas im deutschen Sprachraum?) mischen kann, im Allgemeinen aber nicht (schon ISO-8859-1 scheitert).

- Sven Rautenberg