Dann überprüfe mal ob dein Webserver ein charset mitschickt, z.b. mit wget (Paramater -dv) oder einem anderen Tool das dir die Header die dein Server sendet anzeigt.

zitat aus dem aktuellen php-handbuch:

damit wirst du wohl nicht umhin kommen, deinen quellcode zu renovieren.

cx

Ich danke euch für eure Antworten. Was den wget vorschlag angeht so bin ich mir sicher das mein webserver UTF-8 versendet. Ich glaube cortex hat recht was die Sache angeht. Ich habe noch mal probiert den PHP Programm Quelltext umzuschreiben und neu zu compilieren so das die Funktionen standard mässig UTF-8 benutzen, aber auch das blieb ohne erfolg. Ist wohl auch keine besonders ISO konforme Lösung wenn es dann nur bei mir richtig laufen würde.

Hast du das Problem inzwischen lösen können. Ich stehe vor einem ähnlichen Problem. Auch ich würde gerne komplett auf UTF-8 schalten, also APACHE+PHP+DB/MySQL, damit es beim internationalen Umgang diverser Charsets keine Probleme mehr gibt.

Aus der PHP-Logik heraus, müsste er ja bei jeder Funktion, die auf den Charset zurückgreift automatisch prüfen, wie der default_charset in der PHP.INI lautet und diesen dann auch standardmäßig verwenden. Hmmm... ich hab' das jetzt nicht geprüft, aber falls dem noch nicht so ist, welche Funktionen arbeitet dann alle gegen diese Logik?

In diesen Posts wurden bereits erwähnt:
- htmlspecialchars()
- htmlentities()
- html_entity_decode()
... die alle im dritten Argument den Charset: 'UTF-8' akzeptieren. Aber gibt es noch weitere Funktionen, auf die man achten muss, da sie nicht standardmäßig auf den default_charset achten?

Häh? PHP verwendet intern keine bestimmte Kodierung. Es wird einfach alles als Binärstring verstanden. Wenn man jetzt bspw. einen in UTF-8-kodierten String aus einer Datenbank holt und den per echo() ausgibt, ändert PHP rein gar nichts an den Daten.

Dem Webbrowser dabei zu helfen, die Ausgaben auch als UTF-8 zu verstehen, ist deine Aufgabe: Sorge dafür, dass der entsprechende HTTP-Header gesendet wird und die XHTML|HTML-Datei die entsprechenden Meta-Informationen im Header-Teil eingebaut hat.

Htmlspecialchars() verändert nur Zeichen im ASCII-Range. Also kannst du bei UTF-8 den Encoding-Parameter auch weglassen. Möglicherweise ist das bei UCS2- oder UCS4-kodierten Web-Seiten anders. Aber wer versendet schon solche?

Htmlentities() und html_entity_decode() sind auf einer Website ohne erkennbaren Nutzen für mich, daher kann ich nicht sagen, ob ein charset-Parameter da einen Sinn ergibt.

Anders sieht es bei den String-Bearbeitungsfunktionen (speziell Vergleichsfunktionen) aus. Da gibt es einige, die tatsächlich "locale"-abhängig sind. Von denen würde ich die Finger lassen, weil niemand weiß, ob die auf zwei verschiedenen Servern zu einem gleichen Verhalten überredbar sind (von ASCII abgesehen). Um Unicode-Strings zu bearbeiten oder zu vergleichen, hat PHP ein Sammelsurium von im Laufe der Zeit zusammengestoppelten Funktionsbibliotheken wie iconv, mbstring, pcre (nur UTF-8 ) und intl zur Verfügung. Die Text-Ausgabefunktionen für OTF/TTF/Type1 der LibGD verstehen ebenfalls UTF-8.

http://www.w3.org/International/ques...charset.de.php
http://www.askapache.com/htaccess/se...-htaccess.html

Bedenke auch, falls du Meta-Notierungen oder XML-Encoding Notierungen im Veröffentlichten Quellcode deiner Webs hast, das diese auch verändert werden sollten.