136

「text/xml」を送ろうと思ったら、「application/xml」を送ったほうがいいと読みました。それは問題ですか？誰かが違いを説明できますか？

4

5 に答える 5

167

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 プロセッサはデフォルトの charset 値である「us-ascii」[ASCII] を使用する必要があります。XML MIME エンティティが HTTP 経由で送信される場合でも、デフォルトの文字セット値は「us-ascii」のままです。

application/xmlの場合:

charset パラメータが省略されている application/xml エンティティを受信した場合、MIME Con​​tent-Type ヘッダーによって文字セットに関する情報が提供されません。適合する XML プロセッサは、この不測の事態に直接対処する [XML] のセクション 4.3.3 の要件に従わなければなりません (MUST)。ただし、XML プロセッサではない MIME プロセッサは、application/xml エンティティから charset パラメータが省略されている場合、デフォルトの文字セットを想定すべきではありません。

そのため、charsetパラメータを省略した場合、 text/xmlの文字エンコーディングは US-ASCII ですが、application/xmlでは文字エンコーディングをドキュメント自体で指定できます。

現在、インターネット上の経験則は、「アウトプットには厳格であるが、インプットには寛容であること」です。つまり、インターネット経由でデータを配信するときは、可能な限り標準を満たすようにしてください。ただし、障害を見逃したり、インターネット経由でデータを受信して​​解釈するときに推測したりするメカニズムを組み込む必要があります。

したがって、あなたの場合、2つのタイプのいずれかを選択し（ application/xml をお勧めします）、使用する文字エンコーディングを適切に指定するようにしてください（安全にプレイするために、それぞれのデフォルトの文字エンコーディングを使用することをお勧めします。 UTF-8 または UTF-16)。

于 2010-07-17T17:40:25.260 に答える
27

経験則として、ドキュメントをすべてのWebサーバー、プロキシ、およびクライアントブラウザで適切に処理するための最も安全な方法は、おそらく次のとおりです。

  1. application/xmlコンテンツタイプを使用する
  2. コンテンツタイプ（おそらくUTF-8）に文字エンコードを含めます
  3. XMLドキュメント自体のencoding属性に一致する文字エンコードを含めます。

一部のブラウザが適切に実装できないRFC3023仕様に関して、コンテンツタイプの主な違いは、次のように、クライアントが文字エンコードを処理する方法にあります。

application / xml、application / xml-dtd、application / xml-external-parsed-entity、またはapplication / atom + xml、application / rss + xml、application / rdf+xmlなどのapplication/xmlのサブタイプのいずれか、文字エンコードは次の順序で決定されます。

  1. Content-TypeHTTPヘッダーのcharsetパラメーターで指定されたエンコード
  2. ドキュメント内のXML宣言のencoding属性で指定されたエンコーディング。
  3. utf-8。

text / xml、text / xml-external-parsed-entity、またはtext / foo + xmlのようなサブタイプの場合、ドキュメント内のXML宣言のencoding属性は無視され、文字エンコードは次のようになります。

  1. Content-Type HTTPヘッダーのcharsetパラメーターで指定されたエンコーディング、または
  2. us-ascii。

ほとんどのパーサーは仕様を実装していません。HTTP Context-Typeを無視し、ドキュメント内のエンコーディングを使用するだけです。非常に多くの不正なドキュメントが存在するため、すぐに変更される可能性はほとんどありません。

于 2010-07-17T17:53:26.163 に答える
9

両方とも大丈夫です。

text/xxx は、プログラムが xxx を理解できない場合に、ファイルをプレーンテキストとしてユーザーに表示することが理にかなっていることを意味します。application/xxx は、それを表示しても意味がないことを意味します。

これらのコンテンツ タイプは、後に Web の世界で使用される前に、電子メールの添付ファイル用に定義されたものであることに注意してください。

于 2010-07-17T17:34:02.427 に答える
7

text/xml は、それ以上処理せずにテキストとして表示された場合に人間にとって意味のあるドキュメント用であり、application/xml はそれ以外のすべてのドキュメント用です。

すべての XML エンティティは、変更なしで application/xml メディア タイプでの使用に適しています。しかし、これは、多くの場合、XML をプレーン テキストとして扱うことができるという事実を利用していません。application/xml を明示的にサポートしていない MIME ユーザー エージェント (および Web ユーザー エージェント) は、ファイルへの保存を提案するなどして、それを application/octet-stream として扱います。

デフォルトで XML エンティティをプレーン テキストとして扱う必要があることを示すには、text/xml メディア タイプを使用します。これは、XML エンティティで使用されるエンコーディングを、[RFC-2045] および [RFC-2046] で説明されているテキスト メディア タイプの要件と互換性のあるものに制限します。 HTTP)。

— http://www.ietf.org/rfc/rfc2376.txt

于 2010-07-17T17:33:58.953 に答える