Probleme mit Umlauten

[Simon]

Hallo,

ich habe ein kleines Problem mit der Darstellung von Umlauten.

Wenn ich den Charset
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
verwende, habe ich das Problem, dass Umlaute, die aus die aus Datenbank abgerufen werden als Hieroglyphen dargestellt werden. Umlaute, die direkt in der HTML-Datei stehen, werden im Gegensatz dazu richtig angezeigt.

Wenn ich den Charset
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
verwende ist es genau umgekehrt. Umlaute aus Datenbank sind richtig, festgeschriebene Umlaute falsch.

Kann mir jemand bei diesem Problem helfen? Ich weiß echt nicht mehr weiter.
Die Datenbank wurde unter dem Charset latin1_german2_ci betrieben, das ganze läuft unter xampp. Kann das vielleicht an irgendeiner Einstellung im Apache liegen?

Vielen Dank schonmal im voraus

Gruß Simon

[Felix Riesterer]

Lieber Simon,

vergewissere Dich, dass die Zeichenkodierung Deiner HTML-Dokumente (also der Textdateien) dieselbe ist, wie die Kodierung der DB-Inhalte. Sorge dann dafür, dass entweder der Server oder Dein HTML-Dokument die richtige Angabe bezüglich der Zeichenkodierung macht (besser sowohl als auch) - achte aber darauf, dass Angaben im Dokument von HTTP-Headern des Servers "übschrieben" werden können.

Liebe Grüße,

Felix Riesterer.

[dedlfix]

Hi!

Wenn ich den Charset
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
verwende, habe ich das Problem, dass Umlaute, die aus die aus Datenbank abgerufen werden als Hieroglyphen dargestellt werden. Umlaute, die direkt in der HTML-Datei stehen, werden im Gegensatz dazu richtig angezeigt.

Das heißt, dass die Inhalte aus dem DBMS in einer anderen Kodierung geliefert werden, als ISO-8859-1.

Wenn ich den Charset
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
verwende ist es genau umgekehrt. Umlaute aus Datenbank sind richtig, festgeschriebene Umlaute falsch.

Es reicht nicht, einfach auf einen Briefumschlag etwas draufzuschreiben und dann zu erwarten, dass das drinliegt. Wenn du eine andere Kodierungsangabe (in Content-Type-Angabe leider fälschlich als charset benannt) machst, musst du deinen Text auch in diese Kodierung bringen.

Kann mir jemand bei diesem Problem helfen? Ich weiß echt nicht mehr weiter.

Generell auf UTF-8 umzusteigen wäre keine ganz schlechte Idee. Prüf doch mal, ob du das mit deinem Projekt auch machen kannst.

Die Datenbank wurde unter dem Charset latin1_german2_ci betrieben, das ganze läuft unter xampp. Kann das vielleicht an irgendeiner Einstellung im Apache liegen?

Nein, aber dass MySQL nicht nur eine Stelle hat, an der man Codierungen konfigurieren kann, wird oftmals übersehen. Insgesamt sind es 10 verschiedenartige. Letztlich interessieren, wie schon so oft hier gesagt, nur zwei. Die Kodierungskonfiguration deiner Felder (jedes Stringtyp-Feld einzeln. Tabellen- und Datenbank-Kodierungsangabe sind nur Defaultwerte für neu anzulegende Elemente) und die auf der Verbindung zwischen deinem Script und dem DBMS ausgehandelte Kodierung (Stichwörter: mysql(i)_set_charset() oder SET NAMES).

Wenn du diese beiden Stellen berücksichtigst, und trotzdem noch Müll ankommt, schau ob der phpMyAdmin den Tabelleninhalt richtig anzeigt. Tut er das nicht, passt die Kodierung deiner Daten nicht zur Angabe der Feldkodierung.

Lo!

[Wolfgang]

Hallo Simon

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />

Also das ist zunächst einmal der verkehrteste Weg, den du zur Festlegung des charset wählen kannst. So etwas gehört in die .htaccess-Datei hinein. Sieh dir AddDefaulCharset an und AddCharset oder auch AddTpye

Ich habe bei mir auf der Seite einmal die Arbeit beschrieben mit dem Websniffer - Page-Speed-Probleme mit CSS-Dateien von Textpattern und mit diesem dort beschriebenen Tool kannst du prüfen, ob html, php oder auch css-Datei vor der Übertragung als utf-8 oder iso oder was auch immer deklariert ist. Diese Deklaration ist verbindlich und überschreibt alles andere. Sie ist auch die Schnellste, da der Browser jetzt nicht mehr raten muss.

Ich habe beim Websniffer auf andere Zeilen geachtet, du müsstest auf Content-Type achten. Hier muss die Codierung stehen.

Jeder http-Request ist so aufgebaut. Der Browser schickt den http-request-header und der server den http-resonse-header und dann erst auf Anfrage die Datei.

