[XML/XHTML] encoding declaratie

[X-Lars]

Via dit artikel (zie evt. ook de comments) kwam ik bij het W3C terecht. Ik zal het voor het gemak wel even quoten:

quote: http://www.w3.org/TR/webarch/#xml-media-types

Second, representations whose Internet media types begin with "text/" are required, unless the charset parameter is specified, to be considered to be encoded in US-ASCII. Since the syntax of XML is designed to make documents self-describing, it is good practice to omit the charset parameter, and since XML is very often not encoded in US-ASCII, the use of "text/" Internet media types effectively precludes this good practice.

Good practice: XML and character encodings. In general, a representation provider SHOULD NOT specify the character encoding for XML data in protocol headers since the data is self-describing.

quote: http://www.w3.org/TR/xhtml1/#C_9

Historically, the character encoding of an HTML document is either specified by a web server via the charset parameter of the HTTP Content-Type header, or via a meta element in the document itself. In an XML document, the character encoding of the document is specified on the XML declaration (e.g., <?xml version="1.0" encoding="EUC-JP"?>). In order to portably present documents with specific character encodings, the best approach is to ensure that the web server provides the correct headers. If this is not possible, a document that wants to set its character encoding explicitly must include both the XML declaration an encoding declaration and a meta http-equiv statement (e.g., <meta http-equiv="Content-type" content="text/html; charset=EUC-JP" />). In XHTML-conforming user agents, the value of the encoding declaration of the XML declaration takes precedence.

Note: be aware that if a document must include the character encoding declaration in a meta http-equiv statement, that document may always be interpreted by HTTP servers and/or user agents as being of the internet media type defined in that statement. If a document is to be served as multiple media types, the HTTP server must be used to set the encoding of the document.

Het gaat mij er om wat nou "best practice" is. Je zet in een XHTML en XML document een XML declaratie, eventueel met een encoding declaratie. Ik ging er vanuit dat de vermelding van een encoding declaratie sowieso de bedoeling is (ook al is deze middels een HTTP header al bekend). En ik dacht dat het http-equiv-statement niet wordt herkend door XML applicaties. Kan iemand mij een beetje helder uitleggen hoe het zit?

[Verwijderd]

In het document hebben ze het over XHTML als text/html dus feitelijk gewoon HTML. Om XHTML zowel "forward-" als "backwards-compatible" te houden heb je dus alle methodes nodig.

Het beste is uiteraard er gewoon niet aan te beginnen. Best practice lijkt me gewoon HTML 4.01 en de karaktercodering via de server doorgeven. Eventueel een META element erbij, maar daar heb je niet echt veel aan.

[T-MOB]

Verwijderd schreef op woensdag 19 januari 2005 @ 23:26:
In het document hebben ze het over XHTML als text/html dus feitelijk gewoon HTML. Om XHTML zowel "forward-" als "backwards-compatible" te houden heb je dus alle methodes nodig.

Het beste is uiteraard er gewoon niet aan te beginnen. Best practice lijkt me gewoon HTML 4.01 en de karaktercodering via de server doorgeven. Eventueel een META element erbij, maar daar heb je niet echt veel aan.

Ok, maar stel dat je XHTML als XML verstuurt aan browsers die het snappen. Is het dan voldoende om <?xml version="1.0" encoding="XXXXX"?> op te nemen?

Verder is het niet "uiteraard" beter om iets te gebruiken dat microsoft ook ondersteund. Dat is context-afhankelijk.

[NoControl]

Moeilijk issue, als je je website beschikbaar wilt houden voor ~90% van de bezoekers (IE).
Snel gekopieerd uit deze website:

If you use XHTML, you should deliver it with the application/xhtml+xml
MIME type. If you do not do so, you should use HTML4 instead of XHTML.
The alternative, using XHTML but delivering it as text/html, causes
numerous problems that are outlined below.

Unfortunately, IE6 does not support application/xhtml+xml (in fact, it
does not support XHTML at all).

edit:
Dus zoals Anne al zei, best gewoon niet aan beginnen.
Maar moest je zowel XHTML willen gebruiken, een zo correct mogelijke content-type willen meesturen, en ook IE-bezoekers kunnen ontvangen kunnen de volgende sites en tekst je vast de juiste richting wijzen.

