Hallo NG,

ich habe eine Datenbank mit Charset = utf8 angelegt. Diese enthält diverse
Namen. Nun sende ich die Daten via HTML/PHP an den Browser.

Dabei entsehen im Firefox kleine Rauten mit Fragezeichen statt (ä,ö,ü etc.)
im Explorer das selber Problem nur eben Kästchen.

Also habe ich PHP ein:

setlocale(LC_ALL, 'de_DE');
header("Content-Type: text/html; charset=utf-8");

mitgegeben und dem HTML:
<meta http-equiv="content-type" content="text/html; charset=utf-8">

die Header mit liveHttpHeaders gecheckt und gesehen:

Content-type: utf-8

soweit so gut.

Bleibt da als Problem nur noch die Datenbank über? Wie gesagt, ich hab dort
das charset auf utf-8 gesetzt und PHPMyAdmin zeigt die Namen ohne Artefakte
an.

An welcher Schraube muss ich jetzt noch drehen?

Danke
Johannes

PS: Webadresse kann ich leider nicht mitliefern, da momentan noch nicht
öffentlich - sorry

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

Johannes Mueller schrieb:

> Hallo NG,
>
> ich habe eine Datenbank mit Charset = utf8 angelegt. Diese enthält
> diverse Namen. Nun sende ich die Daten via HTML/PHP an den Browser.
>
> Dabei entsehen im Firefox kleine Rauten mit Fragezeichen statt (ä,ö,ü
> etc.) im Explorer das selber Problem nur eben Kästchen.
>
> Bleibt da als Problem nur noch die Datenbank über? Wie gesagt, ich hab
> dort das charset auf utf-8 gesetzt und PHPMyAdmin zeigt die Namen ohne
> Artefakte an.
>
> An welcher Schraube muss ich jetzt noch drehen?

Diese Seite hast du mal gelesen:
http://dev.mysql.com/doc/refman/5.0/en/charset-connection.ht ml

Du musst MySQL bei der Verbindung sagen, welches Charset du gern hättest.
z.B. mysqli kennt dazu eine eigene Funktion und z.B. mdb2 einen eigenen
Parameter. Bei der mysql-Extension musst du das halt selbst erledigen.

Gruß
Carsten

Johannes Mueller schrieb:
> Hallo NG,
>
> ich habe eine Datenbank mit Charset =3D utf8 angelegt. Diese enthält =
diverse
> Namen. Nun sende ich die Daten via HTML/PHP an den Browser.
>
> Dabei entsehen im Firefox kleine Rauten mit Fragezeichen statt (ä,ö=
,ü etc.)
> im Explorer das selber Problem nur eben Kästchen.
>
> Also habe ich PHP ein:

Lies mal vom 19.10
Subject: PHPMyadmin mit kaputten Sonderzeichen
Newsgroups: de.comp.lang.php.datenbanken

> setlocale(LC_ALL, 'de_DE');
> header("Content-Type: text/html; charset=3Dutf-8");

Du hast dem DB Server nicht gesagt das du UTF8 haben moechtest mit
diesem Client und somit wird die Angabe zum Default Charset bzw.
Encoding gesetzt was wahrscheinlich Latin1 ist.

Aber Achtung:
Wenn du die Daten aus der DB noch verarbeiten willst mit den Standard
String Funktionen von PHP dann ist es ungeschickt nun sich UTF8 zuholen. =

Das bedeutet das du die mb_* Funktionen zur Bearbeitung nehmen must
oder die Alternative sich doch latin1 senden zulasen und per iconv()
fuer die Ausgabe dann den Zeichensatz zu aendern.

> mitgegeben und dem HTML:
> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
>
> die Header mit liveHttpHeaders gecheckt und gesehen:
>
> Content-type: utf-8
>
> soweit so gut.
>
> Bleibt da als Problem nur noch die Datenbank über? Wie gesagt, ich ha=
b dort
> das charset auf utf-8 gesetzt und PHPMyAdmin zeigt die Namen ohne Artef=
akte
> an.

Der PMA setzt ja auch das passende SQL Statement an die DB ab und sagt
was er haben moechte. Das ist ein "SET NAMES UTF8" wenn du mal das
Logging fuer die DB anschaltest.

Gruss
Joerg

--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Joerg Behrens wrote:

> Lies mal vom 19.10
> Subject: PHPMyadmin mit kaputten Sonderzeichen
> Newsgroups: de.comp.lang.php.datenbanken
>
>> setlocale(LC_ALL, 'de_DE');
>> header("Content-Type: text/html; charset=utf-8");
>
> Du hast dem DB Server nicht gesagt das du UTF8 haben moechtest mit
> diesem Client und somit wird die Angabe zum Default Charset bzw.
> Encoding gesetzt was wahrscheinlich Latin1 ist.

