[gelöst] Sonderzeichen aus Word - Problem nur beim Auslesen

[Quetschi]

@AmicaNoctis
mysql_set_charset() steht unter der hier benutzten Version php5.1.4 noch nicht zur Verfügung.
Deswegen eben die manuellen Queries, die das an der Stelle eigentlich regeln sollten.

Restliche Fragen: siehe mein Post zuvor.

[wahsaga]

1. phpMyAdmin kann die Zeichen darstellen
2. Ich bzw. mein Ausgabescript kann es nicht

Das kann zwei Dinge bedeuten.

- Die Daten liegen korrekt in UTF-8 vor, PHP setzt "überall" UTF-8 als Kodierung, zeigt die Daten damit richtig an - dann macht dein Ausgabescript was falsch. Nimmt die Daten falsch entgegen, oder kodiert sie aus irgendeinem Grund noch mal um, ...

- Oder die Daten liegen nicht in UTF-8 vor, PMA "merkt" dies aber (benutzt also irgendwo eine Einstellung, die bisher nicht berücksichtigt wurde), kodiert sie für die Anzeige selber in UTF-8 um, liefert sie als UTF-8 aus, alles fein. Dein Script macht aber keinen solchen Extra-Schritt (soll es ja eigentlich auch nicht), und liefert dann nicht in UTF-8 vorliegende Daten als UTF-8 aus, was zum Fehler führt.


Hast du irgendwo die Multibyte String Functions im Einsatz?
Wenn ja, wie sieht's mit deren Konfiguration im einzelnen aus? (http://www.php.net/manual/en/mbstring.configuration.php)

[AmicaNoctis]

Und du arbeitest in dem PHP-Skript auch nicht mit utf8_decode oder irgendwelchen MBString-Funktionen, hast keinen mb_output_handler registriert, in der php.ini kein mbstring.func_overload, auto_prepend_file, auto_append_file oder sonstige Spezialitäten gesetzt, die unbemerkt was beeinflussen könnten?

[AmicaNoctis]

OffTopic:

---

@wahsaga zwei "Dumme" ein Gedanke

---

[Quetschi]

@wahsaga/AmicaNoctis
utf8_encode/utf8_decode sowie mbstring-Funktionen kann ich ausschliessen. auto_append_file/auto_prepend_file enthalten keine Werte.

Ich vermute momentan wahsagas ersten Gedanken - die Daten liegen in UTF8 vor, nur ich bzw. mein Script macht eben was falsch, wobei die Chance da Fehler zu machen eigentlich recht gering sind.

[Gunah]

wir haben es in einem projekt so gelöst:

SET NAMES 'CHARSET'

und dieses wird direkt nach dem connecten angeben, und dann erst welche Tabelle genommen wird...
klappt einwandfrei...

welche DB Version hast du den???

sonst musst du noch per ini_set() folgendes einstellen:

ini_set('default_charset', 'UTF-8');

gruß
Gunah

[Quetschi]

@Gunah

SET NAMES hatte ich auch schon - überhaupt hab ich langsam alles durch, was MySQL :: MySQL 3.23, 4.0, 4.1 Reference Manual :: 9.1.3 Specifying Character Sets and Collations zu bieten hat.

MySql ist noch eine 4.1.7

[Gunah]

Soweit ich weiss kam mal ein Bugfix für MySQL 5.0 heraus... welcher ein Problem mit UTF-8 beseitig hat... ob dieser Fehler in der MySQL 4.1 vorhanden ist/war, weiss ich leider nicht...

Gruß
gunah

[Quetschi]

Ich trete hier ziemlich auf der Stelle und für heute reichts mir allmählich damit.

Morgen werd ich mal auf einem anderen System mit aktuellerem mySql testen.

Soweit erstmal vielen Dank an alle und falls jemand noch eine Eingebung hat -> her damit

[onemorenerd]

Es kann doch gar kein MySQL-Bug sein, wenn es in phpMyAdmin korrekt funktioniert.

[Quetschi]

@onemorenerd
Der Meinung bin ich schon auch - aber allmählich geh ich dazu über, mich an Strohhalme zu klammern

Wie gesagt - werd nachher mal auf nem anderen System testen.

[Quetschi]

Hab das nun auf einem anderem Server getestet und läuft dort einwandfrei.
Die Frage wär nun eigentlich: was ist auf dem anderem Server los? Gab es einen Bug, den PMA kennt und ein Workaround dafür implementiert hat?

[AmicaNoctis]

Du könntest die Ausgabe von phpinfo() auf beiden Servern vergleichen und die Versionsnummern von MySQL und PMA. Ich vermute trotzdem, dass es an der php.ini liegt, auch wenn das alles ziemlich unlogisch klingt.

[Quetschi]

PHP ist auf beiden Servern 5.1.4 und die Ausgabe von phpinfo() ist weitgehend identisch bis auf die Exif-Erweiterung, die beim funktionierenden Server nicht installiert ist.

Server mit dem Problem:
Mysql 4.1.7, PMA 2.6.0

Server ohne Problem:
Mysql 5.0.77, PMA 2.10.0.2

Was ich vergessen habe zu erwähnen:
Die Ausgabe erscheint ja im Browser richtig, wenn ich den Browser von Hand auf ISO-8859-1 schalte. Also hätte ich im Script die Ausgabe mit iconv von ISO-8859-1 auf UTF-8 konvertiert, was allerdings keine Wirkung gezeigt hat

[AmicaNoctis]

bis auf die Exif-Erweiterung

Soso. EXIF benötigt MBString, wie konntest du das dann ausschließen?

@wahsaga/AmicaNoctis
utf8_encode/utf8_decode sowie mbstring-Funktionen kann ich ausschliessen.

Edit: guck bitte nochmal nach, welchen Wert mbstring.func_overload in der php.in hat.