utf8-Konvertierung trotz latin1_german1_ci?

[Manu]

Guten Abend,

mir ist gerade die folgende Meldung ins Auge gesprungen, als ich in phpmyadmin eine Zeile geupdatet habe:

UPDATE xyz.bf\_lang SET lang\_de = 'Start' WHERE CONVERT( bf\_lang.id USING utf8 ) = 'start' AND CONVERT( bf\_lang.hash USING utf8 ) = 'ea2b2676c28c0db26d39331a336c6b92' LIMIT 1 ;

Ich frage mich, was da konvertiert wird...alle Zeilen stehen auf latin1_german1_ci, es wird nur deutsch und englisch benutzt.

Von einem anderen Projekt hatte ich allerdings beizeiten eine Klasse herüberkopiert, die für die DB-Einträge verantwortlich ist. Sie war zuerst noch utf-8-kodiert. Inzwischen habe ich die Datei aber ascii/ansi-Format konvertiert.

Was kann ich hier machen bzw. was könnte hier los sein? (Ich weiß auch nicht so recht, wonach ich googlen könnte...) Kann ich die Daten irgendwie zu latin1_german1_ci konvertieren?

Gruß,
Manu

[Gonzo]

CONVERT( bf\_lang.id USING utf8 ) = 'start'

Ich frage mich, was da konvertiert wird...alle Zeilen stehen auf latin1_german1_ci

Genau deshalb. Es wird bf_lang.id von latin1 nach utf8 konvertiert, nicht umgekehrt.

Ich vermute einfach mal, dass sich der Browser mit phpMyAdmin in utf8 unterhält, somit auch das zu vergleichende Datum (hier: 'start') prinzipiell utf8-kodiert ist. Warum nicht dieses Datum nach latin1 konvertiert wird, sollte auf der Hand liegen: Es würden Informationen verloren gehen.

[Manu]

Hallo Dedlfix,

danke für die Antwort.
Wie kann das passiert sein? Die anderen Tabellen der DB haben diesen Problem nicht, und dort stehen Texte drin...

Was könnte ich dagegen tun?
Alles in UTF-8 halte ich für überflüssig, zumal sich damit 'etwas' mehr Arbeit auftut...

Gruß,
Manu

[dedlfix]

echo $begrüßung;

mir ist gerade die folgende Meldung ins Auge gesprungen, als ich in phpmyadmin eine Zeile geupdatet habe:

UPDATE xyz.bf\_lang SET lang\_de = 'Start' WHERE CONVERT( bf\_lang.id USING utf8 ) = 'start' AND CONVERT( bf\_lang.hash USING utf8 ) = 'ea2b2676c28c0db26d39331a336c6b92' LIMIT 1 ;

Ich frage mich, was da konvertiert wird...alle Zeilen stehen auf latin1_german1_ci, es wird nur deutsch und englisch benutzt.

phpMyAdmin unterhält sich bei Abfragen mit dem Server generell in der Kodierung UTF-8. Diese Umkodierung, die phpMyAdmin da vornimmt, ist im Prinzip überflüssig, da MySQL selbst zwischen verschiedenen Kodierungen umkodiert, wie beispielsweise der Feldkodierung latin1 und der Verbindungskodierung utf8. Ich kann mir als Grund für dieses Verhalten phpMyAdmins nur vorstellen, dass es in speziellen Fällen Probleme gegeben haben könnte. Bekannt ist mir nichts, müsste ich mal das ChangeLog durchschauen.

Was kann ich hier machen bzw. was könnte hier los sein? (Ich weiß auch nicht so recht, wonach ich googlen könnte...) Kann ich die Daten irgendwie zu latin1_german1_ci konvertieren?

Wenn du generell sowohl für die Kodierung der Felder als auch für die Kodierung der Verbindung (Stichwort: mysql_set_charset() bzw. SET NAMES) die gleiche Einstellung verwendest, kannst du auf die Konvertiererei verzichten. Es ist allerdings eine Überlegung wert, ob du nicht statt Latin1 lieber UTF-8 verwenden willst, denn das kann mit deutlich mehr Zeichen umgehen. Allerdings ist PHP5 noch nicht UTF-8-fähig, was sich bei der Stringverarbeitung nachteilig auswirken kann.

echo "$verabschiedung $name";

[Manu]

Jau, jetzt hab ich eben die falsche Begrüßung geschrieben. Darum hallo auch an Gonzo!

