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