Das ewige Problem: MySQL (win32), UTF8, Sonderzeichen (Umlaute) und mysql.exe
Andreas Eibach
da bin ich auch mal wieder.
Hatte ja lange nix mit MySQL zu tun, aber jetzt ist es eben mal wieder
aufgekommen (das Übliche: alles maßlos überteuert, E**o sei Dank, dann
bleibt eben wieder nur MySQL statt einer gescheiten DB)
Die Entwickler WOLLEN ES EINFACH NICHT WAHRHABEN, dass da ein Bug
drinsteckt.
Sollten wir mal eine Real-Demo veranstalten, mit Plakaten und so?! ;-)
Das Problem besteht jetzt seit 2005 so oder noch früher, und nichts, NICHTS
passiert da.
Ich glaub fast hier sind die falschen Leute an den Entwicklertischen, ein
"Austausch" würde u.U. Wunder bewirken!
Auf der Bug-Liste werden reihenweise diese Requests als "Not A Bug"
geschlossen und immer mit dem Vermerk: auf meinem Testcase funktioniert das.
Nun können sich aber 10000e Menschen in der ganzen Welt auch nicht irren.
Allerdings verwenden die Leute mit diesem Problem alle WINDOWS.
Es scheint also tatsächlich ein Win-only Problem zu sein.
**
Mir ist auch schon angeraten worden, das Problem an Microsoft zu berichten,
da es angeblich ein MS-Problem sei. Ich glaub da kein Wort von, die wollen
nur den Schwarzen Peter wieder woanders hin schieben. Bei mysql.exe handelt
es sich um eine C++-Applikation, und warum soll der nicht wurschtegal sein,
was die Eingabeaufforderung vermag?! Das sollte doch eigentlich autark
laufen, denn der ganze Kram - sofern korrekt - ist da ja drin einkompiliert.
**
Also.
mysql> show variables from tabelle like 'char%';
...
........................................................................................................................
Bis auf filesystem=binary steht da überall 'utf8'. Schön.
........................................................................................................................
Im mysql-client mach ich ein
ganz primitives create table
mysql>CREATE DATABASE dbtest;
mysql>USE dbtest;
mysql>CREATE TABLE test1 (name varchar (255));
Dann einen Wert einfügen:
mysql>INSERT INTO test1 values ('Bäh');
ERROR 1366 (HY000): Incorrect string value: '\xFC' for column 'name' at row
1
Das ging 2005 noch nicht, das geht 2010 immer noch nicht.
Ich hab wirklich ALLES probiert (auch anhand von Foren-Vorschlägen) : mit
'alter table', 'set names utf8', ... NIX.
Das Grundproblem besteht:
*Es* *geht* *einfach* *nicht* in Windows auf die Weise - außer über Krücken
und Umwege.
(Die da wären: latin1 einstellen [auch serverseitig], dann wieder
umkonvertieren nach...xyz)
Kann's denn das sein? Will ich nicht. Das MUSS ja auch so gehen. Die
Dokumentation macht einen ja auch glauben, das ginge.
*WAS* jetzt glücklicherweise (!) geht, ist dass man per "load data infile"
eine Input.-Datei angeben kann, die im UTF-Format (!) sein muss, damit es
funktioniert, allerdings...dazu muss VARCHAR zu VARBINARY werden:
mysql>CREATE TABLE test2 (name varbinary (255));
mysql>quit
(die input_uni.txt im folgenden enthalte nur ein Wort, 'Bäh')
mysql>load data local infile 'C:\\input_uni.txt' into test2 character set
utf8;
mysql>SELECT HEX(name) from test2;
42C3A472
YIPPIEH. Geht doch ... Unicode-Binary "ä" ist jetzt drin.
mysql>SELECT * from test2;
Bär
Zeigt kaputtes ä an, *ABER* es funktioniert korrekt in phpMyAdmin und kann
auch sauber ausgelesen werden.
Aber wieso kann MYSQL.EXE das nicht korrekt *anzeigen*? Nämlich als UTF8?
Hat der eine MySQL-Entwickler recht wenn er sagt, das sei ein
Microsoft-Problem?
Ich kann's einfach nicht ganz glauben!! $ENTW ist doch auch in der Lage, ein
Unicode-fähiges C++-Programm zu schreiben. M. E. sieht es so aus: wenn
mysql.exe das nicht korrekt in Windos darstellen kann, dann muss mysql.exe
(bzw. mysql.cc) so modifiziert werden dass es das eben KANN. Oder ist MySQL
da wirklich machtlos?
In 3 Worten:
"Wer lügt hier"?
-An ' sorry for the long post ' dreas
Dominik Echterbruch
>
> Hatte ja lange nix mit MySQL zu tun, aber jetzt ist es eben mal wieder
> aufgekommen (das Übliche: alles maßlos überteuert, E**o sei Dank, dann
> bleibt eben wieder nur MySQL statt einer gescheiten DB)
Äh... Was ist an PostgreSQL so verkehrt? Kostet nix und ist nach Meinung
vieler Leute deutlich besser als MySQL. OK, Geschmacksssache, aber eine
Alternative ist es allemal.
Grüße,
Dominik
--
"Wo kämen wir hin, wenn alle sagten, wo kämen wir hin, und niemand
ginge, um einmal zu schauen, wohin man käme, wenn man ginge."
Kurt Marti
"Nichts ist praktischer, als eine gute Theorie." - Todor Karman
Martin Schoenbeck
Dominik Echterbruch schrieb:
> �h... Was ist an PostgreSQL so verkehrt? Kostet nix und ist nach Meinung
> vieler Leute deutlich besser als MySQL. OK, Geschmacksssache, aber eine
> Alternative ist es allemal.
Nur da� ihm das wohl auch nicht helfen wird. Wenn man eine Console
verwendet, die man nicht auf utf-8 einstellen kann, dann wird man da keinen
utf-8-Zeichen sinnvoll anzeigen oder eingeben k�nnen. Auch mit PostgreSQL
nicht.
Gru� Martin
--
Bitte nicht an der E-Mail-Adresse fummeln, die pa�t so.
Claus Reibenstein
> Die Entwickler WOLLEN ES EINFACH NICHT WAHRHABEN, dass da ein Bug
> drinsteckt.
> Sollten wir mal eine Real-Demo [viel Blahblah gesnipt]
Warum immer erst so ein Gelaber, anstatt gleich zum Punkt zu kommen?
Außerdem würdest Du Dich mit einer solchen Aktion total lächerlich machen.
> mysql> show variables from tabelle like 'char%';
> ....
> .........................................................................................................................
> Bis auf filesystem=binary steht da überall 'utf8'. Schön.
> .........................................................................................................................
Schön ja, aber vollkommen irrelevant.
> Im mysql-client mach ich ein
> ganz primitives create table
>
> mysql>CREATE DATABASE dbtest;
> mysql>USE dbtest;
> mysql>CREATE TABLE test1 (name varchar (255));
>
> Dann einen Wert einfügen:
Ohne vorher die Zeichencodierung Deines Eingabegerätes korrekt einzustellen.
> mysql>INSERT INTO test1 values ('Bäh');
> ERROR 1366 (HY000): Incorrect string value: '\xFC' for column 'name' at row
> 1
Das ist dann die logische Folge davon.
Mit welcher Zeichencodierung arbeitet denn Dein Eingabegerät? Auf welche
Zeichencodierung hast Du den Client eingestellt? Hier scheint das
Problem zu liegen.
> Das ging 2005 noch nicht, das geht 2010 immer noch nicht.
Doch, das geht schon. Voraussetzung ist allerdings, dass Du MySQL die
richtige Zeichencodierung mitteilst oder - falls das geht - Dein
Eingabegerät auf die richtige Zeichencodierung einstellst.
> Ich hab wirklich ALLES probiert (auch anhand von Foren-Vorschlägen) : mit
> 'alter table', 'set names utf8'
Genau hier liegt Dein Fehler: Statt "utf8" muss hier die
Zeichencodierung Deines Eingabegerätes stehen.
> Das Grundproblem besteht:
> *Es* *geht* *einfach* *nicht* in Windows auf die Weise - außer über Krücken
> und Umwege.
Es geht auch in Windows. Man muss den MySQL-Client nur richtig bedienen.
Auf jeden Fall sehe ich hier nirgends einen Fehler, der auf MySQL
zurückzuführen wäre. Alles, was ich sehe, sind Bedienfehler.
Gruß. Claus
Andreas Treichel
> mysql>USE dbtest;
> mysql>CREATE TABLE test1 (name varchar (255));
> ERROR 1366 (HY000): Incorrect string value: '\xFC' for column 'name' at row 1
Was passiert wenn du folgendes machst?
mysql> SET names utf8;
mysql> CREATE DATABASE dbtest;
mysql> USE dbtest;
mysql> CREATE TABLE test1 (name varchar (255));
mysql> INSERT INTO test1 values ('B�h');
Martin Schoenbeck
Andreas Treichel schrieb:
Was soll passieren? Dasselbe nat�rlich, schlie�lich hat er ja genau das
getestet. Ob er das set names nun vor oder nach dem Einrichten der
Datenbank macht, ist doch egal. Entscheidend ist, da� er eine Konsole
benutzt, die ganz offenbar nicht mit UTF-8 arbeitet. Das, was da als �
erscheint, ist eben kein UTF-8-�.
Christian Kirsch
[schwadronier]
> mysql> show variables from tabelle like 'char%';
> ...
> ........................................................................................................................
> Bis auf filesystem=binary steht da überall 'utf8'. Schön.
> ........................................................................................................................
>
> Im mysql-client mach ich ein
> ganz primitives create table
>
> mysql>CREATE DATABASE dbtest;
> mysql>USE dbtest;
> mysql>CREATE TABLE test1 (name varchar (255));
>
> Dann einen Wert einfügen:
>
> mysql>INSERT INTO test1 values ('Bäh');
> ERROR 1366 (HY000): Incorrect string value: '\xFC' for column 'name' at row
> 1
Aha. Und was macht Dich glauben, 0xFC wäre ein gültiger UTF8-Code?
Garbage in, Fehlermeldung out. Insofern ist das doch ok.
>
> Das ging 2005 noch nicht, das geht 2010 immer noch nicht.
Vielleicht, weil 2005 0xFC kein gültiger UTF8-Code ware und es bis 2010
auch nicht geworden ist.
Was Dir vielleicht (!) helfen könnte, wäre den Connection und/oder
Client Charset auf Latin1 zu stellen, wenn Du schon Latin1 an die
Datenbank schickst. Oder Deinen Client auf UTF8 umzustellen.
> *WAS* jetzt glücklicherweise (!) geht, ist dass man per "load data infile"
> eine Input.-Datei angeben kann, die im UTF-Format (!) sein muss, damit es
> funktioniert, allerdings...dazu muss VARCHAR zu VARBINARY werden:
Du meinst vermutlich: Die Input-Datei muss UTF-8 verwenden? Oder UTF-16?
Oder was? Und warum müsste man dabei aus VARCHAR ein VARBINARY machen?
>
> mysql>CREATE TABLE test2 (name varbinary (255));
> mysql>quit
>
> (die input_uni.txt im folgenden enthalte nur ein Wort, 'Bäh')
Und zwar vermutlich UTF8 kodiert, gell?
> mysql>load data local infile 'C:\\input_uni.txt' into test2 character set
> utf8;
>
> mysql>SELECT HEX(name) from test2;
> 42C3A472
>
> YIPPIEH. Geht doch ... Unicode-Binary "ä" ist jetzt drin.
>
Was jetzt weniger erstaunlich ist: Kein Garbage in, kein Garbage und
keine Fehlermeldung out.
> mysql>SELECT * from test2;
> Bär
>
> Zeigt kaputtes ä an, *ABER* es funktioniert korrekt in phpMyAdmin und kann
> auch sauber ausgelesen werden.
Nein, das zeigt kein "kaputtes" ä an, sondern eins in UTF-8. Wenn Dein
Anzeigeprogramm allerdings auf Latin1 eingestellt ist, dann sieht das
für Dich vielleicht ein bisschen ungewöhnlich aus.
>
> Aber wieso kann MYSQL.EXE das nicht korrekt *anzeigen*? Nämlich als UTF8?
> Hat der eine MySQL-Entwickler recht wenn er sagt, das sei ein
> Microsoft-Problem?
Ja.
>
> Ich kann's einfach nicht ganz glauben!!
Glauben ist hier auch nicht nötig, das kannst Du in der Kirche machen.
> $ENTW ist doch auch in der Lage, ein
> Unicode-fähiges C++-Programm zu schreiben. M. E. sieht es so aus: wenn
> mysql.exe das nicht korrekt in Windos darstellen kann, dann muss mysql.exe
> (bzw. mysql.cc) so modifiziert werden dass es das eben KANN. Oder ist MySQL
> da wirklich machtlos?
Wie wäre es, wenn Du einfach mal ein
echo "bäh" > blafasel.txt
od -b blafasel.txt
(ok, vielleicht gibt es od nicht unter Windows - nimm halt irgendwas,
womit Du Dir da den Inhalt der Datei byteweise angucken kanns)
ausprobiertest? Dann könntest Du sehen, ob Deine Konsole UTF-8 oder
Latin-1 schreibt. Und dann könntest Du entscheiden, ob Du oder die
anderen der Geisterfahrer bist.
Dominik Echterbruch
> Hallo Dominik,
>
> Dominik Echterbruch schrieb:
>
>> �h... Was ist an PostgreSQL so verkehrt? Kostet nix und ist nach Meinung
>> vieler Leute deutlich besser als MySQL. OK, Geschmacksssache, aber eine
>> Alternative ist es allemal.
>
> Nur da� ihm das wohl auch nicht helfen wird. Wenn man eine Console
> verwendet, die man nicht auf utf-8 einstellen kann, dann wird man da keinen
> utf-8-Zeichen sinnvoll anzeigen oder eingeben k�nnen. Auch mit PostgreSQL
> nicht.
Dass es sein Problem m�glicherweise nicht l�st, ist klar. Aber ich bezog
mich ja auch nicht auf sein Problem, sondern auf die Polemik bzgl.
MySQL, die du leider in deiner Antwort weggeschnitten hast. Zur
Erinnerung: "bleibt eben wieder nur MySQL statt einer gescheiten DB".
Gr��e,
Dominik
--
"Wo k�men wir hin, wenn alle sagten, wo k�men wir hin, und niemand
ginge, um einmal zu schauen, wohin man k�me, wenn man ginge."
Thomas Rachel
> Die Entwickler WOLLEN ES EINFACH NICHT WAHRHABEN, dass da ein Bug
> drinsteckt.
Beschreib mal...
[Geblubber gelöscht]
> Bei mysql.exe handelt es sich um eine C++-Applikation
Sicher? Ich meine eher, C.
> und warum soll der nicht wurschtegal sein, was die Eingabeaufforderung
> vermag?! Das sollte doch eigentlich autark laufen, denn der ganze Kram
> - sofern korrekt - ist da ja drin einkompiliert.
Die ganzen Zusammenhänge scheinen Dir nicht so ganz klar zu sein...
> mysql> show variables from tabelle like 'char%';
> ...
> ........................................................................................................................
>
> Bis auf filesystem=binary steht da überall 'utf8'. Schön.
Und da fängts doch schon an. Ich dachte, Du wolltest unter Windows
arbeiten? In der Eingabeaufforderung? Die m.W. mit cp850 arbeitet? (Ggf.
auch cp437...)
> mysql>INSERT INTO test1 values ('Bäh');
> ERROR 1366 (HY000): Incorrect string value: '\xFC' for column 'name' at
> row 1
Du gibst '\xFC' ein. Was willst Du wirklich? Ein ä, oder? Wie sieht das
in UTF8 aus? '\xC3\xA4', nicht wahr? Na also. Wo kommt dann das '\xFC'
her? Und warum erwartest Du, daß das richtig ist?
> Das ging 2005 noch nicht, das geht 2010 immer noch nicht.
Wowereit.
> mysql>SELECT HEX(name) from test2;
> 42C3A472
>
> YIPPIEH. Geht doch ... Unicode-Binary "ä" ist jetzt drin.
>
> mysql>SELECT * from test2;
> Bär
>
> Zeigt kaputtes ä an, *ABER* es funktioniert korrekt in phpMyAdmin und
> kann auch sauber ausgelesen werden.
>
> Aber wieso kann MYSQL.EXE das nicht korrekt *anzeigen*? Nämlich als UTF8?
Tut es doch. Würdest Du ihm sagen, es soll es als cp850 ausgeben (für
die Kommandozeile) bzw. cp1252 (für Windows-Fenster)[1], dann täte es
das auch.
> Hat der eine MySQL-Entwickler recht wenn er sagt, das sei ein
> Microsoft-Problem?
Ich denke, nicht nur der eine sagt Dir das. Windows ist eben ein Problem
:-} Aber wenn mans richtig einstellt, dann paßts auch. Von daher würde
ich sagen, PEBKAC.
[1] Das ist wirklich ein Windows-Problem, und zwar ein ziemlich ekliges:
zwei unterschiedliche Charsets, abhängig davon, ob ich in der
Eingabeaufforderung oder in anderen Fenstern bin.