missing conversion of special chars

[volkszaehler]

missing conversion of special chars

[andig]

Mhm. Meine Datenbank hat charset latin1, MySQLWorkbench zeigt die Umlaute in Titel und Description korrekt an, die JSON Abfrage liefert korrekt (\u) encodierte Unicode entities.
Kannst Du mal prüfen of evtl. phpMyAdmin das Problem ist?

[rgr-rgr]

[mail header junk removed by admin]
Hi,

Am 19.03.2014 13:03, schrieb andig:

Mhm. Meine Datenbank hat charset latin1, MySQLWorkbench zeigt die Umlaute in Titel und Description korrekt an, die JSON Abfrage liefert korrekt (\u) encodierte Unicode entities.
Kannst Du mal prüfen of evtl. phpMyAdmin das Problem ist?

Hab es mal mit mysql einfach getestet:

mysql> select value from volkszaehler.properties;
+----------------------------------------------------------------+
| value |
+----------------------------------------------------------------+
| S0-Demo-Zufallszahlen |
| Dieser Kanal wird durch vzlogger mit Zufallszahlen gefüllt. |
| 2000 |
| 1 |
| black |
| 1 |
| steps |
| Raspi-Core |
| Temperatur des Raspberry von vzlogger ermittelt. |
| 1 |
| red |
| 1 |
| lines |
| Test für Systemload |
| 1 |
| aqua |
| lines |
| Tests2 |
| aqua |
| lines |
| Tests3 |
| aqua |
| lines |
+----------------------------------------------------------------+
23 rows in set (0.00 sec)

pi@raspberrypi ~ $ env
TERM=linux
SHELL=/bin/bash
XDG_SESSION_COOKIE=360e94e12a727822e61151f95116a6ea-1395221181.391230-1564242658
SSH_CLIENT=10.3.0.1 60754 22
SSH_TTY=/dev/pts/1
USER=pi
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:.tar=01;31:.tgz=01;31:.arj=01;31:.taz=01;31:.lzh=01;31:.lzma=01;31:.tlz=01;31:.txz=01;31:.zip=01;31:.z=01;31:.Z=01;31:.dz=01;31:.gz=01;31:.lz=01;31:.xz=01;31:.bz2=01;31:.bz=01;31:.tbz=01;31:.tbz2=01;31:.tz=01;31:.deb=01;31:.rpm=01;31:.jar=01;31:.war=01;31:.ear=01;31:.sar=01;31:.rar=01;31:.ace=01;31:.zoo=01;31:.cpio=01;31:.7z=01;31:.rz=01;31:.jpg=01;35:.jpeg=01;35:.gif=01;35:.bmp=01;35:.pbm=01;35:.pgm=01;35:.ppm=01;35:.tga=01;35:.xbm=01;35:.xpm=01;35:.tif=01;35:.tiff=01;35:.png=01;35:.svg=01;35:.svgz=01;35:.mng=01;35:.pcx=01;35:.mov=01;35:.mpg=01;35:.mpeg=01;35:.m2v=01;35:.mkv=01;35:.webm=01;35:.ogm=01;35:.mp4=01;35:.m4v=01;35:.mp4v=01;35:.vob=01;35:.qt=01;35:.nuv=01;35:.wmv=01;35:.asf=01;35:.rm=01;35:.rmvb=01;35:.flc=01;35:.avi=01;35:.fli=01;35:.flv=01;3
5:.gl=01;35:.dl=01;35:.xcf=01;35:.xwd=01;35:.yuv=01;35:.cgm=01;35:.emf=01;35:.axv=01;35:.anx=01;35:.ogv=01;35:.ogx=01;35:.aac=00;36:.au=00;36:.flac=00;36:.mid=00;36:.midi=00;36:.mka=00;36:.mp3=00;36:.mpc=00;36:.ogg=00;36:.ra=00;36:.wav=00;36:.axa=00;36:.oga=00;36:.spx=00;36:.xspf=00;36:
MAIL=/var/mail/pi
PATH=/home/pi/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
PWD=/home/pi
LANG=en_GB.UTF-8
SHLVL=1
HOME=/home/pi
LOGNAME=pi
SSH_CONNECTION=10.3.0.1 60754 10.3.0.50 22
_=/usr/bin/env

Sieht also schon so aus, als würde es falsch drin stehen.

Gruss
Rainer

[andig]

Sieht also schon so aus, als würde es falsch drin stehen.

Keine Ahnung was die Shell da macht. Unter Windows das gleiche Problem in der shell obwohl die Daten richtig drin stehen- das sagt also nichts aus.

Hast Du ein richtiges Datenbankwerkzeug das nicht shell/webbasiert ist? Damit wäre zu testen. Welches db/tabellenencodign hast Du?

[r00t-]

das hat mit der shell nichts zu tun!

es sind hier mehrere encoding-einstellungen im spiel:

