「text/xml」を送信する必要があると考えましたが、「application/xml」を送信する必要があることを読みました。それは重要ですか?誰かが違いを説明できますか?
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」のままです。
application/xml の場合:
Charsetパラメータが省略されたapplication/xmlエンティティを受信した場合、MIME Content-Typeヘッダーによって文字セットに関する情報は提供されません。適合XMLプロセッサは、この不測の事態に直接対処する[XML]のセクション4.3.3の要件に従う必要があります。ただし、XMLプロセッサではないMIMEプロセッサは、charsetパラメータがapplication/xmlエンティティから省略されている場合、デフォルトの文字セットを想定すべきではありません。
charsetパラメーターが省略されている場合、text/xmlの文字エンコードはUS-ASCIIであり、application/xml文字エンコードはドキュメント自体で指定できます。
現在、インターネットの経験則は次のとおりです。「出力には厳格であるが、入力には寛容であること」。これは、インターネット経由でデータを配信するときに、可能な限り標準に準拠することを意味します。ただし、障害を見落としたり、インターネット経由でデータを受信して解釈するときに推測するためのメカニズムを組み込みます。
したがって、あなたの場合は、2つのタイプの1つを選択し(application/xmlを推奨)、使用する文字エンコーディングを適切に指定するようにしてください(それぞれのデフォルトの文字エンコーディングを使用することをお勧めします安全にプレイするため、application/xmlの場合はUTF-8またはUTF-16を使用します)。
経験則として、すべてのWebサーバー、プロキシ、およびクライアントブラウザでドキュメントを適切に処理するための最も安全な方法は、おそらく次のとおりです。
一部のブラウザが適切に実装できない RFC 302 仕様に関して、コンテンツタイプの主な違いは、クライアントが次のように文字エンコードを処理する方法にあります。
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)。
ここの他の回答は、XML応答の適切なContent-Type
が何であるかという一般的な質問に対処し、結論を出します( webservice応答のtext/xmlとapplication/xmlの違いは何ですか ) text/xml
とapplication/xml
の両方が許可されます。ただし、sitemapsに固有のルールがあるかどうかについては対処していません。
回答:ありません。サイトマップの仕様は https://www.sitemaps.org であり、Google site:
検索を使用すると、単語またはフレーズが含まれていないことを確認できますmime、mimetype、content-type、application/xml、またはtext/xmlどこでも。言い換えれば、サイトマップの提供に使用するContent-Type
のトピックについてはまったく言及していません。
この質問に直接対処するサイトマップ仕様にコメントがない場合、他のXMLドキュメントのContent-Type
を選択するときと同じルールが適用されると安全に想定できます。つまり、text/xml
またはapplication/xml
。