XAMPP und Encoding
Christian Albers
ich experimentiere mit XAMPP und einer webbasierten Applikation auf
PHP-Basis.
Mit großem Erstaunen habe ich gleich zu Beginn feststellen müssen, daß
PHP Probleme mit dem Encoding hat - etwas Recherche brachte ans Licht,
daß PHP UTF-Zeichensätze nicht nativ unterstützt.
Mein Aufbau ist wie folgt:
1) PHP-Skripte, die Webseiten produzieren
2) PHP-Funktionen, die per AJAX von den Skripten aus 1) aufgerufen
werden und HTML-Schnipsel produzieren
3) PHP-Funktionen, die den DB-Zugriff kapseln und von 1) und 2)
aufgerufen werden
PHP sendet immer UTF-8 an den Browser, auch die DB-Kommunikation läuft
in UTF-8. Trotzdem sind z. B. Umlaute ein Problem. Mal habe ich kaputte
Umlaute in der Webseite, mal in der DB. Meist hilft ein passendes
utf8_encode() oder utf8_decode(), aber bislang kann ich da kein System
erkennen.
Kann mir da jemand weiterhelfen? Ich bin schon soweit, daß die
Informationen liefernden Funktionen aus 3) einen Schalter haben, mit dem
festgelegt wird, ob auf die Ergebnisse utf8_encode(), utf8_decode() oder
einfach (string) (explizite Typkonvertierung) angewendet werden soll.
Das muß aber doch einfacher gehen ....
--
Christian Albers
Karl Pflästerer
> Hallo NG,
>
> ich experimentiere mit XAMPP und einer webbasierten Applikation auf
> PHP-Basis.
>
> Mit großem Erstaunen habe ich gleich zu Beginn feststellen müssen, daß
> PHP Probleme mit dem Encoding hat - etwas Recherche brachte ans Licht,
> daß PHP UTF-Zeichensätze nicht nativ unterstützt.
Das stimmt so nicht ganz; für viele Funktionen ist die Kodierung der
Daten egal.
> Mein Aufbau ist wie folgt:
>
> 1) PHP-Skripte, die Webseiten produzieren
> 2) PHP-Funktionen, die per AJAX von den Skripten aus 1) aufgerufen
> werden und HTML-Schnipsel produzieren
> 3) PHP-Funktionen, die den DB-Zugriff kapseln und von 1) und 2)
> aufgerufen werden
>
> PHP sendet immer UTF-8 an den Browser, auch die DB-Kommunikation läuft
> in UTF-8. Trotzdem sind z. B. Umlaute ein Problem. Mal habe ich
> kaputte Umlaute in der Webseite, mal in der DB. Meist hilft ein
> passendes utf8_encode() oder utf8_decode(), aber bislang kann ich da
> kein System erkennen.
Dann schreibe mal genauer, was du machst. Wenn utf8_encode/decode hilft,
dann ist dies eher ein Zeichen für ein Problem. Mit utf8_decode/encode
kannst du nur zwischen latin1 und utf8 Kodierung der Zeichen wechseln
(für Zeichen, die in latin1 kodierbar sind). Wenn aber alles in utf8
kodiert wäre, brauchst du keine Konvertierung.
Stellst du sicher, dass
a) du bei HTTP immer uft-8 als Kodierung gesendet wird; also zb:
Content-Type: text/html; charset=utf-8 als Header?
b) nur wenn a) zutrifft, bekommst du auch immer utf-8 kodierte Daten vom
Browser (das Attribut accept-charset kann zusätzlich helfen)
c) die Kommunikation mit der Datenbank in utf-8 geschieht; bei MySQL
wäre es ein "SET NAMES UTF8;"; wobei besser die jeweiligen
treiberspezifischen Funktionen verwendet werden (zB.
mysqli::set_charset()).
d) c) funktioniert natütlich nur, wenn die Daten, die du sendest auch
wirklich utf-8 kodiert sind.
Um zu sehen, was wirklich in der Datenbank gespeichert ist, verbindet
man sich am besten mit dem Kommandozeilen Client und selektiert dort die
Daten. Wenn du zB ein Schema blog, mit der Tabelle items und der Spalte
title hast (und dem PK id), dann kannst du mit
SELECT HEX(title) FROM blog.items WHERE id = 1
dir anschauen, was wirklich gespeichert ist. Speichere ein Ä und schaue
es dir an.
> Kann mir da jemand weiterhelfen? Ich bin schon soweit, daß die
> Informationen liefernden Funktionen aus 3) einen Schalter haben, mit
> dem festgelegt wird, ob auf die Ergebnisse utf8_encode(),
> utf8_decode() oder einfach (string) (explizite Typkonvertierung)
> angewendet werden soll.
>
> Das muß aber doch einfacher gehen ....
Sicher; wie gesagt wenn utf8_encode() hilft, stimmt deine Aussage schon
mal nicht, dass alles in utf8 ist.
KP
Claus Reibenstein
> Mit großem Erstaunen habe ich gleich zu Beginn feststellen müssen, daß
> PHP Probleme mit dem Encoding hat - etwas Recherche brachte ans Licht,
> daß PHP UTF-Zeichensätze nicht nativ unterstützt.
Dann hast Du wohl falsch recherchiert.
PHP arbeitet sehr wohl mit UTF-Zeichensätzen. Ich benutze PHP schon seit
Jahren und verwende ausschließlich UTF-8. Bislang gab es damit nie
Probleme. Zumindest keine, die auf PHP zurückzuführen gewesen wären.
> PHP sendet immer UTF-8 an den Browser, auch die DB-Kommunikation läuft
> in UTF-8. Trotzdem sind z. B. Umlaute ein Problem. Mal habe ich kaputte
> Umlaute in der Webseite, mal in der DB.
Dann machst Du irgendetwas falsch.
Kannst Du mal ein kleines Beispiel posten, wo das passiert?
Gruß. Claus
Michael Fesser
>Christian Albers schrieb:
>
>> Mit großem Erstaunen habe ich gleich zu Beginn feststellen müssen, daß
>> PHP Probleme mit dem Encoding hat - etwas Recherche brachte ans Licht,
>> daß PHP UTF-Zeichensätze nicht nativ unterstützt.
>
>Dann hast Du wohl falsch recherchiert.
Nein.
>PHP arbeitet sehr wohl mit UTF-Zeichensätzen. Ich benutze PHP schon seit
>Jahren und verwende ausschließlich UTF-8. Bislang gab es damit nie
>Probleme. Zumindest keine, die auf PHP zurückzuführen gewesen wären.
Dennoch unterstützt PHP bislang UTF-8 nicht nativ (siehe auch das ganze
Gerangel um PHP 6/5.3). In vielen Fällen ist das zwar egal, aber String-
Funktionen z.B. brauchen die MultiByte-Erweiterung, um korrekt mit UTF-8
Daten umgehen zu können.
>> PHP sendet immer UTF-8 an den Browser, auch die DB-Kommunikation läuft
>> in UTF-8. Trotzdem sind z. B. Umlaute ein Problem. Mal habe ich kaputte
>> Umlaute in der Webseite, mal in der DB.
>
>Dann machst Du irgendetwas falsch.
Das stimmt allerdings.
Micha
Ulf K@dner
> Hallo NG,
Hallo Newsclient,
> ich experimentiere mit XAMPP und einer webbasierten Applikation auf
> PHP-Basis.
>
> Mit großem Erstaunen habe ich gleich zu Beginn feststellen müssen, daß
> PHP Probleme mit dem Encoding hat
Im Normalfall solle man als Programmierer immer den Fehler zuerst bei
sich suchen. Aber ist natürlich wesentlich einfacher fehlendes Wissen
damit zu kaschieren es auf Andere zu schieben…
> - etwas Recherche brachte ans Licht,
> daß PHP UTF-Zeichensätze nicht nativ unterstützt.
nativ nicht, aber das ist auch nicht nötig. Mit PHP kann man mit jeder
Kodierung vollkommen problemlos arbeiten. Wichtig ist halt nur das in
der ganzen Verarbeitungskette alles an die jeweilige Kodierung angepast
sein muss.
> Mein Aufbau ist wie folgt:
>
> 1) PHP-Skripte, die Webseiten produzieren
> 2) PHP-Funktionen, die per AJAX von den Skripten aus 1) aufgerufen
> werden und HTML-Schnipsel produzieren
> 3) PHP-Funktionen, die den DB-Zugriff kapseln und von 1) und 2)
> aufgerufen werden
Das beschreibt genau garnichts was irgendwelche Rückschnüsse auf
mögliche Fehlerquellen zulassen würde.
> PHP sendet immer UTF-8 an den Browser
Was Du genau wie sicherstellst?
> auch die DB-Kommunikation läuft
> in UTF-8.
Wie stellt Du das sicher?
Und was ist mit allen anderen beachtenswerten Dingen die Du ja kennen
solltest wenn Du zum Schluß kommst das PHP es nicht kann?
> Trotzdem sind z. B. Umlaute ein Problem. Mal habe ich kaputte
> Umlaute in der Webseite, mal in der DB.
Dann ist Deine Verarbeitungkette halt irgendwo doch nicht so aufgebaut
wie nötig.
> Kann mir da jemand weiterhelfen? Ich bin schon soweit, daß die
> Informationen liefernden Funktionen aus 3) einen Schalter haben, mit dem
> festgelegt wird, ob auf die Ergebnisse utf8_encode(), utf8_decode() oder
> einfach (string) (explizite Typkonvertierung) angewendet werden soll.
>
> Das muß aber doch einfacher gehen ....
OK… mal z.B. als utf-8
Zuerst ist es wichtig das Du sicherstellst das alle genutzten Scipte in
utf-8 Kodierung vorliegen. Das bedeutet nicht nur das die Dateiinhalte
entsprechend kodiert sind (ohne BOM!) sondern auch das Du z.B.
verschiedene Elemente wie z.B. reguläre Ausdrücke entsprechend, bei
Notwendigkeit definierst.
In PHP-Dateien hat es sich auch als nützlich erwiesen in jeder Datei am
Anfang manuel den Zeichensatz festzulegen damit der Interpiler weis wie
er damit umgehen soll: declare (encoding='UTF-8');
Was Datenbanken angeht muß folgendes beachtet werden:
Nicht nur die Kommunikation muss über "SET NAMES utf-8" entsprechend
eingerichtet werden sondern die Kodierung der Datenbanken, Tabellen und
Felder muss dazu passen. Hier also beim Anlegen der DBs und Tabellen
bereits die entsprechenden Charset Angaben machen. Aber das ist alles
schon wieder weniger ein PHP-Problem sondern sollte vielmehr durch Dein
Wissen zu Datenbanken abgedeckt werden.
Als letztes kommt dann der Teil der die Ausgabe von Daten durch PHP in
entsprechender Kodierung festlegt. Aber auch hier ist, wie bereits bei
Datenbanken weniger das Wissen zu PHP gefragt sondern vielmehr das zum
entsprechenden Ausgabetype (bei Dir wohl text/html) und natürlich zum
genutzten Protokoll (bei Dir in erster Linie http)
Also sollte man erstmal schauen mit welcher Kodierung der Webserver
Deine Daten an seine Clients ausliefert. Am besten Du installierst Dir
dazu für Firefox die Erweiterung Live-HTTP-Headers und schaust ob und
welcher Zeichensatz im Content-Type Header vom Browser empfangen wird.
Und ehe es zu mißverständnissen kommt: Damit ist nicht die Meta-Angabe
aus der HTML-Datei gemeint sondern der HTTP-Header den der Webserver
sendet. Die Meta-Angabe aus der HTML-Datei sollte lediglich zum
HTTP-Header passen. Korrigieren kannst Du das z.B. mit:
header( 'Content-Type: text/html; charset=utf-8' );
am Anfang des Scripts bevor irgendetwas ausgegeben wird.
Natürlich muß auch das HTML entsprechend als utf-8 Kodiert sein und das
enthaltene Meta-Element passend
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
festlegen. Das Metaelement ist letztendlich ab nur dafür gedacht das man
sich eine von Dir ausgeliefert Resource auch mal Offline mit der
passenden Kodierung anschauen kann.
Wenn Du das alles beachtest und verstehst bekommst Du auch keine
Probleme. Die meisten hier arbeiten bereits seit längeren mit
Unicode-Kodierungen ohne Probleme in Webseiten.
MfG, Ulf
Claus Reibenstein
> ..oO(Claus Reibenstein)
>
>> PHP arbeitet sehr wohl mit UTF-Zeichens�tzen. Ich benutze PHP schon seit
>> Jahren und verwende ausschlie�lich UTF-8. Bislang gab es damit nie
>> Probleme. Zumindest keine, die auf PHP zur�ckzuf�hren gewesen w�ren.
>
> Dennoch unterst�tzt PHP bislang UTF-8 nicht nativ (siehe auch das ganze
> Gerangel um PHP 6/5.3). In vielen F�llen ist das zwar egal, aber String-
> Funktionen z.B. brauchen die MultiByte-Erweiterung, um korrekt mit UTF-8
> Daten umgehen zu k�nnen.
Und die ist nicht nativ?
Gru�. Claus
Michael Fesser
N�. Ist optional und nicht immer aktiviert. Was meinst Du, warum f�r PHP
6 gro�e Teile der Engine und vieler Erweiterungen umgeschrieben werden
mu�ten, um Unicode bereits direkt im PHP-Kern zu haben? IIRC war das ja
zeitweilig sogar schon f�r 5.3 geplant, aufgrund der Schwierigkeiten
dabei dann aber doch nicht umgesetzt. An wirklich nativer Unterst�tzung
scheint also eine ganze Menge mehr dranzuh�ngen.
Gerade gefunden:
PHP 6 - Unicode Completion Stats
http://www.php.net/~scoates/unicode/render_func_data.php
Interessant ist die Statistik am Anfang:
Total Functions 2966
Unicode-Compatible Functions 2097
Unsafe or Untested Functions 869
Functions Without Protos 0
Complete 70.70%
Micha
Michael Fesser
>Zuerst ist es wichtig das Du sicherstellst das alle genutzten Scipte in
>utf-8 Kodierung vorliegen.
Naja, zwingend ist das nicht unbedingt, auch wenn's die Dinge natürlich
vereinfacht. Für ein Script, welches nur Daten aus der DB zum Browser
durchschaufelt, reicht selbst US-ASCII.
>In PHP-Dateien hat es sich auch als nützlich erwiesen in jeder Datei am
>Anfang manuel den Zeichensatz festzulegen damit der Interpiler weis wie
>er damit umgehen soll: declare (encoding='UTF-8');
Seit wann denn dieses bzw. wann braucht man das? War hier noch nie
notwendig. Meine Scripte sind UTF-8 ohne BOM und laufen einfach, da
brauch ich nix zu deklarieren. Der Editor (Eclipse) entscheidet, was wie
gespeichert wird und der Browser entscheidet anhand der gesendeten
Header, wie er's zu interpretieren hat. Wozu also das 'declare'?
>Nicht nur die Kommunikation muss über "SET NAMES utf-8" entsprechend
>eingerichtet werden […]
Das scheint mir der häufigste Fehler zu sein.
Micha
Ulf K@dner
> .oO(Ulf K@dner)
>
>> Zuerst ist es wichtig das Du sicherstellst das alle genutzten Scipte in
>> utf-8 Kodierung vorliegen.
>
> Naja, zwingend ist das nicht unbedingt, auch wenn's die Dinge natürlich
> vereinfacht. Für ein Script, welches nur Daten aus der DB zum Browser
> durchschaufelt, reicht selbst US-ASCII.
Und da wir nichts genaues wissen bleibt es wichtig. Zwingend hab ich
nicht geschrieben.
>> In PHP-Dateien hat es sich auch als nützlich erwiesen in jeder Datei am
>> Anfang manuel den Zeichensatz festzulegen damit der Interpiler weis wie
>> er damit umgehen soll: declare (encoding='UTF-8');
>
> Seit wann denn dieses bzw. wann braucht man das? War hier noch nie
> notwendig. Meine Scripte sind UTF-8 ohne BOM und laufen einfach, da
> brauch ich nix zu deklarieren.
Ich habe die Erfahrung gemacht das diese Deklaration außerst sinnvoll
ist wenn man fremde Libraries einbindet die nicht in der selben
Kodierung vorliegen wie die eigene oder wenn Teile eine Library in
andere Codierung vorliegen. Das macht es der Engine einfacher beide
zusammengeführt nutzen zu können. Hab ich schon oft gehabt und genau
diese Anweisung hat mir größeren Aufwand erspart.
Ich schrieb ja das es Hilfreich ist und nicht irgendwie zwingend oder
wichtig… Es entsteht dadurch kein Nachteil und man erspart sich im
bestimmten KOnstellationen Probleme. Also kein Grund des Anstoßes
Mal abgesehen davon wird dieses Kommando ab PHP 5.3 ohnehin nur beachtet
wenn es mit --enable-zend-multibyte kompiliert wurde.
>> Nicht nur die Kommunikation muss über "SET NAMES utf-8" entsprechend
>> eingerichtet werden […]
>
> Das scheint mir der häufigste Fehler zu sein.
SET NAMES ist ein Fehler oder dessen Nichtnutzung? Ich nehme an Du
meinst letzteres aber irgendwie läst sich Deine Antwort auch in die
andere Richtung interpretieren.
MfG, Ulf
Christian Albers
> Am 15.02.2011 17:01, schrieb Christian Albers:
>> Hallo NG,
>
> Hallo Newsclient,
>
>> ich experimentiere mit XAMPP und einer webbasierten Applikation auf
>> PHP-Basis.
>>
>> Mit großem Erstaunen habe ich gleich zu Beginn feststellen müssen, daß
>> PHP Probleme mit dem Encoding hat
>
> Im Normalfall solle man als Programmierer immer den Fehler zuerst bei
> sich suchen. Aber ist natürlich wesentlich einfacher fehlendes Wissen
> damit zu kaschieren es auf Andere zu schieben…
>
Nun, ich suche den Fehler bei mir. Deswegen habe ich gefragt: "Das muß
aber doch einfacher gehen .... ". Daß mir da Wissen fehlt, versuche ich
nicht zu kaschieren, mir ist das völlig klar und ich dachte, durch meine
Frage würde ich dies auch deutlich machen. Denn wenn ich meinte, alles
zu wissen, bräuchte ich ja nicht fragen. Ich versuche auch nichts auf
andere zu schieben (und frage mich im Übrigen, wie man das aus meinem
Ursprungsposting herauslesen kann), ich will auch nicht rumposen nach
dem Motto "Ich bin zwar der PHP-Crack, stelle aber doch mal ne blöde
Frage an Euch Anfänger". Ich will ein Ziel erreichen und dazu Know-How
sammeln.
Mir ist ebenfalls glasklar, daß viele Leute ohne Probleme mit dem
Encoding Webseiten mit PHP entwickeln und daß ich deshalb grundsätzlich
was falsch machen muß. Weil es einfach unglaublich wäre, wenn sich jede
auf PHP/Apache/MySQL basierende Software mit solchen Problemen
rumschlagen müßte.
>> - etwas Recherche brachte ans Licht,
>> daß PHP UTF-Zeichensätze nicht nativ unterstützt.
>
> nativ nicht, aber das ist auch nicht nötig. Mit PHP kann man mit jeder
> Kodierung vollkommen problemlos arbeiten. Wichtig ist halt nur das in
> der ganzen Verarbeitungskette alles an die jeweilige Kodierung angepast
> sein muss.
>
>> Mein Aufbau ist wie folgt:
>>
>> 1) PHP-Skripte, die Webseiten produzieren
>> 2) PHP-Funktionen, die per AJAX von den Skripten aus 1) aufgerufen
>> werden und HTML-Schnipsel produzieren
>> 3) PHP-Funktionen, die den DB-Zugriff kapseln und von 1) und 2)
>> aufgerufen werden
>
> Das beschreibt genau garnichts was irgendwelche Rückschnüsse auf
> mögliche Fehlerquellen zulassen würde.
>
Guck mal, das hätte ich anders vermutet. Ich dachte, es würde einen
Unterschied machen, ob ein Aufruf per AJAX oder innerhalb eines
PHP-Skriptes erfolgen würde. Weil - wie ich vermutete - der AJAX-Aufruf
utf-8-kodiert ist und der andere - wegen der fehlenden nativen
UTF-8-Unterstützung - eben nicht.
Wie gesagt: so meine Vermutung.
>> PHP sendet immer UTF-8 an den Browser
>
> Was Du genau wie sicherstellst?
Ich gucke im Firefox unter Extras->Seiteninformationen. Da steht unter
Kodierung: UTF-8. Außerdem sende ich
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
im Head jeder Seite. Mir ist klar, daß das Meta-Tag mit dem
tatsächlichen Encoding nicht viel zu tun haben muß.
>> auch die DB-Kommunikation läuft
>> in UTF-8.
>
> Wie stellt Du das sicher?
Ausschnitt aus meiner DB-Ausführ-Funktion:
$connection = mysql_connect( "localhost", "user", "pass" );
mysql_query("SET NAMES utf8");
mysql_select_db( "system", $connection );
$STATEMENT = utf8_encode( $STATEMENT );
$ergebnis = mysql_query( $STATEMENT );
$sql_ok = mysql_error();
> Und was ist mit allen anderen beachtenswerten Dingen die Du ja kennen
> solltest wenn Du zum Schluß kommst das PHP es nicht kann?
Daß PHP nicht nativ unicodefähig ist, hab ich auf einer Webseite
gelesen. Sagen wir mal, ich bin hier um zu lernen, was es sonst noch für
beachtenswerte Dinge gibt. Und wie man sie einstellt.
>> Trotzdem sind z. B. Umlaute ein Problem. Mal habe ich kaputte
>> Umlaute in der Webseite, mal in der DB.
>
> Dann ist Deine Verarbeitungkette halt irgendwo doch nicht so aufgebaut
> wie nötig.
>
Gut erkannt. Du wirst es schon vermuten: mir ist das auch aufgefallen.
>> Kann mir da jemand weiterhelfen? Ich bin schon soweit, daß die
>> Informationen liefernden Funktionen aus 3) einen Schalter haben, mit dem
>> festgelegt wird, ob auf die Ergebnisse utf8_encode(), utf8_decode() oder
>> einfach (string) (explizite Typkonvertierung) angewendet werden soll.
>>
>> Das muß aber doch einfacher gehen ....
>
> OK… mal z.B. als utf-8
>
> Zuerst ist es wichtig das Du sicherstellst das alle genutzten Scipte in
> utf-8 Kodierung vorliegen. Das bedeutet nicht nur das die Dateiinhalte
> entsprechend kodiert sind (ohne BOM!) sondern auch das Du z.B.
> verschiedene Elemente wie z.B. reguläre Ausdrücke entsprechend, bei
> Notwendigkeit definierst.
>
Ich nehme an, wenn man UTF-8 *mit* BOM macht, bekommt man Probleme, weil
"<?php" nicht mehr die ersten Zeichen im Skript sind? Muß ich mal
ausprobieren.
Trotzdem noch eine Frage: OK, es ist wichtig, daß die Skripte
UTF-8-kodiert sind. Warum ist das wichtig? Der Interpreter liest ein
Skript ein, welchen Unterschied macht es, wie das Skript kodiert ist?
> In PHP-Dateien hat es sich auch als nützlich erwiesen in jeder Datei am
> Anfang manuel den Zeichensatz festzulegen damit der Interpiler weis wie
> er damit umgehen soll: declare (encoding='UTF-8');
Danke, werd ich ausprobieren. Ich arbeite mit SSI - reicht das, wenn das
in der Kopfteil-Datei definiert ist?
> Was Datenbanken angeht muß folgendes beachtet werden:
>
> Nicht nur die Kommunikation muss über "SET NAMES utf-8" entsprechend
> eingerichtet werden sondern die Kodierung der Datenbanken, Tabellen und
> Felder muss dazu passen. Hier also beim Anlegen der DBs und Tabellen
> bereits die entsprechenden Charset Angaben machen. Aber das ist alles
> schon wieder weniger ein PHP-Problem sondern sollte vielmehr durch Dein
> Wissen zu Datenbanken abgedeckt werden.
Ich hab irgendwo gelesen, daß die MySQL-Engine das Mapping des
Abfrage-Encodings auf das Tabellen-Encoding selber vornimmt. Sendet man
die Abfrage in UTF-8, sei es mehr oder weniger egal, wie die Tabelle
kodiert ist - das für CHAR-Felder verwendete Standard-Encoding sei dann
jedenfalls OK. Aktuell verwende ich "latin1_swedish_ci".
Für den Fall, daß diese Info nicht stimmt: Welches Encoding schlägst Du
vor? Vermutlich "utf8_general_ci"?
> Wenn Du das alles beachtest und verstehst bekommst Du auch keine
> Probleme. Die meisten hier arbeiten bereits seit längeren mit
> Unicode-Kodierungen ohne Probleme in Webseiten.
Danke für die Tipps, ich werd mal die Skripte nach UTF-8 ohne BOM
konvertieren, da hatte ich bislang irgendein Problem, muß ich nochmal
gucken. Außerdem werd ich das Encoding in der PHP-Datei für den
Interpreter deklarieren.
Ich bin noch nicht sicher, ob und welche Änderungen ich an der DB
vornehmen muß. Mal gucken, wie weit ich mit diesen Hinweisen komme ...
Nochmal: Danke!
Grüße!
--
Christian Albers
Christian Albers
> Christian Albers schrieb:
>
>> Mit groￜem Erstaunen habe ich gleich zu Beginn feststellen mￜssen, daￜ
>> PHP Probleme mit dem Encoding hat - etwas Recherche brachte ans Licht,
>
> Dann hast Du wohl falsch recherchiert.
>
> Jahren und verwende ausschlieï¿œlich UTF-8. Bislang gab es damit nie
> Probleme. Zumindest keine, die auf PHP zurï¿œckzufï¿œhren gewesen wï¿œren.
>
Eine kurze Google-Recherche brachte folgendes zu Tage:
"Andrei Zmievski is one of the leading developers of the PHP programming
language. Since March 2005, he has been working with about 20 other
developers to add Unicode support to version 6.0 of PHP. Now their
efforts are nearing an alpha release."
http://www.linux.com/archive/feed/60386
Es gibt noch weitere Quellen. PHP Version < 6 unterstï¿œtzt nicht nativ
Unicode/UTF-Zeichensￜtze. Daￜ PHP mit UTF-Zeichensￜtzen arbeiten kann,
hab ich nie bezweifelt - sie werden aber nicht nativ unterstï¿œtzt.
Gruￜ
--
Christian Albers
Stefan Froehlich
> Trotzdem noch eine Frage: OK, es ist wichtig, daß die Skripte
> UTF-8-kodiert sind. Warum ist das wichtig? Der Interpreter liest
> ein Skript ein, welchen Unterschied macht es, wie das Skript
> kodiert ist?
Fuer das Skript selbst (im Sinn von: die Programmlogik) ist es
relativ gleichgueltig, weil das zu 99.9% 7-Bit clean sein wird.
Anders ist das allenfalls bei Texten, die in Deinem Programm
verwendet werden (die gibt es ja meist in irgendeiner Art und
Weise), und genau bei denen kann es dann Probleme geben.
> > Nicht nur die Kommunikation muss über "SET NAMES utf-8"
> > entsprechend eingerichtet werden sondern die Kodierung der
> > Datenbanken, Tabellen und Felder muss dazu passen. [...]
> Ich hab irgendwo gelesen, daß die MySQL-Engine das Mapping des
> Abfrage-Encodings auf das Tabellen-Encoding selber vornimmt.
> Sendet man die Abfrage in UTF-8, sei es mehr oder weniger egal,
> wie die Tabelle kodiert ist
Ja, ist so (und tatsaechlich empfiehlt man in der Datenbankgruppe,
alle Felder z.B. auf iso-8895-1 zu belassen, _ausser_ es wird
explizit anders benoetigt). Probleme gibt es - nona - dann, wenn man
Zeichen abspeichert, die mit dem gewaehlten Encoding nicht abbildbar
sind.
Ich muss gestehen, aus Traegheit aber ebenfalls alle Datenbankfelder
auf utf-8 einzustellen (mehr als 90% davon enthalten
Benutzereingaben, bei denen ich fuer nichts garantieren kann).
> Ich bin noch nicht sicher, ob und welche Änderungen ich an der DB
> vornehmen muß. Mal gucken, wie weit ich mit diesen Hinweisen komme
> ...
Am besten ist bei solchen Problemen, sich die Verarbeitungskette
Schritt fuer Schritt in Hexadezimal anzeigen zu lassen. Das Zeichen,
wie es in PHP ankommt, wie es an die Datenbank uebergeben wird, wie
es dort gespeichert ist (dabei noch darauf achten, dass nicht der
Transportweg beim Debugging hineinpfuscht, d.h. dirkekt auf
SQL-Ebene hex-codieren lassen), wie es zurueck in die Applikation
kommt und wie es an den Browser ausgeliefert wird. Dann wirst Du
recht schnell den Punkt finden, wo etwas aus dem Ruder laeuft.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Geht nicht!? Aber, aber - es gibt doch Stefan!
(Sloganizer)
Ulf K@dner
>>> PHP sendet immer UTF-8 an den Browser
>>
>> Was Du genau wie sicherstellst?
>
> Ich gucke im Firefox unter Extras->Seiteninformationen. Da steht unter
> Kodierung: UTF-8. Außerdem sende ich
>
> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
>
> im Head jeder Seite. Mir ist klar, daß das Meta-Tag mit dem
> tatsächlichen Encoding nicht viel zu tun haben muß.
Du solltest neben dem eher sekundären Meta-Element _immer_ selbst den
entsprechenden HTTP-Header senden
> mysql_query("SET NAMES utf8");
OK
> $STATEMENT = utf8_encode( $STATEMENT );
Das ist absolut unnötig wenn in der Verarbeitungskette und im HTML sowie
in der Kommunikation alles bereits utf-8 Kodiert ist. Die Notwendigkeit
zu utf8_*() Funktionen ist immer ein guter Indikator das noch was
vergessen wurde.
> $ergebnis = mysql_query( $STATEMENT );
Mal etwas abschweifend: Du solltest Dir dringend mal PDO oder MySQLi
anschauen. Beide ermöglichen es Dir, im Gegensatz zur prozeduralen
Variante mit Prepared Statements zu arbeiten was einen enormen
Sicherheitszuwachs darstellt.
> Ich nehme an, wenn man UTF-8 *mit* BOM macht, bekommt man Probleme, weil
> "<?php" nicht mehr die ersten Zeichen im Skript sind?
Absolut korrekt!
> Trotzdem noch eine Frage: OK, es ist wichtig, daß die Skripte
> UTF-8-kodiert sind. Warum ist das wichtig? Der Interpreter
Wenn mans ganz genau nimmt nennt man den in PHP Interpiler (da er bereit
Interpreter und Compiler vereinigt) Aber das nur am Rande. Mit
Interpreter weis jeder was Du meinst.
> liest ein
> Skript ein, welchen Unterschied macht es, wie das Skript kodiert ist?
Ohh das ist absolut entscheident! Stellt Dir mal Vor irgendwo in Deinem
Code sind Zeichenketten (Bei Dir z.B. SQL-Queries oder HTML)
gespeichert. Die liegen dann natürlich immer in der Kodierung vor wie
die Skriptdatei selbst. Das würde für jedwige Nutzung der Zeichenketten
aus der Datei ein Recoding in die jeweilige Zielkodierung nötig machen.
Und das das nicht überall geht sollte klar sein.
> Danke, werd ich ausprobieren. Ich arbeite mit SSI - reicht das
Server Side Includes? Wozu das? Wenn Du PHP nutzt ist SSI doch nur
Spielkram und kann nix was PHP nicht besser könnte. Würde ich komplett
entsorgen.
> Ich hab irgendwo gelesen, daß die MySQL-Engine das Mapping des
> Abfrage-Encodings auf das Tabellen-Encoding selber vornimmt.
Ja, Stefan hat dazu bereits mögliche Problemstellen erklärt.
> Für den Fall, daß diese Info nicht stimmt: Welches Encoding schlägst Du
> vor? Vermutlich "utf8_general_ci"?
Das ist aber eine Collation. Das ensprechende Charset heist logischer
weise nur utf8 und sollte auch genutzt werden
Reihenfolge:
- Eine Datenbank immer in utf-8 anlegen:
CREATE DATABASE `foo` /*!40100 CHARACTER SET utf8
COLLATE utf8_general_ci */
- Tabelle in utf8 anlegen:
CREATE TABLE `bar` (
`ID` int(11) NOT NULL AUTO_INCREMENT,
`baz` varchar(50) NOT NULL,
PRIMARY KEY (`ID`),
) ENGINE=MyISAM DEFAULT CHARSET=utf8
MfG, Ulf
Michael Fesser
>Am 15.02.2011 21:36, schrieb Michael Fesser:
>> .oO(Ulf K@dner)
>>
>>> In PHP-Dateien hat es sich auch als nützlich erwiesen in jeder Datei am
>>> Anfang manuel den Zeichensatz festzulegen damit der Interpiler weis wie
>>> er damit umgehen soll: declare (encoding='UTF-8');
>>
>> Seit wann denn dieses bzw. wann braucht man das? War hier noch nie
>> notwendig. Meine Scripte sind UTF-8 ohne BOM und laufen einfach, da
>> brauch ich nix zu deklarieren.
>
>Ich habe die Erfahrung gemacht das diese Deklaration außerst sinnvoll
>ist wenn man fremde Libraries einbindet die nicht in der selben
>Kodierung vorliegen wie die eigene oder wenn Teile eine Library in
>andere Codierung vorliegen.
OK, das ist ein gutes Beispiel.
>>> Nicht nur die Kommunikation muss über "SET NAMES utf-8" entsprechend
>>> eingerichtet werden […]
>>
>> Das scheint mir der häufigste Fehler zu sein.
>
>SET NAMES ist ein Fehler oder dessen Nichtnutzung? Ich nehme an Du
>meinst letzteres aber irgendwie läst sich Deine Antwort auch in die
>andere Richtung interpretieren.
Stimmt, sorry. Aber Du lagst richtig. In vielen Fällen sind die Tabellen
korrekt eingerichtet und PHP sendet korrekte HTTP-Header, nur an die
Verbindung zur DB wurde nicht gedacht. Ist ja für einen Anfänger auch
nicht unbedingt naheliegend, daß auch dort Zeichencodierungen greifen.
Micha
Christian Albers
Hallo Gruppe nochmal,
der Tipp mit der Umstellung der Skripte auf UTF8 ohne BOM war der
Treffer, vielen Dank dafür. Jetzt funktionierts im Firefox wie erwartet
(abgesehen davon, daß der DB-Zugriff krötenlangsam ist, da muß ich
nochmal auf den hier genannten Tipp mit pear zurückgreifen.). Aber ...
Überraschung: nicht im Internet Explorer 8 native (also nicht
Kompatibilitätsmodus). Der zeigt ebenfalls (unter Seite->Kodierung) an,
daß die Seite in UTF-8 kodiert ist, scheint aber bei Formularen
iso-irgendwas (was genau weiß ich noch nicht) zu senden.
Hat dazu noch jemand einen Tipp? Vermutlich liegt der Fehler wieder bei
mir; ich wüßte nur gerne, wo ....
Grüße!
--
Christian Albers
Diplom-Informatiker (FH)
___ christia...@calbers.de ___
Ulf K@dner
> der Tipp mit der Umstellung der Skripte auf UTF8 ohne BOM war der
> Treffer, vielen Dank dafür.
Stelle aber auch Sicher das, falls voher kein UTF8 war, die Inhalte von
Zeichenketten entsprechend umkodiert wurden!
> Jetzt funktionierts im Firefox wie erwartet
> (abgesehen davon, daß der DB-Zugriff krötenlangsam ist, da muß ich
> nochmal auf den hier genannten Tipp mit pear zurückgreifen.)
Langsame DB-Zugriffe haben nix damit zu tun welches DB-Interface Du
nutzt (zumindest nicht merklich). Das Deutet eher auf ein unpassendes
DB/Query Design hin. Aber diese Frage solltest Du definitiv in der
MySql-Gruppe klären.
Bezüglich der Zeichenkodierung wäre es wohl am einfachsten wenn Du mal
eine URL zur Problemwebseite posten könntest.
> Überraschung: nicht im Internet Explorer 8 native (also nicht
> Kompatibilitätsmodus). Der zeigt ebenfalls (unter Seite->Kodierung) an,
> daß die Seite in UTF-8 kodiert ist, scheint aber bei Formularen
> iso-irgendwas (was genau weiß ich noch nicht) zu senden.
Formulare == HTML != PHP Aber zeig einfach mal die Webseite her.
Notfalls halt mal online stellen.
MfG, Ulf
Dr. Franz-Josef Huecker
<wer...@calbers.de> wrote:
> der Tipp mit der Umstellung der Skripte auf UTF8 ohne BOM war der
> Treffer, vielen Dank dafür. Jetzt funktionierts im Firefox wie erwartet
> (abgesehen davon, daß der DB-Zugriff krötenlangsam ist, da muß ich
> nochmal auf den hier genannten Tipp mit pear zurückgreifen.). Aber ...
> Überraschung: nicht im Internet Explorer 8 native (also nicht
> Kompatibilitätsmodus). Der zeigt ebenfalls (unter Seite->Kodierung) an,
> daß die Seite in UTF-8 kodiert ist, scheint aber bei Formularen
> iso-irgendwas (was genau weiß ich noch nicht) zu senden.
Hi Christian
Ich habe hier nicht alles mitverfolgt, darum nur so als Idee dazu,
falls noch nicht probiert, verworfen oder sowieso abwegig.
Ich bin in gewisser Weise UTF-8 geschaedigt, hatte eine Menge Probleme
damit und das hat mich viel Zeit gekostet, bis ich das gesamte Projekt
radikal auf ISO umgestellt habe, und ploetzlich ging die Sonne auf.
Franz-Josef
--
Dr. Franz-Josef Huecker
W3: http://www.huecker.com
Email: in...@huecker.com
Ulf K@dner
> Ich bin in gewisser Weise UTF-8 geschaedigt, hatte eine Menge Probleme
> damit und das hat mich viel Zeit gekostet
Das ist üblich das einen Dinge die man nicht kennt Zeit kosten. Keine
Programmiersprache und deren Eigenheiten erlernt sich über Nacht! Ohne
Investition von viel Zeit geht halt nix. Es sei den man bekommts
sozusagen in die Wiege gelegt. Aber das dürfte hier in der Gruppe wohl
keiner sein.
> bis ich das gesamte Projekt
> radikal auf ISO umgestellt habe, und ploetzlich ging die Sonne auf.
Und was ist wenn Du auf Deiner Webseite Zeichen darstellen willst die
über ISO hinaus gehen? Was ist wenn auf Deiner Webseite ein Formular
(Kontaktformular, Kommentarformular, etc.) ausgefüllt wird und Zeichen
reinkommen die nicht ISO¿ entsprechen?
Aber vorallem was ist "auf ISO umgestellt"?
Den Ratschlag hätte ich mir an Deiner Stelle einfach verkniffen!
Wer UTF-8 nutzen will sollte das auch tun und nicht aus welchen Gründen
auch immer zu Notlösungen greifen.
Die Herangehensweise von Christian ist letztendlich da wesentlich
proffesioneller denn er nimmt auch mögliche zeitliche mehraufwendungen
durch Lernen in kauf. Das würde ich Dir auch ans Herz legen. Unicode und
PHP ist keine Hexerei!
Ich könnte Dir anbieten das ich mich am Wochenende mal mit Dir hinsetze
und wir mal alles durchgehen damit Du es auch hinbekommst. (Am besten
über Skype)
Wenn Du Lust dazu hast melde dich bei mir. Meine Mailadresse ist
Replyfähig. Aber nur an diesem Wochenande. Nächste Woche fängt wieder
ein größerer Auftrag an.
MfG, Ulf
Jo Schulze
> Am 15.02.2011 18:43, schrieb Claus Reibenstein:
> Eine kurze Google-Recherche brachte folgendes zu Tage:
>
> "Andrei Zmievski is one of the leading developers of the PHP
> programming language. Since March 2005, he has been working with about
> 20 other developers to add Unicode support to version 6.0 of PHP. Now
> their efforts are nearing an alpha release."
>
> http://www.linux.com/archive/feed/60386
Es gibt kein PHP6, die Art wie Unicode Unterstützung dafür geplant war
ist abgeleht worden.
> Es gibt noch weitere Quellen. PHP Version < 6 unterstützt nicht nativ
> Unicode/UTF-Zeichensätze. Daß PHP mit UTF-Zeichensätzen arbeiten kann,
> hab ich nie bezweifelt - sie werden aber nicht nativ unterstützt.
Encoding ist aus Sicht von PHP ein Problem das auf Applikationsebene
gehört.
Claus Reibenstein
> Christian Albers wrote:
>
>> Am 15.02.2011 18:43, schrieb Claus Reibenstein:
>> Eine kurze Google-Recherche brachte folgendes zu Tage:
Nein, das schrieb ich nicht. Ich schrieb eigentlich gar nichts von dem,
was Du hier zitiert hast. Warum Du meinen Namen trotzdem zitierst, ist
mir schleierhaft.
> Es gibt kein PHP6, die Art wie Unicode Unterstützung dafür geplant war
> ist abgeleht worden.
Wann? Von wem? Quelle?
>> Es gibt noch weitere Quellen. PHP Version < 6 unterstützt nicht nativ
>> Unicode/UTF-Zeichensätze. Daß PHP mit UTF-Zeichensätzen arbeiten kann,
>> hab ich nie bezweifelt - sie werden aber nicht nativ unterstützt.
>
> Encoding ist aus Sicht von PHP ein Problem das auf Applikationsebene
> gehört.
So ist es bis jetzt. Mit PHP6 sollte sich genau das ändern.
Gruß. Claus
Dr. Franz-Josef Huecker
wrote:
> Und was ist wenn Du auf Deiner Webseite Zeichen darstellen willst die
> über ISO hinaus gehen? Was ist wenn auf Deiner Webseite ein Formular
> (Kontaktformular, Kommentarformular, etc.) ausgefüllt wird und Zeichen
> reinkommen die nicht ISO¿ entsprechen?
Interessanter Hinweis. Vor einigen Tagen habe ich etwas in eine grosse
Datenbank eingetragen, die, wie mir bekannt ist, nicht von Amateuren
betrieben wird, und dabei gesehen, dass die dank UTF-8 mit dem
gleichen Thema beschaeftigt sind, dass ich mit ISO prima geloest habe.
Witzigerweise sogar auch an exakt der gleichen Stelle. :-)
Natuerlich ehrt es dich, dass du die UTF-8-Fahne so tapfer
verteidigst, dass du allerdings vor dem Hintergrund der hier staendig
laufenden Diskussion darauf bestehst, und rein gar nichts daneben
akzeptieren magst, das wundert mich schon ein wenig?!.
Ausserdem habe ich niemand gesagt, er soll das oder das tun, sondern
von meiner Erfahrung berichtet. Und meint jemand, er muss auf Biegen
und Brechen mit UTF-8 ein Problem loesen, das er ohne UTF-8 gar nicht
haette, dann ist das eben so. Schliesslich gibt es genug, die mit dem
Kopf erst einmal vor die Wand laufen muessen, bis sie irgendwann
endlich begreifen, dass dort wirklich keine Tuer ist..
Den von dir befuerchteten Fehlern habe ich weitgehend einen Riegel
vorgeschoben, wie gemeinhin ueblich, und wenn dennoch etwas auftreten
sollte, koennte ich das sicher auch nicht mit UTF-8 erschrecken,
sondern muss mir eben etwas Neues einfallen lassen.
Vielleicht gibt es Menschen, die alles voraussehen und kontrollieren
koennen.. Ich kann das jedenfalls nicht. Und wir wissen beide, Ulf,
wenn morgen die Sonne auf die Erde faellt, dann haben wir auch ein
Problem, ueber das es sich wirklich lohnt gruendlich nachzudenken.
Thomas 'PointedEars' Lahn
> Christian Albers schrieb:
>> Mit großem Erstaunen habe ich gleich zu Beginn feststellen müssen, daß
>> PHP Probleme mit dem Encoding hat - etwas Recherche brachte ans Licht,
>> daß PHP UTF-Zeichensätze nicht nativ unterstützt.
>
> Dann hast Du wohl falsch recherchiert.
>
> PHP arbeitet sehr wohl mit UTF-Zeichensätzen.
JFTR: *Es* *gibt* *keine* *UTF-Zeichensätze*!
> Ich benutze PHP schon seit Jahren und verwende ausschließlich UTF-8.
Das ist eine mögliche _Zeichencodierung_ für Zeichen des Unicode-
Zeichensatzes.
> Bislang gab es damit nie Probleme. Zumindest keine, die auf PHP
> zurückzuführen gewesen wären.
Das PHP-Modul für IIS 6.0 hat IIRC Probleme mit UTF-8-codiertem Quelltext;
dieser wurde nicht ausgeführt (ob es eine Fehlermeldung gab, weiss ich nicht
mehr). Mit Windows-1252-codiertem Quelltext gab es da kein Problem. Ob das
an IIS oder am PHP-Modul lag, weiss ich nicht, da ich damals einfach
(Eclipse für dieses Projekt) auf Windows-1252 umgestellt und utf8_encode()
für die Ausgabe verwendet hatte.
PointedEars
--
Es ist ein ohne Sinn und Verstand ausgeschnittener Teil von invalidem
HTML mit in MSIE funktionierendem JScript (allerdings fehlen hier zum
Funktionieren erforderliche Teile), erzeugt von Micros~1 AffrontPage.
(Dietmar Meier in <aq8afp$7cc0b$1...@ID-3767.news.dfncis.de>)
Ulf K@dner
> viel leeres Geblubber…
In Anbetracht Deiner vollkommen lernresistenten Verhaltensweise erspare
ich mir jedwigen sachlichen kommentar.
Doch eins gebe ich Dir noch mit zum drüber Nachdenken:
Wenn man keine Ahnung hat einfach mal den Schnabel zulassen.
EOD für mich.
Jo Schulze
Claus Reibenstein wrote:
>> Christian Albers wrote:
>>
>>> Am 15.02.2011 18:43, schrieb Claus Reibenstein:
>>> Eine kurze Google-Recherche brachte folgendes zu Tage:
>
> Nein, das schrieb ich nicht. Ich schrieb eigentlich gar nichts von
> dem, was Du hier zitiert hast. Warum Du meinen Namen trotzdem
> zitierst, ist mir schleierhaft.
Das ist korrekt. Sry, war keine böse Absicht dir irgendwas zu
unterstellen, AFAICS hat der USENET Client gesponnen.
>> Es gibt kein PHP6, die Art wie Unicode Unterstützung dafür geplant
>> war ist abgeleht worden.
>
> Wann? Von wem? Quelle?
php.internals irgendwo, da nicht durchsuchbar:
<http://marc.info/?t=126832843700001>
Vor dem 5.3 release.
Claus Reibenstein
> Claus Reibenstein wrote:
>
>> Jo Schulze schrieb:
>>
>>> Es gibt kein PHP6, die Art wie Unicode Unterstützung dafür geplant
>>> war ist abgeleht worden.
>>
>> Wann? Von wem? Quelle?
>
> php.internals irgendwo, da nicht durchsuchbar:
> <http://marc.info/?t=126832843700001>
"Nicht durchsuchbar" stimmt nicht. Gleich als erstes erscheint ein Suchfeld.
Allerdings gleicht die Suche hier dem Finden der berühmten Stecknadel im
nicht minder berühmten Heuhaufen. Vor allem, wenn man nicht die
richtigen Suchbegriffe hat, was bei mir offensichtlich der Fall ist
(habe nach etwa 1/2 Stunde aufgegeben). Auch ist die Darstellung der
Suchergebnisse alles andere als übersichtlich :-(
Gruß. Claus
Carsten Wiedmann
>>>> Es gibt kein PHP6, die Art wie Unicode Unterstützung dafür geplant
>>>> war ist abgeleht worden.
>>>
>>> Wann? Von wem? Quelle?
>
> nicht minder berühmten Heuhaufen. Vor allem, wenn man nicht die
> richtigen Suchbegriffe hat, was bei mir offensichtlich der Fall ist
> (habe nach etwa 1/2 Stunde aufgegeben). Auch ist die Darstellung der
> Suchergebnisse alles andere als übersichtlich :-(
Die Infos darüber zusammenzubringen ist wirklich mühselig. Sowas wie
eine Zusammenfassung gibt es hier:
http://lwn.net/Articles/379909/
Die Beschreibung der SVN-Revision "296284" ist ja auch bezeichnend:
| Moved the Unicode experiment from trunk to its own branch
| for reference.
(Und Trunk ist ja jetzt ~5.4 (oder genauer 5.3.99))
Gruß,
Carsten
Irmgard Schwenteck
>
> Das PHP-Modul für IIS 6.0 hat IIRC Probleme mit UTF-8-codiertem Quelltext;
> dieser wurde nicht ausgeführt (ob es eine Fehlermeldung gab, weiss ich nicht
> mehr). Mit Windows-1252-codiertem Quelltext gab es da kein Problem. Ob das
> an IIS oder am PHP-Modul lag, weiss ich nicht, da ich damals einfach
> (Eclipse für dieses Projekt) auf Windows-1252 umgestellt und utf8_encode()
> für die Ausgabe verwendet hatte.
Das muß an was anderem gelegen haben.
Hier läuft IIS6 schon seit Jahren, PHP (inzwischen 5.3) als CGI.
Ob die Scripte in UTF-8 mit und ohne BOM oder ISO-8859-1 oder ISO-8859-2
codiert sind, ist dem völlig egal.
Windows-1252 verwende ich nie, auch nicht für Intranet-Lösungen.
(das kann mein Editor gar nicht).
Gruß
Irmgard
Claus Reibenstein
> Die Infos darüber zusammenzubringen ist wirklich mühselig. Sowas wie
> eine Zusammenfassung gibt es hier:
> http://lwn.net/Articles/379909/
Wenn ich das richtig verstehe - ich hab's noch nicht komplett gelesen,
sondern nur überflogen -, scheint PHP6 erst mal komplett auf Eis gelegt
worden zu sein wegen der Unicode-Problematik.
Eine der IMHO größten Fehlentscheidungen an dieser Stelle scheint mir zu
sein, alles auf UTF-16 aufsetzen zu wollen. Die Kommentare zu diesem
Thema drehen sich zum großen Teil um genau dieses Problem.
Danke jedenfalls für den Link. Wenn ich mal viel Zeit habe, werde ich es
mir komplett zu Gemüte führen.
Gruß. Claus
Jo Schulze
> Wenn ich das richtig verstehe - ich hab's noch nicht komplett gelesen,
> sondern nur überflogen -, scheint PHP6 erst mal komplett auf Eis
> gelegt worden zu sein wegen der Unicode-Problematik.
Nicht ganz.
Die Unicode Problematik wurde als Punkt identifiziert der die weitere
Entwicklung von PHP blockiert. Auf der einen Seite die UTF-16
Befürworter, auf der anderen der Rest.
Um die weitere Entwicklung nicht zu blockieren wurde das Problem
vertagt.
Da bereits Bücher über PHP6 erschienen sind die ein PHP beschreiben das
wohl nie implementiert wird ist es eher unwahrscheinlich dass es jemals
ein PHP6 geben wird, welche (major) Version für das nächste release
gewählt wird ist ungewiss, wird aber schon disskutiert.