Quelle est la différence entre text/xml vs application/xml pour la réponse de webservice?
il s'agit plus d'une question générale sur la différence entre text/xml et application/xml .
Je suis assez nouveau à écrire webservices (REST-Jersey). J'ai été la production de application/xml puisque c'est ce qui apparaît dans la plupart des tutoriels / exemples de code que j'ai utilisé pour apprendre, mais j'ai récemment découvert text/xml et me demandais ce qui est différent et quand vous l'utilisez sur des application/xml ?
5 réponses
du RFC ( 3023 ), à la section 3, types de supports XML:
si un document XML -- c'est-à-dire le document XML source non traité -- est lisible par les utilisateurs occasionnels, texte / xml est préférable à application / xml. Les agents utilisateurs MIME (et les agents utilisateurs web) qui ne avoir un support explicite pour le texte / xml le traitera comme texte / simple, pour exemple, en affichant l'entité MIME XML en texte simple. Application/xml est préférable lorsque le fichier XML MIME entité est illisible par les utilisateurs occasionnels.
(l'emphase est mienne)
il s'agit d'une vieille question, mais celle-ci est fréquemment visitée et des recommandations claires sont maintenant disponibles à partir de RFC7303 qui obsolète RFC3023. En bref (section 9.2):
The registration information for text/xml is in all respects the same
as that given for application/xml above (Section 9.1), except that
the "Type name" is "text".
Selon cet article application/xml est préféré.
MODIFIER
j'ai fait un petit suivi sur l'article.
l'auteur affirme que l'encodage déclaré dans les instructions de traitement XML, comme:
<?xml version="1.0" encoding="UTF-8"?>
peut être ignoré lorsque le type de média text/xml est utilisé.
ils soutiennent la thèse avec le définition de text/* spécification de la famille MIME dans RFC 2046 , en particulier le fragment suivant:
4.1.2. Charset Parameter
A critical parameter that may be specified in the Content-Type field
for "text/plain" data is the character set. This is specified with a
"charset" parameter, as in:
Content-type: text/plain; charset=iso-8859-1
Unlike some other parameter values, the values of the charset
parameter are NOT case sensitive. The default character set, which
must be assumed in the absence of a charset parameter, is US-ASCII.
The specification for any future subtypes of "text" must specify
whether or not they will also utilize a "charset" parameter, and may
possibly restrict its values as well. For other subtypes of "text"
than "text/plain", the semantics of the "charset" parameter should be
defined to be identical to those specified here for "text/plain",
i.e., the body consists entirely of characters in the given charset.
In particular, definers of future "text" subtypes should pay close
attention to the implications of multioctet character sets for their
subtype definitions.
selon eux, de telles difficultés peuvent être évitées en utilisant le type MIME application/xml . Que ce soit vrai ou pas, je n'irais pas jusqu'à éviter text/xml . IMHO, il est préférable de suivre la sémantique de la lisibilité humaine(non-lisibilité) et de toujours se rappeler de spécifier le jeu de caractères.
application/xml est vu par svn comme binaire type tandis que text/xml comme texte fichier pour lequel un diff peut être affiché.
pas pour répondre à votre question mais pour assurer une vie simple:
lorsque vous vivez dans l'écosystème du cadre. net - > regardez https://referencesource.microsoft.com/#system.web/MimeMapping.cs ligne ~ 430:
AddMapping(".xml", "text/xml");
donc vous pouvez toujours faire
string mimeType = System.Web.MimeMapping.GetMimeMapping(string yourFileName)
pour obtenir votre mimetype correctement