Zum wahnsinnig werden: Migration von mySQL 5.1. auf 5.5, UTF-8 oder Latin1

[DBcrazy]

Hallo,

habe einen modified Shop auf einem Debian squeeze Server (mySQL 5.1) laufen und würden den gern auf einen neuen Debian Jessie Server übernehmen (mySQL 5.5.49-0+deb8u1). Allerdings verzweifle ich gerade an diesem furchtbaren Collate Thema:

Ich verwende phpmyadmin zum Export und Import der Daten. Auf dem alten Server habe ich nicht die Möglichkeit, ein spezielles Format zu exportieren, deshalb nehme ich an (?), dass der Export auch so läuft, wie der collate wert in der Datenbank steht - das ist "latin1_german1_ci".

Auf dem neuen Server habe ich die Shop-Datenbank entsprechend angelegt und das Datenbankfile importiert.

Der Shop funktioniert erst mal, solange ich die Funktion "Meta-Tags/Suchmaschinen" -> "Suchmaschinenfreundliche URLs benutzen?" deaktiviere. Allerdings nur oberflächlich, sobald ich in Adressfiles hineinschaue, werden Sonderzeichen nicht korrekt angezeigt (�? für ein ß).

Wenn ich die Funktion "Suchmaschinenfreundliche URLs benutzen?" aktiviere, dann funktionieren die Kategorientitel nicht mehr - die Links sind nicht existent (Fehlermeldung).

Da ich schon den ganzen Abend vergeblich dran sitze, zu schauen, welche Optionen ich für Export und Re-Import auf dem neuen Server noch habe, frage ich jetzt einfach in die Runde:

Kann es sein, dass ich besser komme, wenn ich Export und Import direkt auf der Konsole mit dem mysql-client mache? Kann ich einen exportierten Datenbankdump irgendwie prüfen, in welchem Zeichensatz die gespeicherten Daten vorliegen? Habe ich eine Möglichkeit, das alles auf UTF-8 zu migrieren, ohne Daten zu verlieren?

Ich wäre hier für Hinweise sehr dankbar, da mich diese Inkompatibilitäten einfach wahnsinnig machen .. irgendwie bin ich es in letzter Zeit immer gewohnt, dass Dinge einfach intuitiv funktionieren, wahrscheinlich bin ich ($Hersteller)-versaut

Danke & VG,
Olaf.

Linkback: https://www.modified-shop.org/forum/index.php?topic=34976.0

[Fakrae]

Okay, zuerstmal, etwas "anzunehmen" ist meistens ein schlechter Weg zum Erfolg

Wenn du deine exportierte Datei anschaust, stellst du fest, dass es eine einfache Textdatei ist. Mit Notepad++ bspw. kannst du oben unter "Kodierung" sehen, welche Kodierung die DATEI hat (noch nicht die Datenbank) - das sagt dir, welche Einstellung du beim Importieren machen musst.
Dann steht an jeder einzelnen Tabelle die Kodierung dieser TABELLE dran, ich würde empfehlen das so zu lassen, normal zu importieren und dann der Anleitung im Forum zur Migration auf utf8 zu folgen (da gibt es sogar Scripte dazu, ich glaube von NoRiddle(?))

Wenn du im Zuge deiner Umstellung auch noch die PHP Version auf >5.4 änderst, könnte es eventuell Probleme mit der Umstellung geben (weil sich der default-Zeichensatz geändert hat) - also am Besten eines nach dem anderen.

[Bonsai]

Nimm nie phpMyAdmin für Backups. Installiere Dir das: MySQLDumper
Da kann man auch einstellen mit welchem Charset exportiert wird.

Das von Fakrae angesprochene Script (und eine verständliche Erklärung des ganzen Themas): SHOP UTF-8 ...

[voodoopupp]

Nimm nie phpMyAdmin für Backups. Installiere Dir das: MySQLDumper
Da kann man auch einstellen mit welchem Charset exportiert wird.
...

Was allerdings schwierig wird, ob sich das weiterhin mit php7 so verhalten wird, nachdem das Projekt dieses Jahr offiziell eingestellt wurde: http://forum.mysqldumper.de/viewtopic.php?t=7541

Nur, wenn sich jemand dem Thema annimmt.

[web0null]

Es gibt Hoffnung,

http://foren.myoos.de/viewtopic.php?f=41&t=1784
https://github.com/r23/MyOOS/tree/master/msd