Umlaute, die direkt in der HTML-Datei stehen, werden im Gegensatz dazu richtig angezeigt.
Umlaute aus Datenbank sind richtig, festgeschriebene Umlaute falsch.

Diese Logik ist absolut normal. Wenn du die Zeichenkodierung änderst, dann musst du die fest im html-text stehenden Zeichen auch anpassen.

latin1_german2_ci

Das ist eigentlich kein utf-8. Das ist eine latin-1-Schrift und damit eines von den iso-schriften oder eine windows-Schrift. Allerdings ist es denbar, dass man den Wert einstellte und dann utf-8-Strings in die Datenbank eingetragen hat. Wenn das so ist, müsste man das eigentlich reparieren. Wenn du aber bestimmte Suchen und Sortierfunktionen nicht brauchst, dann kannst du es erst mal lassen.

Die ordentlichste Lösung wäre alles abchecken - wobei auch im php einiges auf utf-8 eingestellt sein kann oder nicht - und die schnellste Lösung ist: Nicht drüber nachdenken, den charset in der .htaccess auf utf-8 setzen, die "festen Zeichen" zu ändern und hoffen, dass es keiner merkt.

Herzliche Grüße
wolfgang

[Auge]

Hallo

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />

Also das ist zunächst einmal der verkehrteste Weg, den du zur Festlegung des charset wählen kannst.

Zwar weist Simon darauf hin, dass Daten aus einer DB in das Dokument eingefügt werden, was darauf hinweist, dass es nicht um ein statisches Dokument geht, deine Feststellung ist aber dennoch irreführend. Das ist nicht der 'verkehrteste Weg' zur Festlegung des charsets, sondern der Fallback für den Fall, dass der Server im HTTP-Header keine Angabe mitliefert oder für den Fall, dass das Dokument (irgendwann mal) nicht von einem Server ausgeliefert wird (lokale Ausgabe aus Datei).

Das Wort 'Fallback' weist aber darauf hin, dass es andere, zu bevorzugende Methoden gibt, z.B. auch die Angabe über .htaccess. Das muss aber nicht überall zur Verfügung stehen. Es gibt viele Hoster, die die mit .htaccess möglichen Angaben stark einschränken. Dann wäre eine Anfrage beim Hoster fällig.

Tschö, Auge

[Wolfgang]

deine Feststellung ist aber dennoch irreführend. Das ist nicht der 'verkehrteste Weg' zur Festlegung des charsets, sondern der Fallback für den Fall, dass der Server im HTTP-Header keine Angabe mitliefert oder für den Fall, dass das Dokument (irgendwann mal) nicht von einem Server ausgeliefert wird (lokale Ausgabe aus Datei).

Ok, welcher dir bekannte Browser öffnet eine Datei ließt diese bis irgendwo eine Meta-Anweisung ausgeliefert wird interpretiert diese und beginnt wieder von vorne mit dem "richtigen Charset"?

Diese Zeile als Fallback zu nutzen bedeutet: Manuelle Ansicht des Quelltextes, lesen der Metazeile, manuelle Einstellung des Browsers.

Es gibt viele Hoster, die die mit .htaccess möglichen Angaben stark einschränken.

Nur wenn man diesen Personenkreis zu den Hostern zählt. Das sind Anbieter von irgendwelchen werbefinanzierten Webseitenteilleistungen. Bei einem bezahlten Auftritt ist ein nichtzugang zur .htaccess undenkbar. Und sorry wir sprechen hier von ab 1,15 im Monat (Das wäre ein Werbelink, wenn du willst linke ich es mal ein!).

[Auge]

Hallo

deine Feststellung ist aber dennoch irreführend. Das ist nicht der 'verkehrteste Weg' zur Festlegung des charsets, sondern der Fallback für den Fall, dass der Server im HTTP-Header keine Angabe mitliefert oder für den Fall, dass das Dokument (irgendwann mal) nicht von einem Server ausgeliefert wird (lokale Ausgabe aus Datei).

Ok, welcher dir bekannte Browser öffnet eine Datei ließt diese bis irgendwo eine Meta-Anweisung ausgeliefert wird interpretiert diese und beginnt wieder von vorne mit dem "richtigen Charset"?

Warum meinst du, soll diese Anweisung als erste Angabe in den <head>?

Diese Zeile als Fallback zu nutzen bedeutet: Manuelle Ansicht des Quelltextes, lesen der Metazeile, manuelle Einstellung des Browsers.

Blödsinn

Es gibt viele Hoster, die die mit .htaccess möglichen Angaben stark einschränken.

Nur wenn man diesen Personenkreis zu den Hostern zählt. Das sind Anbieter von irgendwelchen werbefinanzierten Webseitenteilleistungen. Bei einem bezahlten Auftritt ist ein nichtzugang zur .htaccess undenkbar. Und sorry wir sprechen hier von ab 1,15 im Monat (Das wäre ein Werbelink, wenn du willst linke ich es mal ein!).

