1. Betaversion vom Release 1.2

[xray]

Hallo magnum,

denke Du hast das schon ganz gut analysiert. Meine Gedanken gehen auch in diese Richtung.
Denke ich kann das Problem am Wochenende konkret angehen, da hab ich wieder bissl Zeit

Mir schwebt auch vor die Tabellen gleich zu UTF8 zu migrieren(zumindest bei Neuinstallationen). So würde alles halt gleich aus "1 Hand" kommen...Zeichensatzprobleme sollten so erst gar nicht auftreten.

Danke auf jeden Fall für die Hilfe und Tipps!

Gruss
Volker

[magnum]

Hallo Volker,

das mit den Tabellen umstellen, ist m.E. gar nicht so dringend. Wenn die Verbindung per set names auf utf8 gestellt ist, regelt m.W. mysql die Umwandlung selbst ...
Und Updates macht es nicht wirklich einfacher.

Übrigens habe ich noch die Erfahrung gemacht, dass eine evt. falsche Standardeinstellung bei php auch noch dazwischenfunken könnte. Die setzt man per

Code:

ini_set("default_charset", "") ;

auf einen leeren Wert, ansonsten sendet php einen header mit der falschen, nämlich möglicherweise ansi Kodierung.

viele Grüße

Magnus

[xray]

Ich hab mich da nochmal ein bischen schlau gemacht. Scheint das die Kollation auf die Übermittlung der Daten keinen Einfluss hat. Insofern ist "SET NAMES utf8" zusammen mit dem richtigen Header der korrekte Weg. Die Kollation ist wohl nur für die interne Sortierung bzw. das Vergleichen der Daten zuständig.

Was ini_set() bzw. den default_charset betrifft: es sieht so aus, als könnte das nicht jeder (Webspace-)User über PHP einstellen. Eine .htaccess Lösung wäre da wohl sinnvoller.

Ich bleib an dem Problem drann, bis zum finalen Release ist das gelöst

[magnum]

Ich bin da auch noch auf was kleines Feines gestoßen:
für http, also den Browser muss utf-8 mit Bindestrich geschrieben werden.
für mysql, also in set names() muss das utf8, also ohne Bindestrich sein. Im expCounter 1.2 ist das derzeit auch so drin.

Ist zwar richtig fies, aber scheinbar wichtig. Beim Browser ist das nicht sooo entscheidend, der bekommt normalerweise ja vom Webserver den header, mysql stellt mit Bindestrich die Verbindung einfach nicht um. Da suchst du dir dann nen Wolf ...

Das mit dem ini_set() betrifft nach meiner Erfahrung auch nur wenige Server, die bei php den default charset auf ansi gestellt haben. Default ist das bei php eigentlich auskommentiert.

Viele Grüße

magnum

[xray]

Also das Problem mit den Zeichensätzen ist etwas komplizierter als gedacht.
Wobei, mit viel Arbeit, auch wieder leicht zu lösen ::roll:

Es sieht so aus, dass der Counter eingehende Daten intern, von dem im Adminbereich
eingestellten Zeichensatz der Website, zu UFT-8 umcodiert und so an den MySQL Server
übermittelt. Das geschieht ohne der Verbindung zwischen PHP und MySQL Server zu
sagen das UTF-8 gesendet wird. Wie die Daten letztlich in der Datenbank gespeichert
werden, wird dem Zufall bzw. der Voreinstellung des MySQL Servers überlassen.

So weit, so gut. Nun habe ich aber in der Version 1.2beta der Verbindung zwischen PHP
und MySQL Server über den SQL-Befehl SET NAMES utf8 "gesagt" das die Daten als
UTF-8 gesendet werden und der MySQL Server diese auch so speichern mag.

Das funktioniert bei Neuinstallationen recht gut. Bei Updates gibt es da Probleme, weil
so unter Umständen Daten mit unterschiedlicher Kodierung vorliegen können. Alle Anzeige-
fehler resultieren daraus.

Hinzu kommt, dass ich keine Rücksicht auf die Codierung(UTF8 ohne BOM) der Language
und aller restlichen Dateien genommen habe. Das verschärft die Probleme.

[xray]

Es gibt eine weitere Betaversion Ist ein Update Paket für Beta 1, braucht man also nur in das Counterverzeichnis zu kopieren. Es sollten danach keine neuen Umlauteprobleme mehr entstehen. Vorhandene fehlerhafte Umlaute können wie hier nachzulesen behoben werden.

Es ist auch ratsam den XSS-Schutz komplett im Administrationsbereich auszuschalten(inklusive dem Logging).

Download: update_expcounter-1.2beta1_to_beta2.zip

Diff: expCounter-1.2_beta2-diff.html

Feedback welcome.