Wieder mal Codierung

[paulderfinne]

Hallo erstmal in die Runde:

Ich bin neu hier und freue mich auf eine gute Zusammenarbeit.

Mein Problem: Vor ein paar Tagen habe ich mein System erneuert (Debian stretch) dabei bekam ich als mysql-server die Version:

paul@pily:~$ mysql --version
mysql Ver 14.14 Distrib 5.6.25, for debian-linux-gnu (i686) using EditLine wrapper

Das Komische ist nun, dass ich jetzt plötzlich Probleme mit der Kodierung habe. Das System ist auf utf8:

ANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"

und die /etc/mysql/my.cnf enthält auch folgende Zeilen:

[client]
default-character-set=utf8

[mysql]
default-character-set=utf8


[mysqld]
collation-server = utf8_unicode_ci
init-connect='SET NAMES utf8'
character-set-server = utf8

Meine Daten liegen in csv vor und diese sind offenbar auch in utf8 codiert:

paul@pily:~/gg/datenbank$ file Kunden.csv
Kunden.csv: UTF-8 Unicode text, with very long lines

Tatsächlich werden Umlaute in der Datei auf der Konsole auch richtig angezeigt. Wenn ich sie aber importiere und wieder per select ausgebe, sind die umlaute plötzlich auf latin1 oder was auch immer das für ein Code ist:
Günthersbühler Str. 61
statt Günthersbühler Str. 61

Ich kann mich jetzt nicht detalliert erinnern was ich früher gemacht habe, aber mit dem alten System hat das funktioniert. Ist das irgend ein neuer Bug?

 

[akretschmer]

Wenn ich sie aber importiere und wieder per select ausgebe, sind die umlaute plötzlich auf latin1 oder was auch immer das für ein Code ist:
Günthersbühler Str. 61
statt Günthersbühler Str. 61

Willkommen in der wundervollen und abwechslungsreichen Welt von MySQL.

Ich kann mich jetzt nicht detalliert erinnern was ich früher gemacht habe, aber mit dem alten System hat das funktioniert. Ist das irgend ein neuer Bug?

Möglicherweise. Möglicherweise steht aber auch nur client_encoding (oder wie auch immer dies unter MySQL sich nennt, diese Variable gibt es aber in PostgreSQL) falsch.

 

[paulderfinne]

Danke für die schnelle Antwort. Die einzige Variable, die ich finde mit Client ist character_set_client und die steht auf utf8 (seit ich das in der /etc/mysql/my.cnf geändert habe.

Da scheint mysql wirklich ein Problem zu haben und das ist richtig blöd. Aber ich habe da halt ein Programm mit der Datenbank laufenund alles wieder ändern ist auch doof.

Natürlich kann es auch sein, dass ich wieder was vermurkse, aber ich wüsste nicht was.

 

[akretschmer]

Das Problem ist vermutlich beim Import. Aber viel helfen kann ich Dir da grad auch nicht, MySQL umd Umlaute ist halt eine unendliche Geschichte für sich.

 

[Distrilec]

Wenn ich mich nicht ganz irre, bietet MySQL eine Funktion für die UTF8-Konvertion... Nennt sich glaube ich "utf8_encode"

 

[paulderfinne]

Hmm.. abgesehen davon, dass es Wahnsinn wäre alle Befehle umzuschreiben bringt das auch nix. Ich habe den Befehl:

select convert(strasse using utf8) from kunden;

eingeben. Es kommen trotzdem die falschen Umlaute.

@akretschmer: wie mainst du das mit dem Import. Alles steht doch auf utf8: Das System , mysql und die Daten selbst. Beim Import muss mysql da ja gar nichts machen.

 

[akretschmer]

Beim Import muss mysql da ja gar nichts machen.

Der Client muß sagen, in was für einem Zeichensatz das nachfolgende kommt.

 

[paulderfinne]

Ok, vielen Dank an euch. Ich habe jetzt beim Import zusätlich noch gesagt, dass die Daten in utf8 kodiert sind:

load data infile '/pfad_zur_datei/datei.csv' into table datei CHARACTER SET UTF8 fields terminated by ',' enclosed by '"' lines terminated by '\n';

und da kamen zwar einige angebliche Duplikate, abere nachdem ich die gelöscht habe lief das durch und nun sind die Daten auch richtig kodiert.

Das war jetzt ein bisschen Tricky und hat mir einige Tage Rätselei gekostet. Zudem sind meine Haare (wenn möglich) noch ein wenig grauer geworden, aber jetzt habe ich die Daten wenigstens richtig kodiert drinnen.
Also nochmals vielen Dank.

 

[akretschmer]

Zudem sind meine Haare (wenn möglich) noch ein wenig grauer geworden,

Verständlich bei MySQL ;-)

 

[paulderfinne]

Ja, du magst ja recht haben, aber ich habe mich nun mal mit mysql abgegeben. Es gibt auch native Treiber zu Libreoffice usw. Ein Umschwenken ist immer mit Mühe verbunden. Aber wenn ich das nächste Mal ganz von vorne anfange, werde ich über Postgre nachdenken. Ich schwöre ...