Réponses:
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 (c.-à-d. US-ASCII) pour text / xml n'est pas pratique pour une raison quelconque (par exemple, de mauvais serveurs Web), application / xml fournit une alternative (voir "Paramètres optionnels" de l'enregistrement application / xml dans la section 3.2).
Pour le texte / xml :
Conformément à la [RFC2046], si une entité text / xml est reçue avec le paramètre charset omis, les 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 alors 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 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.
Donc, si le paramètre charset est omis, le codage de caractères de text / xml est US-ASCII tandis 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 strict avec la sortie, mais soyez tolérant avec l'entrée." Cela signifie qu'il faut s'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 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 l' application / xml ) et assurez - vous de préciser le caractère utilisé coder correctement (je vous recommande d'utiliser le codage de caractères par défaut respectif pour jouer en toute sécurité, donc en cas d' application / xml utilisation 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, proxys et navigateurs clients est probablement le suivant:
En ce qui concerne la spécification RFC 3023 , que certains navigateurs ne parviennent pas à implémenter correctement, la principale différence dans les types de contenu réside dans la manière dont les clients sont censé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:
Pour text / xml, text / xml-external-parsed-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 des caractères est:
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 de si tô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 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 aux e-mails avant d'être utilisés ultérieurement dans le monde Web.
text / xml est pour les documents qui seraient significatifs pour un humain s'ils étaient présentés sous forme de texte sans traitement supplémentaire, application / xml est pour tout le reste
Chaque entité XML peut être utilisée avec le type de média 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 les agents utilisateurs Web) qui n'ont pas de support explicite pour application / xml le traiteront comme application / flux 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 média text / xml. Cela restreint le codage utilisé dans l'entité XML à ceux qui sont compatibles avec les exigences pour les types de support texte comme décrit dans [RFC-2045] et [RFC-2046], par exemple, UTF-8, mais pas UTF-16 (sauf pour HTTP).
text/htmlexiste depuis très longtemps, et il était un peu tard pour le changer.
D'autres réponses ici abordent la question générale de ce qu'est le bon Content-Typepour une réponse XML, et concluent (comme avec Quelle est la différence entre text / xml vs application / xml pour une réponse de service Web ) que les deux text/xmlet application/xmlsont autorisés. Cependant, aucune ne précise s'il existe des règles spécifiques aux plans de site .
Réponse: il n'y en a pas. La spécification du plan du site est https://www.sitemaps.org , et en utilisant les site:recherches Google, vous pouvez confirmer qu'il ne contient nulle part les mots ou expressions mime , mimetype , content-type , application / xml ou text / xml . En d'autres termes, il est entièrement silencieux sur le sujet de ce qui Content-Typedevrait être utilisé pour servir les plans de site.
En l'absence de tout commentaire dans la spécification du plan du site traitant directement de cette question, nous pouvons supposer sans risque que les mêmes règles s'appliquent que lors du choix Content-Typede tout autre document XML - c'est-à-dire qu'il peut s'agir de text/xmlou de application/xml.
text/htmlet que le type XHTML MIME préféré soitapplication/xhtml+xml.