nicht angemeldet
Hallo dedlfix,
danke für Deine Zeit.
»» Besser ist das. Nötig ist es aber nur, wenn im Quelltext Zeichen vorkommen, die jenseits von ASCII liegen.
Verstehe, dann bevorzuge ich aber den Editor der das kann.
»» Im Zend Studio 5.2.0 Professional Edition Build 233 lässt sich das Encoding einstellen.
Aha, ist die Software also schon wieder veraltet.
»» Wenn die 183er Ausgabe das nicht kann ... Pech gehabt. Updaten, anderen Editor verwenden, hinterher iconv oder recode auf die Dateien anwenden, ...
Update ist schon unterwegs.
»» Wichtiger als die charset-Angabe im Meta-Element Content-Type ist die Angabe des gleichnamigen HTTP-Headers, den der hat Vorrang wenn beide vorhanden sind. Oder anders gesagt: Das Meta-Element ist nur ein Ersatz für eine fehlende HTTP-Header-Angabe.
Also klar, muss rein, wichtiger ist aber der HTTP-Header.
»» PHP bietet momentan nur rudimentäre/kaum Unterstützung beim Thema Zeichensatz/-kodierung. Erst PHP 6 wird vollständig mit Multibyte-Zeichenkodierungen umgehen können. Solange liefert strlen() beispielsweise bei einem UTF-8-kodierten Täst eine Länge von 5.
»» Es gibt zwar die Multibyte String Functions-Extension, doch die ist nicht bei jedem Hoster freigegeben (und wohl auch nicht besonders schnell). Zur bisherigen UTF-8-Unterstützung gibt es eine Übersicht: http://wiki.silverorange.com/UTF-8_Notes
Hab mir beides angeschaut, ehrlich gesagt kann ich das so gar nicht brauchen, seufz. Was passiert denn wenn ich in meiner UTF-8 Kette bei PHP ISO-8859-1 nutze? Was genau geht da schief? Ich muss dazu sagen, dass ich bisher eine Mischung aus beiden habe und bisher habe ich noch keinen Nachteil bemerkt. Weder lokal noch online.
Ich muss aber sicherstellen, dass Clients die kein ISO-8859-1 erwarten sondern u.a. UTF-8 keinen Buchstabensalat am Bildschirm haben.
»» Es gibt viele verschiedene Stellen, an denen in MySQL eine Angabe zum Zeichensatz/-kodierung wirkt. Das MySQL-Handbuch spendiert diesem Thema ein eigenes Haupt-Kapitel. Wichtig für die Kommunikation mit Clients (z.B. PHP) sind die "Connection Character Set"-Einstellungen. (Zusammenfassung: SET NAMES utf8)
Alles klar, ist im Griff.
»» Diese Transfer-Encoding-Angabe ist in dem Zusammenhang unwichtig. Am Content-Type-Header hängt eine charset-Angabe dran, oder auch nicht. Ändern kannst du das durch eine Konfiguration des Apachen. Schau dir die Direktiven an, die was mit "Charset" im Namen haben. Oder du kannst mit PHP selbst einen passenden Content-Type-Header inklusive charset-Angabe senden. (header())
Bei meinem Provider war das bisher unproblematisch. Das sind supernette Leute, die haben bis jetzt alle Änderungen an der Konfiguration vorgenommen um die sie gebeten habe.
Mit PHP header() ist es eher umständlich. Gefällt mir nicht so gut, behalte ich aber im Hinterkopf, ist zumindest eine Möglichkeit.
»» Neben dem Websniffer gibt es Erweiterungen für die Browser, z.B. die livehttpheaders-Extension für den Firefox.
Das ist ja sensationell! Diese 87 kB bereiten mir mehr Freude als so manche Megabyte grossen Anwendungen. Allerdings habe ich jetzt gleich zuviel Informationen, allen Ernstes:
GET / HTTP/1.1
Host: domain.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1) Gecko/20061010 Firefox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
HTTP/1.x 200 OK
Date: Fri, 22 Dec 2006 10:04:18 GMT
Server: Apache/1.3.36 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.4.2 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.27 OpenSSL/0.9.7a mod_mono/1.0.2
X-Powered-By: PHP/4.4.2
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 -> Heisst das, dass das Dokument mit zwei Kodierungen gesendet wird, oder wie?
Danke und Gruss