J’ai pensé que je devrais l’envoyer « text/xml », mais ensuite j’ai lu que je devrais l’envoyer « application/xml ». C'est important ? Est-ce que quelqu'un peut expliquer la différence ?
Réponses
Trop de publicités?
La différence entre texte/xml et application/xml codage de caractères par défaut si le jeu de caractères du paramètre est omis:
Text/xml et application/xml se comporter différemment lorsque le charset le paramètre n'est pas spécifié. Si le jeu de caractères par défaut (c'est à dire, US-ASCII) pour text/xml n'est gênant que pour une raison quelconque (par exemple, les mauvaises web les serveurs), application/xml fournit une solution de remplacement (voir la section "Option les paramètres" de l'application/xml d'inscription dans la Section 3.2).
Pour text/xml:
Conforme à [RFC2046], si un texte/xml entité est reçu avec le paramètre charset omis, MIME les transformateurs et les processeurs XML DOIT utiliser le jeu de caractères par défaut la valeur "us-ascii"[ASCII]. Dans les cas où le XML MIME entité est transmis via le protocole HTTP, la valeur par défaut jeu de caractères de la valeur est toujours "us-ascii".
Pour application/xml:
Si une application/xml entité est reçu, dans lequel le jeu de caractères paramètre est omis, aucune information n'est fournie sur le jeu de caractères par le MIME-tête Content-Type. Conforme XML les transformateurs DOIVENT suivre les exigences de la section 4.3.3 de [XML] qui s'adresse directement à cette éventualité. Cependant, MIME processeurs qui ne sont pas les processeurs XML DOIVENT PAS assumer un jeu de caractères par défaut si le jeu de caractères du paramètre est omis à partir d'une application/xml entité.
Donc, si le jeu de caractères du paramètre est omis, l'encodage des caractères de texte/xml est de US-ASCII, alors qu'avec l'application/xml de l'encodage des caractères peut être spécifié dans le document lui-même.
Maintenant, une règle de pouce sur internet est: "Être strict avec la sortie mais être tolérant à l'entrée." Que signifie assurez-vous de respecter les normes, autant que possible, lors de la diffusion des données sur internet. Mais dans certains mécanismes de négliger les défauts ou de deviner lors de la réception et de l'interprétation des données sur l'internet.
Donc dans votre cas il suffit de choisir l'un des deux types (je recommande l' application/xml) et assurez-vous utilisé pour spécifier le codage des caractères correctement (je recommande d'utiliser la codage de caractères par défaut pour jouer en toute sécurité, de sorte qu'en cas d' application/xml utiliser l'UTF-8 ou UTF-16).
Alex M.
Points
338
En règle générale, le pari le plus sûr pour faire de votre document seront traitées correctement par tous les serveurs web, les serveurs proxy, et les navigateurs des clients, est probablement la suivante:
- L'utilisation de l'application/xml type de contenu
- Inclure un codage de caractères dans le type de contenu, probablement UTF-8
- Inclure un correspondant de l'encodage des caractères dans l'attribut de codage du document XML lui-même.
En termes de la RFC 3023 spec, que certains navigateurs ne parviennent pas à mettre correctement en œuvre, la principale différence entre les types de contenu est dans la façon dont les clients sont censés traiter l'encodage des caractères, comme suit:
Pour application/xml, application/xml-dtd, application/xml-externe-analysé entité, ou l'un des sous-types d'application/xml, application/atom+xml, application/rss+xml ou application/rdf+xml, le codage des caractères est déterminé dans cet ordre:
- l'encodage des données dans le paramètre charset du Type de Contenu d'en-tête HTTP
- l'encodage donné dans l'attribut de codage de la déclaration XML dans le document,
- utf-8.
Pour text/xml, text/xml-externe-analysé entité, ou un sous-type comme texte/foo+xml, l'attribut de codage de la déclaration XML dans le document est ignoré, et le codage des caractères est:
- l'encodage des données dans le paramètre charset du Type de Contenu d'en-tête HTTP, ou
- us-ascii.
La plupart des analyseurs de ne pas mettre en œuvre la spécification; ils ignorent le Contexte HTTP de Type et il suffit d'utiliser l'encodage dans le document. Avec donc beaucoup de mal formé des documents là-bas, c'est peu susceptible de modifier à tout moment bientôt.
Hendrik Brummermann
Points
4543
les deux sont très bien.
texte/xxx signifie que dans le cas où le programme ne comprend pas de xxx, il est logique d’afficher le fichier à l’utilisateur en texte brut. application/xxx signifie qu’il est inutile de le montrer.
Veuillez noter que ces types de contenu ont été définis initialement pour la pièce jointe avant ils ont pris l’habitude plus tard dans le monde du Web.
Quentin
Points
325526
text/xml est pour les documents qui pourraient être utiles pour un homme présenté comme le texte, sans autre traitement, application/xml est pour tout le reste
Chaque entité XML est adapté pour une utilisation avec l'application/xml médias type sans modification. Mais cela ne veut pas exploiter le fait que XML peut être traitée en tant que texte brut dans de nombreux cas. MIME les agents utilisateurs (web et les agents utilisateurs qui ne disposent pas du soutien explicite pour application/xml traite en tant que application/octet-stream, pour exemple, en offrant à l'enregistrer dans un fichier.
Pour indiquer qu'une entité XML doivent être traités comme du texte brut par défaut, utilisez le texte/xml type de média. Cette limite à l'encodage utilisé dans l'entité XML pour ceux qui sont compatibles avec la exigences pour le texte de types de médias comme décrit dans [RFC 2045] et [RFC 2046], par exemple, UTF-8, mais pas en UTF-16 (à l'exception de HTTP).
