dedlfix: mysqli_set_charset utf8 warum?

Beitrag lesen

Tach!

ausführliche Erklärung. Reif 1:1 für einen Artikel im Wiki. :-)

Fertig.

Außerdem gibts da noch das SET NAMES-Statement, das ebenfalls die Verbindungskodierungswerte setzt, abzüglich dem für mysqli_real_escape_string() und andere API-Funktionen. Deswegen ist mysqli_set_charset() vor SET NAMES zu bevorzugen.

Was passiert, wenn man beide Möglichkeiten benutzt und nicht die gleichen Werte einsetzt?

Für den Teil der Kommunikation zwischen DBMS und Client wirkt das zuletzt ausgeführte. Für in der Client-API selbst ausgeführte Funktionen (Escaping) zieht das, was mysqli_set_charset() gesetzt hat.

An welcher Stelle kneift es dann? Wie macht sich das "optisch" im Browser bemerkbar?

Beim Escapen kneift es nur, wenn man eine Kodierung hat, die nicht ASCII-basiert ist und dann auch noch die Kodierungen der Sonderzeichen nicht eindeutig zu anderen Teilen der kodierten Zeichen abgrenzbar ist. Bei ISO-8859-x und UTF-8 liegen alle Sonderzeichen im ASCII-Bereich und es gibt keine Kollisionen mit anderweitigen Sequenzen. Da ist also auch praktisch kein Unterschied zwischen SET NAMES und mysqli_set_charset().

Wie die Optik aussieht, hängt immer davon ab, welche Kodierungen und Kodierungsangaben und Konvertierungen in welcher Reihenfolge vermasselt werden. Da gibt es so einige Konstellationen. Allein schon die mehr als 10 Konfigurationswerte MySQLs sorgen für eine sehr hohe Anzahl an Kombinationen. Man kann sowas untersuchen, wenn man mag, aber die Lösung läuft immer darauf hinaus, die korrekten Angaben und Kodierungen bei allen Beteiligten zu verwenden. Und zu wissen, wo man das überall setzt. Dafür hat der Zeichenkodierungsbereich im Wiki auch noch Unterseiten für Webserver und -dokumente.

dedlfix.