Ich schrieb nicht vom Nichtzugang zur .htaccess, sondern von Einschränkungen dieses Zugangs (wie oben auch nachzulesen ist). Hier darfst du dies nicht, dort das. Darunter *könnte* auch die Festlegung des Standardcharsets fallen. Es kann ja wohl nicht falsch sein, Simon auf diesen Umstand hinzuweisen, oder?

Tschö, Auge

[dedlfix]

Hi!

[...]

Hast du an den Zitatzeichen "rumgefummelt"? Bitte tu das nicht, sonst kann man nur noch schwer Zitat und Antwort unterscheiden.

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
Also das ist zunächst einmal der verkehrteste Weg, den du zur Festlegung des charset wählen kannst. So etwas gehört in die .htaccess-Datei hinein.

Wie Auge schon sagte, ist das eine gängige Alternative. Man sollte am besten beides verwenden, die charset-Angabe im HTTP-Header und dieses Meta-Element. Denn wenn diese Seite lokal abgespeichert wird, ist die Server-Angabe weg, die Meta-Angabe aber immer noch da.

Die .htaccess ist eine Möglichkeit, aber kein zwingendes "gehört so". Es ist ebenso perfekt, HTTP-Header über PHP oderwasauchimmer zu setzen.

Ich habe bei mir auf der Seite einmal die Arbeit beschrieben mit dem Websniffer [...] und mit diesem dort beschriebenen Tool kannst du prüfen, ob html, php oder auch css-Datei vor der Übertragung als utf-8 oder iso oder was auch immer deklariert ist. Diese Deklaration ist verbindlich und überschreibt alles andere. Sie ist auch die Schnellste, da der Browser jetzt nicht mehr raten muss.

Wenn der Browser die Meta-Angabe bekommt, muss er ebenfalls nicht mehr raten. Der Geschwindigkeitsunterschied ist zu gering, also vernachlässigbar.
Als sehr feines lokales Tool, um HTTP-Requests und -Responses auszuwerten eignet sich die livehttpheaders-Extension für den Firefox.

latin1_german2_ci
Das ist eigentlich kein utf-8.

Nicht nur eigentlich sondern definitiv. Allerdings war die Aussage im OP relativ nichtssagend, weil zu ungenau.

Das ist eine latin-1-Schrift und damit eines von den iso-schriften oder eine windows-Schrift.

Nein, Schrift kommt erst viel später ins Spiel, wenn die Daten vom Browser ans Betriebssystem zwecks Darstellung auf einem Bildschirm gegeben werden. An dieser Stelle ist es eindeutiger, von Zeichen und ihrer Abbildung auf Bytes zu sprechen, Zeichenkodierung genannt. Latin1 ist üblicherweise gleich ISO-8859-1. Bei MySQL ist Latin1 aber Windows-1252. Das bringt uns aber nicht weiter, weil von dem Unterschied die Umlaute nicht betroffen sind, nur das €-Zeichen (und ein paar andere selten gebrauchte Zeichen).

Allerdings ist es denbar, dass man den Wert einstellte und dann utf-8-Strings in die Datenbank eingetragen hat. Wenn das so ist, müsste man das eigentlich reparieren. Wenn du aber bestimmte Suchen und Sortierfunktionen nicht brauchst, dann kannst du es erst mal lassen.

Die Daten so zu lassen, wenn sie fehlerhaft im DBMS stehen, würde ich nicht empfehlen. Das zieht nach sich, dass man noch weitere Fehler machen muss, um sie wieder ordentlich zu bekommen. Man müsste sie beispielsweise wieder als Latin1 abfragen und dann als UTF-8 interpretieren. Zudem hat man dann immer Probleme, wenn man mit richtig arbeitenden Tools, wie dem phpMyAdmin, zugreifen möchte. Für Suchen und Sortieren ist es, wie du schon sagst, ein K.O.-Kriterium. Es geht aber auch String-Länge verloren. In ein als Latin1 ausgezeichnetes Feld mit 10 Zeichen passen zum Beispiel bei einem UTF-8-kodierten Umlaut nur noch 8 weitere Zeichen.

Die ordentlichste Lösung wäre alles abchecken - wobei auch im php einiges auf utf-8 eingestellt sein kann oder nicht - und die schnellste Lösung ist: Nicht drüber nachdenken, den charset in der .htaccess auf utf-8 setzen, die "festen Zeichen" zu ändern und hoffen, dass es keiner merkt.

Warum schludern? Die korrekte Lösung erfordert nach meiner Einschätzung nur eine ganz kleine Mühe - falls der phpMyAdmin alles richtig anzeigt.

Lo!

[hotti]

hi,

siehe Hier. Speziell die Abschnitte zum thema DB-Anbindung.

Additional:

UTF-8-Tabellen

ISO-Tabellen

Hotti