Das war der entscheidende Punkt. Mir war so gar nicht klar, dass ich gar
kein UTF-8 haben wollte.

> Aber Achtung:
> Wenn du die Daten aus der DB noch verarbeiten willst mit den Standard
> String Funktionen von PHP dann ist es ungeschickt nun sich UTF8
> zuholen. Das bedeutet das du die mb_* Funktionen zur Bearbeitung
> nehmen must oder die Alternative sich doch latin1 senden zulasen und
> per iconv() fuer die Ausgabe dann den Zeichensatz zu aendern.

....gut zu wissen.

Danke
Johannes

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

> Aber Achtung:
> Wenn du die Daten aus der DB noch verarbeiten willst mit den Standard
> String Funktionen von PHP dann ist es ungeschickt nun sich UTF8 zuholen.
> Das bedeutet das du die mb_* Funktionen zur Bearbeitung nehmen must
> oder die Alternative sich doch latin1 senden zulasen und per iconv()
> fuer die Ausgabe dann den Zeichensatz zu aendern.

Kann ich so nicht unterschreiben, ich bin vor etwa einem Jahr komplett
auf UTF8 umgestiegen und habe es nicht bereut. Einerseits habe ich
mb_string, andererseits funktionieren viele String-Funktionen wie z. B.
explode genausogut mit UTF8. Hinzu kommt, dass die neueren Versionen von
PHP ein preg haben, dass ebenfalls UTF8 kann und bei dem man z. B. auf
"Zeichenklassen" matchen kann.
Alles in allem ist UTF8 selbst unter PHP dem ganzen iso-Gefrickel weit
überlegen.
--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/
Ansonsten:
http://www.php-faq.de/q/q-newsgroup-wie-helfen.html

..oO(Hadanite Marasek)

>> Wenn du die Daten aus der DB noch verarbeiten willst mit den Standard
>> String Funktionen von PHP dann ist es ungeschickt nun sich UTF8 zuholen.
>> Das bedeutet das du die mb_* Funktionen zur Bearbeitung nehmen must
>> oder die Alternative sich doch latin1 senden zulasen und per iconv()
>> fuer die Ausgabe dann den Zeichensatz zu aendern.
>
>Kann ich so nicht unterschreiben, ich bin vor etwa einem Jahr komplett
>auf UTF8 umgestiegen und habe es nicht bereut. Einerseits habe ich
>mb_string,

.... die sich obendrein sogar teilweise auf die normalen Stringfunktionen
abbilden lassen, so daß der Code nicht mal angepaßt werden muß.

>andererseits funktionieren viele String-Funktionen wie z. B.
>explode genausogut mit UTF8. Hinzu kommt, dass die neueren Versionen von
>PHP ein preg haben, dass ebenfalls UTF8 kann und bei dem man z. B. auf
>"Zeichenklassen" matchen kann.

ACK

Ein klasse Feature.

>Alles in allem ist UTF8 selbst unter PHP dem ganzen iso-Gefrickel weit
>überlegen.

ACK

Allerdings sollte man sich auch immer bewußt sein, daß UTF-8 in PHP 5
nur eine Erweiterung und kein Kernbestandteil ist und somit an vielen
Ecken noch Fallstricke lauern können, auch mit mb_*. Man muß als etwas
aufpassen. Grundlegende Änderungen diesbzgl. wird erst PHP 6 bringen,
was einen aber nicht davon abhalten sollte, auch jetzt schon ausgiebig
Gebrauch von UTF-8 zu machen. Die Vorteile überwiegen ganz klar.

Micha

Hadanite Marasek schrieb:
>
> Kann ich so nicht unterschreiben, ich bin vor etwa einem Jahr komplett
> auf UTF8 umgestiegen und habe es nicht bereut. Einerseits habe ich
> mb_string, andererseits funktionieren viele String-Funktionen wie z. B.
> explode genausogut mit UTF8. Hinzu kommt, dass die neueren Versionen von
> PHP ein preg haben, dass ebenfalls UTF8 kann und bei dem man z. B. auf
> "Zeichenklassen" matchen kann.
> Alles in allem ist UTF8 selbst unter PHP dem ganzen iso-Gefrickel weit
> überlegen.

Leider gibt es doch noch Fälle, in denen es mit UTF8 unter PHP nicht so
gut klappt (oder ich mache noch einen Denkfehler):
_Zeichenweises_ Parsen von Strings... Mal schaun, ob es sich da lohnt
utf8 zu nehmen (vor allem, weil ich so Funktionen wie
isLetter($character) bräuchte, was dann doch recht hässlich wird).

Viele Grüße
Christoph

Christoph Bersch wrote:
> _Zeichenweises_ Parsen von Strings... Mal schaun, ob es sich da lohnt
> utf8 zu nehmen (vor allem, weil ich so Funktionen wie
> isLetter($character) bräuchte, was dann doch recht hässlich wird).

