[8] application/octet-stream
は、任意のバイナリ(二進)・データを表すMIME型です。
すなわち、 application/octet-stream
と札付けされた実体の本体は何らかの意味を持つ
(あるいは持たない) 任意のビット列です。
[9] MIME の媒体型の仕組みの中では、この媒体型はやや特殊な位置付けです。
text/*
や
multipart/*
以外の媒体型は、
もし実装がその具体的な媒体型を知らなければ、
application/octet-stream
と同じように扱います。
また、実装が知っている媒体型であっても、知らない CTE で転送符号化されているときには、やはり
application/octet-stream
として扱うことになっています。
つまり、 application/octet-stream
は最も基本的な媒体型と言うことができます。
[37] たとえば、 application/x-foobar という媒体型を知らない MIME UA は、 aplication/x-foobar
の実体を application/octet-stream
の実体と同じように処理します。
[38] このMIME型は、対象となるデータのファイル形式が明確でない時や、 明確にしたくない時 (例えばWebブラウザーにファイルを解釈させず、 ダウンロードさせたい時) に使われることがあります。
[24] MIME型 application/octet-stream
は、
任意のバイナリーデータを表します >>23, >>32。
[36] 「オクテット列」 (= バイト列) という名前に反して、 実は任意のビット列を扱えます。 8ビット単位になっている必要はありません。
[48]
application/octetstream
とされることがありますが、
誤りです。
[19] 何らかのバイナリデータがあり、そのMIME型が分からない場合や、
敢えて MIME型を明確にせずに扱いたい時に、 application/octet-stream
を使います。
text/plain
を使う実装もありますが、
不適切です。[10] MIME UA が application/octet-stream
の実体を受取った時に、これをどう処理するかは、
他のほとんどの媒体型同様に、実装依存です。
しかしながら、未知のバイナリ・データなのですから、 直接表示しないで利用者の指示を仰ぐか、 バイナリ・エディタの類のように十六進数などで表示するのが望ましいでしょう。 実際ほとんどの実装はそのように扱います。
[30] 実装は、受信したデータを (CTE を復号してから) ファイルに保存することを提示したり >>23, >>32、 利用者が指定した処理への入力として使ったり >>23 することが推奨されています。
[31] 危険な入力を与えられる可能性があるので、
Content-Type:
の引数から任意のプログラムを決定して実行するような実装とはしないことを強く推奨されています >>23。
[43] MIME Sniffing も参照。
type
引数[25] type
引数は、
バイナリーデータの一般的な型や種別を表します
>>23。
[26] これは自動処理のためのものではなく、人間受信者に対する情報として使うことが想定されています >>23。
[29] この引数の値は特に規定されておらず、任意の値を記述できるようです。
[27] 次のような値が見られます。
Content-Type: application/octet-stream; type=tar+gzip
[21] application/*
、Content-Disposition: attachment
、
download
属性も参照。
[33] 未知の charset
の未知の text/*
部分型は、 application/octet-stream
として扱われるべきです。
text/*
参照。[34] multipart/*
や text/*
を除き、各最上位型の未知のMIME型は、
application/octet-stream
として扱われるべきです。
conversions
引数を使っています。値は x-CBF_CANONICAL
と x-CBF_PACKED
。name
引数の意味で file
引数を使っています。ファイルをダウンロードさせたいときは application/octet-stream
を使えばいい
と言うのはいろいろな意味で間違いであり、気持ち悪い。 (1) ダウンロード ≠ 保存。 (2) application/octet-stream
は保存と言う意味でもダウンロードという意味でもない。 Content-Type
欄などはあくまで実体本体の媒体型を記述するべきであって、受信者の動作を記述するべきではない。 (MIME や HTTP では他に内容の記述形式を表す方法がないと言うのに、動作の表現に使ってどうするのさ。) (受信者の動作の指針を与えるためには Content-Disposition
を使うのが正しい。)[11] W3C のサイトの tar+gz な資源、
なぜか application/octet-stream
になってます。ブラウザで展開ソフトウェアに関連付けることができないので不便。なんとかしてほしいなあ。
Content-Type: application/octet-stream; type=gzip
[40] それ自体は妥当な仕様だと思いますが、こういう説明になっているのは、
application/octet-stream
のとき IE が sniffing
する仕様だったため、 IE ではWebブラウザー内で表示され、 Netscape
ではダウンロード扱いになり、困った人がたくさんいたということなのでしょうね。
[45] Fix overrideMimeType() again (annevk著, ) https://github.com/whatwg/xhr/commit/121cee50b6f51215f046266642964b4c53a02a7c
[46] 918731 - XMLHttpRequest's overrideMimeType() does not follow the standard () https://bugzilla.mozilla.org/show_bug.cgi?id=918731
[47] No longer render resources requested via FTP (mikewest著, ) https://github.com/whatwg/fetch/commit/c6b3a750f811cb4f628def0313ac317d9dcec88a
[49] RFC 2911 - Internet Printing Protocol/1.1: Model and Semantics (, ) https://tools.ietf.org/html/rfc2911#section-4.1.9.1