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

Je pensais que je devais envoyer “text / xml“, mais ensuite j’ai lu que je devais envoyer “application / xml”. Est-ce que ça importe? Quelqu’un peut-il expliquer la différence?

La différence entre text / xml et application / xml est le codage de caractères par défaut si le paramètre charset est omis:

Text / xml et application / xml se comportent différemment lorsque le paramètre charset n’est pas explicitement spécifié. Si le jeu de caractères par défaut (US-ASCII) pour text / xml est incommode pour une raison quelconque (par exemple, serveurs Web incorrects), application / xml offre une alternative (voir “Paramètres facultatifs” de l’enregistrement application / xml dans Section 3.2).

Pour text / xml :

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

Pour application / xml :

Si une entité application / xml est reçue et que le paramètre charset est omis, aucune information n’est fournie sur le charset par l’en-tête MIME Content-Type. Les processeurs XML conformes DOIVENT suivre les exigences de la section 4.3.3 de [XML] qui traitent directement de cette éventualité. Cependant, les processeurs MIME qui ne sont pas des processeurs XML NE DEVRAIENT PAS supposer un jeu de caractères par défaut si le paramètre charset est omis d’une entité application / xml.

Donc, si le paramètre charset est omis, le codage de caractères de text / xml est US-ASCII alors qu’avec application / xml, le codage de caractères peut être spécifié dans le document lui-même.

Maintenant, une règle de base sur Internet est: «Soyez ssortingct avec le résultat, mais soyez tolérant avec l’entrée.» Cela signifie que vous devez vous assurer de respecter les normes autant que possible lors de la livraison de données sur Internet. Mais intégrez certains mécanismes pour ignorer les défauts ou deviner lors de la réception et de l’interprétation de données sur Internet.

Donc, dans votre cas, choisissez l’un des deux types (je recommande l’ application / xml ) et assurez-vous de bien spécifier le codage de caractères utilisé (je recommande d’utiliser le codage de caractères par défaut respectif pour jouer en toute sécurité, donc en cas d’ utilisation de l’ application / xml) UTF-8 ou UTF-16).

En règle générale, le pari le plus sûr pour que votre document soit traité correctement par tous les serveurs Web, serveurs proxy et navigateurs clients est probablement le suivant:

  1. Utilisez le type de contenu application / xml
  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’atsortingbut de codage du document XML lui-même.

En ce qui concerne la spécification RFC 3023 , que certains navigateurs ne parviennent pas à implémenter correctement, la principale différence entre les types de contenu réside dans la manière dont les clients sont supposés traiter le codage des caractères, comme suit:

Pour application / xml, application / xml-dtd, application / xml-external-parsed-entity ou l’un des sous-types d’application / xml tels que application / atom + xml, application / rss + xml ou application / rdf + xml , l’encodage des caractères est déterminé dans cet ordre:

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

Pour text / xml, text / xml-external-parsed-entity ou un sous-type tel que text / foo + xml, l’atsortingbut de codage de la déclaration XML dans le document est ignoré et le codage des caractères est le suivant:

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

La plupart des parsingurs n’implémentent pas la spécification; ils ignorent le type de contexte HTTP et utilisent simplement l’encodage du document. Avec autant de documents mal formés, il est peu probable que cela change de sitôt.

les deux vont bien.

text / xxx signifie que si le programme ne comprend pas xxx, il est logique de montrer le fichier à l’utilisateur en texte brut. application / xxx signifie qu’il est inutile de le montrer.

Notez que ces types de contenu ont été définis à l’origine pour les pièces jointes avant qu’ils ne soient utilisés ultérieurement dans le monde Web.

text / xml est pour les documents qui seraient significatifs pour un humain s’ils sont présentés sous forme de texte sans traitement supplémentaire, application / xml est pour tout le rest

Chaque entité XML peut être utilisée avec le type de support application / xml 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 agents utilisateurs Web) qui ne prennent pas explicitement en charge l’application / xml le traiteront comme application / stream d’octets, par exemple en proposant de l’enregistrer dans un fichier.

Pour indiquer qu’une entité XML doit être traitée comme du texte brut par défaut, utilisez le type de support text / xml. Cela limite le codage utilisé dans l’entité XML à ceux qui sont compatibles avec les exigences pour les types de média texte, comme décrit dans [RFC-2045] et [RFC-2046], par exemple UTF-8, mais pas UTF-16 (sauf pour HTTP).

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