nicht angemeldet dedlfix
Gunnar Bittersmann
dedlfix
dedlfix
Gunnar Bittersmann
Gunnar Bittersmann
dedlfix
dedlfix
Gunnar Bittersmann
Guten Abend!
Ich bin grad dabei von der Standard ISO Kodierung auf utf-8 umzusteigen, da xhtml sich besser damit macht ;)
Ich nutze zum Entwickeln Zend Studio, welches utf-8 Kodierung nur ohne BOM unterstützt.
Um den Internet Explorer auch meine Seiten zu zeigen, verzichte ich auf die XML Deklaration; eine meta Angabe möchte ich nur notfalls einfügen (es sollte auch ohne funktionieren).
Nun weiß ich, dass die Kodierung vom HTTP Header abhängt, dieser sendet auf meinem Testserver allerdings keine Kodierung (1).
Somit bleibt als einzige Möglichkeit (bisher) zu erkennen, welche Kodierung da ist, indem der Browser sich die Datei ansieht. Es scheint aber, dass weder Firefox noch IE utf-8 kodierte Dateien erkennen, wenn kein BOM dabei ist. Da ich aber nur ungern meinen Editor wechseln möchte und BOM manchmal Probleme machen könnte (2), möchte ich darauf verzichten BOM zu verwenden.
Wie würdet ihr jetzt empfehlen, die Datei als utf-8 erkennbar zu machen bzw. wie macht ihr es selber?
Soll ich per .htaccess den ContentType für .html und .css ändern, und in der php.ini einstellen, dass die Dateien als utf-8 gesendet werden? Reicht dazu die AddDefaultCharset-Direktive von Apache?
Vielen Dank für jede Antwort
Patrick
-----
Anhang:
(1) Beispiel Header:
-----
Date: Tue, 24 Jul 2007 19:54:59 GMT
Server: Apache/2.2.4 (Win32) PHP/5.2.3
Last-Modified: Tue, 24 Jul 2007 19:40:36 GMT
Etag: "12d65-3a9b-913fa087"
Accept-Ranges: bytes
Content-Length: 15003
Content-Type: text/html
200 OK
(2) http://www.w3.org/International/questions/qa-utf8-bom
echo $begrüßung;
eine meta Angabe möchte ich nur notfalls einfügen (es sollte auch ohne funktionieren).
Warum? Damit machst du nur dir und anderen das Leben schwer, wenn das Dokument lokal gespeichert werden soll, denn das passiert ohne HTTP-Header, und somit steht das Dokument gänzlich ohne Kodierungsangabe da.
Es scheint aber, dass weder Firefox noch IE utf-8 kodierte Dateien erkennen, wenn kein BOM dabei ist.
Das liegt daran, dass ein UTF-8-kodiertes Dokument immer auch mindestens ein gültiges ISO-8859-X Dokument ist. Ein Browser braucht viel Intelligenz, um die ursprüngliche Kodierung zu erraten. Eine Analyse müsste mittels Wörterbuchern der verschiedenen Sprachen geschehen und selbst dann ist das Rateergebnis ungewiss. Hinzu kommt noch, dass erstmal die Sprache erraten werden muss, was ohne Kodierungsangabe schwierig bis unmöglich ist - ein Henne-und-Ei-Problem.
Wie würdet ihr jetzt empfehlen, die Datei als utf-8 erkennbar zu machen bzw. wie macht ihr es selber?
Angabe in HTTP-Header und Meta-Äquivalent.
Soll ich per .htaccess den ContentType für .html und .css ändern, und in der php.ini einstellen, dass die Dateien als utf-8 gesendet werden? Reicht dazu die AddDefaultCharset-Direktive von Apache?
AddDefaultCharset wirkt auf alle text/plain- und text/html-Dokumente. In der php.ini ist die Angabe dann nicht mehr erforderlich. Außerdem kann der Content-Type-Header auch im Script mittels header() generiert werden.
echo "$verabschiedung $name";
Hello out there!
Das liegt daran, dass ein UTF-8-kodiertes Dokument immer auch mindestens ein gültiges ISO-8859-X Dokument ist.
Nein, das ist es nicht.
Nicht immer jedenfalls, sondern nur dann, wenn in der Oktettsequenz nur Werte kleiner als 80 (hexadazimal) vorkommen; also im Dokument nur Basic-Latin-Zeichen vorkommen. [https://forum.selfhtml.org/?t=156477&m=1018379]
Ein Browser braucht viel Intelligenz, um die ursprüngliche Kodierung zu erraten.
Warum sollte er das tun? Bei Abwesenheit jeglicher Information nimmt er ISO 8859-1 an.* Ein 'ä' in einem eigentlich UTF-8-codierten Dokument wird dann als 'ä' dargestellt. (Dieses Verhalten wird oft hier im Forum beschrieben und nachgefragt, warum das so ist.)
See ya up the road,
Gunnar
* gemäß HTTP-Spec, obwohl er es gemäß HTML-Spec nicht darf. [HTML401 §5.2.2]
echo $begrüßung;
Das liegt daran, dass ein UTF-8-kodiertes Dokument immer auch mindestens ein gültiges ISO-8859-X Dokument ist.
Nein, das ist es nicht.
Nicht immer jedenfalls, sondern nur dann, wenn in der Oktettsequenz nur Werte kleiner als 80 (hexadazimal) vorkommen; also im Dokument nur Basic-Latin-Zeichen vorkommen. [https://forum.selfhtml.org/?t=156477&m=1018379]
Wenn du auf die Positionen 0x80-9F anspielst, die sind nur unbenutzt. Für mich heißt das nicht, dass ein ISO-8859-Dokument ungültig wird, wenn es Werte aus diesem Bereich enthält.
Und warum ein Dokument mit Oktetts ab 0x80 aufwärts kein gültiges ISO-8859-Dokument sein soll, erschließt sich mir auch aus deinem Link nicht. Jede der ISO-8859-Kodierungen enthält Oktetts zumindest aus dem Bereich 0xA0-FF.
Ein Browser braucht viel Intelligenz, um die ursprüngliche Kodierung zu erraten.
Warum sollte er das tun?
Mein Satz sollte eigentlich im Konjunktiv stehen. Nichtsdestotrotz, manche machen es halt, um sich unfähigen HTML-"Programmierern" gefälliger zu zeigen. (Browser machen noch ganz andere Sachen, die nicht oder nicht genau spezifiziert sind.) Soweit ich hier im Forum erfahren habe, hat zumindest Firefox (oder Gecko oder wie auch immer) eine Kodierungsrateroutine eingebaut.
echo "$verabschiedung $name";
Hi dedlfix!
Warum? Damit machst du nur dir und anderen das Leben schwer, wenn das Dokument lokal gespeichert werden soll, denn das passiert ohne HTTP-Header, und somit steht das Dokument gänzlich ohne Kodierungsangabe da.
Letzendlich wird das Ganze eh eine sehr dynamische Sache, was die lokale Ansicht nicht möglich machen wird ;)
AddDefaultCharset wirkt auf alle text/plain- und text/html-Dokumente. In der php.ini ist die Angabe dann nicht mehr erforderlich. Außerdem kann der Content-Type-Header auch im Script mittels header() generiert werden.
Wirkt sich die Einstellung in der php.ini nicht auch auf die dateiinterne Kodierung der geparsedten (<- dämliches denglisch) Datei aus? Also entsprechend der dateiinternen Kodierung vom Editor? Oder wird die von der php Datei übernommen? Oder versteh ich grad was falsch? ^^
Gruß
Patrick
echo $begrüßung;
Wirkt sich die Einstellung in der php.ini nicht auch auf die dateiinterne Kodierung der geparsedten (<- dämliches denglisch) Datei aus?
Nein, laut Beschreibung wird einfach nur der dort angegebene Wert im entsprechenden Header eingetragen. Auf Richtigkeit wird er nicht geprüft, auch sonst wird er nicht ausgewertet.
Also entsprechend der dateiinternen Kodierung vom Editor? Oder wird die von der php Datei übernommen?
PHP kennt derzeit keine Kodierungsvarianten für Quelltext. Seine eigenen Bezeichner, Operatoren und sonstige Zeichen sind in reinem ASCII angesiedelt. Für andere Bezeichner werden die Bytes einzeln betrachtet, deren Werte auch im Bereich 0x7f-0xff liegen können. Es kann auch von Haus aus nicht mit Multibyte-Kodierungen umgehen. Strings werden als Bytefolge angesehen, wenn du mit den Standard-Stringfunktionen arbeitest. Nur einige wenige Funktionen, speziell solche die zur Umkodierung verwendet werden, kennen sich mit Multibytekodierungen aus. Ab PHP 6 wird das anders.
echo "$verabschiedung $name";
Hello out there!
Es scheint aber, dass weder Firefox noch IE utf-8 kodierte Dateien erkennen, wenn kein BOM dabei ist.
Nope. Weder Firefox noch IE* verarbeiten das Dokument als XHTML wegen
Content-Type: text/html
sondern schicken es durch den Tag-Soup-Parser. Dieser ist durchaus empfänglich für HTTP-EQUIV-Angaben (wenn es keine dementsprechende Angabe im HTTP-Header gibt). Mache eine solche – so früh wie möglich im Dokument. [HTML401 §5.2.2]
Fehlt jegliche Angabe zur Zeichencodierung, wird ISO 8859-1 angenommen. Im Tag-Soup-Parser wohlgemerkt; bei Verarbeitung als XHTML (Content-Type: application/xhtml+xml) wird bei nichtvorhandenem BOM UTF-8 angenommen. [XML §4.3.2, XML §F.1]
Soll ich per .htaccess den ContentType für .html und .css ändern, und in der php.ini einstellen, dass die Dateien als utf-8 gesendet werden?
Auch das wäre möglich, wenn du wirklich alle Dokumente in dieser Codierung hast.
Reicht dazu die AddDefaultCharset-Direktive von Apache?
Für CSS (Content-Type: text/css) nicht. U.U. ist es dafür aber auch nicht nötig. [https://forum.selfhtml.org/?t=156477&m=1019013] Wenn doch: AddCharset.
See ya up the road,
Gunnar
* IE schon wegen seiner Unfähigkeit nicht
Hallo Gunnar!
Fehlt jegliche Angabe zur Zeichencodierung, wird ISO 8859-1 angenommen. Im Tag-Soup-Parser wohlgemerkt; bei Verarbeitung als XHTML (Content-Type: application/xhtml+xml) wird bei nichtvorhandenem BOM UTF-8 angenommen. [XML §4.3.2, XML §F.1]
Nur ist die Ausgabe als application/xhtml+xml leider noch nicht wirklich sinnvoll :(
Ich verstehe nur nicht, warum die Browser nicht einfach versuchen, bei fehlenden Kodierungsinformationen, die Kodierung aus der Datei zu lesen - so wie Editoren es auch machen..
Auch das wäre möglich, wenn du wirklich alle Dokumente in dieser Codierung hast.
Davon ist dann auszugehen ;)
Für CSS (Content-Type: text/css) nicht. U.U. ist es dafür aber auch nicht nötig. [https://forum.selfhtml.org/?t=156477&m=1019013] Wenn doch:
AddCharset.
Hm, naja, ich speicher die Dateien aufjeden Fall als utf-8 ab.. content werde ich denk ich nicht nutzen, von daher sollte das keine Probleme machen.
Ich habe bereits probiert @charset 'utf-8'; an den Anfang der Datei zu setzen, aber die Kodierung blieb trotzdem ISO-8859-1..
Aber ich werde denk ich mal dann auf die .htaccess methode zurückgreifen und zusätzlich noch die meta Angabe angeben (zur Sicherheit).
Wie sieht das bei php aus? Muss ich da für .php Dateien die Kodierung setzen (von Apache aus) oder sendet php automatisch einen Header, wenn ich die php.ini dementsprechend bearbeite?
Gruß
Patrick
Hello out there!
Ich verstehe nur nicht, warum die Browser nicht einfach versuchen, bei fehlenden Kodierungsinformationen, die Kodierung aus der Datei zu lesen - so wie Editoren es auch machen..
Weil es nicht Aufgabe des Browsers sein kann, beim Empfang der Oktettsequenz C3 A4 zu entscheiden, ob ein Webseitenautor damit die Zeichenfolge 'ä' oder das Zeichen 'ä' gemeint hatte.
See ya up the road,
Gunnar
echo $begrüßung;
Ich habe bereits probiert @charset 'utf-8'; an den Anfang der Datei zu setzen, aber die Kodierung blieb trotzdem ISO-8859-1..
Hier unterliegst du anscheinend einem Denkfehler. Wenn du auf einen Briefumschlag "200 €" schreibst, wandelt sich dessen Inhalt nicht automatisch in einen Geldschein um. Du musst schon selbst für den zur Beschriftung passenden Inhalt oder umgekehrt sorgen.
echo "$verabschiedung $name";
Hi dedlfix,
Hier unterliegst du anscheinend einem Denkfehler. Wenn du auf einen Briefumschlag "200 €" schreibst, wandelt sich dessen Inhalt nicht automatisch in einen Geldschein um. Du musst schon selbst für den zur Beschriftung passenden Inhalt oder umgekehrt sorgen.
wofür gibts die Funktion dann, wenn sie eh nichts zu sagen hat? Weil im Header stand nichts und ich bin davon ausgegangen, dass @charset 'utf-8'; dann so wirkt wie die meta Angabe oder der XML Header in der html Datei..
Gruß
Patrick
echo $begrüßung;
Weil im Header stand nichts und ich bin davon ausgegangen, dass @charset 'utf-8'; dann so wirkt wie die meta Angabe oder der XML Header in der html Datei..
Ja, alle diese Angaben sagen dem Empfänger, in welcher Kodierung das Dokument vorliegt. Sie dienen nicht dazu, dem Editor zu sagen, welche Kodierung er beim Speichern verwenden soll. Mir ist auch kein Editor bekannt, der diese Angabe auswertet.
echo "$verabschiedung $name";
Hi Patrick,
Um den Internet Explorer auch meine Seiten zu zeigen, verzichte ich auf die XML Deklaration;
...welche auch nicht benötigt wird, wenn das Dokument-Encoding UTF-8 oder UTF-16 entspricht.
eine meta Angabe möchte ich nur notfalls einfügen (es sollte auch ohne funktionieren).
diese Denke ist Blödsinn, IMHO. Die meta-Angabe zum Zeichensatz wird herangezogen, wenn kein HTTP-Header zur Verfügung steht, also außerhalb von HTTP, z.B. beim Öffnen im Browser aus dem Filesystem. Sie schadet aber keinesfalls - falls ein HTTP-Header zur Verfügung steht, bekommt die Angabe darin den Vorzug.
dieser sendet auf meinem Testserver allerdings keine Kodierung (1).
das ist schlecht!
Wie würdet ihr jetzt empfehlen, die Datei als utf-8 erkennbar zu machen bzw. wie macht ihr es selber?
den HTTP-Server dazu bringen, einen entsprechenden charset im Content-Type mitzusenden. Und, wie gesagt zusätzlich, eine entsprechende meta-Angabe vornehmen, damit die Seite auch lokal korrekt angezeigt wird.
Reicht dazu die AddDefaultCharset-Direktive von Apache?
diese wird auf alle Dokumente, die mit dem Content-Type text/html ausgeliefert werden, angewendet? Dann sollte sie reichen, da bin ich mir aber nicht 100% sicher.
Gruß,
Andreas.
Hello out there!
dieser sendet auf meinem Testserver allerdings keine Kodierung (1).
das ist schlecht!
Warum?
Auf diese Art wäre es einfach, Dokumente, die in unterschiedlichen Codierungen vorliegen, auszuliefern (vorhandene HTTP-EQUIV-Angabe vorausgesetzt).
Andernfalls müsste man bie einer von der mit AddCharset / AddDefaultCharset gesetzten Codierung rumfrickeln: <Files> oder andere Extension oder gar PHP bemühen.
See ya up the road,
Gunnar
Hi Gunnar,
Warum?
weil man nicht davon ausgehen kann, dass der produktive HTTP-Server dies ebenso (nicht) macht.
Andernfalls müsste man bie einer von der mit
AddCharset/AddDefaultCharsetgesetzten Codierung rumfrickeln:<Files>oder andere Extension oder gar PHP bemühen.
ja, aber das ist doch nicht schlimm!?
Gruß,
Andreas.
Nabend!
Warum?
weil man nicht davon ausgehen kann, dass der produktive HTTP-Server dies ebenso (nicht) macht.
Der Server, auf dem das später alles laufen wird gibt mir folgenden Header:
Date: Tue, 24 Jul 2007 21:29:55 GMT
Server: Apache/2.0.54 (Debian GNU/Linux) mod_python/3.1.3 Python/2.3.5 mod_ssl/2.0.54 OpenSSL/0.9.7e
X-Powered-By: PHP/4.3.10-22
Keep-Alive: timeout=15, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
200 OK
Um den Internet Explorer auch meine Seiten zu zeigen, verzichte ich auf die XML Deklaration;
...welche auch nicht benötigt wird, wenn das Dokument-Encoding UTF-8 oder UTF-16 entspricht.
Naja, in Zukunft wird die XML Deklaration dazu gehören. Nämlich dann, wenn XHTML endlich als XML geparsed wird..
Und eben deswegen sollte man, wenn möglich, schon jetzt auf den meta Tag verzichten (denn der gehört nicht zu den kommenden xhtml versionen dazu)
den HTTP-Server dazu bringen, einen entsprechenden charset im Content-Type mitzusenden. Und, wie gesagt zusätzlich, eine entsprechende meta-Angabe vornehmen, damit die Seite auch lokal korrekt angezeigt wird.
Also per .htaccess sollte das ganze ausreichen.
Danke euch :)
Gruß
Patrick
Hello out there!
...welche auch nicht benötigt wird, wenn das Dokument-Encoding UTF-8 oder UTF-16 entspricht.
Naja, in Zukunft wird die XML Deklaration dazu gehören. Nämlich dann, wenn XHTML endlich als XML geparsed wird..
Aber gerade dann kannst du diese auch weglassen, wenn du in UTF-8 codierst.
Und eben deswegen sollte man, wenn möglich, schon jetzt auf den meta Tag verzichten
Sagt wer? Wer auch immer, es ist Unsinn.
(denn der gehört nicht zu den kommenden xhtml versionen dazu)
Was hat XHTML 2 mit heutiger Praxis zu tun?
See ya up the road,
Gunnar
Nochmal hi Gunnar!
Und eben deswegen sollte man, wenn möglich, schon jetzt auf den meta Tag verzichten
Sagt wer? Wer auch immer, es ist Unsinn.
W3C persönlich ^^
http://www.w3.org/International/tutorials/tutorial-char-enc/#invalid
(denn der gehört nicht zu den kommenden xhtml versionen dazu)
Was hat XHTML 2 mit heutiger Praxis zu tun?
Wie gesagt: leider nichts..
Gruß
Patrick
Hello out there!
Und eben deswegen sollte man, wenn möglich, schon jetzt auf den meta Tag verzichten
Sagt wer? Wer auch immer, es ist Unsinn.
W3C persönlich ^^
http://www.w3.org/International/tutorials/tutorial-char-enc/#invalid
</hilfe/bedienung.htm#verweise-einbinden>, danke.
Und was steht da? “You should similarly not use the meta element to declare character encodings in XHTML served as XML.” Ist denn dein XHTML _served as XML_?
Was hat XHTML 2 mit heutiger Praxis zu tun?
Wie gesagt: leider nichts..
Wieso „wie gesagt“? Du hattest dich lediglich beklagt, dass man in heutiger Praxis XHTML nicht als 'application/xhtml+xml' ausliefern sollte. Mit XHTML 2 hat das nichts zu tun.
Auch in als XML ausgeliefertem XHTML 1.0 ist eine '<meta http-equiv="content-type" content="text/html; charset=UTF-8" />'-Angabe kein Fehler.
See ya up the road,
Gunnar
</hilfe/bedienung.htm#verweise-einbinden>, danke.
danke ;)
Und was steht da? “You should similarly not use the meta element to declare character encodings in XHTML served as XML.” Ist denn dein XHTML _served as XML_?
Nein, aber es ging ja auch eben darum, dass wir derzeit keine Vorteile von XHTML haben (zumindest nicht als text/html) und somit XHTML - zumindest für mich - nur schonmal Gewöhnung für "bessere Zeiten" ist.. Und dazu gehört nunmal eigentlich auch, dass man gleich so schreibt, dass man später nur noch den Content Type ändert und dann ein valides, echtes XHTML Dokument hat.
Mit XHTML 2 hat das nichts zu tun.
Hab ich auch nicht gesagt. Ich beziehe mich da eher auf XHTML 1.1 welches doch etwas mehr Verbreitung hat und im Firefox z.B. auch schon funktioniert. Ich fänd es schön, wenn das auch in anderen Browsern so wäre..
Und könnten die bekannten Browser alle etwas mit application/xhtml+xml anfangen, dann wäre XHTML1.1 sicherlich kein working draft mehr.. und selbst wenn würde es benutzt werden.
Gruß
Patrick
Hello out there!
Nein, aber es ging ja auch eben darum, dass wir derzeit keine Vorteile von XHTML haben (zumindest nicht als text/html)
Doch, die haben wir. [http://forum.de.selfhtml.org/archiv/2007/7/t156468/#m1018194 und dortige Links, http://forum.de.selfhtml.org/archiv/2007/7/t156210/#m1016646, http://forum.de.selfhtml.org/archiv/2007/1/t145129/#m941741]
Ich beziehe mich da eher auf XHTML 1.1
Das allerdings hat keine Vorteile, dafür aber erhebliche Nachteile [http://forum.de.selfhtml.org/archiv/2007/1/t145129/#m941741, Archiv]
See ya up the road,
Gunnar
Nein, aber es ging ja auch eben darum, dass wir derzeit keine Vorteile von XHTML haben (zumindest nicht als text/html)
Doch, die haben wir. [http://forum.de.selfhtml.org/archiv/2007/7/t156468/#m1018194 und dortige Links, http://forum.de.selfhtml.org/archiv/2007/7/t156210/#m1016646, http://forum.de.selfhtml.org/archiv/2007/1/t145129/#m941741]
Vorteile, die erst richtig zur Geltung kommen, wenn sie durch einen XML Parser gehen.. Dieser findet die Fehler schnell.. Aber als text/html muss man extra einen Parser zur Hand nehmen, um das ganze zu testen -> Unnötiger Aufwand eigentlich..
Einfachere Regeln und dadurch weniger Möglichkeiten Fehler zu machen.. Wer mit HTML arbeitet, gewöhnt sich an diese Regeln und Fehler passieren dort auch nicht so oft. Und selbst wenn richten es die derzeiten Browser eh von selbst..
Und auch ein HTML Validator nennt dir Fehler im Quelltext (z.B. nicht geschlossener Tag)
Naja, für mich sind die einzigen Vorteile für XHTML derzeit, dass ich erstens auf kommende Unterstützung vorbereitet bin und mir zweitens XHTML intuitiver erscheint (dadurch, dass ich auch mit XML arbeite) - aber das ist wohl Geschmackssache..
Ich beziehe mich da eher auf XHTML 1.1
Das allerdings hat keine Vorteile, dafür aber erhebliche Nachteile [http://forum.de.selfhtml.org/archiv/2007/1/t145129/#m941741, Archiv]
Naja, "Nachteile" wegen mangelnder Unterstützung der Browser lasse ich nicht gelten.
Gruß
Patrick
Hello out there!
Und auch ein HTML Validator nennt dir Fehler im Quelltext (z.B. nicht geschlossener Tag)
Nein. Nicht, wenn das End-Tag optional ist; wenn es also kein Fehler im Sinne der HTML-DTD ist.
Allerdings ist das Markup nicht das, was der Autor im Sinn hatte. Ein Beispiel, wo das Problem deutlich wird, ist in den genannten Links zu finden.
Naja, "Nachteile" [von XHTML 1.1] wegen mangelnder Unterstützung der Browser lasse ich nicht gelten.
Den Nachteil, die Sprache von Textpassagen nicht angeben zu können, auch nicht?
Dass Imagemaps nicht möglich sind, auch nicht?
See ya up the road,
Gunnar