Sowas müsste sich mit Regexen faken(!) lassen, ungefähr so:
if( preg_match( '/$(\w|ö|ä|ü|ß|Ö|Ä|Ü)^/', $vielleicht_ein_buchstabe ) )
echo "Juhu";

Klappt allerdings nur, wenn deine PHP-Datei auch in utf8 codiert
gespeichert wird. Wie gesagt, ein Fake...


--
Testscript für RegEchsen:
http://diesundas.funzt-halt.net/regextest.php

Michael Ziegler schrieb:
> Christoph Bersch wrote:
>> (vor allem, weil ich so Funktionen wie
>> isLetter($character) bräuchte, was dann doch recht hässlich wird).
>
> Sowas müsste sich mit Regexen faken(!) lassen, ungefähr so:
> if( preg_match( '/$(\w|ö|ä|ü|ß|Ö|Ä|Ü)^/', $vielleicht_ein_buchstabe ) )
> echo "Juhu";

Da hatte ich nicht dran gedacht. Mit Regulären Ausdrücken sollte ein

if (preg_match('/^\pL$/u', $letter))

funktionieren, obwohl es bestimmt nicht die schnellste[tm] Variante ist ;-)

Christoph

"Joerg Behrens" <behrens [at] takenet.de> wrote:
> ich habe eine Datenbank mit Charset = utf8 angelegt. Diese enthält
> diverse Namen. Nun sende ich die Daten via HTML/PHP an den Browser.
>
> Dabei entsehen im Firefox kleine Rauten mit Fragezeichen statt (ä,ö,ü
> etc.) im Explorer das selber Problem nur eben Kästchen.
>
> Also habe ich PHP ein:

>Lies mal vom 19.10
>Subject: PHPMyadmin mit kaputten Sonderzeichen
>Newsgroups: de.comp.lang.php.datenbanken

> setlocale(LC_ALL, 'de_DE');
> header("Content-Type: text/html; charset=utf-8");

>Du hast dem DB Server nicht gesagt das du UTF8 haben moechtest mit
>diesem Client und somit wird die Angabe zum Default Charset bzw.
>Encoding gesetzt was wahrscheinlich Latin1 ist.

Hier muss ich auch mal was bemerken:

Bei einer Reihe 5er Versionen von mySQL sind tatsächlich irgendwie die
Umlaute kaputt!
Klappte hervorragend mit der 4er Installation bzw. einer frühen 5er
Beta: jedoch ab 5.1 wurde es verdammt kritisch: ohne Änderungen alles
"trashed".
Außerdem abstruse Fehlermeldung beim INSERTen von Werten, die äöü
enthalten.
Bis dieses nachweislich behoben ist, hab ich auch mein privates
DB-Projekt noch auf Eis gelegt: das tu ich mir nicht an. Lief doch
vorher perfekt. Nur ab irgendeiner bestimmten 5er-Version muss da was
wirklich essentielles zerschossen worden sein.
Und halten wir mal fest: die bei mySQL interessieren Umlautprobleme
(fast) kaum. Wir haben doch Englisch, wir brauchen das nicht, so der
Tenor zwischen den Zeilen.

Rant over.

-Andreas

Andreas Eibach wrote:
> Und halten wir mal fest: die bei mySQL interessieren Umlautprobleme
> (fast) kaum. Wir haben doch Englisch, wir brauchen das nicht, so der
> Tenor zwischen den Zeilen.

Wenn Du die Erklaerung in englischer Sprache nicht verstehst findest Du eine
deutscher Sprache bei

http://blog.koehntopp.de/archives/1360-Zeichensatzaerger.htm l

und

http://blog.koehntopp.de/archives/1424-MySQL-Zeichensatz-Gru ndlagen.html

Kris

--
Kristian =?iso-8859-15?q?Köhntopp?= <kris [at] xn--khntopp-90a.de>

"Kristian Köhntopp" <kris [at] koehntopp.de> wrote:
> Andreas Eibach wrote:
>> Und halten wir mal fest: die bei mySQL interessieren Umlautprobleme
>> (fast) kaum. Wir haben doch Englisch, wir brauchen das nicht, so der
>> Tenor zwischen den Zeilen.
>
> Wenn Du die Erklaerung in englischer Sprache nicht verstehst
???
Der war gut. :-)

War ganz anders gemeint. Das Entwicklerteam interessiert sich (fast)
kaum für Umlautprobleme in mySQL selbst, weil der Tenor meist so
rauskommt: "_Unsere_ Sprache ist doch Englisch, und Umlaute haben wir
nicht - wieso müssen wir uns daher um Bugs bei deutschen Umlauten
kümmern? OK wir schreiben es auf die Todo-Liste, aber wann wir das
fixen? *shrug*"

-Andreas