Also ich habs gerade noch einmal ausprobiert: weitere Table mit News - Zeile geändert - gespeichert - keine Umkodierung. Das passiert nur in meiner Language-Table.

Ich frage mich echt, was da passiert ist...oO ???

Gruß,
Manu

[Manu]

Habe jetzt folgenden Dump eingespielt, leider ohne eine Änderung:

CREATE TABLE bf\_lang (
  id varchar(4096) collate latin1_german1_ci NOT NULL,
  lang\_en varchar(4096) collate latin1_german1_ci NOT NULL,
  lang\_de varchar(4096) collate latin1_german1_ci NOT NULL,
  date timestamp NOT NULL default CURRENT_TIMESTAMP,
  hash varchar(32) collate latin1_german1_ci NOT NULL,
  PRIMARY KEY  (id(254),hash(31))
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci;

Mir ists ein Rätsel...

Gruß,
Manu

[dedlfix]

echo $begrüßung;

Habe jetzt folgenden Dump eingespielt, leider ohne eine Änderung:
CREATE TABLE bf\_lang (
Mir ists ein Rätsel...

Mir auch, denn das ist ein Statement zum Erzeugen einer Tabelle ohne weitere Daten. Es fehlt zum Nachvollziehen eine Beschreibung der Zielsetzung und des stattdessen erhaltenen Ergebnisses.

echo "$verabschiedung $name";

[Manu]

Hallo,

jetzt kann ich Dir nicht mehr ganz folgen...

Das Problem tritt ja nur in PHPMyAdmin  auf, und zwar bei einem Update. Dort steht plötzlich 2x CONVERT( bf\_lang.xyz USING utf8 ) = 'xxx'...

Ich habe die Table exportiert, im Editor geöffnet. Dort stand nichts über utf-8. Dann per phpmyadmin->sql wieder eingefügt. Beim erneuten Update wieder dasselbe... Es ist zum ****...

Gruß,
Manu

[dedlfix]

echo $begrüßung;

Das Problem tritt ja nur in PHPMyAdmin  auf, und zwar bei einem Update. Dort steht plötzlich 2x CONVERT( bf\_lang.xyz USING utf8 ) = 'xxx'...

Ich habe die Table exportiert, im Editor geöffnet. Dort stand nichts über utf-8. Dann per phpmyadmin->sql wieder eingefügt. Beim erneuten Update wieder dasselbe... Es ist zum ****...

Das ist eine Eigenart neuerer Versionen des PMA. Es scheint seine Gründe dafür zu haben, diese Konvertierung explizit vorzunehmen, statt sie dem Server zu überlassen. Was für ein Problem hast du denn damit konkret? Wenn du unbedingt verhindern willst (wofür es eigentlich keinen Grund gibt), dass der PMA UTF-8 mit dem Server redet, dann sag ihm das auf der Startseite.

echo "$verabschiedung $name";

[dedlfix]

echo $begrüßung;

Also ich habs gerade noch einmal ausprobiert: weitere Table mit News - Zeile geändert - gespeichert - keine Umkodierung. Das passiert nur in meiner Language-Table.

Da du es nicht nachvollziehbar mit Zielstellung und stattdessen erhaltenem Ergebnis beschreibst, weiß ich nicht, was du da eben getrieben hast.

Prinzipiell ist der MySQL-Server eine Blackbox. Du schiebst Daten in der für deine aktuelle Verbindung ausgehandelten Kodierung (oder einem Default-Wert) in diese Blackbox hinein und bekommst sie in ebendieser Kodierung wieder zurück. Falls die Einstellungen der Felder unterschiedlich sind, kodiert MySQL die Daten um.

Man kann Blackbox-Prinzip-bedingt und aufgrund dieser Umkodierung nicht direkt nachsehen, was im Inneren passiert. Man kann nur Vermutungen aufstellen und mit einem Test, bei denen diese Umkodierung technisch nicht möglich ist, nachzuweisen versuchen, dass sie stattfindet: </archiv/2007/7/t157019/#m1021663>

Ich frage mich echt, was da passiert ist...oO ???

Das Beispiel im Ausgangsposting verwendet nur Zeichen aus dem ASCII-Bereich 00-7F. Bei diesem gibt es zwischen Latin1/ISO-8859-1 und UTF-8 keine Unterschiede.

Wenn du nun etwas nachzuvollziehen versuchst, dann nimm nicht noch eine zweite Blackbox namens phpMyAdmin hinzu, sondern mach dies im Direktgespräch mit dem MySQL-Server.

echo "$verabschiedung $name";