回答:
text / xmlとapplication / xmlの違いは、charsetパラメータが省略されている場合のデフォルトの文字エンコーディングです。
charsetパラメータが明示的に指定されていない場合、Text / xmlとapplication / xmlの動作は異なります。text / xmlのデフォルトの文字セット（つまり、US-ASCII）が何らかの理由（Webサーバーの不良など）で不便な場合、application / xmlが代替手段を提供します（セクション3.2のapplication / xml登録の「オプションパラメータ」を参照）。
以下のためにtext / xmlで：
[RFC2046]に準拠し、charsetパラメータを省略してtext / xmlエンティティを受信した場合、MIMEプロセッサとXMLプロセッサは、デフォルトの文字セット値「us-ascii」[ASCII]を使用する必要があります。XML MIMEエンティティがHTTP経由で送信される場合でも、デフォルトの文字セット値は「us-ascii」のままです。
charsetパラメーターが省略されているapplication / xmlエンティティを受信した場合、MIME Content-Typeヘッダーでは文字セットに関する情報は提供されません。適合XMLプロセッサは、この不測の事態に直接対処する[XML]のセクション4.3.3の要件に従う必要があります。ただし、XMLプロセッサではないMIMEプロセッサは、application / xmlエンティティからcharsetパラメータが省略されている場合、デフォルトの文字セットを想定してはなりません（SHOULD NOT）。
したがって、charsetパラメータを省略した場合、text / xmlの文字エンコーディングはUS-ASCIIになりますが、application / xmlでは、文字エンコーディングをドキュメント自体で指定できます。
インターネットでの経験則は次のとおりです。「出力には厳格であるが、入力には寛容である」。つまり、インターネットを介してデータを配信するときは、できる限り標準に準拠するようにしてください。ただし、インターネット経由でデータを受信して解釈するときに、障害を見落としたり推測したりするためのメカニズムをいくつか組み込んでください。
だからあなたの場合にはちょうど2つのタイプのいずれかを選ぶ（私はお勧めのアプリケーション/ XMLを（私はそうした場合には、安全でプレーするエンコードそれぞれのデフォルトの文字を使用することをお勧めします）、適切にエンコードに使用する文字を指定してくださいアプリケーション/ XMLの使用UTF-8またはUTF-16）。
経験則として、すべてのWebサーバー、プロキシ、およびクライアントブラウザでドキュメントを適切に処理するための最も安全な方法は、おそらく次のとおりです。
一部のブラウザでは適切に実装できないRFC 3023仕様に関して、コンテンツタイプの主な違いは、クライアントが次のように文字エンコーディングを処理する方法にあります。
application / xml、application / xml-dtd、application / xml-external-parsed-entity、またはapplication / atom + xml、application / rss + xml、application / rdf + xmlなどのapplication / xmlのサブタイプのいずれか、文字エンコードは次の順序で決定されます。
text / xml、text / xml-external-parsed-entity、またはtext / foo + xmlのようなサブタイプの場合、ドキュメント内のXML宣言のエンコーディング属性は無視され、文字エンコーディングは次のとおりです。
ほとんどのパーサーは仕様を実装していません。HTTP Context-Typeを無視し、ドキュメントのエンコーディングを使用します。不正な形式のドキュメントが非常に多いため、すぐに変更される可能性はほとんどありません。
どちらも大丈夫です。
text / xxxは、プログラムがxxxを理解できない場合に、ユーザーにファイルをプレーンテキストとして表示することは意味があることを意味します。application / xxxは、表示しても意味がないことを意味します。
これらのコンテンツタイプは、後でWebの世界で使用される前に、電子メールの添付ファイル用に最初に定義されたことに注意してください。
text / xmlは、それ以上処理せずにテキストとして表示された場合に人間にとって意味のあるドキュメント用であり、application / xmlはその他すべてのものです。
すべてのXMLエンティティは、変更せずにapplication / xmlメディアタイプでの使用に適しています。しかし、これは多くの場合XMLがプレーンテキストとして処理できるという事実を利用しません。application / xmlを明示的にサポートしていないMIMEユーザーエージェント（およびWebユーザーエージェント）は、たとえば、ファイルに保存することを申し出て、application / octet-streamとして扱います。
XMLエンティティをデフォルトでプレーンテキストとして扱う必要があることを示すには、text / xmlメディアタイプを使用します。これにより、XMLエンティティで使用されるエンコードは、[RFC-2045]と[RFC-2046]で説明されているテキストメディアタイプの要件と互換性のあるエンコードに制限されます。 HTTP）。
text/html非常に長い間使用されており、変更するのは少し遅れました。
他の回答は、ここで適切なものの一般的な質問に対処Content-TypeXML応答のですが、と結論付けて（と同じようにWebサービスの応答のためのアプリケーション/ xmlの対text / xmlでの違いは何の両方のこと）text/xmlとはapplication/xml許容されます。ただし、サイトマップに固有のルールがあるかどうかについては触れていません。
回答：ありません。サイトマップの仕様はhttps://www.sitemaps.orgであり、Google site:検索を使用すると、mime、mimetype、content-type、application / xml、またはtext / xmlという単語やフレーズがどこにも含まれていないことを確認できます。つまり、Content-Typeサイトマップを提供するために何を使用する必要があるかについては、まったく触れられていません。
この質問に直接対処するサイトマップ仕様にコメントがない場合、Content-Type他のXMLドキュメントを選択するときと同じルールが適用されると見なすことができます。つまり、text/xmlまたはのいずれかになりますapplication/xml。
text/htmlあり、XHTML MIMEタイプがであることはおかしいですapplication/xhtml+xml。