nicht angemeldet
echo $begrüßung;
Es reicht nicht, einfach nur irgendeine Kodierung zu verwenden. Wichtig ist, dass man dem Empfänger mitteilt, welche Kodierung verwendet wurde.
Genau das meinte ich ja damit, als ich sagte, die Seite muß utf-8 codiert sein.
Deine Aussage war mir nicht eindeutig genug. Es muss immer beides berücksichtigt werden, die Kodierung selbst und die Angabe zur Kodierung.
<meta http-equiv="content-type" content="text/html; charset=utf-8" />ist also nur _zweite_ Wahl?
Wenn der Webserver vorkonfiguriert ist und eine charset-Angabe sendet, die nicht deiner tatsächlichen Kodierung entspricht, dann nützt dir die Meta-Element-Angabe nichts, weil beim Vorhandensein der charset-Angabe im HTTP-Header diese zu verwenden ist, sagt der Standard.
Kannst Du das mit dem Content-Type-Header bitte näher erklären?
Die HTTP-Header-Zeile Content-Type gibt dem Client an, was er da gerade für Daten empfängt. Das ist eine Pflichtangabe. Für Bild-Daten beispielsweise ist es image/irgendwas, für HTML ist es text/html. Und diese Angabe kann genauso wie bei der Meta-Element-Angabe um den charset-Zusatz ergänzt werden.
Ist das was, was ich mit der .htaccess beeinflussen kann?
Ja, das kann man in der Webserver-Konfiguration einstellen, dass er diese Angabe selbständig anhängt. Für den Apache zuständig sind die Direktiven AddDefaultCharset und AddCharset.
<?php
header("Content-type:text/html;charset=utf-8");
?>
Auch das ist eine Möglichkeit. Damit macht man es von PHP aus, und überschreibt eine im Server voreingesstellte Content-Type(inklusive charset)-Konfiguration.
> Und um mich ganz zu verwirren, habe ich auch wo gelesen, daß man über die php.ini was machen kann: default\_charset = "utf-8"
Auch damit kann man die charset-Angabe hinzufügen.
> [...] hab über phpinfo() entdeckt, daß bei 'default\_charset' sowohl bei Local Value, als auch bei Master Value ein 'no value' steht.
Dann ändert PHP selbst an der Einstellung nichts.
> Ich dachte immer, das `<meta http-equiv="content-type" content="text/html; charset=utf-8" />`{:.language-html} reicht und ist auch das Einzige. OK, dann mache ich ab jetzt Beides. Nur wie?
Welches davon die beste Methode ist, kommt ganz drauf an, welche Möglichkeiten einem seitens der Administrators eingeräumt wurden. Ich bevorzuge AddDefaultCharset in der DocumentRoot-Konfiguration und eine konsequente Verwendung der angegebenen Kodierung. Damit kann man jedem Projekt an zentraler Stelle eine individuelle Kodierung vergeben.
Schreibt man Scripte, die auf unbekannten Konfigurationen laufen sollen, und man auch nicht annehmen kann, dass man den Webserver konfigurieren kann, so ist wohl der header()-Aufruf der beste Kompromiss.
> > Wenn du damit die MySQL-Tabelle (mit MySQL ab Version 4.1) meinst, dann ist das im Prinzip unwichtig. Das ist, genauso wie die Angabe zur Kollation für die Datenbank, nur ein Default-Wert, der für neu hinzugefügte, untergeordnete Elemente herangezogen wird, wenn für diese nicht explizit etwas eingestellt wurde.
>
> Ich meinte das, was unter phpMyAdmin für jeden Teil einer Tabelle unter "Kollation" eingestellt wird.
Ich interpretiere mal "jeden Teil einer Tabelle" als die Felder.
Feld x vom Typ y mit der Kollation z.
Wobei "Kollation" hier für das Gemisch aus Kodierung/Charset-Angabe und der Kollation steht.
> > Außerdem sollte bei der Kommunikation mit einem MySQL-Server eine Kodierung explizit ausgehandelt werden (mysql\_set\_charset() oder zur Not SET NAMES).
> Auch diesbezüglich habe ich jetzt lange gegoogelt. Hab ich das richtig verstanden, daß ich das in jene Datei dazuschreibe, in der die Verbindung zum Server hergestellt wird?
Das sollte nach jedem Verbindungsaufbau erfolgen, wenn einem die Daten lieb sind. Diese Einstellung gilt ja nur für die aktuelle Verbindung.
> Diese Datei ist bei mir ausgelagert an eine Stelle vor dem Wurzelursprung meines Webspaces [...]
Umso besser. Dann hast du nur eine einzige Stelle zu pflegen.
> if(!$verbindung\_server)
> die("Verbindung zum Server nicht möglich: ".mysql\_error());
Hat man dir schon mal gesagt, dass das Sterbenlassen mit Ausgabe der detailierten Fehlerursache bei so etwas banalem wie einer nicht zustandegekommenen Datenbankverbindung nicht gerade benutzer- dagegen aber sehr angreiferfreundlich ist? Besser ist es, das Script bis zum geplanten Ende auszuführen. Damit entsteht auch eine vollständige HTML-Seite, die ins Corporate Design passt und nicht nach der Hälfte abgeschnitten ist. Anstelle des Datenbankabfrageergebnisses kann man dem Anwender eine Tröstmeldung zeigen. Ändern kann der an dem Zusatand nichts, deswegen ist für ihn eine genaue Angabe des Fehlers nicht sinnvoll. Die Details sollten nur dem Administrator zur Verfügung gestellt werden, sei es in einem regelmäßig zu sichtendem Logfile oder auch per Mailversand.
> Übertrage ich jetzt zB das Wort 'Hügel' [UTF-8-kodiert] in die DB und sehe mir dann den Datensatz via phpMyAdmin an, dann sehe ich dort ein 'Hügel' stehen. Lese ich den Datensatz aus, wird aber wieder 'Hügel' ausgegeben. Umgekehrt, wenn ich direkt über phpMyAdmin das Wort 'Hügel' eingebe, steht es genau so in der DB, wird aber wiederum nicht korrekt ausgegeben, wenn es per php ausgelesen wird.
> Ich nehme jetzt mal an, das liegt daran, daß ich bisher das mysql\_set\_charset("utf8"); nicht hatte, oder?
Genau das ist der Grund. MySQL wird als Default-Verbindungs-Kodierung Latin1 eingestellt haben. Es erkennt die beiden Bytes der UTF-8-Sequent vom ü als zwei Latin1-Zeichen an. Kodiert diese so um, dass sie zur angegebenen Feld-Kodierung passen. Der PMA sieht die beiden Zeichen genauso einzeln, wie sie MySQL interpretiert hat. Bei der Ausgabe über eine Latin1-Verbindung bekommst du ebenfalls wieder zwei Zeichen zurück. Da du sie aber als UTF-8-Sequenz interpretierst, ist die Welt für dich in Ordnung. Du bekämst nur dann Probleme, wenn die Feldlänge auf 5 eingestellt wäre. Dann hat das l keinen Platz mehr, weil das ü zwei Zeichen belegt, und "Hüge" wäre das was zurückkommt.
echo "$verabschiedung $name";
Gunnar Bittersmann