mySQL - Das Problem mit den Umlauten

[steff11]

Chief Senior Web Application Mainstream Framework Consultant Assistant of Incoming and Outgoing Sourcecode Developement

heißt das, Du hast schon jemand im Büro, der für dich Kaffee mitkocht?

[DSB]

Dummerweise nicht.
Da sitzen nur 15 Leute, die sich solche Stellenbezeichnungen ausdenken und dann habe ich noch 4 Mann in der Werkstatt, die die Rahmen für die Visitenkarten zusammenschweißen.
Das sind topqualifizierte Leute, aber Kaffee kochen können die nicht.
Das muss ich selbst machen.

[steffenk]

Du hast bestimmt den gehört: http://dev.traum-projekt.com/NEU/index.php?id=209 Nr.5

[§_mo]

sorry wenn ich das leidliche thema nochmal aufrolle, aber ich komme nicht mehr weiter. habe duzende foren durchsucht und ich bin bisher keinen schritt weiter gekommen.

zu meiner situation:
DB umzug auf neuen php5 server -> dabei umstellung auf UTF8

ich kann garantieren das:
1. neu DB inklusiver aller tabellen in UTF8 konvertiert/erstellt sind
2. die daten an sich ebenfalls in UTF8 vorliegen
3. die anbindung der DB aus der anwendung heraus auch auf UTF8 gestellt ist.

das hat aber zur folge das die darstellung der umlaute im frontend nur kraut und rüben ist.
stell ich die verbindung (SET NAMES ...) auf LATIN1, dann ist die darstellung korrekt.

phpmyadmin sagt mir (mit show variables) das alle charakter_sets korrekt auf UTF8 eingestellt sind, mit ausnahme von "character_set_server". das ist immer noch auf latin gestellt. ebenso ist die collation_database die callation_connection korrekt auf UTF8 eingestellt. "collation_server" allerdings wieder auf latin.

ich kann mir darauf keinen reim machen. kann es an den beiden werten liegen? ich habe eigentlich alles andere ausgeschlossen!?!

diese werte soll man ja (laut google suche) in der my.cnf setzen können. in meiner umgebung gibts keine "my.cnf". auf dem linux server liegen unter /usr/share/mysql/ mehrere verschiedene cnf's. ich kann nicht nachvollziehen welche davon benutzt wird.

wenn irgendwer noch eine idee hat, ich wäre wirklich sehr dankbar!

gruß
markus

[DSB]

Lies Dir das mal durch:
http://www.mysqldumper.de/board/viewtopic.php?t=2313

Wahrscheinlich hast Du bereits falsch kodierte Umlaute in der DB. Im Artikel findest Du ein Programm, welches das korrigieren kann.

[§_mo]

ich hatte den guide schon vorher gelesen. hatte irgendwie gehofft das es an callation_server und character_set_server liegt

mit sqldump habe ich auch schon versucht einen dump zu erstellen, aber da bekomme ich immer einen socket error. keine ahnung woran das liegt. hab mich mit dem fehler (2002) auch durch-ge-googelt, ohne erfolg.

euer msqldumper läßt ich auch nicht in die gänge kriegen. es scheitert schon daran das ich der config.php keine anderen rechte zuweise kann. denke mal meine eigenen rechte reichen dafür nicht aus. und ich habe momentan keine möglichkeit das zu ändern (der verantwortliche ist nicht zugegen).

die anzeige der umlaute in myphpadmin ist auf jeden fall korrekt. und wenn ich den dump (den ich mit phpmyadmin erstellt habe) in einem editor öffne dann werden die umlaute auch richtig angezeigt. auch mit utf8. ich werd noch ein bisschen (umständlich) rumprobieren. ich klammere mich dabei an den ansatz, das es an dem falschen format der daten liegt und nicht an was anderem.

gruß
markus

NACHTRAG:
die darstellungsfehler entsprechen denen aus der guide-beschreibung für das szenario: utf8-daten ziehen nach latin-DB um. also die ersetzung des einen utf8 zeichens durch 2 (äöü...). das sagt mir doch jetzt eigentlich, das der sql server das problem ist, oder? er scheint irgendwie/irgendwo latin zu erwarten. die DB und alle tabellen sind definitiv in utf8 erstellt und werden mir auch so angezeigt. beim import des dumps gebe ich an, das ich daten im utf8 format (dropdown menü) importiere. also wo kracht das denn bitte?!

[steffenk]

der server ist nicht das problem, es ist immer der user
wenn die Daten mit latin1 kodiert wurden, dann sind sie auch mit latin1 gespeichert. Das hat nix mit den Einstellungen zu tun. Man kann nicht einfach einen Hebel umlegen und alle Daten sind plötzlich utf8, also müssen die Daten konvertiert werden.

[§_mo]

die alte datenbank inklusive die alte phpmyadmin version wurden von irgend einer externen firma lange vor meiner zeit verwaltet. keine ahnung wie, aber sie haben in phpmyadmin beim export die funktion freigeschaltet/implementiert, das man auch beim beim Export die kollation angeben kann in der die daten raus sollen. habe versucht nachzuvollziehen wie sie das gemacht haben, ohne erfolg (ein serverseitiges uploadverzeichnis für dumps hab ich ja auch hinbekommen).

jedenfalls kann ich beim export aus der alten DB bereits utf8 angeben. und das die daten dann tatsächlich in utf8 vorliegen, dafür habe ich, denke ich, bereits argumente geliefert.

also nochmal: ich bin zu 99% sicher das die daten tatsächlich in utf8 vorliegen!
ich denke der import in die neue DB ist das problem (mysql client 5.0.51 + phpmyadmin 2.11.0).

[DSB]

Ich frage mich ernsthaft, wie Du anständig debuggen willst, wenn Du noch nicht einmal ein simples PHP-Skript auf dem Server ans Laufen bekommst. Deine Überzeugung alles richtig gemacht zu haben in allen Ehren. Ich habe aber genug Probleme beim Import und auch bei der Anzeige von Daten mit PhpMyAdmin gehabt, um zu wissen, dass das nicht immer gelingt, auch wenn man alles korrekt angibt.
Wie die Zusammenhänge wirklich sind kann zumindest ich nur dann einschätzen, wenn MSD ab Version 1.22 läuft. Da bin ich 100%ig sicher, dass die Daten korrekt im SQLBrowser angezeigt werden und auch genau so in der DB vorliegen. Allen anderen Programmen traue ich keinen Zentimeter mehr über den Weg. Sogar das vB macht in Bezug auf utf8-Umstellung konzeptlosen Blödsinn (ich habe mir eine Lizenz gekauft, wollte auf utf8 umstellen und war bei Ansicht des Codes entsetzt!).

Gewissheit also mit korrekter Installation von MySQLDumper ab Version 1.22 .