Risposte:
La differenza tra text / xml e application / xml è la codifica dei caratteri predefinita se il parametro charset viene omesso:
Text / xml e application / xml si comportano in modo diverso quando il parametro charset non viene specificato in modo esplicito. Se il set di caratteri predefinito (ovvero US-ASCII) per text / xml è scomodo per qualche motivo (ad es. Server Web non validi), application / xml fornisce un'alternativa (vedere "Parametri opzionali" della registrazione application / xml nella Sezione 3.2).
Per text / xml :
Conforme a [RFC2046], se si riceve un'entità text / xml con il parametro charset omesso, i processori MIME e i processori XML DEVONO utilizzare il valore charset predefinito di "us-ascii" [ASCII]. Nei casi in cui l'entità MIME XML viene trasmessa tramite HTTP, il valore del set di caratteri predefinito è ancora "us-ascii".
Per application / xml :
Se viene ricevuta un'entità application / xml in cui viene omesso il parametro charset, l'intestazione MIME Content-Type non fornisce informazioni sul charset. I processori XML conformi DEVONO seguire i requisiti della sezione 4.3.3 di [XML] che affrontano direttamente questa eventualità. Tuttavia, i processori MIME che non sono processori XML NON DOVREBBERO assumere un set di caratteri predefinito se il parametro charset viene omesso da un'entità application / xml.
Quindi se il parametro charset viene omesso, la codifica dei caratteri di text / xml è US-ASCII mentre con application / xml la codifica dei caratteri può essere specificata nel documento stesso.
Ora una regola empirica su Internet è: "Sii rigoroso con l'output ma sii tollerante con l'input". Ciò significa assicurarsi di soddisfare gli standard il più possibile durante la consegna di dati su Internet. Tuttavia, incorporare alcuni meccanismi per trascurare i guasti o indovinare quando si ricevono e interpretano i dati su Internet.
Quindi nel tuo caso basta scegliere uno dei due tipi (mi raccomando application / xml ) e assicurarsi di specificare il carattere utilizzato codifica correttamente (vi consiglio di utilizzare la rispettiva codifica dei caratteri di default andare sul sicuro, quindi in caso di application / xml uso UTF-8 o UTF-16).
Come regola generale, la scommessa più sicura per far sì che il tuo documento sia trattato correttamente da tutti i server Web, i proxy e i browser client, è probabilmente la seguente:
In termini di specifiche RFC 3023 , che alcuni browser non riescono a implementare correttamente, la principale differenza nei tipi di contenuto è nel modo in cui i clienti dovrebbero trattare la codifica dei caratteri, come segue:
Per application / xml, application / xml-dtd, application / xml-external-parsed-entity, o uno qualsiasi dei sottotipi di application / xml come application / atom + xml, application / rss + xml o application / rdf + xml , la codifica dei caratteri è determinata in questo ordine:
Per text / xml, text / xml-external-parsed-entity o un sottotipo come text / foo + xml, l'attributo di codifica della dichiarazione XML all'interno del documento viene ignorato e la codifica dei caratteri è:
La maggior parte dei parser non implementa le specifiche; ignorano il tipo di contesto HTTP e usano semplicemente la codifica nel documento. Con così tanti documenti mal formati là fuori, è improbabile che cambi presto.
entrambi vanno bene.
text / xxx significa che nel caso in cui il programma non capisca xxx, ha senso mostrare il file all'utente come testo normale. application / xxx significa che è inutile mostrarlo.
Si noti che tali tipi di contenuto sono stati originariamente definiti per l'allegato di posta elettronica prima di essere successivamente utilizzati nel mondo Web.
text / xml è per i documenti che sarebbero significativi per un essere umano se presentato come testo senza ulteriore elaborazione, application / xml è per tutto il resto
Ogni entità XML è adatta all'uso con il tipo di supporto application / xml senza modifiche. Ma questo non sfrutta il fatto che XML può essere trattato come testo normale in molti casi. Gli user agent MIME (e gli user agent web) che non hanno un supporto esplicito per application / xml lo tratteranno come application / octet-stream, ad esempio, offrendo di salvarlo in un file.
Per indicare che un'entità XML deve essere trattata come testo normale per impostazione predefinita, utilizzare il tipo di supporto text / xml. Ciò limita la codifica utilizzata nell'entità XML a quelli compatibili con i requisiti per i tipi di supporto di testo come descritto in [RFC-2045] e [RFC-2046], ad esempio UTF-8, ma non UTF-16 (eccetto per HTTP).
text/htmlè in circolazione da molto tempo ed è stato un po 'tardi per cambiarlo.
Altre risposte qui affrontano la domanda generale su quale sia il giusto Content-Typeper una risposta XML e concludono (come con Qual è la differenza tra text / xml vs application / xml per la risposta al servizio web ) che entrambi text/xmle application/xmlsono ammessi. Tuttavia, nessuno indica se esistono regole specifiche per le Sitemap .
Risposta: non ci sono. La specifica della Sitemap è https://www.sitemaps.org e, utilizzando le site:ricerche di Google , puoi confermare che non contiene le parole o le frasi mime , mimetype , content-type , application / xml o text / xml ovunque. In altre parole, è completamente silenzioso sull'argomento di cosa Content-Typedovrebbe essere usato per servire le sitemap.
In assenza di commenti nelle specifiche della Sitemap che affrontano direttamente questa domanda, possiamo tranquillamente presumere che si applichino le stesse regole di quando si sceglie il documento Content-Typedi qualsiasi altro documento XML, ovvero che può essere uno text/xmlo application/xml.
text/htmle il tipo MIME XHTML preferito siaapplication/xhtml+xml.