verzwicktes umlaut-problem nach server-umzug, (buggy mysql-version bei hosteurope schuld?) |
Willkommen, Gast ( Anmelden | Registrierung ) [ Hilfe | Mitglieder | Suche ]
verzwicktes umlaut-problem nach server-umzug, (buggy mysql-version bei hosteurope schuld?) |
Mon. 29. March 2010, 17:48
Beitrag
#1
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 255 Mitglied seit: 05.07.2006 Mitglieds-Nr.: 104 |
hallo alle,
ich habe ein recht verzwicktes problem - und streite mich damit gerade mit meinem provider hosteurope rum. also, ich habe auf unserem server -- PHP 5.3.1 MySql 5.1.36 version_comment SUSE MySQL RPM version_compile_machine i686 version_compile_os suse-linux-gnu character_set_client utf8 character_set_connection utf8 character_set_database utf8 character_set_filesystem binary character_set_results utf8 character_set_server utf8 character_set_system utf8 collation_connection utf8_unicode_ci collation_database utf8_unicode_ci collation_server utf8_unicode_ci -- einen auftritt in sefrengo 1.4.3 umgesetzt. alles komplett utf8_unicode_ci. diesen auftritt habe ich nun auf ein webpack bei hosteurope gespielt -- PHP 5.2.12 MySql 5.0.32 version_comment Debian etch distribution version_compile_machine i486 version_compile_os pc-linux-gnu character_set_client utf8 character_set_connection utf8 character_set_database latin1 character_set_filesystem binary character_set_results utf8 character_set_server latin1 character_set_system utf8 collation_connection utf8_general_ci collation_database latin1_german2_ci collation_server latin1_german2_ci -- mittels mysqldumper 1.24. wie immer vollkommen problemlos. in der datenbank ist auch alles paletti. ABER - in der ausgabe werden alle umlaute zerschossen. Lege ich nun z.b. eine neue seite mit umlauten im namen an wird dieser umlaut seltsam formatiert (nicht utf-8) in die datenbank geschrieben, dafür aber korrekt ausgegeben. aus dem dump: "Hochkarätig" in der DB --> "Hochkar�tig" in der Ausgabe neu angelegt: "Seite äöüß" in der DB --> "Seite äöüß" in der Ausgabe am backup und dem wiedereinspielen liegt es definitiv nicht. ich habe das gefühl, dass es an der mysql-version bei hosteurope liegt. siehe folgenden bug: http://vandenabeele.com/mysqldump-utf8-bug http://bugs.mysql.com/bug.php?id=28969 genau das erlebnis hatten wir als wir seinerzeit unseren server von mysql 5.0.x auf die jetzige version geupdated hatten. danach waren alle umlaute der auf dem server befindlichen sefrengo-installationen zerschossen. mit dem trick oben haben wir das fixen können. das aktuelle problem mit hosteurope scheint mir exakt das gleiche zu sein - nur genau andersrum... laut hosteurope support liegt es hartnäckig an folgendem: - "dass die von Ihnen benutzte Software nicht utf8-sichere PHP-Funktionen verwendet" wohl kaum, oder? hat jemand eine idee? bzw, kann jemand der auch noch kunde bei hosteurope ist das zerschiessen der umlaute in einer standard-installation nachvollziehen? entweder sind wir, der entwickler vom mysqldumper und sonstige personen im bekanntenkreis alle auf dem holzweg, oder hosteurope hat eine buggy mysql-version auf allen webpacks laufen und updaten seid jahren die version nicht, weil sie sonst die installationen von allen kunden zerschiessen. ich hoffe ersteres... greetz, oberbilker -------------------- |
|
|
Wed. 31. March 2010, 07:17
Beitrag
#2
|
|
TRAIL AND ERROR SPECIALIST Gruppe: AdvancedMembers Beiträge: 1.708 Mitglied seit: 27.06.2006 Wohnort: Hansestadt Rostock, Deutschland Mitglieds-Nr.: 9 |
ist merkwürdig aber ich tippe mal auf
character_set_database utf8/character_set_database latin1 hier liegt vlt. die problematik. bin da auch nicht so der profi ... verzichte doch einmal auf den mysqldumper und nutze ganz klassisch phpmyadmin und teste beim dump-import jeweils die character-set einstellung latin/utf8. -------------------- cheers, Alex
|
|
|
Vereinfachte Darstellung | Aktuelles Datum: 27.4.24 - 02:37 |