PHPMyAdmin Import nicht möglich: Unerwartetes Zeichen
Hallo zusammen
Ich versuche, bis jetzt leider erfolglos, eine MySQL Datenbank mit PHPmyAdmin zu importieren. Beim Importieren erscheint immer eine Fehlermeldung.
Exportiert wurde die Datenbank so:
Und Importiert wurde diese so:
Beim Import wurde darauf geachtet, das "utf-8" ausgewählt ist. Zumindest gehe ich davon aus, dass das richtig ist. Weil wenn ich die db_name.sql mit z.B. Notepad++ öffne steht in Zeile 10:
Ob mir da jemand weiterhelfen kann?
Freundliche Grüsse
Markus
Ich versuche, bis jetzt leider erfolglos, eine MySQL Datenbank mit PHPmyAdmin zu importieren. Beim Importieren erscheint immer eine Fehlermeldung.
1. Unerwartetes Zeichen. (near "" at position 315)
2. Unerwartetes Zeichen. (near "~" at position 316)
3. Unerwartetes Zeichen. (near "=" at position 317)
[..]
Exportiert wurde die Datenbank so:
mysqldump -u root -p db_name > db_name.sql
Und Importiert wurde diese so:
Beim Import wurde darauf geachtet, das "utf-8" ausgewählt ist. Zumindest gehe ich davon aus, dass das richtig ist. Weil wenn ich die db_name.sql mit z.B. Notepad++ öffne steht in Zeile 10:
/*!40101 SET NAMES utf8 */;
Ob mir da jemand weiterhelfen kann?
Freundliche Grüsse
Markus
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 291397
Url: https://administrator.de/forum/phpmyadmin-import-nicht-moeglich-unerwartetes-zeichen-291397.html
Ausgedruckt am: 23.12.2024 um 11:12 Uhr
8 Kommentare
Neuester Kommentar
von einem Windows-System zu einem Linux-Server? - Windows kodiert gerne UTF-16...
Schlüssig und zügig kann man das wohl nur mit einem kleinen Hexdump entscheiden, also auf der Konsole mit hd (mit: man hd die Anleitung) um die Fehlerzeilen herum als Hex und daneben ASCII ausgeben lassen, dann kann man die Kodierung für das konkrete Datenbankfeld erkennen (hier ggf. wieder einstellen).
HG
Mark
Schlüssig und zügig kann man das wohl nur mit einem kleinen Hexdump entscheiden, also auf der Konsole mit hd (mit: man hd die Anleitung) um die Fehlerzeilen herum als Hex und daneben ASCII ausgeben lassen, dann kann man die Kodierung für das konkrete Datenbankfeld erkennen (hier ggf. wieder einstellen).
HG
Mark
Moin,
das in deinem File steht das es UTF-8 Daten enthält sagt rein garnichts darüber aus, dass es auch tatsächlich im UTF-8 Encoding auf der Platte gelandet ist.
So wie du die Daten über STDOUT exportiert hast ist das böse wenn deine Shell nicht auf UTF8 Character-Encoding gesetzt ist!
Wenn dann nur so
Dann wird ein korrekt kodiertes File geschrieben.
Siehe dazu auch folgende Seite wie du es richtig machst:
http://makandracards.com/makandra/595-dumping-and-importing-from-to-mys ...
Gruß jodel32
das in deinem File steht das es UTF-8 Daten enthält sagt rein garnichts darüber aus, dass es auch tatsächlich im UTF-8 Encoding auf der Platte gelandet ist.
So wie du die Daten über STDOUT exportiert hast ist das böse wenn deine Shell nicht auf UTF8 Character-Encoding gesetzt ist!
Wenn dann nur so
mysqldump -uroot -p database -r export.dump
Siehe dazu auch folgende Seite wie du es richtig machst:
http://makandracards.com/makandra/595-dumping-and-importing-from-to-mys ...
Gruß jodel32
Die erste Ansicht ist schon völlig ausreichend, eine kompakte Darstellung hätte auch gereicht:
BLOB-Felder sind in den HexDumps trotz der zufälligen Auswahl auch tatsächlich zu sehen, die Kodierung ist aber auch tatsächlich sehr wahrscheinlich UTF-8, da sonst regelmäßig zwischen regulären ASCII-Werten (gerade den nicht-BLOBs) 00-Bytes stünden.
Das Setzen auf latin1 würde es also schlechter machen.
@LordGurke hat da schon recht, den Export wiederholen wäre Best Practice.
Wurde er nach dem Export nochmal mit Editoren geöffnet? die könnten in den BLOBs vielleicht CR oder LF+CR eingefügt haben?
BLOB-Felder sind in den HexDumps trotz der zufälligen Auswahl auch tatsächlich zu sehen, die Kodierung ist aber auch tatsächlich sehr wahrscheinlich UTF-8, da sonst regelmäßig zwischen regulären ASCII-Werten (gerade den nicht-BLOBs) 00-Bytes stünden.
Das Setzen auf latin1 würde es also schlechter machen.
@LordGurke hat da schon recht, den Export wiederholen wäre Best Practice.
Wurde er nach dem Export nochmal mit Editoren geöffnet? die könnten in den BLOBs vielleicht CR oder LF+CR eingefügt haben?