Quelle valeur de type de contenu dois-je envoyer pour mon sitemap XML?

Question

Je pensais que je devrais envoyer "text/xml", mais alors j'ai lu que je devrais envoyer "application/xml". Est-ce que ça importe? Quelqu'un peut-il expliquer la différence?

Answer 1

Le difference between text/xml and application/xml est le caractère par défaut si le codage paramètre charset est omises:

text/xml et application/xml se comportent différemment lorsque le paramètre charset n'est pas explicitement spécifié. Si le charset par défaut (ie, US-ASCII) pour text/xml n'est pas pratique pour une raison quelconque (par exemple, mauvais serveurs web ), application/xml fournit une alternative (voir "Paramètres optionnels " de l'enregistrement application/xml dans Section 3.2).

Pour text/xml:

Conformant avec [RFC2046], si une entité text/xml est reçu avec le paramètre charset omis, processeurs MIME et les processeurs XML DOIVENT utiliser la valeur charset par défaut " us-ascii "[ASCII]. Dans les cas où l'entité XML MIME est transmise via HTTP, la valeur par défaut du jeu de caractères est toujours "us-ascii".

Pour application/xml:

Si une entité application/xml est reçue lorsque le paramètre charset est omis, aucune information est fournie au sujet de la charset par l'en-tête Content-Type MIME. Les processeurs XML conformes DOIVENT respecter les exigences de la section 4.3.3 de [XML] qui répondent directement à cette éventualité. Cependant, les processeurs MIME qui ne sont pas des processeurs XML NE DEVRAIENT PAS assumer un jeu de caractères par défaut si le paramètre charset est omis dans une entité application/xml.

Donc, si le paramètre charset est omis, l'encodage de caractères de text/xml est US-ASCII alors qu'avec application/xml l'encodage de caractères peut être spécifié dans le document lui-même. Maintenant, une règle de base sur Internet est: "Soyez strict avec la sortie, mais soyez tolérant avec l'entrée." Cela signifie assurez-vous de respecter les normes autant que possible lors de la livraison de données sur Internet. Mais intégrez des mécanismes pour ignorer les fautes ou pour deviner lors de la réception et de l'interprétation des données sur Internet. Donc dans votre cas, il suffit de choisir l'un des deux types (je recommande application/xml) et assurez-vous de spécifier correctement le codage de caractères utilisé (je recommande d'utiliser l'encodage de caractères par défaut respectif, donc dans cas de application/xml utilisez UTF-8 ou UTF-16).

Answer 2

text/xml est pour les documents qui seraient utiles à un être humain si elle est présentée sous forme de texte sans autre traitement, l'application/xml est pour tout le reste

Chaque entité XML est adapté à une utilisation avec l'application/xml media type sans modification. Mais cela n'exploite pas le fait que XML peut être traité comme du texte brut dans de nombreux cas. Les agents utilisateurs MIME (et les agents utilisateur Web) qui ne prennent pas explicitement en charge application/xml le traiteront comme application/octet-stream, par exemple, en proposant de l'enregistrer dans un fichier.

Pour indiquer qu'une entité XML doit être traitée en texte brut par défaut , utilisez le type de média text/xml. Cela restreint le codage utilisé dans l'entité XML à ceux qui sont compatibles avec les exigences pour les types de supports de texte décrits dans [RFC2045] et [RFC2046], par exemple, UTF-8, mais pas UTF-16 (sauf pour HTTP).

- http://www.ietf.org/rfc/rfc2376.txt

Answer 3

les deux sont très bien. Text/xxx signifie que si le programme ne comprend pas xxx, il est logique de montrer le fichier à l'utilisateur sous forme de texte brut. application/xxx signifie qu'il est inutile de le montrer.

Veuillez noter que ces types de contenu ont été définis à l'origine pour la pièce jointe avant de pouvoir être utilisés ultérieurement dans le monde Web.

Answer 4

En règle générale, le pari le plus sûr à faire de votre document soit traité correctement par tous les serveurs Web, les proxy et les navigateurs clients, est probablement la suivante:

1. Utilisez l'application/xml type de contenu
2. Inclure un codage de caractères dans le type de contenu, probablement UTF-8
3. Inclure un codage de caractères correspondant dans l'attribut de codage du document XML lui-même.

En termes de spécifications RFC 3023, que certains navigateurs ne parviennent pas à mettre en œuvre correctement, la principale différence dans les types de contenu est dans la façon dont les clients sont censés traiter le codage de caractères, comme suit:

Pour une application/xml, application/xml-dtd, application/xml-external-parsed-entité, ou l'un des sous-types d'application/xml tels que application/atom + xml, application/rss + xml ou application/rdf + xml, le caractère le codage est déterminé dans cet ordre:

1. le codage donné dans le paramètre charset er de l'en-tête HTTP Content-Type
2. le codage donné dans l'attribut de codage de la déclaration XML dans le document,
3. utf-8.

Pour text/xml, text/xml-external-entité analysable, ou un sous-type comme text/foo + xml, l'attribut encoding de la déclaration XML dans le document est ignoré, et le codage des caractères est:

1. l'encodage donné dans le paramètre charset de l'en-tête HTTP Content-type, ou
2. nous-ascii.

La plupart des analyseurs n'implémentent pas la spécification; ils ignorent le type de contexte HTTP et utilisent simplement le codage dans le document. Avec autant de documents mal formés, il est peu probable que cela change d'ici peu.