私の知る限り、それらはまったく同じです。ただし、いくつかのDjangoドキュメントを参照すると、次のコードが見つかりました。
HttpResponse.__init__(content='', mimetype=None, status=200, content_type='text/html')
二人がお互いに仲良くなっているのは驚きです。公式ドキュメントは、問題を実用的な方法で解決できました。
content_typeはmimetypeのエイリアスです。歴史的に、このパラメーターはmimetypeと呼ばれていましたが、これは実際にはHTTP Content-Typeヘッダーに含まれる値であるため、文字セットエンコーディングも含めることができ、MIMEタイプの仕様以上のものになります。 mimetypeが(Noneではなく)指定されている場合、その値が使用されます。それ以外の場合、content_typeが使用されます。どちらも指定されていない場合、DEFAULT_CONTENT_TYPE設定が使用されます。
ただし、十分に解明されていません。 (ほぼ同じ)ものに2つの異なる命名を使用する理由「Content-Type」はブラウザのリクエストで使用される単なる名前であり、それ以外ではほとんど使用されませんか?
それぞれの主な違いは何ですか?また、content-type
ではなくmimetype
を呼び出すのはいつですか?私は取るに足らないと文法ナチですか?
(ほぼ同じ)ものに2つの異なる命名を使用する理由「Content-Type」はブラウザのリクエストで使用される単なる名前であり、それ以外ではほとんど使用されませんか?
それぞれの主な違いは何ですか?また、content-typeではなくmimetypeを呼び出すのはいつですか?私は取るに足らないと文法ナチですか?
理由は後方互換性だけではありません。通常、優れたDjangoのドキュメントはそれについて少し手を振っています。 [〜#〜] mime [〜# 〜] (少なくともWikipediaのエントリを読む価値はあります)は、インターネットメール、特にSMTPを拡張することに起源を持っています。ここではHTTPなど)、既存のプロトコルで新しい種類のメタデータやデータを送信する必要がある場合にまだ使用されています。多くの目的で使用されるMIMEについて説明しているRFCは多数あります。
具体的には、Content-Type:
は、いくつかのMIMEヘッダーの1つです。 「MIMEタイプ」は確かに時代遅れに聞こえますが、MIME自体への参照はそうではありません。必要に応じて、その部分を後方互換性で呼び出します。
[ところで、これは純粋に用語の問題であり、文法とは何の関係もありません。 「文法」の下ですべての使用法の質問を提出することは私の厄介者です。 Grrrr。]
私は常にcontentTypeがmimeTypeのスーパーセットであると考えてきました。唯一の違いは、オプションの文字セットエンコーディングです。 contentTypeにオプションの文字セットエンコーディングが含まれていない場合、mimeTypeと同じです。それ以外の場合、mimeTypeは文字セットエンコーディングシーケンスの前のデータです。
例えば。 text/html; charset=UTF-8
text/html
はmimeTypeです;
は追加のパラメーターインジケーターです。charset=UTF-8
は文字セットエンコーディングパラメータです
例えば。 application/msword
application/msword
はmimeTypeです
整形式のoctet-stream
文字を直接含まない。
詳細を知りたい場合は、チケット 526 を参照してください。
見積もり:
Mimetypeのエイリアスとしてcontent_typeをHttpResponseコンストラクターに追加しました。少し正確な名前です。 Simon Willisonのパッチに基づいています。完全な下位互換性があります。
(ほぼ同じ)ものに2つの異なる命名を使用する理由
ドキュメントからの引用に基づく下位互換性。