21
Umstellen der MySQL und PHP von ISO (latin1) auf UTF8 (utf8 general ci)
@developer
Aktuell stelle ich gerade administrator.de von ISO auf UTF-8 um. Dabei bin ich auf einige merkwürdige Verhaltensweisen meiner Programmierung und Datenbank gestoßen. Ich will nun den Weg zum Ziel etwas genauer dokumentieren. Die Umstellung ist nötig, um auch bei mehreren Sprachen nicht dauernd zwischen den ISO Normen hin und her zu springen. Auch kann ich mir in der Programmierung einige Konvertierungen per iconv sparen. Meist entstehen dort Konvertierungsfehler (z.B. beim Euro Symbol). Für die Zukunft spricht also alles für UTF-8. Wenn man ein PHP Projekt umstellen möchte, sollte man meiner Meinung nach, bei der Datenbank anfangen und dann erst die Programmierung anpassen. Es gibt mehrere UTF-Kollationen. Für uns gilt die "utf8 general ci".
Einstellungen in der my.conf:
Dann startet die aufwendige Datenbank Konvertierung. Als Erstes die Defaults Sets:
(datenbank_name, tabellen_name und tabellen_feld natürlich mir den eigen Daten ausfüllen, das dient hier nur zur Orientierung)
Danach die einzelnen Tabellen:
Nicht die Defaults Sets der Tabellen vergessen:
Bestehende "Fullindex" und "Index" Felder muss man gelegentlich (bei mehreren Feldern in einem Index) erst mal löschen und nach der Konvertierung wieder neu anlegen.
Da ein Index laut MySQL immer ein Limit von 1000 hat, wird man unter UTF 8 (jetzt 1-4 Bit pro Zeichen, ISO 2 Bit pro Zeichen) recht schnell an das Limit kommen.
Mann kann sich damit aushelfen, einfach den Index auf ein paar Stellen zu beschränken. Hier ein Beispiel: Hier sind Feld 2 und 3 auf 10 und 20 Stellen reduziert. Generell sowieso besser, als einen vollen Index zu erstellen.
Wichtig auch, das immer die ganze Datenbank auf UTF-8 umgestellt wird. Sonst gibt es sehr starke Performance Probleme unter der MySQL. Erst als ich alle Tabellen umgestellt hatte und per "Repair" jeder Index neu berechnet wurde, lief die MySQL wieder schnell. Ich denke das Problem waren die Index Felder, Mischungen aus ISO und UTF-8 bringen den Performance Verlust.
Damit jetzt auch die Webseite UTF lesen kann muss man dem PHP irgendwie sagen, dass jetzt UTF-8 über den Datenbank-Connector kommen soll.
Die Lösung: Bei der Initialisierung der DB (also beim Connect) einmalig den SQL Befehl: SET NAMES 'utf8' an die DB schicken. Nun liefert die DB nur noch UTF-8 aus.
Schön für jeden, der das in einer PHP Klasse hat
Jetzt noch ein paar Einstellung an der Webseite und in PHP vornehmen und man hat es geschafft.
Jede Webseite sollte jetzt einen UTF Header bekommen:
Damit es auch bei Seiten wo man das Vergessen hat funktioniert, gibt es eine nette Einstellung in der php.ini:
So das war es. Für Ergänzungen bin ich natürlich dankbar.
Gruß
Frank
Webmaster
Aktuell stelle ich gerade administrator.de von ISO auf UTF-8 um. Dabei bin ich auf einige merkwürdige Verhaltensweisen meiner Programmierung und Datenbank gestoßen. Ich will nun den Weg zum Ziel etwas genauer dokumentieren. Die Umstellung ist nötig, um auch bei mehreren Sprachen nicht dauernd zwischen den ISO Normen hin und her zu springen. Auch kann ich mir in der Programmierung einige Konvertierungen per iconv sparen. Meist entstehen dort Konvertierungsfehler (z.B. beim Euro Symbol). Für die Zukunft spricht also alles für UTF-8. Wenn man ein PHP Projekt umstellen möchte, sollte man meiner Meinung nach, bei der Datenbank anfangen und dann erst die Programmierung anpassen. Es gibt mehrere UTF-Kollationen. Für uns gilt die "utf8 general ci".
Einstellungen in der my.conf:
[mysqld]
character-set-server = utf8
default-character-set = utf8
....Dann startet die aufwendige Datenbank Konvertierung. Als Erstes die Defaults Sets:
(datenbank_name, tabellen_name und tabellen_feld natürlich mir den eigen Daten ausfüllen, das dient hier nur zur Orientierung)
ALTER DATABASE `datenbank_name` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;Danach die einzelnen Tabellen:
ALTER TABLE `tabellen_name` CHANGE `tabellen_feld` `tabellen_feld` VARCHAR( 254 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ;
ALTER TABLE `tabellen_name2` CHANGE `tabellen_feld2` `tabellen_feld2` VARCHAR( 254 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ;
etc., etc. Nicht die Defaults Sets der Tabellen vergessen:
ALTER TABLE `user_interest` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;Bestehende "Fullindex" und "Index" Felder muss man gelegentlich (bei mehreren Feldern in einem Index) erst mal löschen und nach der Konvertierung wieder neu anlegen.
Da ein Index laut MySQL immer ein Limit von 1000 hat, wird man unter UTF 8 (jetzt 1-4 Bit pro Zeichen, ISO 2 Bit pro Zeichen) recht schnell an das Limit kommen.
Mann kann sich damit aushelfen, einfach den Index auf ein paar Stellen zu beschränken. Hier ein Beispiel:
ALTER TABLE `tabellen_name` ADD INDEX `index_name` ( `feld_1` , `feld_2` ( 10 ) , `feld_3` ( 20 ) ) ;Wichtig auch, das immer die ganze Datenbank auf UTF-8 umgestellt wird. Sonst gibt es sehr starke Performance Probleme unter der MySQL. Erst als ich alle Tabellen umgestellt hatte und per "Repair" jeder Index neu berechnet wurde, lief die MySQL wieder schnell. Ich denke das Problem waren die Index Felder, Mischungen aus ISO und UTF-8 bringen den Performance Verlust.
Damit jetzt auch die Webseite UTF lesen kann muss man dem PHP irgendwie sagen, dass jetzt UTF-8 über den Datenbank-Connector kommen soll.
Die Lösung: Bei der Initialisierung der DB (also beim Connect) einmalig den SQL Befehl: SET NAMES 'utf8' an die DB schicken. Nun liefert die DB nur noch UTF-8 aus.
Schön für jeden, der das in einer PHP Klasse hat
Jetzt noch ein paar Einstellung an der Webseite und in PHP vornehmen und man hat es geschafft.
Jede Webseite sollte jetzt einen UTF Header bekommen:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> Damit es auch bei Seiten wo man das Vergessen hat funktioniert, gibt es eine nette Einstellung in der php.ini:
default_mimetype = "text/html"
default_charset = "UTF-8" So das war es. Für Ergänzungen bin ich natürlich dankbar.
Gruß
Frank
Webmaster
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 53604
Url: https://administrator.de/tutorial/umstellen-der-mysql-und-php-von-iso-latin1-auf-utf8-utf8-general-ci-53604.html
Ausgedruckt am: 22.12.2024 um 07:12 Uhr
21 Kommentare
Neuester Kommentar
G' Abend,
erstmal riesen Lob von mir an dich Frank. Sowas habe ich schon gesucht!
Was hälst du davon, wenn du deine Klasse veröffentlichst. Nach deinem Grinsen entwickelst du bzw. hast schon eine. *gg*
Ich möchte nämlich auch umstellen (ca 30 Datenbanken, ca. 300 Tabellen). Warum nochmal die Mühe machen und eine schreiben.
Grüße
Dani
erstmal riesen Lob von mir an dich Frank. Sowas habe ich schon gesucht!
Was hälst du davon, wenn du deine Klasse veröffentlichst. Nach deinem Grinsen entwickelst du bzw. hast schon eine. *gg*
Ich möchte nämlich auch umstellen (ca 30 Datenbanken, ca. 300 Tabellen). Warum nochmal die Mühe machen und eine schreiben.
Grüße
Dani
Hi Frank,
ok....wunderbar!!! Werde ich mich mir mal reinziehen!
Grüße
Dani
ok....wunderbar!!! Werde ich mich mir mal reinziehen!
Grüße
Dani
mysql_query("SET NAMES utf8",$ConnectionHandle);
hattest du ja schon geschrieben
, aber an dieser Zeile habe ich eine ganze Weile gekaut . Also nicht vergessen
hattest du ja schon geschrieben
, aber an dieser Zeile habe ich eine ganze Weile gekaut . Also nicht vergessen
Hallo!
Ich habe noch zwei Fragestellungen zu Deinem Beitrag:
Kann man das nicht vereinfachen in dem man einfach
ALTER TABLE `tabellen_name` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
schreibt?
Zudem: Wird der Inhalt welcher in der Datenbank bzw. in der Tabelle/Spalte steht denn von Latin1 in UTF-8 transformiert? An welcher Stelle geschieht dies oder braucht man das gar nicht?
In der Variante, dass man die Datenbank dumped, lässt man dann ein iconv oder recode über die Dump-Datei laufen, so wird der Inhalt zu UTF-8 gewandelt bevor sie wieder in eine als UTF-8-angelegte Datenbank spielt.
Wo geschieht dies hier?
Gruß PHANTOMIASER
Ich habe noch zwei Fragestellungen zu Deinem Beitrag:
ALTER TABLE `tabellen_name` CHANGE `tabellen_feld` `tabellen_feld` VARCHAR( 254 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ;
ALTER TABLE `tabellen_name2` CHANGE `tabellen_feld2` `tabellen_feld2` VARCHAR( 254 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ;
ALTER TABLE `tabellen_name2` CHANGE `tabellen_feld2` `tabellen_feld2` VARCHAR( 254 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ;
Kann man das nicht vereinfachen in dem man einfach
ALTER TABLE `tabellen_name` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
schreibt?
Zudem: Wird der Inhalt welcher in der Datenbank bzw. in der Tabelle/Spalte steht denn von Latin1 in UTF-8 transformiert? An welcher Stelle geschieht dies oder braucht man das gar nicht?
In der Variante, dass man die Datenbank dumped, lässt man dann ein iconv oder recode über die Dump-Datei laufen, so wird der Inhalt zu UTF-8 gewandelt bevor sie wieder in eine als UTF-8-angelegte Datenbank spielt.
Wo geschieht dies hier?
Gruß PHANTOMIASER
Hi,
ja
sobald der CONVERT abgeschlossen ist ist die Tabelle im UTF8 Format.
sorry, dazu kann ich leider nichts sagen, auf die Idee den Dump per "iconv" oder "recode" umzuwandeln kam ich noch nicht.
Gruß
Frank
ALTER TABLE `tabellen_name` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
hmm, sollte eigentlich auch funktionieren.Wird der Inhalt welcher in der Datenbank bzw. in der Tabelle/Spalte steht denn von Latin1 in UTF-8 transformiert?
ja
An welcher Stelle geschieht dies oder braucht man das gar nicht?
sobald der CONVERT abgeschlossen ist ist die Tabelle im UTF8 Format.
In der Variante, dass man die Datenbank dumped, lässt man dann ein iconv oder recode über die Dump-Datei laufen
sorry, dazu kann ich leider nichts sagen, auf die Idee den Dump per "iconv" oder "recode" umzuwandeln kam ich noch nicht.
Gruß
Frank
Danke für die schnelle Antwort!
Wie kriege ich denn solche gelben Textblöcke hin? Dachte es reicht ein > zu schreiben?
Es liegen dann alle Tabellen und alle Spalten, zudem die Datenbank, wenn man "show variables" macht bzw. "show create table TABLENAME" und "show full fields from TABLENAME" als UTF-8 vor, nun ist ja von Datenbankseite alles fertig?
Was mich eigentlich bei der Dump-Variante interessiert ist, dass die Tabellenspalten wenn ich ein "show full fields from TABLENAME" mache, dass bei der COLLATION-Spalte noch das latin1_swedish_ci steht statt utf8_general_ci und ob das ein Problem darstellen kann?
Anbei der Dump-Weg:
mysqldump -u root --default-character-set=latin1 -c --insert-ignore --skip-set-charset DBNAME > DBDUMP.sql
Eins von denen:
chgrep latin1 utf8 DBDUMP.sql
sed -i "" 's/latin1/utf8/g' DBDUMP.sql
sed -r 's/latin1/utf8/g' DBDUMP.sql > DBDUMP_UTF8.sql
iconv -f ISO-8859-1 -t UTF-8 DBDUMP.sql > DBDUMP_UTF8.sql
recode latin1..utf8 DBDUMP.sql
drop database DBNAME;
create database DBNAME CHARACTER SET utf8 COLLATE utf8_general_ci;
mysql -u root --default-character-set=utf8 DBNAME < DBDUMP.sql
Aber dann bin ich ja jetzt einen Schritt weiter beim Projekt des lustigen Konvertierens, das mich schon knapp zwei Tage beschäftigt
Zusatz: Weißt Du was geschieht wenn das CONVERT über eine Tabelle laufen lasse, die bereits in UTF-8 vorliegt?
Das CONVERT hat doch einen Haken, aber deine Lösung wohl dann auch, siehe http://dev.mysql.com/doc/refman/5.1/de/alter-table.html
Es wird erst als BLOB geCHANGEd, dann wieder zurück als UTF-8. Warum verstehe ich nicht so ganz warum das gemacht wird und das CONVERT nicht geht.
Wie kriege ich denn solche gelben Textblöcke hin? Dachte es reicht ein > zu schreiben?
sobald der CONVERT abgeschlossen ist ist die Tabelle im UTF8 Format.
Ah okay, und bei deiner Lösung wären es die CHANGE-Statements die diese umwandeln?Es liegen dann alle Tabellen und alle Spalten, zudem die Datenbank, wenn man "show variables" macht bzw. "show create table TABLENAME" und "show full fields from TABLENAME" als UTF-8 vor, nun ist ja von Datenbankseite alles fertig?
Was mich eigentlich bei der Dump-Variante interessiert ist, dass die Tabellenspalten wenn ich ein "show full fields from TABLENAME" mache, dass bei der COLLATION-Spalte noch das latin1_swedish_ci steht statt utf8_general_ci und ob das ein Problem darstellen kann?
Anbei der Dump-Weg:
mysqldump -u root --default-character-set=latin1 -c --insert-ignore --skip-set-charset DBNAME > DBDUMP.sql
Eins von denen:
chgrep latin1 utf8 DBDUMP.sql
sed -i "" 's/latin1/utf8/g' DBDUMP.sql
sed -r 's/latin1/utf8/g' DBDUMP.sql > DBDUMP_UTF8.sql
iconv -f ISO-8859-1 -t UTF-8 DBDUMP.sql > DBDUMP_UTF8.sql
recode latin1..utf8 DBDUMP.sql
drop database DBNAME;
create database DBNAME CHARACTER SET utf8 COLLATE utf8_general_ci;
mysql -u root --default-character-set=utf8 DBNAME < DBDUMP.sql
Aber dann bin ich ja jetzt einen Schritt weiter beim Projekt des lustigen Konvertierens, das mich schon knapp zwei Tage beschäftigt
Zusatz: Weißt Du was geschieht wenn das CONVERT über eine Tabelle laufen lasse, die bereits in UTF-8 vorliegt?
Das CONVERT hat doch einen Haken, aber deine Lösung wohl dann auch, siehe http://dev.mysql.com/doc/refman/5.1/de/alter-table.html
Es wird erst als BLOB geCHANGEd, dann wieder zurück als UTF-8. Warum verstehe ich nicht so ganz warum das gemacht wird und das CONVERT nicht geht.
Wie kriege ich denn solche gelben Textblöcke hin? Dachte es reicht ein > zu schreiben?
ja aber mit Leerzeichen dahinter. Schau mal unter: Formatierungen in den Beiträgen
Was mich eigentlich bei der Dump-Variante interessiert ist, dass die Tabellenspalten wenn ich ein "show full fields from TABLENAME" mache,
dass bei der COLLATION-Spalte noch das latin1_swedish_ci steht statt utf8_general_ci und ob das ein Problem darstellen kann?
dass bei der COLLATION-Spalte noch das latin1_swedish_ci steht statt utf8_general_ci und ob das ein Problem darstellen kann?
Ich denke schon. Bei zukünftigen Inserts könnte er dann "latin1_swedish_ci" nehmen. Ausprobiert habe ich das aber noch nicht.
Außerdem könnte es ein Performance Problem geben. Unterschiedliche CHARACTER in der DB haben bei meinen Test dazu geführt.
Du kannst Die Tabelle aber jederzeit mit:
ALTER TABLE `tabellenname` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ciGruß
Frank
Jetzt habe ich wohl zu spät das editiert und du hast meinen Zusatz nicht mehr gelesen:
Könnte man es dann universeller so machen?
ALTER TABLE TABLENAME CONVERT TO CHARACTER SET binary;
und danach
ALTER TABLE TABLENAME CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
oder muss ich danach
ALTER TABLE TABLENAME CHANGE spalte spalte SpaltenTyp CHARACTER SET utf8 COLLATE utf8_general_ci;
machen?
Zusatz: Weißt Du was geschieht wenn das CONVERT über eine Tabelle laufen lasse, die bereits in UTF-8 vorliegt?
Das CONVERT hat doch einen Haken, aber deine Lösung wohl dann auch, siehe http://dev.mysql.com/doc/refman/5.1/de/alter-table.html
Es wird erst als BLOB geCHANGEd, dann wieder zurück als UTF-8. Warum verstehe ich nicht so ganz warum das gemacht wird und das CONVERT nicht geht.
Es wird erst als BLOB geCHANGEd, dann wieder zurück als UTF-8. Warum verstehe ich nicht so ganz warum das gemacht wird und das CONVERT nicht geht.
Könnte man es dann universeller so machen?
ALTER TABLE TABLENAME CONVERT TO CHARACTER SET binary;
und danach
ALTER TABLE TABLENAME CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
oder muss ich danach
ALTER TABLE TABLENAME CHANGE spalte spalte SpaltenTyp CHARACTER SET utf8 COLLATE utf8_general_ci;
machen?
Hi,
da steht aber:
Das erledigt übrigens auch Deine Frage: Was wenn in COLLATION-Spalte noch das latin1_swedish_ci steht? MySQL empfehlt es nicht.
Meine Inhalte waren aber beide im "latin1_swedish_ci", Tabelle wie auch die Spalte. Also habe ich mit:
erst einmal die Inhalte und dann sofort mit
die Tabellen konvertieren. Im Übrigen hat es bei mir je hervorragend funktioniert. Das was Du gerade liest ist UTF8 in meiner DB 
Gruß
Frank
Das CONVERT hat doch einen Haken
da steht aber:
Sie sollten dies keinesfalls tun, wenn Sie eine Spalte in einem Zeichensatz (z. B. latin1) haben, die gespeicherten Werte aber eigentlich einen anderen inkompatiblen Zeichensatz (wie utf8) verwenden.
Das erledigt übrigens auch Deine Frage: Was wenn in COLLATION-Spalte noch das latin1_swedish_ci steht? MySQL empfehlt es nicht.
Meine Inhalte waren aber beide im "latin1_swedish_ci", Tabelle wie auch die Spalte. Also habe ich mit:
ALTER TABLE `tabellen_name` CHANGE `tabellen_feld` `tabellen_feld` VARCHAR( 254 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ; ALTER TABLE `user_interest` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;Gruß
Frank
Hehe, ja scheint geklappt zu haben. Nur strebe ich immer das Universelle an
Interessant wäre ja nur ob das
ALTER TABLE t1 CHANGE c1 c1 BLOB;
... mit den ganzen Spalten der Tabelle ...
das gleiche wie das
ALTER TABLE t1 CONVERT TO CHARACTER SET binary;
auf einen Schlag wäre, denn
"Wenn Sie CONVERT TO CHARACTER SET binary angeben, werden die CHAR-, VARCHAR- und TEXT-Spalten in ihre entsprechenden binären String-Typen umgewandelt (BINARY, VARBINARY, BLOB)."
Dann könnte man ja danach deine Implementierung
ALTER TABLE t1 CHANGE c1 c1 TEXT CHARACTER SET utf8;
wieder einsetzen bzw. ein Script das ich gefunden habe, welche dieses Statement automatisiert rausgibt.
Interessant wäre ja nur ob das
ALTER TABLE t1 CHANGE c1 c1 BLOB;
... mit den ganzen Spalten der Tabelle ...
das gleiche wie das
ALTER TABLE t1 CONVERT TO CHARACTER SET binary;
auf einen Schlag wäre, denn
"Wenn Sie CONVERT TO CHARACTER SET binary angeben, werden die CHAR-, VARCHAR- und TEXT-Spalten in ihre entsprechenden binären String-Typen umgewandelt (BINARY, VARBINARY, BLOB)."
Dann könnte man ja danach deine Implementierung
ALTER TABLE t1 CHANGE c1 c1 TEXT CHARACTER SET utf8;
wieder einsetzen bzw. ein Script das ich gefunden habe, welche dieses Statement automatisiert rausgibt.
Hi,
ja, viele Wege führen nach Rom
Gruß
Frank
ja, viele Wege führen nach Rom
Gruß
Frank
So langsam verzweifle ich an meiner Konvertierungsproblematik...
Ich habe alle oben aufgeführten Schritte soweit befolgt und dennoch werden die Sonderzeichen allesamt als "?" in Firefox angezeigt bzw. im IE mit äußerst kriptischen Zeichen. Ich kann mir einfach nicht erklären, wo das Problem liegt?
Wenn ich mir die Felder in der DB anschaue, dann werden die Sonderzeichen korrekt (im Klartext, also nicht ü oder dergleichen) angezeigt.
Ein wenig zu meiner Konfig:
Aktuell habe ich eine DB im ISO Format (latin1) und möchte aus dieser einige Tabellen exportieren um sie auf meiner neuen Seite mit einer DB im UTF8-Format zu importieren. Sofern ich die Daten exportiert habe und mir die Zeichen im SQL-Dump anschaue, sieht alles wunderbar aus. Importiere ich diese jetzt aber und stelle die Galerie danach auf UTF8 werden, alle Zeichen falsch dargestellt, aber es kommt noch besser, wenn ich nun neue Einträge vornehme, werden diese diese mit äußerst kriptischen Zeichen in der DB abgelegt.
Der Knaller ist allerdings, wenn ich im Vorwege manuell alle Zeichen im SQL-Dump von "ä" zu "ä" usw. ändere, dann funktioniert alles soweit tadellos - zumindest im Frontend...
Ich hoffe Ihr könnt mir helfen.
Gruß
Smyloman
Ich habe alle oben aufgeführten Schritte soweit befolgt und dennoch werden die Sonderzeichen allesamt als "?" in Firefox angezeigt bzw. im IE mit äußerst kriptischen Zeichen. Ich kann mir einfach nicht erklären, wo das Problem liegt?
Wenn ich mir die Felder in der DB anschaue, dann werden die Sonderzeichen korrekt (im Klartext, also nicht ü oder dergleichen) angezeigt.
Ein wenig zu meiner Konfig:
Aktuell habe ich eine DB im ISO Format (latin1) und möchte aus dieser einige Tabellen exportieren um sie auf meiner neuen Seite mit einer DB im UTF8-Format zu importieren. Sofern ich die Daten exportiert habe und mir die Zeichen im SQL-Dump anschaue, sieht alles wunderbar aus. Importiere ich diese jetzt aber und stelle die Galerie danach auf UTF8 werden, alle Zeichen falsch dargestellt, aber es kommt noch besser, wenn ich nun neue Einträge vornehme, werden diese diese mit äußerst kriptischen Zeichen in der DB abgelegt.
Der Knaller ist allerdings, wenn ich im Vorwege manuell alle Zeichen im SQL-Dump von "ä" zu "ä" usw. ändere, dann funktioniert alles soweit tadellos - zumindest im Frontend...
Ich hoffe Ihr könnt mir helfen.
Gruß
Smyloman
Stelle doch mal im Firefox unter Ansicht die Zeichencodierung auf UTF-8 um. Was passiert dann bei dir?
Gruß PHANTOMIASER
Gruß PHANTOMIASER
Hallo PHANTOMIASER,
vielen Dank für Deine Rückmeldung. Ich habe mal die Std. Zeichenkodierung im Firefox von ISO auf UTF-8 geändert, das Ergebnis bleibt aber das Gleiche.
Was mir dabei auch völlig unverständlich ist, wenn ich mir die DB auf der alten Seite anschaue, dann sind dort (zumindest im Browser und beim Dump) alle Umlaute korrekt. Also ebenfalls nichts mit "ü" und das obwohl hier in der Galerie ISO eingestellt ist???
Ich weiß nicht ob es irgendwelche Relevanz hat, aber bei der von mir eingesetzten Galerie handelt es sich um die Coppermine Gallery.
Wäre klasse, wenn Du noch irgendeine Idee oder einen Tipp für mich hast. Mit der manuellen Änderung von "ä" zu "ä" funktioniert es zwar momentan, aber elegant ist etwas anderes...
Vielen Dank.
vielen Dank für Deine Rückmeldung. Ich habe mal die Std. Zeichenkodierung im Firefox von ISO auf UTF-8 geändert, das Ergebnis bleibt aber das Gleiche.
Was mir dabei auch völlig unverständlich ist, wenn ich mir die DB auf der alten Seite anschaue, dann sind dort (zumindest im Browser und beim Dump) alle Umlaute korrekt. Also ebenfalls nichts mit "ü" und das obwohl hier in der Galerie ISO eingestellt ist???
Ich weiß nicht ob es irgendwelche Relevanz hat, aber bei der von mir eingesetzten Galerie handelt es sich um die Coppermine Gallery.
Wäre klasse, wenn Du noch irgendeine Idee oder einen Tipp für mich hast. Mit der manuellen Änderung von "ä" zu "ä" funktioniert es zwar momentan, aber elegant ist etwas anderes...
Vielen Dank.
Hallo,
wichtig ist zu wissen, dass jeder Editor (auch der der die Anzeige der Datenbankinhalte macht) ein bestimmtes Textformat beherrscht. wenn also dein DB Editor UTF-( beherrscht dann zeigt er die Werte im richtigen Format an. das bedeutet Export als "Ansi" Text ->Ansicht alles Ok -> Import in DB -> Datenfelder im UTF 8 Fromat -> Ausgabe -> ?? . das ist logisch , da der Import von Ansizeichen in eine UTF tab ein anderes zeichen bewirkt (wenn es ein Umlaut ist bzw.) ein ??.
Abhilfe kann hier nur eine Transormation von Umlauten zu UTF8 zeichen schaffen.
Übrigens: wenn kryptische zeichen in deinem DB Viewer sind, dann kann der auch kein UTF8 !!!!! (Konfig prüfen)
wichtig ist zu wissen, dass jeder Editor (auch der der die Anzeige der Datenbankinhalte macht) ein bestimmtes Textformat beherrscht. wenn also dein DB Editor UTF-( beherrscht dann zeigt er die Werte im richtigen Format an. das bedeutet Export als "Ansi" Text ->Ansicht alles Ok -> Import in DB -> Datenfelder im UTF 8 Fromat -> Ausgabe -> ?? . das ist logisch , da der Import von Ansizeichen in eine UTF tab ein anderes zeichen bewirkt (wenn es ein Umlaut ist bzw.) ein ??.
Abhilfe kann hier nur eine Transormation von Umlauten zu UTF8 zeichen schaffen.
Übrigens: wenn kryptische zeichen in deinem DB Viewer sind, dann kann der auch kein UTF8 !!!!! (Konfig prüfen)
Hallo HeikoD,
ich nutze phpMyAdmin 2.11.7 und lokal Notepad++.
ich nutze phpMyAdmin 2.11.7 und lokal Notepad++.
Zitat von @HeikoD:
Übrigens: wenn kryptische zeichen in deinem DB Viewer sind, dann
kann der auch kein UTF8 !!!!! (Konfig prüfen)
Die kryptischen Zeichen erscheinen aber erst, wenn ich die DB auf der neuen Seite importiert habe und dort die Seitenconfig von ISO auf UTF-8 ändere und dann z.B. einen neuen Kommentar in der Galerie abgebe (mit Umlauten natürlich).Übrigens: wenn kryptische zeichen in deinem DB Viewer sind, dann
kann der auch kein UTF8 !!!!! (Konfig prüfen)
Hi Smyloman,
dann versuche ich mal zu helfen:
1) eine Zeichensatz Teilumstellung kann ich nicht empfehlen, die DB und die Seiten die ausgegeben werden, sollten alle UTF-8 sein (steht im Quellcode der Seiten das <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> oder hast du per php.ini default_charset = "UTF-8" drin stehen?)
Ganz oder gar nicht
2) ä ist der HTML-Code für ein "ä". Klar funktioniert der HTML-Code immer (egal welcher Zeichensatz), dass ist aber nicht das Ziel der Umstellung und hat auch nix mit UTF-8 zu tun.
3) soweit ich das noch in Erinnerung habe, erstellt ein "mysqdump" per default immer noch ISO (latin1) Ausgaben, auch dann wenn sie in UTF-8 vorliegen (hier dürft Ihr mich aber gerne korrigieren, mein Stand ist schon etwas älter). Ich würde Deine Inhalte in die neue DB im "Latin-1" Format importieren und sie dann in UTF-8 umwandeln. Wie war Deine Reihenfolge?
4) arbeitest Du mit phpmyadmin? Wenn nicht, solltest Du es mal dringend installieren. Dort siehst Du Kollation (Latin-1 oder UTF-8 etc.) zu Deinen Datenbanken bzw. Tabellen. Wenn Sie dort richtig angezeigt werden, ist von der DB-Seite schon mal alles richtig. Dann liegt es eher an der "Coppermine Gallery".
5) Wichtig bei dem DB-Connect zu der Gallery ist auch das "SET NAMES 'utf8'" (siehe oben). Ohne das "SET NAMES" wird die DB der Applikation (Coppermine Gallery) kein UTF-8 ausgeben. Das kannst Du global einstellen oder bestimmt in der Config der Gallery.
Gruß
Frank
dann versuche ich mal zu helfen:
1) eine Zeichensatz Teilumstellung kann ich nicht empfehlen, die DB und die Seiten die ausgegeben werden, sollten alle UTF-8 sein (steht im Quellcode der Seiten das <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> oder hast du per php.ini default_charset = "UTF-8" drin stehen?)
Ganz oder gar nicht
2) ä ist der HTML-Code für ein "ä". Klar funktioniert der HTML-Code immer (egal welcher Zeichensatz), dass ist aber nicht das Ziel der Umstellung und hat auch nix mit UTF-8 zu tun.
3) soweit ich das noch in Erinnerung habe, erstellt ein "mysqdump" per default immer noch ISO (latin1) Ausgaben, auch dann wenn sie in UTF-8 vorliegen (hier dürft Ihr mich aber gerne korrigieren, mein Stand ist schon etwas älter). Ich würde Deine Inhalte in die neue DB im "Latin-1" Format importieren und sie dann in UTF-8 umwandeln. Wie war Deine Reihenfolge?
4) arbeitest Du mit phpmyadmin? Wenn nicht, solltest Du es mal dringend installieren. Dort siehst Du Kollation (Latin-1 oder UTF-8 etc.) zu Deinen Datenbanken bzw. Tabellen. Wenn Sie dort richtig angezeigt werden, ist von der DB-Seite schon mal alles richtig. Dann liegt es eher an der "Coppermine Gallery".
5) Wichtig bei dem DB-Connect zu der Gallery ist auch das "SET NAMES 'utf8'" (siehe oben). Ohne das "SET NAMES" wird die DB der Applikation (Coppermine Gallery) kein UTF-8 ausgeben. Das kannst Du global einstellen oder bestimmt in der Config der Gallery.
Gruß
Frank
Hallo Frank,
auch dir erstmal vielen Dank für die Rückmeldung, ich werde die aufgeführten Punkte mal Step by Step abarbeiten... ;)
Genau das steht bei mir im Quellcode bzw. wird von der Galerie je nach Einstellung in den Quellcode geschrieben.
Der Fehler steckt bestimmt wieder im Detail und dieses scheine ich momentan einfach zu übersehen
Ich hoffe Du hast vielleich noch einen Tipp für mich?
Gruß
Smyloman
auch dir erstmal vielen Dank für die Rückmeldung, ich werde die aufgeführten Punkte mal Step by Step abarbeiten... ;)
Zitat von @Frank:
1) eine Zeichensatz Teilumstellung kann ich nicht empfehlen, die DB
und die Seiten die ausgegeben werden, sollten alle UTF-8 sein (steht
im Quellcode der Seiten das <meta
http-equiv="Content-Type" content="text/html;
charset=UTF-8"> oder hast du per php.ini default_charset =
"UTF-8" drin stehen?)
Ganz oder gar nicht
"http-equiv="Content-Type" content="text/html; charset=UTF-8"1) eine Zeichensatz Teilumstellung kann ich nicht empfehlen, die DB
und die Seiten die ausgegeben werden, sollten alle UTF-8 sein (steht
im Quellcode der Seiten das <meta
http-equiv="Content-Type" content="text/html;
charset=UTF-8"> oder hast du per php.ini default_charset =
"UTF-8" drin stehen?)
Ganz oder gar nicht
Genau das steht bei mir im Quellcode bzw. wird von der Galerie je nach Einstellung in den Quellcode geschrieben.
2) ä ist der HTML-Code für ein "ä". Klar
funktioniert der HTML-Code immer (egal welcher Zeichensatz), dass ist
aber nicht das Ziel der Umstellung und hat auch nix mit UTF-8 zu tun.
Upps, das ist jetzt peinlich, dass es sich dabei um den HTML Code handelt war mir zwar bewußt allerdings wußte ich nicht, dass dies nichts mit der Kodierung zu tun hat ...funktioniert der HTML-Code immer (egal welcher Zeichensatz), dass ist
aber nicht das Ziel der Umstellung und hat auch nix mit UTF-8 zu tun.
3) soweit ich das noch in Erinnerung habe, erstellt ein
"mysqdump" per default immer noch ISO (latin1) Ausgaben,
auch dann wenn sie in UTF-8 vorliegen (hier dürft Ihr mich aber
gerne korrigieren, mein Stand ist schon etwas älter). Ich
würde Deine Inhalte in die neue DB im "Latin-1" Format
importieren und sie dann in UTF-8 umwandeln. Wie war Deine
Reihenfolge?
Ich hatte das Dump mit phpMyAdmin 2.11.7 gezogen, dabei hatte ich beim Export extra auf UTF-8 geachtet. Ich hatte den Dump extra nicht gezippt etc. sonder als Textdoc heruntergeladen und mir dann mit Notepad++ angeschaut - alles gut! (laut Notepad++ handelt es sich um UTF-8 ohne Bom - sämtliche Zeichen werden korrekt im Klartext dargestellt, sprich "ä")"mysqdump" per default immer noch ISO (latin1) Ausgaben,
auch dann wenn sie in UTF-8 vorliegen (hier dürft Ihr mich aber
gerne korrigieren, mein Stand ist schon etwas älter). Ich
würde Deine Inhalte in die neue DB im "Latin-1" Format
importieren und sie dann in UTF-8 umwandeln. Wie war Deine
Reihenfolge?
4) arbeitest Du mit phpmyadmin? Wenn
nicht, solltest Du es mal dringend installieren. Dort siehst Du
Kollation (Latin-1 oder UTF-8 etc.) zu Deinen Datenbanken bzw.
Tabellen. Wenn Sie dort richtig angezeigt werden, ist von der DB-Seite
schon mal alles richtig. Dann liegt es eher an der "Coppermine
Gallery".
Die Kollation ist laut phpMyAdmin UTF-8, also auch korrekt.nicht, solltest Du es mal dringend installieren. Dort siehst Du
Kollation (Latin-1 oder UTF-8 etc.) zu Deinen Datenbanken bzw.
Tabellen. Wenn Sie dort richtig angezeigt werden, ist von der DB-Seite
schon mal alles richtig. Dann liegt es eher an der "Coppermine
Gallery".
5) Wichtig bei dem DB-Connect zu der Gallery ist auch das "SET
NAMES 'utf8'" (siehe oben). Ohne das "SET
NAMES" wird die DB der Applikation (Coppermine Gallery) kein
UTF-8 ausgeben. Das kannst Du global einstellen oder bestimmt in der
Config der Gallery.
Also ich habe alle Befehle oben auf die DB für jede einzelne Tabelle manuell angewendet. Aber dennoch verhält es sich wie beschrieben?NAMES 'utf8'" (siehe oben). Ohne das "SET
NAMES" wird die DB der Applikation (Coppermine Gallery) kein
UTF-8 ausgeben. Das kannst Du global einstellen oder bestimmt in der
Config der Gallery.
Der Fehler steckt bestimmt wieder im Detail und dieses scheine ich momentan einfach zu übersehen
Ich hoffe Du hast vielleich noch einen Tipp für mich?
Gruß
Smyloman
Hi Smyloman,
nochmal zu Punkt 5.
Das "SET NAMES 'utf8'" wird ja nicht auf jede einzelne Tabelle angewendet. Es wird nur einmalig bei dem DB-Connect für die PHP-Ausgabe gesetzt. PHP ist bei UTF-8 im Moment noch die größte Schwachstelle. Der normale MySQL- oder iMysql Connect von PHP gibt die Datensätze tatsächlich ohne das SET nur im Latin-1 aus. Damit jetzt auch die Webseite UTF-8 lesen kann muss man dem PHP irgendwie sagen, dass jetzt UTF-8 über den Datenbank-Connector kommen soll. Daher gibt man beim Verbinden der Datenbank mit PHP dem Connect das "SET NAMES 'utf8'" dazu. Ohne das geht es zurzeit leider nicht. Hast Du das gemacht?
Gruß
Frank
nochmal zu Punkt 5.
Also ich habe alle Befehle oben auf die DB für jede einzelne Tabelle manuell angewendet. Aber dennoch verhält es sich wie beschrieben?
Das "SET NAMES 'utf8'" wird ja nicht auf jede einzelne Tabelle angewendet. Es wird nur einmalig bei dem DB-Connect für die PHP-Ausgabe gesetzt. PHP ist bei UTF-8 im Moment noch die größte Schwachstelle. Der normale MySQL- oder iMysql Connect von PHP gibt die Datensätze tatsächlich ohne das SET nur im Latin-1 aus. Damit jetzt auch die Webseite UTF-8 lesen kann muss man dem PHP irgendwie sagen, dass jetzt UTF-8 über den Datenbank-Connector kommen soll. Daher gibt man beim Verbinden der Datenbank mit PHP dem Connect das "SET NAMES 'utf8'" dazu. Ohne das geht es zurzeit leider nicht. Hast Du das gemacht?
Gruß
Frank
Hallo,
ich stehe vor dem selben Problem. Meine DB und die Tabellen sind latin1_swedish_ci. Ich hatte zurerst mit mysqldump und der Sprachangabe latin1 einen Dump gezogen. Dort konnte ich auch die Umlaute finden, als ich dann mit recode oder, wie oben beschrieben, mit iconv die DB zu UTF-8 konvertiert hatte fehlten alle Umlaute. Ich habe den Text zwar verfolgt, aber so klar ist mir das jetzt nicht. Kann ich mittels mysqldump und einem recoder die DB umwandeln, oder muss ich das so wie von dir beschrieben direkt auf der DB machen? Ich würde den Dump umwandeln und dann die DB neu erstellen.
ich stehe vor dem selben Problem. Meine DB und die Tabellen sind latin1_swedish_ci. Ich hatte zurerst mit mysqldump und der Sprachangabe latin1 einen Dump gezogen. Dort konnte ich auch die Umlaute finden, als ich dann mit recode oder, wie oben beschrieben, mit iconv die DB zu UTF-8 konvertiert hatte fehlten alle Umlaute. Ich habe den Text zwar verfolgt, aber so klar ist mir das jetzt nicht. Kann ich mittels mysqldump und einem recoder die DB umwandeln, oder muss ich das so wie von dir beschrieben direkt auf der DB machen? Ich würde den Dump umwandeln und dann die DB neu erstellen.