Om dit ongeveer in praktijk te brengen heb ik dit PHP-scriptje geschreven (wat ongetwijfeld nog niet 1000% standaard-compliant is, zoals sites zoals http://keystonewebsites.com/articles/mime_type.php, http://www.autisticcuckoo...11/03/content-negotiation en vele anderen wel zullen beamen.

PHP:

if ( !headers_sent() )
    if ( stristr( $_SERVER[ 'HTTP_ACCEPT' ] , 'application/xhtml+xml' ) )
        header( 'Content-Type: application/xhtml+xml; charset=UTF-8' );
    else
        header( 'Content-Type: text/html; charset=UTF-8' );

Het lijkt toch te werken: mozilla (en andere browsers die de server vertellen dat ze application/xhtml+xml ondersteunen) krijgen dat content-type, IE en anderen krijgen text/html...

Daarna heb ik de standaard XHTML reutemeteut (zonder nog een meta tag met het content-type of de encoding):

HTML:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="nl">

[ Voor 27% gewijzigd door NoControl op 20-01-2005 04:39 ]

[Verwijderd]

Ok, maar stel dat je XHTML als XML verstuurt aan browsers die het snappen. Is het dan voldoende om <?xml version="1.0" encoding="XXXXX"?> op te nemen?

Dan heb je het niet nodig. UTF-8 is de standaard karaktercodering voor XML.

Verder is het niet "uiteraard" beter om iets te gebruiken dat microsoft ook ondersteund. Dat is context-afhankelijk.

Huh, waar heb ik het over Microsoft? Een veel groter nadeel is dat "incremental display" er niet is in de huidige browsers voor XHTML (XML).

[Verwijderd]

Het lijkt toch te werken: mozilla (en andere browsers die de server vertellen dat ze application/xhtml+xml ondersteunen) krijgen dat content-type, IE en anderen krijgen text/html...

Even een counterquote:

quote: http://www.mozilla.org/docs/web-developer/faq.html#accept

There is a fad of serving text/html to IE but serving the same markup with no added value as application/xhtml+xml to Mozilla. This is usually done without a mechanism that would ensure the well-formedness of the served documents. Mechanisms that ensure well-formed output include serializing from a document tree object model (eg. DOM) and XSLT transformations that do not disable output escaping. When XHTML output has been retrofitted to a content management system that was not designed for XML from the ground up, the system usually ends up discriminating Mozilla users by serving tag soup labeled as XML to Mozilla (leading to a parse error) and serving the same soup labeled as tag soup to IE (not leading to a parse error).

[X-Lars]

OK, bedankt voor de replies. Ik doelde echter wel op de encoding bij XML en XHTML documenten. Het content type verhaal heeft daar op zich helemaal niets mee te maken.

Als het om een XML document gaat is het volgens deze quote wel gewoon nodig om de encoding declaratie op te geven:

quote: http://www.w3.org/TR/REC-xml/#sec-guessing

This level of autodetection is enough to read the XML encoding declaration and parse the character-encoding identifier, which is still necessary to distinguish the individual members of each family of encodings (e.g. to tell UTF-8 from 8859, and the parts of 8859 from each other, or to distinguish the specific EBCDIC code page in use, and so on).

Because the contents of the encoding declaration are restricted to characters from the ASCII repertoire (however encoded), a processor can reliably read the entire encoding declaration as soon as it has detected which family of encodings is in use. Since in practice, all widely used character encodings fall into one of the categories above, the XML encoding declaration allows reasonably reliable in-band labeling of character encodings, even when external sources of information at the operating-system or transport-protocol level are unreliable. Character encodings such as UTF-7 that make overloaded usage of ASCII-valued bytes may fail to be reliably detected.

Verder wordt het http-equiv-statement volgens mij niet herkend door XML applicaties, dus heeft het ook in XHTML documenten geen zin om dit META element op te nemen. Temeer daar het dus ook al in de encoding declaratie zou moeten staan.

code:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

[Verwijderd]

Hebben we het over XML over HTTP of gewoon over XML? (Ik dacht zelf aan XML over HTTP.)

[X-Lars]

Aha, heel goed Daar had ik nog helemaal geen onderscheid in gemaakt. Ga ik naar kijken.

[T-MOB]

Verwijderd schreef op donderdag 20 januari 2005 @ 08:49:
[...]
Dan heb je het niet nodig. UTF-8 is de standaard karaktercodering voor XML.

W3C:

The document character set for XML and HTML 4.0 is Unicode (aka ISO 10646). This means that HTML browsers and XML processors should behave as if they used Unicode internally. But it doesn't mean that documents have to be transmitted in Unicode. As long as client and server agree on the encoding, they can use any encoding that can be converted to Unicode.

Hieruit maak ik dan weer op dat je best een andere character encoding kunt gebruiken, maar dat het gebruik van unicode aan te bevelen is omdat elke XML-parser dit (per definitie) ondersteund.

[...]
Huh, waar heb ik het over Microsoft? Een veel groter nadeel is dat "incremental display" er niet is in de huidige browsers voor XHTML (XML).

Je hebt het idd niet over Microsoft, ik nam aan dat je zoiets bedoelde. Maar voor incremental display geldt hetzelfde: er zijn situaties (denkbaar) waar deze nadelen er minder toe doen en de voordelen van XHTML opwegen tegen de nadelen. Bijvoorbeeld als je met MathML aan de slag wil. Het is dus niet "uiteraard beter om er niet aan te beginnen", er kleven gewoon een aantal nadelen aan die je in acht moet nemen. Als het gaat om een doodnormale website geef ik je volledig gelijk.