[webald]

Ich kann euch beruhigen. mysqldumper geht auch unter PHP7 mit kleiner Änderung. Ich nutze das seit PHP 7.0.2 ohne Probleme.

[hpzeller]

Hallo Olaf,

kann ich kaum glauben, dass es bei deiner Version von phpMyAdmin nicht möglich ist das Format und vor allem die Zeichencodierung des Exports zu wählen.

Tipp:
Klicke in der zu exportierenden Datenbank auf [Export] und setze in der dann folgenden  Bildschirmausgabe den Radiobutton vor "Angepasst – zeige alle möglichen Optionen an", dann findest du unter "Ausgabe" die Option "Zeichencodierung der Datei:" dort Wählst du den gleichen Zeichensatz der auch dein Webshop hat (bei älteren Shops oft 'iso-8859-15').

PS:
Natürlich kannst du die Datei auch mit 'utf-8' exportieren, aber dann muss bei deinem neuen Shop alles auf 'utf-8' konfiguriert sein, also z.B. auch alle Textkonstanten sollten dann in 'utf-8' codiert sein.

Gruss
Hanspeter

[Bonsai]

Finger weg von myphpadmin für Backups!!!!

Habe schon erlebt, dass

Code: XML  [Auswählen]

Hier ein Text mit 'Anführungszeichen'

dann so in der SQL Datei stand:

Code: XML  [Auswählen]

'Hier ein Text mit 'Anführungszeichen''

Führt dann natürlich zu einem SQL Fehler .... "in der Nähe von"

Code: XML  [Auswählen]

mit 'Anführungszeichen

Die Datei ist völlig zerschossen gewesen .... mit der Hand wiederhergestellt in Stundenlanger Arbeit 

Bei myphpadmin ist es einfach ein Glücksspiel ob beim Backup eine Datei raus kommt, die man wieder importieren kann, oder nicht! Dann macht mal ein Provider ein Update und schon ist eine defekte Version da.
MySQLDumper schreibt übrigens in die Datei rein (als Kommentar) wie die Einstellungen beim Export waren und somit übernimmt der beim Import AUTOMATISCH die richtigen Einstellungen.

[hpzeller]

Erstaunlich, nur weil du schon Probleme mit phpMyAdmin gehabt hast und offensichtlich auch mit der richtigen Schreibweise dieses Werkzeugs sollen also alle die Finger davon lassen. Meine Erfahrung beim exportieren und importieren von Datenbanken oder Teilen davon mit phpMyAdmin ist die, das Tool ist sehr flexibel und kann umfangreich konfiguriert werden, eignet sich allerdings, wenn man eine komplette Datenbank sichern will, nur für kleinere bis mittlere Datenbankgrössen.

Gruss
Hanspeter

[p3e]

Da kann ich mich Hanspeter nur anschließen. phpMyAdmin ist ein prima Werkzeug. Wenn man aber nicht weiß was man tut, sollte man die Finger davon lassen. Es aber nur wegen der Möglichkeiten zu verteufeln halte ich hier für falsch.

Wenn es nur um das Backup der Shop-Datenbank geht, hat modified aber ja bereits eine Backupfunktion, die auch mit sehr großen Datenbanken klar kommt.

[Bonsai]

Spielt weiter Lotto .... Ich bin mit der dieser Datenbankdumpfunktion schon zweimal auf ein völlig unterschiedliches Problem gelaufen, beides mal nicht wegen falschen Einstellungen, sondern wegen eines Bugs. Das wird mir nie wieder passieren, weil ich das Tool dafür nie wieder nehmen werde.

[DBcrazy]

Hallo,

danke für das umfangreiche Feedback und es lässt mich natürlich schon erst mal klarer durchblicken

Der Shop läuft momentan auf einem alten Debian GNU/Linux 6.0.10 (squeeze). Wenn ich dort mit dem Webbrowser das Encoding anschaue, dann sagt mir der Browser mit Show Page Source:

"meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15""

Und http://validator.w3.org sagt:

Encoding: iso-8859-15.

Darstellung ist rundum OK (Frontend, Admin, Datenbank-Content mit phpmyadmin angeschaut)

Der "neue" Shop (der nur der per rsync kopierte Content vom alten Shop zzgl. DB ist) läuft nun auf nem neuen Debian GNU/Linux 8.4 (jessie).

