Bookmarks

Yahoo Gmail Google Facebook Delicious Twitter Reddit Stumpleupon Myspace Digg

Search queries

Use of assignment to $[ is deprecated at /usr/local/sbin/apxs line 86. , wwwxxx vim, mysql closing table and opening table, 800c5000, setgid operation not permitted, pciehp: acpi_pciehprm on IBM, WWWXXX.DBF, 078274121, info0a ip, should prodicers of software_based services be held liable or not liable for economic injuries

Links

XODOX
Impressum

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

Posted on 2008-01-28 20:40:38 by unknown

Post removed (X-No-Archive: yes)

Report this message

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

Posted on 2008-01-28 21:04:34 by Axel Schwenke

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

Irrelevant.

> Text in einem Tabellen-Feld: "Schn=FCrpel".
>=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=FCge 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 =FC f=FCr die die es nicht darstellen=
=20
> k=F6nnen)
>=20
> Nochmal zur=FCck: "Schn=FCrpel" im Tabellen-Feld, die Ausgabe lasse ich=
=20
> vorher mit utf8_encode bearbeiten. Resultat im Textfeld: "Schn=FCrpel" =

> (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 =FC.
>=20
> Nochmal zur=FCck: "Schn=FCrpel" im Tabellen-Feld, die Ausgabe lasse ich=
=20
> vorher mit utf8_encode bearbeiten. Resultat im Textfeld: "Schn=FCrpel",=
=20
> bevor ich das wieder in die DB schreibe lase ich utf8_decode dr=FCber, =

> Resultat in der DB: "Sch=FCrpel". 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=E4umen 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=E4tte dein PHP-Skript (das hier aller=
dings
off topic ist) der Datenbank nicht gesagt, da=DF 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 ('=FC' =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=
=2E

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


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

Report this message

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

Posted on 2008-01-28 22:29:08 by unknown

Post removed (X-No-Archive: yes)

Report this message

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

Posted on 2008-01-28 23:26:48 by Axel Schwenke

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=E4tte dein PHP-Skript (das hier
>> aller dings off topic ist) der Datenbank nicht gesagt, da=DF 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 ('=FC' =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 =DCberzeugung bin an jeder mir zug=E4nglichen Stelle utf8 als=20
> Standard zu haben. Ich frage dann mal beim Provider ob da noch irgendwo=
=20
> ein b=F6ses latin1/ISO-Irgendwas drin steckt welches mir nicht zug=E4ng=
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=F6rt ein 'SET NAMES utf8'. Wenn dein DB-API das unterst=FCt=
zt,
gerne auch als Initial-Command, dann funktioniert das auch nach einem
eventuellen Reconnect noch.


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

Report this message