Da ich grade eben selbst ein paar Probleme bei der Konvertierung einer Webanwendung von ISO-8859-1 auf UTF-8 hatte, hab ich mir gedacht, ich stell meine Erfahrungen mal dar und erläutere meinen Lösungsansatz.
Ausgangssituation ist eine dynamische Website, deren (X)HTML und Datenbankinhalte mit ISO-8859-1 kodiert sind – wir wollen, dass das Ganze möglichst unkompliziert und schnell UTF-8 fähig wird, ich hab es folgendermaßen gemacht:
- Backup-Dump der Datenbank ziehen (selbstverständlich…)
- Die Kollation der Datenbank und der einzelnen Tabellen auf
utf8_unicode_cisetzen - Die betroffenen Datenbank-Inhalte (Textfelder) in UTF-8 konvertieren (siehe Converter Script)
- Die (X)HTML-Dateien UTF-8-kodiert speichern
- Die Ausgabe im Frontend auf UTF-8 umstellen – entweder per PHP-Header oder Meta-Tag
Converter Script
Für die eigentliche Arbeit des Konvertierens der DB-Inhalte hab ich ein kleines Script geschrieben, welches ich hier auch zur Verfügung stellen wollte: DB Convert.
Das Script ist eher quick and dirty und braucht eine SQL-Klasse die ich immer für MySQL-Datenbankzugriffe benutze (ist beigelegt) – falls Fragen dazu sind, postet diese bitte in den Kommentaren, falls Bedarf sein sollte, kann ich das Script auch noch ein wenig mehr dokumentieren.
Probleme mit phpMyAdmin
Anfängliche Verständnisschwierigkeiten hat mir phpMyAdmin bereitet. Dort werden scheinbar – obwohl die Zeichenkodierung UTF-8 ist – die konvertierten Zeichen (bspw. Umlaute) sehr wirr angezeigt, die letztendliche Ausgabe auf der Seite stimmt dann allerdings und ist UTF-8. Falls jemand sachdienliche Hinweise dazu hat, postet es bitte in den Kommentaren.
Edit: Ich hab grade noch einen Artikel von O’Reilly zu diesem Thema gefunden.
6. September 2006 um 13:29
Uwe Klawitter schreibt:
Hi,
wie genau führt man das Update-Script aus? Wo werden die Werte für die Datenbankverbindung eingegeben?
Gruß
Uwe
6. September 2006 um 13:40
Dennis schreibt:
Hallo Uwe, das läuft folgendermaßen:
In Zeile 31 der db_convert.php die vier Konstanten (DB_HOST, …) mit den Werten für deine MySQL-DB ersetzen und anschließend die Dateien auf deinen Server kopieren.
Dann rufst du einfach die db_convert.php auf – vorher bitte die Schritte 1 (auf keinen Fall das Backup vergessen!) und 2 wie oben beschrieben ausführen – sollte alles so klappen.
8. September 2006 um 12:01
robi schreibt:
There is another solution, I’ve tested it for my blog, so easy and it takes only a few minutes. Check this (in french, sorry):
http://weblogger.ch/blog/archives/2006/09/07/passage-a-utf-8/
You need an ssh account and the iconv library, and that’s it!
11. Oktober 2006 um 21:50
Thorsten schreibt:
Hallo,
Ihr Script scheint richtig gut bei uns zu funktionieren. Allerdings bricht es nach einiger Zeit mit einer Fehlermeldung ab: Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 48 bytes) in ……./class.sql_link.php on line 30
Wir haben eine MySQL-Datenbank mit über 100 Tabellen und mit insgesamt über 40 Mio. Datensätzen!!! Wo liegt der Fehler in Ihrem Script?
Können Sie uns weiterhelfen?
12. Oktober 2006 um 10:38
Dennis schreibt:
Hallo Thorsten,
der Fehler ist nicht durch das Script bedingt, sondern in den PHP-Einstellungen. Das Problem ist, dass PHP den ihm zur Verfügung stehenden Speicher komplett belegt hat (bei der grossen Datenbank kein Wunder
) und dann abbrechen muss, weil kein weiterer Speicher mehr da ist.
Ich weiss nicht genau, wie die Variable heisst, die in der php.ini (auf eurem Server) angepasst werden muss – ich meine allowed_memory_… oder ähnliches. Diese Variable müsstet ihr temporär erhöhen, damit das Script vollständig durchlaufen kann.
Hoffe diese Antwort hilft soweit
13. Oktober 2006 um 00:12
Thorsten schreibt:
Hallo Dennis,
nunja, das hatte ich auch schon probiert: auf 2 GB gesetzt aber selbst da bricht das Script auch ab. An der gleichen Stelle, als wenn ich nur 1 GB in PHP zulassen. Sehr seltsam. Aber vielleicht kann ich mir dein Script als Anreiz nehmen um ein eigenen zu schreiben. Ansonsten: kann ich 2 Tabellen von der Umwandlung ausschließen in deinem Script? Diese sind zwar UTF-8 Felder, enthalten aber nur A-Z und 0-9 Zeichen – die nicht umgewandelt werden müssen. Diese beiden Tabellen beinhalten den Hauptbestand der Datenbank.
Für nen Tipp wäre ich dankbar.
lg
Thorsten
13. Oktober 2006 um 16:27
Dennis schreibt:
Hey Thorsten, die betroffene Tabelle könntest du durch eine Abfrage des Namens oder ähnliches aus der Schleife ausschliessen… bin grad im Urlaub, nächste Woche aber wieder da, dann könnte ich dir da genauer weiterhelfen.
27. Oktober 2006 um 14:10
Anonymous schreibt:
hallo.
sehr interessanter bog.
weiter so!
28. November 2006 um 15:33
Konvertieren einer TYPO3-Installation nach UTF-8 » Stefan Macke schreibt:
[...] Abhilfe schuf ein kleines Script, das sämtliche Datenbankinhalte in UTF-8 konvertiert, indem es diese ausliest und mittels utf8_ecnode() in PHP konvertiert. Das Script habe ich auf dopefreshtight.de entdeckt: Von ISO-8859-1 zu UTF8. [...]
28. November 2006 um 15:44
Stefan Macke schreibt:
Moin!
Das Script hat mir sehr weitergeholfen bei der Umstellung einer TYPO3-Installation auf UTF-8. Musste es aber ein wenig anpassen (hatte u.a. auch das Speicherproblem, das Thorsten erwähnt). Ich habe das angepasste Script einfach mal veröffentlicht (siehe Trackback). Ich hoffe das ist in Ordnung (habe deine Seite natürlich im Quelltext erwähnt
)
13. Dezember 2006 um 14:54
fob marketing schreibt:
WordPress PDF-Plugins und UTF-8…
Kurznotiz: Für ein englisch sprachiges Projekt schraube ich gerade an einem neuen WordPress-System herum. Für die Integration von PDF-Funktionalitäten bieten sich momentan 2 Plugins an:
Das WordPress (PDF) Plugin von Contutto (ContuttoPDF) sowie
da…
16. Dezember 2006 um 16:38
daNny schreibt:
Also ich habe auch das Problem, dass phpMyAdmin die Zeichen nicht richtig anzeigt, obwohl sie richtig in der Datenbank stehen. Ne Abfrage über die Konsole zumindest zeigt alles richtig bei mir an.
Wenn ich allerdings nen Datensatz mit umlauten in phpMyAdmin anlege, dann ist es nicht mehr richtig. Noch keiner ne Lösung gefunden?
Trotzdem danke für dein Script! Echt super
9. Januar 2007 um 19:52
OldDragon schreibt:
Bin auch grad dabei, meine DB auf UTF-8 umzustellen. Klappt zwar noch nicht alles perfekt, aber solche Tips sind immer hilfreich. Hab meine Testumgebung zwar schon umgestellt, aber für die Online-Version werd ich wohl dein Script verwenden…
24. Januar 2007 um 20:52
Einige Fragen zu UTF-8 - Seite 2 - XHTMLforum schreibt:
[...] Zitat von netspy Mit deinen Einstellungen macht er das. Nein. Habe recherchiert. PhpMyAdmin kann nunmal keine UTF-8 sachen richtig darstellen. Das ist ein bekannter Bug. Habe sogar vorhin die neuste Version von PMA aufgespielt, aber auch dann keine veränderung. Siehe hier weiter unten: //dopefreshtightblog » Von ISO-8859-1 zu UTF-8 in PHP und MySQL MfG Zen [...]
10. Februar 2007 um 00:22
Feechen schreibt:
Ich habe die 4 Konstanten mit den Werten meiner DB-Tabelle ersetzt (ohne Anführungszeichen, etc.). Beim Aufruf des Scriptes bekomme ich immer folgende Meldung:
Parse error: parse error, unexpected T_STRING in /kunden/psygrenz.de/webseiten/pg/db_convert.php on line 31
Was ist hier falsch?
MfG
Feechen
10. Februar 2007 um 08:26
Dennis schreibt:
Hey, du musst die Konstanten durch Strings (mit Anführungszeichen!) ersetzen… beispielsweise so:
Viel Erfolg
10. Februar 2007 um 11:44
Feechen schreibt:
Hallo Dennis,
habe ich schon ausprobiert. Dann kommt folgende Fehlermeldung:
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /kunden/psygrenz.de/webseiten/pg/class.SQL_link.php on line 30
Kann es mit dem Host zusammenhängen? Der ist bei mir nämlich nicht “localhost”.
MfG
Feechen
10. Februar 2007 um 12:03
Dennis schreibt:
Ja, das kann durchaus sein
Du musst da natürlich die Daten eintragen, mit denen das PHP-Script zu deiner Datenbank verbinden kann.
27. Februar 2007 um 22:40
Daniel schreibt:
Hallo Dennis, wie kann ich das Skript verwenden, wenn meine Datenbank nicht localhost ist? Ich bekomme auch immer den Zeile-30-Fehler. Was muß in der class… angepaßt werden? Zeile 4? Wie soll die dann aussehen? Viele Grüße und vielen Dank.
27. Februar 2007 um 23:43
Dennis schreibt:
Hallo Daniel, siehe hier – einfach statt “localhost” als ersten Parameter die Adresse deiner Datenbank angeben. In der Class-Datei musst du gar nichts anpassen.
2. März 2007 um 19:03
Daniel schreibt:
Hallo Dennis, danke für die Hilfe, aber es hat nicht geklappt. Ich lasse besser die Finger. Trotz eingetragener Verbindung bricht das Skript irgendwann mit Hinwweis auf die class.php und Zeile 30 ab. Ein Teil wurde dann konvertiert und ein Teil nicht. Vielleicht liegt es an dem seltsamen Server
6. März 2007 um 18:23
Harald schreibt:
Der Hinweis:
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result
ist eben nur ein Hinweis, der auftaucht wenn PHP besonders rückmeldungsfreudig konfiguriert ist. Ist aber kein grundsätzliches Problem.
Der Grund warum aber bei einigen (so auch bei mir) nicht alle Felder konvertiert wurden bzw. werden ist folgende Skriptzeile (Zeile 49):
if(strpos($column['Type'], “char”) != false || strpos($column['Type'], “text”) != false)
Wenn man diese durch folgende ersetzt läuft alles ganz problemlos:
if(strpos( ! $column['Type'], “char”) === false || ! strpos($column['Type'], “text”) === false)
Bei Verwendung der obigen Zeile wurden bei mir nur Felder vom Typ “varchar” konvertiert, nicht allerdings Felder vom Typ “char” und “text”. Tauscht man obige mit untiger Zeile aus, dann werden Felder vom Typ “char”, “varchar” und “text” konvertiert.
lg,
Harald
7. März 2007 um 11:30
Dennis schreibt:
Hallo Harald, vielen Dank für den Patch, ich habe es korrigiert und in der aktuellen Version online gestellt. Sehr gut
15. März 2007 um 10:39
hellbringer schreibt:
PhpMyAdmin kann sehr wohl UTF-8 Daten korrekt darstellen. Habe diesbezüglich noch nie Probleme gehabt.
15. März 2007 um 11:33
Dennis schreibt:
Hey, gut dass du es ansprichst, das hängt wohl irgendwie hiermit zusammen… das Problem tritt daher auch nicht bei allen auf.
15. März 2007 um 21:20
Göks schreibt:
Hi,
habe das selbe Problem mit phpMyAdmin. Hast du das Irgendwie in den Griff bekommen? Des regt total uff … so unnötig …^^
Grüsse
Göks
16. März 2007 um 08:59
Göks schreibt:
Hallo,
ich habe das Problem nun folgendermaßen gelöst.
In der Datenbankschicht meiner Anwendung sieht der Verbindungsaufbau nun folgenderweise aus.
$this->con_id = @mysql_connect($this->host, $this->user, $this->password);
mysql_query(“SET NAMES utf8″);
mysql_query(‘SET CHARACTER SET utf8′);
@mysql_select_db($this->database, $this->con_id);
Ich erhalte nun im phpMyAdmin, in meiner Anwendung und auf der Konsole mittels mysql-Client nach der Ausführung der beiden utf8 Queries ebenfalls die richtigen Umlaute.
Hoffe das hilft.
Grüsse
Göks
16. März 2007 um 14:41
Dennis schreibt:
Hey, danke auch für die Hinweise, das Problem und die Lösung sind auch hier noch genauer beschrieben.
23. März 2007 um 15:13
Harald schreibt:
Ach ja, was mir noch am Converter-Script aufgefallen ist:
Ein Feld in dem einen einfaches Anführungszeichen vorkommt wird nicht konvertiert. Ich hab das jetzt manuell nachgeholt (ist nicht so oft vorgekommen), aber im Grunde könnte man das im Script nochmal korrigieren, z.B. indem man die SQL-Anweisung mit “addslashes” in dieser Hinsicht sicher macht.
lg,
Harald
26. April 2007 um 19:09
Anonymous schreibt:
Big Kisses,
das
mysql_query(“SET NAMES utf8″);
mysql_query(’SET CHARACTER SET utf8′);
hat mir sehr geholfen. Ich war der Meinung, alles richtig zu machen (Alle Tabellen auf UTF8 gestellt, das gesammte Script in UTF8 mit entsprechenden Headern), die Header wurden auch von den Browsern richtig interpretiert. Nur im PMA sahs “oll” aus. Vielen Dank auch für den Link zum Mysqldumper, bessergesagt zu der Erklärung, sehr aufschlussreich!
25. Juni 2007 um 12:38
Michael schreibt:
Hi, ich habe da eine Frage zu deinen vielversprechend klingendem Script, die Punkte 1. und 2. suggerieren das ich nur die Datenbank und die Tabellen Kollationen umstellen muss, da steht nichts davon dass ich auch die Spalten Kollationen in den Tabellen selber umstellen muss? Muss ich es tun oder nicht?
25. Juni 2007 um 13:07
Michael schreibt:
Hi, ich bin es nochmal, tut mir leid das ich zweimal hintereinander schreibe (die beiden Kommentare könnten gernen zusammengefügt werden)
Ich habe das Script entsprechend konfiguriert und ausgeführt und nun erhalte ich diesen Fehler knapp 20-30 mal hintereinander:
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /WWWROOT/1647/htdocs/admin/class.sql_link.php on line 30
woran kann das liegen. Die Zugangsdaten sind ok ich benutze sie genau so auch für meine Datenbankscripte.
25. Juni 2007 um 13:32
Dennis schreibt:
Hey Michael, die Kollation der Spalten sollte auch angepasst werden. Zu dem anderen Problem kann ich schlecht was sagen, irgendwas scheint bei der Abfrage der Tabellen nicht richtig zu laufen… steht da eine Zeilennummer bzgl. des Fehlers in der db_covert.php?
25. Juni 2007 um 13:43
Michael schreibt:
Nein da steht nur diese Fehlerzeile, von einem Fehler in der db_convert.php steht nichts.
25. Juli 2007 um 15:07
Michael Lambertz schreibt:
Ich habe jetzt seit einigen Stunden versucht, mit diesem Skript, meine Typo3 Datenbank auf utf-8 umzustellen. Das Problem ist, dass typo3 das, was im Skript als id bezeichnet ist (die erste spalte) einmal “uid” nennt, ein anderes mal “ses_id” (bei be_sessions) oder sonstwie. daher klappt das skript für typo3 (Version 4.x) leider nicht. Wenn ich ne Änderung habe, poste ich sie.
25. Juli 2007 um 15:56
Michael Lambertz schreibt:
Habe das Skript gefunden, das auf typo3 angepasst wurde. Link: http://blog.stefan-macke.de/2006/11/28/konvertieren-einer-typo3-installation-nach-utf-8/
17. September 2007 um 23:39
Slowking schreibt:
Hi,
könntest du dieses Script vielleicht auch nocheinmal in die andere Richtung schreiben? Wir haben gerade das Problem, dass wir eine UTF-8 DB haben, der neue server dies aber nicht unterstützt, weswegen wir sie zu ISO-8859-1 konvertieren müssen.
Das würde uns extrem weite rhelfen!
18. September 2007 um 08:52
Dennis schreibt:
Wenn ich euch dafür eine Rechnung schreiben kann…
Ihr könnt ja das bestehnde Script nehmen und es selbst umschreiben.
Schönen Gruß,
Dennis
18. September 2007 um 12:57
Russische/kyrillische Inhalte in Typo3 - UTF-8, Schriftzeichen, Typo3, Erweiterung, Hinweis, Extension, Umlaute, Schritt, FragezeichenKästchen, Zeichencodierung, Dies, ISO-8859-1 - typo3.schloebe.de schreibt:
[...] Von ISO-8859-1 zu UTF-8 in PHP und MySQL [...]
18. Oktober 2007 um 10:54
Thami schreibt:
Hallo,
ich habe den Grund für die Meldung
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /kunden/psygrenz.de/webseiten/pg/class.SQL_link.php on line 30
aufgespürt. Die Tabellen bei denen diese Warnung auftritt werden nicht konvertiert.
In Zeile 63 der db_convert.php steht folgende Abfrage
$rows = $sql->query_array(“SELECT id” . $load . ” FROM ” . $table[0]);
Wenn die Tabelle aber keine Spalte id hat kracht es.
Habe nun alle Tabellen noch mit einer Spalte id versehen, nun geht es wunderbar.
18. Dezember 2007 um 04:58
Marc Gutt schreibt:
Hallo!
Ich habe auch das Problem in phpmyadmin.
Erstmal sollte man checken, ob alle Kollationen in mysql Stimmen per:
SHOW VARIABLES LIKE ‘character_set%’
Damit gibts ne Liste der eingestellten Zeichensätze, die alle dann utf8 sein sollten, wenn man in Zukunft nur utf8 einsetzen will.
Übrigens gibt es trotzdem ein Problem, wenn man ein Backup macht. Denn die falsch dargestellten Zeichen in phpmyadmin werden noch mals in UTF8 abgespeichert, so dass man ein ziemlich korruptes Backup erhält (mysql4 bei mir).
Z.B. wird aus einem ü in UTF8, wenn man es sich in ISO anschaut ein ü das wiederrum wird beim Backup zu ü, also doppelt UTF8 codiert, was ziemlicher Unsinn sein dürfte, wenn ich das richtig verstehe.
Ich schaue mal, ob mir das Script von Dir weiter hilft. Ich melde mich dann noch mal, wenn ich beide Probleme (Konvertierung und phpmyadmin) gelöst bekommen habe.
Gruß
18. Dezember 2007 um 06:34
Marc Gutt schreibt:
Also ging schneller als ich dachte.
Zum Glück musste ich das Backup nicht nutzen, weil ich mir echt nicht sicher bin, ob das noch hätte importiert werden können, aber egal.
Ich habe die drei Funktionen in die db_convert.php eingebaut:
http://www.phpbb-de.com/utf-8-sonderzeichen-ersetzen-wird-im-ie-zum-kaestchen-t736.html
Und dann dein “output” unten bei “Aenderungen durchfuehren” gegen “utf8_to_html” ersetzt.
Sinn dieser Funktionen ist einfach, dass die UTF-8 Zeichen gegen ihre äquivalenten HTML-Codierungen getauscht werden. Man muss nur eben seine Scripte insofern erweiteren, dass diese vor Eintragung in die Datenbank ebenfalls durch die Funktion gejagd werden.
Dann kann man bei Bedarf auch locker nervige Sonderzeichen mit preg_replace() oder str_replace() an Hand ihrer HTML-Codierung gegen “normale” ersetzen und so bestimmte UTF8-Zeichen ausmerzen. Es gibt nämlich so einige, die der IE6 nicht darstellt. Wobei das in der Zukunft mit den neuen Browsern immer weniger zum Problem führen wird.
Gruß
Marc
18. Dezember 2007 um 12:04
Dennis schreibt:
Die Kollation hat nichts damit zu tun, ob die Daten als UTF-8 oder wie auch immer in der Kollation angegeben gespeichert werden. Die Kollation bezieht sich auf Funktonen wie Sortierreihenfolge, hat aber KEINEN Einfluß darauf, wie eingehende Daten gespeichert werden. Wenn ihr Die Daten als UTF-8 in der DB haben wollte, dann müssen sie aus PHP (oder wie auch immer) als UTF-8 an die DB gesendet werden.
19. Januar 2008 um 17:42
paul schreibt:
yeah
vielen dank
das convert skript hat mir gerade meinen abend gerettet
ich schreib sosnt nie blog kommentare, aber ich bin grad so froh das ich endlich umlaute seh
danke
12. März 2008 um 01:28
Media Addicted schreibt:
Hallo,
ich versuche schon eine Weile, dein Skript zum Laufen zu bekommen, leider ohne Erfolg.
Ich habe in der db_covert.php in Zeile 33 (nicht 31) alle Daten in echten Anführungszeichen eingetragen (“angabe”). Wenn ich das Skript dann aufrufe, will er die PHP-Datei runterladen.
Was ist mit der class.sql_link.php? Muss man da in Zeile 6-9 nicht auch etwas eintragen?
Danke für einen Tipp!
12. März 2008 um 08:04
Dennis schreibt:
Hey, wenn er das Script zum Download anbietet kann das zwei Gründe haben: Entweder dein Server intepretiert kein PHP (PHP installiert? Webserver korrekt konfiguriert?) oder die Rechte der Datei sind nicht richtig gesetzt.
Hoffe das hilft,
Dennis
17. März 2008 um 19:40
Media Addicted schreibt:
Hi,
hat leider bislang immer noch nicht funktioniert. Rechte beider Dateien und des Ordners sind “777″ und der Webserver liefert andere PHP-Seiten ja korrekt aus (ein Verzeichnis höher zum Beispiel). Im Root dasselbe Spiel. Gibts da sonst noch irgendwelche Tricks?!
26. März 2008 um 15:37
SL schreibt:
Hallo Dennis,
ich habe das gleiche Problem wie Media Addicted. Kann es weitere Gründe haben, warum ein Download-Dialog geöffnet wird?
Viele Grüße
Samuel
26. März 2008 um 15:40
Dennis schreibt:
Ich meine nicht…
1. Juni 2008 um 00:11
tuxor schreibt:
Hallo,
ich habe meine Webseite jetzt auch gerade mithilfe des Scripts umschreiben wollen und traf auf die Komplikationen, die dadurch ausgelöst werden, dass in dem Script standardmäßig nicht
mysql_query(“SET NAMES utf8″);
mysql_query(’SET CHARACTER SET utf8′);
ausgeführt wird. Namentlich handelt es sich dabei um die Ursache für das bei “Probleme mit phpMyAdmin” beschriebene Phänomen.
Technischer Hintergrund: Das PHP-Script schickt der MySQL-DB etwas – diese denkt, es handle sich um latin1-codiertes (warum auch immer), und schreibt es als solches in die Tabelle. Wenn die DB die Informationen als UTF-8 wieder herausrücken soll – das macht sie NUR mit “set names utf8″ – dann kommt das heraus, was eben diese “Probleme mit phpMyAdmin” darstellt.
Ganz genau durchschaue ich das auch nicht, aber definitiv weiß ohne “set names utf8″ hier weder php noch mysql was es da überhaupt für Zeichen empfängt.
Vielen Dank übrigens für dieses super Tutorial!
24. Juni 2008 um 11:21
basti schreibt:
Hi,
das Script funzt super, allerdings werden Spiegelstriche (die langen aus Word) und Hochkommas teilweise nicht umgewandelt.
Lässt sich da noch was nachjustieren?
5. Oktober 2008 um 23:41
Thomas schreibt:
Hallo,
vielleicht sollte man einmal, zum besseren Verständnis sagen, dass das Script ein Feld als Primärschlüssel mit dem Namen “id” verlangt. Wenn das Feld mit dem Primärschlüssel einen anderen Namen hat, kommt es eben auch zu diesem hier oft genannten Fehler in Zeile 30 der Klasse (da das Feld id des select nicht existiert).
Für meinen Fall habe ich dann einmal das Feld “id” im select entfernt und den Update ganz pragmatisch mit unterschiedlichen if’s angepasst.
Ein Script, das die Datenbank, die Tabellen und die Tabellenfelder umsetzt, findet man hier: http://serversupportforum.de/forum/sql/9279-kollation-von-tabellen-ndern.html
Ciao Thomas
1. Februar 2009 um 10:20
Moni schreibt:
hey, du hast mir mit dem script sehr geholfen, dankeschön!
mfg
Monika
28. Februar 2009 um 21:30
Valkum schreibt:
Ich bekomme immer einen Speicherzugriffsfehler wenn ich das script mit ein paar änderungen über die shell ausführe. Im Browser nur ein Weißes Fenster.
Bitte um hilfe.
Ich habe unter der Variable $coloumns nur
$idname = “`” . $columns[0][0] . “`”;
hinzugefügt und die variable als id ersatz eingesetzt um eine dynamische auswahl des 1. feldes zu gewährleisten.
28. Februar 2009 um 21:47
Valkum schreibt:
P.s. Das ganze nutze ich um eine Joomla 1.0.x Installation ganz nach utf8 zu konvertieren. Dort sind bereits 550 Datensätze in der content table.
Die tabelle soll angeblich 1,611,0 KiB Groß sein.
der Speicherzugriffsfehler kommt wenn er die foreach($rows as $row) schleife ausführt bei der tabelle.
Liegt es daran, dass es zu viele Daten für ihn sind?
Kann man es so optimieren das er es einliest dann sofort updaten ud dann zum nächsten datansatz geht? Dann würde doch glaub ich kein Speicherzugriffsfehler kommen.
Ich bin Ratlos ???
23. November 2009 um 12:59
Michael schreibt:
Hallo Dennis,
dein script ist echt super und hat mir geholfen. Ich war echt schon am verzweifeln. Supersache.
Die Zugangsdaten waren bei mir allerdings in zeile 33 bei der Benutzung vom PHPDesigner2007 Personal.
Man musste die Zugangsdaten auch in anführungszeichen setzen…
Echt Klasse Script und nochmals vielen Dank an dich
Gruß Michael
3. März 2010 um 16:38
Felix Nagel schreibt:
Hallo,
ich habe dein script noch leicht angepasst und bei einem unserer Projekte genutzt. Dabei haben sich einige Fragen aufgeworfen. Kann es sein das der Test auf UTF8 in is_utf8 nur bedingt nützlich ist?
Ich habe das Gefühl das man dieses Script nur einsetzen kann wenn die gesamte Datenbank definitiv anders als utf8 codiert ist. Falls einige Daten bereits in utf8 sind, kommt es zu Fehlern.
Ist das korrekt?
Grüße Felix
4. März 2010 um 08:36
Dennis schreibt:
Hey Felix,
tut mir leid, ich habe das Script ewig nicht mehr benutzt und angeguckt – es kann durchaus sein, dass es nicht in jedem Fall funktioniert.
Schönen Gruß,
Dennis
8. März 2010 um 23:28
Felix Nagel schreibt:
Hey Dennis,
schade, Dennis Blöcke hat mir das fast gleiche geantwortet. Dann lass ich das mal so da stehen, vielleicht dient es jemandem als Warnung.
Was nutzt du mittlerweile wenn du eine Installation umkodieren musst, oder konntest du dem die letzte Zeit entgehen?
Grüße
Felix
9. März 2010 um 07:17
Dennis schreibt:
Hey Felix,
mittlerweile habe ich das Problem nicht mehr, da ich immer gleich mit UTF-8 Kodierung starte…
Schönen Gruß,
Dennis
9. April 2010 um 16:37
Lothar schreibt:
Danke für die Anleitung und das Konverter-Script. Hat mir gerade eine Menge Zeit erspart!
18. Mai 2010 um 09:10
Benjamin Neu schreibt:
Vielen Dank für das Skript Dennis
Würde oben in der Beschreibung wirklich noch aufnehmen, dass die Tabellen eine “id” haben müssen. Ich habs relativ schnell gesehen aber andere scheinen es ja laut Kommentaren nicht ganz so schnell bemerkt zu haben.