• das encoding der datenbanktabelle - dieses ist grossteils IRRELEVANT, da der mysql-server das encoding on-the-fly nach den anforderungen des clients konvertiert

• die encoding-einstellung des mysql-clients (zB /usr/bin/mysql, aber auch die php-api)

  der 'mysql'-client stellt das wohl automatisch abhaengig von der locale ein,
  aber die einzige zuverlaessige methode das zu pruefen ist:
  show variables like 'character_set_client';

• fuer den fall der anzeige in einem terminal, das encoding welches das terminal fuer die ein/ausgabe verwendet

wenn in der 'mysql'-shell die sonderzeichen falsch angezeigt werden,
dann KANN das daran liegen, dass das encoding das im client eingestellt ist nicht mit dem des terminal uebereinstimmt.
die sinnvollste moeglichkeit soetwas auszuschliessen ist, die konvertierung zu unterdruecken,
und die ausgabe als hexdump ausgeben zu lassen (schliesst beide fehlerquellen aus):
$ mysql volkszaehler -u root --password= -Bse 'select cast(value as binary) from properties where value like "%test%";' | xxd
0000000: 7465 7374 207a 6165 686c 6572 0a74 6573 test zaehler.tes
0000010: 740a
(genau so stehen die daten in der tabelle, sollte dann zu deren encoding passen)

wenn rgr-rgr aber recht hat, dann gibt es da ggfs, noch ein problem in der middleware beim anlegen des kanals.
das kann auch wieder ein konfigurationsproblem sein.

• encoding der daten im browser (beim eintragen im formular)
• encoding der daten im request an die api
• ggfs ist dann eine konvertierung beim eintragen in die DB (in das encoding der db-verbindung) falsch

so wie die daten aussehen, werden die faelschlicherweise einmal zufiel von iso nach utf-8 konvertiert.

[andig]

Genau deshalb war ja meine Frage was wirklich in der DB steht...

Viele Grüße,
Andreas

Am 21.03.2014 um 17:47 schrieb r00t- [email protected]:

das hat mit der shell nichts zu tun!

es sind hier mehrere encoding-einstellungen im spiel:

das encoding der datenbanktabelle - dieses ist grossteils IRRELEVANT, da der mysql-servr das encoding on-the-fly nach den anforderungen des clients konvertiert
die encoding-einstellung des mysql-clients (zB /usr/bin/mysql, aber auch die php-api) der 'mysql'-client stellt das wohl automatisch abhaengig von der locale ein, aber die einige zuverlaessige methode das zu pruefen ist: show variables like 'character_set_client';
fuer den fall der anzeige in einem terminal, das encoding das das terminal fuer die ein/ausgabe verwendet wenn in der 'mysql'-shell die sonderzeoichen falsch angezeigt werden, dann KANN das daran liegen, dass das encoding das im client eingestellt ist nicht mit dem des terminal uebereinstimmt. die sinnvollste moeglichkeit soetwas auszuschliessen ist, die konvertierung zu unterdruecken, und die ausgabe als hexdump ausgeben zu lassen (schliesst beide fehlerquellen aus): $ mysql volkszaehler -u root --password= -Bse 'select cast(value as binary) from properties where value like "%test%";' | xxd 0000000: 7465 7374 207a 6165 686c 6572 0a74 6573 test zaehler.tes 0000010: 740a
wenn rgr-rgr aber recht hat, dann gibt es da ggfs, noch ein problem in der middleware beim anlegen des kanals.
das kann auch wieder ein konfigurationsproblem sein.

encoding der daten im browser (beim eintragen im formular)
encoding der daten im request an die api
ggfs fehlt dann eine konvertierung beim eintragen in die DB

Thorben

—
Reply to this email directly or view it on GitHub.

[rgr-rgr]

pi@raspberrypi ~ $ mysql volkszaehler -u root --password=raspberry -Bse 'select cast(value as binary) from properties where value like "%wird%";' | xxd
0000000: 4469 6573 6572 204b 616e 616c 2077 6972 Dieser Kanal wir
0000010: 6420 6475 7263 6820 767a 6c6f 6767 6572 d durch vzlogger
0000020: 206d 6974 205a 7566 616c 6c73 7a61 686c mit Zufallszahl
0000030: 656e 2067 6566 c3bc 6c6c 742e 0a en gef..llt..

[r00t-]

es stehen also utf-8 daten in der tabelle die latin1 encoding hat
(rgr-rgr: du hattest das encoding deiner tabelle noch nicht erwaehnt, duerfte aber auch bei dir latin1 sein?)
entsprechend einmal zuoft iso->utf8 konvetrtiert, ist zu klaeren wo.

[rgr-rgr]

Tabelle: latin1_swedish_ci
Zeichensatz / Kollation der MySQL-Verbindung: utf8_general_ci
MySQL-Zeichensatz: UTF-8 Unicode (utf8)

