Quelle valeur de type de contenu dois-je envoyer pour mon sitemap XML?
Je pensais que je devrais 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 jeu de caractères paramètre n'est pas spécifié explicitement. Si le jeu de caractères par défaut (c'est-à-dire US-ASCII) pour text/xml n'est pas pratique pour une raison quelconque (par exemple, mauvais serveurs Web ), Application/xml fournit une alternative (consultez la section "Paramètres optionnels. enregistrement application/xml dans la section 3.2).
Pour text/xml :
Conforme à la [RFC2046], si une entité text/xml est reçue avec paramètre de jeu de caractères omis, processeurs MIME et processeurs XML DOIT 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 par défaut La valeur de charset est toujours "us-ascii".
Pour application/xml :
Si une entité application/xml est reçue, le jeu de caractères paramètre est omis, aucune information n'est fournie sur le fichier jeu de caractères par l'en-tête MIME Content-Type. XML conforme les processeurs 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 assumer un jeu de caractères par défaut si le paramètre charset est omis d'une entité application/xml.
Par conséquent, 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 empirique sur Internet est la suivante: «Soyez strict avec la sortie mais soyez tolérant avec la saisie». Cela signifie que vous devez vous conformer autant que possible aux normes lorsque vous transmettez des données sur Internet. Cependant, intégrez des mécanismes pour ignorer les erreurs ou pour deviner lors de la réception et de l'interprétation de données sur Internet.
Donc, dans votre cas, il vous suffit de choisir l’un des deux types (je recommande application/xml) et de vous assurer de spécifier correctement le codage de caractères utilisé (je vous recommande d’utiliser le codage de caractères par défaut pour jouer en toute sécurité. application/xml utilise 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:
- Utiliser le type de contenu application/xml
- Incluez un codage de caractères dans le type de contenu, probablement UTF-8
- Incluez un codage de caractère correspondant dans l'attribut de codage du document XML lui-même.
En termes de RFC 3023 spec, 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 censés traiter l'encodage 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 , le codage des caractères est déterminé dans cet ordre:
- l'encodage donné dans le paramètre charset de l'en-tête HTTP Content-Type
- le codage donné dans l'attribut de codage de la déclaration XML dans le document,
- utf-8.
Pour text/xml, text/xml-external-analysed-entity, ou un sous-type tel que text/foo + xml, l'attribut de codage de la déclaration XML dans le document est ignoré et le codage de caractères est le suivant:
- l'encodage donné dans le paramètre charset de l'en-tête HTTP Content-Type, ou
- nous-ascii.
La plupart des analyseurs n'implémentent pas les spécifications. ils ignorent le type de contexte HTTP et n'utilisent que l'encodage du document. Avec autant de documents mal formés, il est peu probable que cela change de si tôt.
les deux vont bien.
text/xxx signifie que si le programme ne comprend pas xxx, il est logique d'afficher 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 les pièces jointes au courrier électronique avant leur utilisation ultérieure dans le monde Web.
text/xml est destiné aux documents qui auraient un sens pour un humain s'il était présenté sous forme de texte sans autre traitement, application/xml était destiné à tout le reste
Chaque entité XML peut être utilisée avec le média application/xml tapez sans modification. Mais cela n'exploite pas le fait que XML peut être traité comme du texte brut dans de nombreux cas. Agents utilisateurs MIME (et les utilisateurs Web) qui ne prennent pas explicitement en charge application/xml le traitera comme application/octet-stream, pour exemple, en proposant de l’enregistrer dans un fichier.
Pour indiquer qu'une entité XML doit être traitée comme un texte brut par Par défaut, utilisez le type de média text/xml. Cela limite l'encodage utilisé dans l'entité XML à ceux qui sont compatibles avec le exigences pour les types de supports de texte tels que décrits dans [RFC-2045] et [RFC-2046], par exemple, UTF-8, mais pas UTF-16 (sauf pour HTTP).
D'autres réponses ici abordent la question générale de savoir quel est le Content-Type approprié pour une réponse XML et concluent (comme avec Quelle est la différence entre text/xml et application/xml pour une réponse de service Web ) que text/xml et application/xml sont autorisés? Cependant, aucun n’indique s’il existe des règles spécifiques à sitemaps.
Réponse: il n'y en a pas. La spécification de sitemap est https://www.sitemaps.org , et en utilisant les recherches site: de Google, vous pouvez confirmer qu'elle ne contient pas les mots ou les expressions mime, mimetype, content -type, application/xml ou text/xml n'importe où. En d'autres termes, la question de ce que Content-Type doit être utilisé pour la diffusion de plans Sitemap est totalement ignorée.
En l'absence de commentaire dans les spécifications du sitemap qui aborde directement cette question, nous pouvons sans risque supposer que les mêmes règles s'appliquent que pour le choix du Content-Type de tout autre document XML, c'est-à-dire qu'il peut s'agir du text/xml ou du application/xml.