Wenn ich dort mit dem Webbrowser das Encoding anschaue, dann sagt mir der Browser mit Show Page Source immer noch:

"meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15""

Und http://validator.w3.org sagt:

Encoding: utf8.

Und spuckt den Fehler:
"Sorry, I am unable to validate this document because on line 218 it contained one or more bytes that I cannot interpret as utf-8 (in other words, the bytes found are not valid values in the specified Character Encoding). Please check both the content of the file and the character encoding indication.

The error was: utf8 "\xF6" does not map to Unicode "

Darstellung ist in den Kategorien "kaputt" (da wird aus dem Begriff Zubehör der Begriff "Zubeh�r"), im Fließtext und Produktbeschreibungen aber OK (da werden die Umlaute korrekt angezeigt).

Wenn ich in die Datenbank schaue (mit phpmyadmin) sehe ich die Umlaute auch korrekt drin stehen und korrekt angezeigt.

Was das ganze Thema Datenbank-Export und -Import betrifft, habe ich mich an die Empfehlungen gehalten und die Datenbank direkt per mysql Befehl gedumpt und auch per mysql Befehl wieder eingespielt.

Wenn ich keine Konvertierung anwende, kommt eben das spannende Zeichen "�" in die Kategorientitel und Überschriften, wenn ich die Empfehlung mit Konvertierung von ISO8859-15 auf UTF8 anwende, verschwinden die Umlaute (der Kategorientitel "Zubehör" lautet dann "Zubehr".

Ich erlaube mir also noch mal, zu "vermuten": Es liegt der Fehler möglicherweise darin, dass ich den "installierten" modified-shop einfach ge-rsync'ed habe. Vielleicht sollte ich auf dem neuen Server auch neu installieren, damit alle Einstellungen "korrekt" mit UTF-8 kommen?

Bitte dazu noch mal einen Typ von Euch "Erfahreneren" ... mir bleibt ja sonst nur, auf dieses Produkt hier auszuweichen:

https://www.getdigital.eu/Scheiss--Encoding.html



Danke & VG,
dbcrazy

[hpzeller]

[...]
Wenn ich dort mit dem Webbrowser das Encoding anschaue, dann sagt mir der Browser mit Show Page Source immer noch:

"meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15""

Und http://validator.w3.org sagt:

Encoding: utf8.
[...]

Das Problem liegt wahrscheinlich an der falschen Charsetangabe im HTTP-Header und diese Angabe steht ist in der Hierarchie über der Angabe im HTML-Header. Mit Firebug kannst du diesen Header anzeigen lassen, siehe Bild.

In diesem Zusammenhang wäre interessant zu wissen wie deine '.htaccess' Datei aussieht.

Tipp:
Du kannst Testweise in 'includes/application_top.php' und 'admin/includes/application_top.php' nach

Code: PHP  [Auswählen]

   Released under the GNU General Public License
   ---------------------------------------------------------------------------------------*/
 

folgenden Code einfügen

Code: PHP  [Auswählen]

header('Content-Type: text/html; charset=iso-8859-15');
 

Gruss
Hanspeter

[Bonsai]

in der
.htaccess
sollte sowas stehen:

Code: XML  [Auswählen]

##-- Default charset
AddDefaultCharset ISO-8859-15
 

Das steuert den Apache, damit der seine Standardeinstellung, (heutzutage UTF-8), überschrieben bekommt.

[DBcrazy]

Hallo again,

habe in der .htaccess drin stehen:

 AddDefaultCharset ISO-8859-15

Das hat erstmal nichts geändert (Kategorientitel weiter mit Sonderzeichen).

Dann habe ich die Hinweise von hpzeller angewendet und in den zwei [admin/]includes/application_top.php die Zeile

header('Content-Type: text/html; charset=iso-8859-15');

eingefügt. Damit sind die Zeichen jetzt richtig - sowohl Kategorien als auch im Admin-Interface der Aufruf z.B. einer Kundenadresse mit "Straße" wird korrekt ausgegeben.

Was bedeutet das nun final? Server und DB laufen auf UTF-8 und nur für die Shop-Installation biege ich das per "Hack" um auf ISO-8859-15?

Oder sollte ich doch noch "irgendwie" die Datenbankinhalte nach UTF-8 wandeln und dann den header-Hinweis wieder entfernen?

Danke und VG,
dbcrazy