Zeichensalatprobleme mit UTF-8 und ich komme nicht dahinter...

Post removed (X-No-Archive: yes)

Re: Zeichensalatprobleme mit UTF-8 und ich komme nicht dahinter...

Oliver C. Thornton wrote:
>=20
> DEFAUL CHARSET ist utf8
> Collation ist utf8_general_ci

Irrelevant.

> Text in einem Tabellen-Feld: "Schnürpel".
>=20
> Jetzt gebe ich das in einem Textfeld auf einer Seite aus die ebenfalls =

> sagt "Hallo, ich bin in UTF-8".

Ich rate mal, was du sagen wolltest: "Ich füge das Ergebnis eines SELEC=
Ts
nach diesem String in eine HTML-Seite ein, deren Zeichensatz korrekt als
utf8 deklariert ist."

> Resultat im Textfeld: "Schn?rpel"
>
> Ich speichere das wieder in die DB, Text im Tabellen-Feld: "Schn¿½r=
pel"=20
> (seltsamer Zeichensalat statt dem ü für die die es nicht darstellen=
=20
> können)
>=20
> Nochmal zurück: "Schnürpel" im Tabellen-Feld, die Ausgabe lasse ich=
=20
> vorher mit utf8_encode bearbeiten. Resultat im Textfeld: "Schnürpel" =

> (Supi, so solls sein, aber wozu brauche ich dazu utf8_encode?)
> Ich speichere das wieder in die DB. Tabellen-Feld: "Schürpel" *seu=
fz*=20
> wieder Zeichensalat statt dem ü.
>=20
> Nochmal zurück: "Schnürpel" im Tabellen-Feld, die Ausgabe lasse ich=
=20
> vorher mit utf8_encode bearbeiten. Resultat im Textfeld: "Schnürpel",=
=20
> bevor ich das wieder in die DB schreibe lase ich utf8_decode drüber, =

> Resultat in der DB: "Schürpel". So solls sein.
>=20
> Wo liegt der Fehler bzw. die Ursache darin, dass ich, obwohl mMn alles =

> utf8 ist, utf8_decode und utf8_encode brauche um keinen Zeichensalat zu=
=20
> bekommen? Sehe ich den Wald vor lauter Bäumen nicht?=20

Du liest nicht das Handbuch.

> Oder ist das ggf. sogar garkein mySQL-Problem?

Exakt. Der Fehler befindet sich vor dem Bildschirm ca. 15cm oberhalb dein=
es
Halses :)

Von hier aus sieht es so aus, als hätte dein PHP-Skript (das hier aller=
dings
off topic ist) der Datenbank nicht gesagt, daß es Daten in utf8 haben w=
ill
(und Daten als utf8 sendet) sondern verwendet den Default latin1.
Deswegen wandelt MySQL den utf8 Umlaut in latin1 um ('ü' =3D 0xFC) und =
dein
Browser zeigt die illegale utf8 Sequenz als '?' an. Genauso erwartet MySQ=
L
Strings von dir als latin1 und wandelt sie vor dem Abspeichern in utf8 um=


Lesen, verstehen und anwenden:
http://dev.mysql.com/doc/refman/5.0/en/charset-connection.ht ml


XL
--=20
In der klassischen Kryptographie verschlüsselt Alice Nachrichten an Bob=
um
sie vor Carol zu schützen. Bei DRM sind Bob und Carol die gleiche Perso=
n.

Re: Zeichensalatprobleme mit UTF-8 und ich komme nicht dahinter...

Post removed (X-No-Archive: yes)

Re: Zeichensalatprobleme mit UTF-8 und ich komme nicht dahinter...

Moin moin,

Oliver C. Thornton wrote:
> Di dalam de.comp.datenbanken.mysql Axel Schwenke menulis sebagai=20
> berikut:
>=20
>>> Oder ist das ggf. sogar garkein mySQL-Problem?
>> Exakt. Der Fehler befindet sich vor dem Bildschirm ca. 15cm oberhalb
>> deines Halses :)
>=20
> *schmoll*

;)

>> Von hier aus sieht es so aus, als hätte dein PHP-Skript (das hier
>> aller dings off topic ist) der Datenbank nicht gesagt, daß es Daten
>> in utf8 haben w ill (und Daten als utf8 sendet) sondern verwendet
>> den Default latin1. Deswegen wandelt MySQL den utf8 Umlaut in latin1
>> um ('ü' =3D 0xFC) und dein Browser zeigt die illegale utf8 Sequenz
>> als '?' an. Genauso erwartet MySQ L Strings von dir als latin1 und
>> wandelt sie vor dem Abspeichern in utf8 um .=20
>> Lesen, verstehen und anwenden:
>> http://dev.mysql.com/doc/refman/5.0/en/charset-connection.ht ml
>=20
> Das war mir nicht bekannt. Ich ging davon aus, dass eine utf8-DB und ei=
n=20
> utf8-Script ohne weitere Anweisungen auch in utf8 zusammenarbeiten zuma=
l=20
> ich der Überzeugung bin an jeder mir zugänglichen Stelle utf8 als=20
> Standard zu haben. Ich frage dann mal beim Provider ob da noch irgendwo=
=20
> ein böses latin1/ISO-Irgendwas drin steckt welches mir nicht zugäng=
lich=20
> ist.

Du liest das Handbuch ja immer noch nicht!

Deinen Provider trifft keine Schuld. In welchem Encoding ein Client (in
deinem Fall: das PHP-Skript) mit dem MySQL-Server reden will, ist allein
seine Sache. Insbesondere haben das Encoding, in dem der Quellcode
geschrieben ist und das Encoding in dem die Daten in der Datenbank
*gespeichert* werden, damit wenig bis gar nichts zu tun.

Direkt hinter die Stelle in deinem Code, wo du die MySQL-Verbindung
aufbaust, gehört ein 'SET NAMES utf8'. Wenn dein DB-API das unterstüt=
zt,
gerne auch als Initial-Command, dann funktioniert das auch nach einem
eventuellen Reconnect noch.


XL
--=20
In der klassischen Kryptographie verschlüsselt Alice Nachrichten an Bob=
um
sie vor Carol zu schützen. Bei DRM sind Bob und Carol die gleiche Perso=
n.