PhPMyadmin bug?
Knut Krueger
ich weiß nicht ob dies hier die richtige Gruppe ist.
Wenn nicht weiß jemand welche Gruppe dafür richtig ist?
Webspace, keinen Zugriff auf den Apache oder auf den Mysql Server.
Ich habe eine Datenbank mit Textfeldern.
Format latin1_swedish
Beim exportieren über Export werden die Umlaute verhackstückt.
Wenn ich einen Datensatz über die Suchmaske suche, den dann exportiere
so kommt der Umlaut richtig an.
Sprich ich bekomme die Daten nicht mehr richtig aus der Datenbank um sie
in eine neue einzulesen :-(
Viele Grüße Knut
Dominik Echterbruch
>
> Ich habe eine Datenbank mit Textfeldern.
> Format latin1_swedish
Nein, nicht Format, sondern Kollation. Das ist ein großer Unterschied.
Schau mal in der MySQL-Doku nach, was die Jungs mit der Kollation machen
(kleiner Hinweis: Sortierung).
> Beim exportieren über Export werden die Umlaute verhackstückt.
Das glaube ich nicht. Ich glaube eher, dass du folgendes getan hast:
Du hast eine Datenbank mit Zeichensatz ISO-8859-1 (bei MySQL entspricht
das grob latin1) angelegt und dort Texte im UTF-8 Zeichensatz
gespeichert, ohne vorher die Verbindung auf UTF-8 einzustellen. Jetzt
hast du das ganze exportiert und dir in irgendeinem Editor angeschaut.
Du siehst dann natürlich die UTF-8 Entsprechungen der Sonderzeichen, die
in deiner Datenbank gespeichert sind.
> Wenn ich einen Datensatz über die Suchmaske suche, den dann exportiere
> so kommt der Umlaut richtig an.
Ja, weil phpMyAdmin als Standardzeichensatz UTF-8 eingestellt hat und
das deinem Browser sagt, wenn er dir die Zeichen schickt. Dein Browser
zeigt dann das zum UTF-8 Code gehörende Zeichen an.
> Sprich ich bekomme die Daten nicht mehr richtig aus der Datenbank um sie
> in eine neue einzulesen :-(
Doch, bekommst du. In deinem Datenbankdump steht alles drin, was MySQL
braucht, um die Daten exakt so wieder in eine andere DB zu importieren,
wie sie aus der alten DB waren. Einfach mal ausprobieren und auf die
neue DB mittels phpMyAdmin zugreifen.
Grüße,
Dominik
--
Wo kämen wir denn da hin, wenn jeder nur fragte "Wo kämen wir denn
da hin?", aber niemand ginge, um zu sehen, wohin wir kämen, wenn wir
gingen?
(Autor unbekannt)
Knut Krueger
>
> Doch, bekommst du. In deinem Datenbankdump steht alles drin, was MySQL
> braucht, um die Daten exakt so wieder in eine andere DB zu importieren,
> wie sie aus der alten DB waren. Einfach mal ausprobieren und auf die
> neue DB mittels phpMyAdmin zugreifen.
Hallo Dominik,
leider nein,
ich verwende beide male den SQL Datenbank dump (Export -SQL -> Datei
senden) und beide male den gleichen Editor verwende.
(der Einfachheit HTML-Kit, weil ich damit die Web Seiten erstelle)
Es ist also sichergestellt, dass der Datenbank Dump unterschiedlich
übermittelt wird.
Viele Grüße Knut
Thomas Fuchs
> ich weiß nicht ob dies hier die richtige Gruppe ist.
Nein.
> Wenn nicht weiß jemand welche Gruppe dafür richtig ist?
<http://www.phpmyadmin.net/home_page/support.php>
> Webspace, keinen Zugriff auf den Apache oder auf den Mysql Server.
> Ich habe eine Datenbank mit Textfeldern.
> Format latin1_swedish
> Beim exportieren über Export werden die Umlaute verhackstückt.
Kann ich hier nicht reproduzieren. Verwendest du die aktuelle Version
von PMA? Wie sehen die Umlaute aus? Was soll "verhackstückt" heissen?
> Sprich ich bekomme die Daten nicht mehr richtig aus der Datenbank um sie
> in eine neue einzulesen :-(
mysqldump existiert. Vielleicht kannst du ja einen der Admins deines
Providers bitten einfach den Dump zu erstellen.
VG
Thomas
Claus Reibenstein
> Webspace, keinen Zugriff auf den Apache oder auf den Mysql Server.
Aber vielleicht auf den MySQL Client?
> Ich habe eine Datenbank mit Textfeldern.
> Format latin1_swedish
> Beim exportieren über Export werden die Umlaute verhackstückt.
phpMyAdmin hat zwar so manche Macke (und ist deshalb hier allgemein
nicht besonders beliebt), aber Derartiges konnte ich bislang nicht
beobachten.
> Wenn ich einen Datensatz über die Suchmaske suche, den dann exportiere
> so kommt der Umlaut richtig an.
?
> Sprich ich bekomme die Daten nicht mehr richtig aus der Datenbank um sie
> in eine neue einzulesen :-(
Bist Du denn sicher, dass die Daten richtig _in_ die Datenbank gelangt
sind? Wie hast Du das geprüft?
Gruß. Claus
Dominik Echterbruch
> Dominik Echterbruch schrieb:
>
>> Doch, bekommst du. In deinem Datenbankdump steht alles drin, was MySQL
>> braucht, um die Daten exakt so wieder in eine andere DB zu
>> importieren, wie sie aus der alten DB waren. Einfach mal ausprobieren
>> und auf die neue DB mittels phpMyAdmin zugreifen.
>
> ich verwende beide male den SQL Datenbank dump (Export -SQL -> Datei
Wieso beide Male? Ich denke, dein Dump (das impliziert Einzahl) ist
"defekt".
> senden) und beide male den gleichen Editor verwende.
> (der Einfachheit HTML-Kit, weil ich damit die Web Seiten erstelle)
Was hat denn das jetzt mit dem Thema zu tun? Ich kann dir nicht folgen.
> Es ist also sichergestellt, dass der Datenbank Dump unterschiedlich
> übermittelt wird.
Du gestattest, dass ich mal auf hessisch frage: Hä?
Knut Krueger
> phpMyAdmin hat zwar so manche Macke (und ist deshalb hier allgemein
> nicht besonders beliebt), aber Derartiges konnte ich bislang nicht
> beobachten.
Gibt es ein besseres Tool wenn man keinen Konsolenzugriff hat?
Sprich perl, oder php
>
>> Wenn ich einen Datensatz über die Suchmaske suche, den dann exportiere
>> so kommt der Umlaut richtig an.
>
> ?
>
>> Sprich ich bekomme die Daten nicht mehr richtig aus der Datenbank um sie
>> in eine neue einzulesen :-(
>
> Bist Du denn sicher, dass die Daten richtig _in_ die Datenbank gelangt
> sind? Wie hast Du das geprüft?
hm naja sie werden vom System und von PHPmyAdmin richtig angezeigt.
Gerade habe ich festgestellt dass sie im Dump ohne Senden also im
PhPMyAdmin Fenster richtig angezeigt werden nach dem Senden und
speichern aber wir d z.B Müller zu Müller,
Auch die TExte kommen falsch rüber
-- Tabellenstruktur für Tabelle `refs` (also ü wird hex: c3 bc ) falls
nicht richtig ankommt.
egal ob ich sie mit einem Hex Editor oder irgendeinem anderen anschaue.
Es sieht also nach einem Problem des Sendens aus nicht des Auslesens aus
der DB aus
Gut der Workaround ist dass man es eben mit Copy und Paste macht, nur
bin ich da bei fast 10 mb nicht drauf gekommen, zumal mir ein Dump
direkt auf die Platte lieber ist.
Den Unterschied zwischen einem und allen Datensätzen könnt Ihr wieder
streichen. Ich vermute den einzelnen habe ich mir direkt angesehen alle
habe ich als Dump auf die Platte sendenlassen
Viele Grüße Knut
Knut Krueger
> phpMyAdmin hat zwar so manche Macke (und ist deshalb hier allgemein
> nicht besonders beliebt), aber Derartiges konnte ich bislang nicht
> beobachten.
Gibt es ein besseres Tool wenn man keinen Konsolenzugriff hat?
Sprich perl, oder php
> Bist Du denn sicher, dass die Daten richtig _in_ die Datenbank gelangt
> sind? Wie hast Du das geprüft?
hm naja sie werden vom System und von PHPmyAdmin richtig angezeigt.
Gerade habe ich festgestellt dass sie im Dump ohne Senden also im
PhPMyAdmin Fenster richtig angezeigt werden nach dem Senden und
speichern aber wir d z.B Müller zu Müller,
und wenn man sie dann mit utf einliest so sind sie auch wieder richtig.
also doch ein BUG - bei mir..:-(
Viele Grüße Knut
Knut Krueger
>
> Du gestattest, dass ich mal auf hessisch frage: Hä?
aber klar ich werde mir erst mal durchlesen was du in der ersten Antwort
über Koalltion geschrieben hast:
> Nein, nicht Format, sondern Kollation. Das ist ein großer Unterschied. Schau mal in der MySQL-Doku nach, was die Jungs mit der Kollation machen (kleiner Hinweis: Sortierung).
Die Tabelle hat Koalltion latin1_swedish_ci
also habe ich versucht sie mit latin1 einzulesen
Lasse ich das Feld der Einlesemaske auf utf8 stehen so sind die Daten.
richtig.
Irgend ein Grundwissen fehlt mir da...
Viele GRüße Knut
Dominik Echterbruch
>
> Die Tabelle hat Koalltion latin1_swedish_ci
> also habe ich versucht sie mit latin1 einzulesen
> Lasse ich das Feld der Einlesemaske auf utf8 stehen so sind die Daten.
> richtig.
>
> Irgend ein Grundwissen fehlt mir da...
Gut, malen wir mal ein Bild:
Stell dir vor, du sprichst nur Deutsch. Nun kommt ein Chinese zu dir und
malt ein paar hübsche Zeichen aus seiner Sprache auf ein Blatt. Da dir
Chinesisch fremd ist, kannst du nicht verstehen, was das bedeutet. Aber
du kannst die Zeichen einfach so abpausen. Du brauchst dafür halt etwas
länger. Die DB braucht entsprechend einfach mehr Platz.
Was aber ist passiert?
Deine DB spricht latin1, soweit korrekt. Dein Browser spricht aber
UTF-8. Sendest du nun Daten an den Server, kommen die als UTF-8 an. Wenn
du das in die DB schreibst, zuckt MySQL zwar mit den Achseln, weil es
keine Ahnung hat, was das da sein soll, aber es paust die lustigen
Zeichen brav ab (d.h., schreibt die latin1-Entsprechung der komischen
Zeichen in die DB).
Möchtest du den Rümpel über deine Weboberfläche wieder angucken, holt
der Server diese seltsamen Zeichen aus der DB und schickt sie mit dem
Hinweis, dass es sich um UTF-8 Zeichen handelt, an deinen Browser. Dein
Browser wiederum stellt sie korrekt dar, weil er UTF-8 spricht und damit
weiß, was sich hinter den seltsamen Zeichen versteckt.
Unterschied zum Export:
Beim Export gibt es keine Zwischeninstanz, die die Daten interpretiert
und dir die gewohnten Umlaute anzeigt (es sei denn, du würdest einen
UTF-8 fähigen Editor verwenden und ihm sagen, dass es sich um eine UTF-8
kodierte Datei handelt). Dementsprechend bekommst du rohe latin1
Entsprechungen der UTF-8 Zeichen angezeigt.
Wenn du im Dump mal genau hin schaust, müsstest du da irgendwo ein "SET
NAMES latin1;" finden. Das sagt der Zieldatenbank, dass die Zeichen als
latin1 behandelt werden sollen. Das bedeutet dann nichts anderes, als
dass auch die Zieldatenbank schulterzuckend die lustigen Bildchen
abmalt. Benutzt du dann das gleiche Frontend zum Anzeigen der Daten, ist
alles wieder in bester Ordnung, weil dein Broser das UTF-8 korrekt
interpretiert.
Helmuth Justin
> Gut, malen wir mal ein Bild:
darf ich deine Antwort in der Schulung verwenden? Das war so schön
beantwortet...
P.S.
> Wo kämen wir denn da hin, wenn jeder nur fragte "Wo kämen wir denn
> da hin?", aber niemand ginge, um zu sehen, wohin wir kämen, wenn wir
> gingen?
> (Autor unbekannt)
P.S. Deine sig ist von Kurt Marti, Schweizer Pfarrer und Schriftsteller, *
31.01.1921 - Bern
http://de.wikiquote.org/wiki/Kurt_Marti
Gruß Helmuth
--
Was haben wir eigentlich davon, daß wir einander die kurze Lebenszeit
vergällen, uns beneiden und hassen, kränken und verfolgen, statt uns und
anderen
freundlich und glückreich zu machen? Wenn wir uns in rechter Gesinnung
gegenseitig
helfen, ist allen geholfen. Üben wir darum Menschlichkeit und sorgen wir,
daß unser
Denken und Tun immer auf das Wohl aller gerichtet ist. Denn ehe wir dessen
gewahr
werden, endet der Tod unsere Mühen. (Seneca)
Dominik Echterbruch
>
>> Gut, malen wir mal ein Bild:
>
> darf ich deine Antwort in der Schulung verwenden? Das war so schön
> beantwortet...
Gerne, ich erachte meine Anworten nicht als materielles Gut. Sonst würde
ich sie in einem Buch veröffentlichen ;)
Aber freut mich, dass sie dir gefällt.
>> Wo kämen wir denn da hin, wenn jeder nur fragte "Wo kämen wir denn
>> da hin?", aber niemand ginge, um zu sehen, wohin wir kämen, wenn wir
>> gingen?
>> (Autor unbekannt)
>
> P.S. Deine sig ist von Kurt Marti, Schweizer Pfarrer und Schriftsteller,
> * 31.01.1921 - Bern
> http://de.wikiquote.org/wiki/Kurt_Marti
Hervorragend, vielen Dank! Signatur ist angepasst.
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.
Autor: Kurt Marti (http://de.wikiquote.org/wiki/Kurt_Marti)