Benutzer Diskussion:Netspy/Archiv-2004

aus Wikipedia, der freien Enzyklopädie
Letzter Kommentar: vor 15 Jahren von Netspy in Abschnitt XHTML
Zur Navigation springen Zur Suche springen

Hallo Mario, im Artikel zu XHTML hast du die Passage geändert, dass XML-Parser ein Dokument ohne Kodierungsangabe als UTF-8-kodiert verarbeiten müssen. Dies ist aber richtig. Ein konformer XML-Parser muss gemäß dem XML-Standard (http://www.w3.org/TR/REC-xml/#NT-EncName) davon ausgehen, dass das Dokument UTF-8-kodiert (oder UTF-16 mit entsprechendem Byte-Order-Mark) ist: »In the absence of information provided by an external transport protocol (e.g. HTTP or MIME), it is a fatal error for an entity including an encoding declaration to be presented to the XML processor in an encoding other than that named in the declaration, or for an entity which begins with neither a Byte Order Mark nor an encoding declaration to use an encoding other than UTF-8. (...) Unless an encoding is determined by a higher-level protocol, it is also a fatal error if an XML entity contains no encoding declaration and its content is not legal UTF-8 or UTF-16.« Später: »Because each XML entity not accompanied by external encoding information and not in UTF-8 or UTF-16 encoding must begin with an XML encoding declaration, ...« (http://www.w3.org/TR/REC-xml/#sec-guessing-no-ext-info) Wenn also XHTML durch einen konformen XML-Parser verarbeitet wird und keine Kodierungsangabe gemacht wird (XML-Deklaration oder charset-Parameter im HTTP-Content-Type-Header), muss es UTF-8-kodiert sein (oder UTF-16 mit Byte-Order-Mark), ansonsten muss der XML-Parser die Verarbeitung abbrechen (fatal error). Opera und Mozilla unter Linux machen das auch teilweise, sie nehmen UTF-8 an und zeigen z.B. bei ISO-8859-1-kodierte 8-Bit-Zeichen nur Fragezeichen an. Bei Tests unter Windows hatte ich, soweit ich mich recht erinnere, bemerkt, dass sie unter Umständen sehr fehlertolerant sind und die verwendete Kodierung auch ohne Kodierungsangaben erraten. Wenn man ihnen ein ISO-8859-1-kodiertes XHTML-Dokument (als application/xhtml+xml freilich) ohne Kodierungsangabe vorsetzt, verarbeiten sie es manchmal trotzdem, obwohl es gemäß dem Standard kein gültiges XML-Dokument ist. Darauf kann man sich allerdings nicht verlassen, die Regeln des XML-Standards haben also durchaus praktische Relevanz. Für andere Parser wie libxml2 gilt das sowieso. -- molily 11:33, 9. Okt 2004 (CEST)

Hallo Mathias, ein XHTML-Benutzeragent ist aber eigentlich nie nur ein XML-Parser und somit kann man die Regeln für XML nicht immer 100%ig auf XHTML anwenden. Mozilla kann bspw. unter bestimmten Umständen die Zeichensatzkodierung selbständig erkennen ... -- net 13:42, 9. Okt 2004 (CEST)
Mir ging es darum, dem Leser zu vermitteln, dass man sich darauf nicht verlassen kann, weil es letztlich ein Verstoß gegen den XML-Standard ist. Es ist reine Fehlertoleranz, die übrigens dem Grundgedanken von XML widerspricht (keine Unklarheit hinsichtlich der Kodierung durch klare Regelungen, wann die Kodierung angegeben werden muss). -- molily 18:40, 9. Okt 2004 (CEST)
... oder es ist eine Standard-Kodierung eingestellt, weshalb man in der Praxis auch bei konformen XML-Parsern nicht immer davon ausgehen kann, dass UTF-8/16 bei fehlenden Angaben verwendet wird. ... -- net 13:42, 9. Okt 2004 (CEST)
Naja, dann ist es aber, was diesen Punkt angeht, kein konformer XML-Parser. Ein bisschen schwanger gibt es nicht. -- molily 18:40, 9. Okt 2004 (CEST)
... Das „kann der Benutzeragent“ war von mir aber schon so gemeint, dass in der Regel UTF-8/16 angewandt wird. ...
Das »kann« steht momentan im Zusammenhang »... kann der Benutzeragent gemäß dem XML-Standard ...«. Das »kann« ändert gegenüber dem vorigen »muss« den Sinn des kompletten Satzes. Ich wollte mit dem Satz ausdrücken, dass ein XHTML-Dokument, das keine XML-Deklaration enthält und nicht in UTF-8/16 (evtl. mit BOM) kodiert ist, strenggenommen kein gültiges XHTML-Dokument ist. Wenn man das Dokument direkt mit libxml2 o.ä. verarbeiten will, merkt man das schnell. Durch das »kann« wird diese Warnung m.E. abgeschwächt. Um die Verbindung zur Vorschrift des XML-Standards klarer herauszustellen, würde ich eher »sollte der Parser gemäß dem XML-Standard« oder ähnliches bzw. einen weiteren klärenden Satz vorschlagen. -- molily 18:40, 9. Okt 2004 (CEST)
... Hauptsächlich hatte ich den Artikel auch deshalb geändert, weil ich noch das „und keine Kodierung im HTTP-Header gesendet wurde“ einfügen wollte. ... -- net 13:42, 9. Okt 2004 (CEST)
Um die konkrete Browserunterstützung ging es (mir) nicht im fraglichen Satz, sondern um die generellen Anforderungen an konforme X(HT)ML-Dokumente und konforme XML-Parser. Ich hatte absichtlich nicht von Benutzeragenten bzw. Browsern geschrieben, sondern (im Satz davor) allgemein von Parsern. Es geht nicht nur um die HTTP-Situation, sondern um das Verarbeiten des XML-Markups in verschiedenen Situationen. Dazu gehört auch das lokale Speichern, bei dem die Kodierungsangabe im HTTP-Header letztlich nichts bringt. Wenn man serverseitig irgendetwas sinnvolles mit dem XHTML anfangen will, wird man schnell auf den besagten fatal error stoßen. -- molily 18:40, 9. Okt 2004 (CEST)
... Aber das sollte vielleicht wirklich noch mal überarbeitet werden. Evtl. wäre da eine Liste nicht schlecht, wo die verschiedenen Möglichkeiten zur Angabe der Zeichensatzkodierung absteigend nach ihrer Priorität aufgelistet werden. Als letztes bleibt dann halt der Standardwert UTF-8/16 übrig. -- net 13:42, 9. Okt 2004 (CEST)
Sicher ist lediglich die XML-Deklaration mit ausdrücklicher Kodierungsangabe. Wenn das Dokument dann als text/html ausgeliefert wird, sollte es möglichst ein meta-Element mit Kodierungsangabe haben (wegen lokaler Speicherung), bei application/xhtml+xml eine XML-Deklaration. Das müsste man jeweils dynamisch einfügen. Kodierungen im HTTP-Header sind zusätzlich natürlich auch sehr gut. Darauf sollten wir auf jeden Fall hinweisen. Das ist soweit ich es sehe die einzige zuverlässige Methode, die Rücksicht auf die Quirksmode-Thematik und die Kodierungsprobleme nimmt. -- molily 18:40, 9. Okt 2004 (CEST)

XHTML

Hi Netsky,

ich hab dir schon auf meiner Diskussionsseite geantwortet und hab nun noch einen Kommentar auf die XHTML-Diskussionsseite geschrieben, den du dir vielleicht durchlesen könntest. mfg FutureCrash 19:51, 17. Nov 2004 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: net 13:17, 24. Mär. 2009 (CET)