Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

Umstellen der MySQL und PHP von ISO (latin1) auf UTF8 (utf8 general ci)

Anleitung Entwicklung Datenbanken

Mitglied: Frank

Frank (Level 5) - Jetzt verbinden

08.03.2007, aktualisiert 07.08.2008, 65275 Aufrufe, 21 Kommentare

@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:
01.
[mysqld] 
02.
character-set-server        = utf8 
03.
default-character-set       = utf8 
04.
....
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)
01.
ALTER DATABASE `datenbank_name` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
Danach die einzelnen Tabellen:
01.
ALTER TABLE `tabellen_name` CHANGE `tabellen_feld` `tabellen_feld` VARCHAR( 254 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ; 
02.
ALTER TABLE `tabellen_name2` CHANGE `tabellen_feld2` `tabellen_feld2` VARCHAR( 254 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ; 
03.
etc., etc. 
Nicht die Defaults Sets der Tabellen vergessen:
01.
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:
01.
ALTER TABLE `tabellen_name` ADD INDEX `index_name` ( `feld_1` , `feld_2` ( 10 ) , `feld_3` ( 20 ) ) ;
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:
01.
<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:
01.
default_mimetype = "text/html" 
02.
default_charset = "UTF-8"
So das war es. Für Ergänzungen bin ich natürlich dankbar.

Gruß
Frank
Webmaster
Mitglied: Dani
24.03.2007 um 22:20 Uhr
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
Bitte warten ..
Mitglied: Frank
26.03.2007 um 11:02 Uhr
Hallo Dani,

du findest die Klasse unter:
http://bug.administrator.de/view.php?id=101



Gruß
Frank
Bitte warten ..
Mitglied: Dani
26.03.2007 um 11:42 Uhr
Hi Frank,
ok....wunderbar!!! Werde ich mich mir mal reinziehen!


Grüße
Dani
Bitte warten ..
Mitglied: HeikoD
23.04.2008 um 20:39 Uhr
mysql_query("SET NAMES utf8",$ConnectionHandle);
hattest du ja schon geschrieben , aber an dieser Zeile habe ich eine ganze Weile gekaut . Also nicht vergessen
Bitte warten ..
Mitglied: PHANTOMIASER
07.08.2008 um 16:46 Uhr
Hallo!

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 ;

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
Bitte warten ..
Mitglied: Frank
07.08.2008 um 17:04 Uhr
Hi,

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
Bitte warten ..
Mitglied: PHANTOMIASER
07.08.2008 um 17:17 Uhr
Danke für die schnelle Antwort!

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.
Bitte warten ..
Mitglied: Frank
07.08.2008 um 17:27 Uhr
Wie kriege ich denn solche gelben Textblöcke hin? Dachte es reicht ein > zu schreiben?

ja aber mit Leerzeichen dahinter. Schau mal unter: http://www.administrator.de/index.php?faq=20

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?


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:
01.
ALTER TABLE  `tabellenname` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci
nachträglich ändern.

Gruß
Frank
Bitte warten ..
Mitglied: PHANTOMIASER
07.08.2008 um 17:36 Uhr
Jetzt habe ich wohl zu spät das editiert und du hast meinen Zusatz nicht mehr gelesen:
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.

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?
Bitte warten ..
Mitglied: Frank
07.08.2008 um 17:43 Uhr
Hi,

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:
01.
 ALTER TABLE `tabellen_name` CHANGE `tabellen_feld` `tabellen_feld` VARCHAR( 254 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ; 
erst einmal die Inhalte und dann sofort mit
01.
 ALTER TABLE `user_interest`  DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
die Tabellen konvertieren. Im Übrigen hat es bei mir je hervorragend funktioniert. Das was Du gerade liest ist UTF8 in meiner DB

Gruß
Frank
Bitte warten ..
Mitglied: PHANTOMIASER
07.08.2008 um 17:48 Uhr
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.
Bitte warten ..
Mitglied: Frank
07.08.2008 um 17:53 Uhr
Hi,

ja, viele Wege führen nach Rom

Gruß
Frank
Bitte warten ..
Mitglied: Smyloman
03.05.2009 um 17:45 Uhr
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 &uuml; 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 "&auml;" usw. ändere, dann funktioniert alles soweit tadellos - zumindest im Frontend...

Ich hoffe Ihr könnt mir helfen.

Gruß
Smyloman
Bitte warten ..
Mitglied: PHANTOMIASER
03.05.2009 um 18:00 Uhr
Stelle doch mal im Firefox unter Ansicht die Zeichencodierung auf UTF-8 um. Was passiert dann bei dir?

Gruß PHANTOMIASER
Bitte warten ..
Mitglied: Smyloman
04.05.2009 um 21:01 Uhr
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 "&uuml;" 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 "&auml;" funktioniert es zwar momentan, aber elegant ist etwas anderes...

Vielen Dank.
Bitte warten ..
Mitglied: HeikoD
04.05.2009 um 21:20 Uhr
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)
Bitte warten ..
Mitglied: Smyloman
04.05.2009 um 21:38 Uhr
Hallo HeikoD,

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).
Bitte warten ..
Mitglied: Frank
06.05.2009 um 17:17 Uhr
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) &auml; 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
Bitte warten ..
Mitglied: Smyloman
06.05.2009 um 21:04 Uhr
Hallo Frank,

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"
Genau das steht bei mir im Quellcode bzw. wird von der Galerie je nach Einstellung in den Quellcode geschrieben.


2) &auml; 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 ...

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 "ä")

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.

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?

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
Bitte warten ..
Mitglied: Frank
07.05.2009 um 11:48 Uhr
Hi Smyloman,

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
Bitte warten ..
Mitglied: sunghost
22.10.2009 um 15:29 Uhr
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.
Bitte warten ..
Neuester Wissensbeitrag
Internet

Unbemerkt - Telekom Netzumschaltung! - BNG - Broadband Network Gateway

(3)

Erfahrungsbericht von ashnod zum Thema Internet ...

Ähnliche Inhalte
PHP
PHP MySQL Login (7)

Frage von Yanmai zum Thema PHP ...

PHP
MySQL-Abfrage mit php: Wert + true bzw. false (2)

Frage von tomolpi zum Thema PHP ...

Datenbanken
gelöst Eine Art Access, nur mit PHP und MySQL? (14)

Frage von McLion zum Thema Datenbanken ...

Heiß diskutierte Inhalte
Switche und Hubs
Trunk für 2xCisco Switch. Wo liegt der Fehler? (17)

Frage von JayyyH zum Thema Switche und Hubs ...

Windows Server
Outlook Verbindungsversuch mit Exchange (15)

Frage von xbast1x zum Thema Windows Server ...

DSL, VDSL
DSL-Signal bewerten (14)

Frage von SarekHL zum Thema DSL, VDSL ...