Datenbank finde ich auf die Schnelle nicht.
Ich denke auch, dass da irgendwo eine Konvertierung nicht gemacht wird.

Eigentlich kenne ich das, dass man bei der Verbindung mit angeben kann, in welchem Zeichensatz sie läuft. Wir haben aber nichts in der volkszaehler.conf.php, oder?
Das einzige in der Richtung: $config['locale'] = array('de_DE', 'en_US', 'C');

Im Header vom Request steht kein Charset drin.
php hat in der ini den Charset nicht explizit gesetzt.

Jemand einen Vorschlag wo man am Besten angreift?
In anderen Projekten stelle ich in solchen Situationen einfach alles auf utf8 um (DB,PHP,Webserver). Auf meinem Image kann ich das machen aber wenn es darauf ankommt dann fallen eventuell alle die auf die Nase, die nicht mein Image nutzen

[andig]

Browser sendet UTF8, VZ konvertiert soweit mir bekannt nix. Bleibt die Datenbankverbindung.

Doctrine's DBAL scheint einen Parameter charset: UTF8 zu besitzen. Der sollte sich über $config['db']['charset'] setzen lassen. Kannst Du mal versuchen ob das hilft?

Siehe http://stackoverflow.com/questions/13399912/symfony2-charset-for-queries-parameters

[andig]

@rgr-rgr könntest Du's testen?

[rgr-rgr]

Hallo,

Am 27.03.2014 16:18, schrieb andig:

Browser sendet UTF8, VZ konvertiert soweit mir bekannt nix. Bleibt die
Datenbankverbindung.

Dass die middleware nichts konvertiert ist aus meiner Sicht ein Fehler.
Letztlich trat der Fehler auf, weil nichts konvertiert wurde.

Eingabewerte gehören immer ins eigene Charset konvertiert, ansonsten
gibt es Stress mit Stringvergleichen und DB-Verbindungen.

Doctrine's DBAL scheint einen Parameter |charset: UTF8| zu besitzen. Der
sollte sich über |$config['db']['charset']| setzen lassen. Kannst Du mal
versuchen ob das hilft?

Das hilft hier bei meiner Installation, zumindest auf den ersten Blick.
Die Umlaute kommen jetzt sauber in die DB, mysql konvertiert sie. Das
war die halbe Miete.

Da das Frontend utf8 nutzt dürfte das jetzt im Image immer
funktionieren, zumindest soweit mir bekannt mit aktuellen Browsern.
Sobald jemand mit einem alternativem Frontend kommt, das nicht von sich
aus utf8 spricht kann es dann noch Probleme geben, da die middleware
dann Zeichen falsch nutzt.

Gruss
Rainer

[andig]

Content analysis details: (-2.9 points, 5.0 required)

@rgr-rgr Deine Anworten scheinen bei Dir durch einen SPAM Filter zu laufen der sie etwas unleserlich macht- ließe sich das für github evtl. vermeiden?

Dass die middleware nichts konvertiert ist aus meiner Sicht ein Fehler. Letztlich trat der Fehler auf, weil nichts konvertiert wurde.

Jaein. Der Fehler liegt auf der Ausgangsseite und zwar nicht in fehlender Konvertierung sondern daran dass wir der DB nicht erklärt haben was wir eigentlich senden.

Sobald jemand mit einem alternativem Frontend kommt, das nicht von sich aus utf8 spricht kann es dann noch Probleme geben, da die middleware dann Zeichen falsch nutzt.

Da ist was dran. Die naheliegende Lösung wäre zumindest zu dokumentieren dass die MW utf-8 erwartet. Wärst Du evtl so nett und würdest einen passenden Platz im Wiki suchen? Einen Umbau der Eingangsseite sehe ich im Moment eher nicht.

[rgr-rgr]

Spam: Kann ich eher nicht, bzw nur mit hohem Aufwand. Ich schreib einfach per Web-Frontend.

Da ist was dran. Die naheliegende Lösung wäre zumindest zu dokumentieren dass die MW utf-8 erwartet.

Das tut sie nicht. Sie nimmt einfach alles an und schiebt es weiter. Und wenn jemand eine Konfig anlegt die nicht zu den anderen Einstellungen anpasst, so gibt sie Zeichenmüll weiter. Das müsste man dokumentieren.
Könnte man auch tun, indem man dieses Issue offen lässt :-)

[andig]

Das tut sie nicht. Sie nimmt einfach alles an und schiebt es weiter.

Jetzt bist Du aber wirklich kleinlich. Das FE sendet UTF8, also erwartet die MW UTF8 ;) (frei nach dem Motto eine starke Behauptung ist besser als ein schwacher Beweis). Indem wir jetzt auch der DB erzählen dass sie UTF8 bekommt ist es konsistent.

In einem anderen Projekt habe ich die Inputs per mbstring konvertiert, aber das erscheint mir hier eher overkill. Aber sei's drum- wenn's jemand bauen will...