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!