Edit

Page

Page title:

Page body:

[8] [DFN[[CODE(MIME)@en[[[application/octet-stream]]]]]]
は、''任意の[[バイナリ(二進)・データ][バイナリーデータ]]''を表す[[MIME型]]です。
すなわち、 [CODE(MIME)[application/octet-stream]]
と札付けされた[[実体]]の[[本体]]は何らかの意味を持つ
(あるいは持たない) 任意のビット列です。

[9] [[MIME]] の媒体型の仕組みの中では、この媒体型はやや特殊な位置付けです。
[CODE(MIME)[[[text/[VAR[*]]]]]] や
[CODE(MIME)[[[multipart/[VAR[*]]]]]] 以外の媒体型は、
もし実装がその具体的な媒体型を知らなければ、
[CODE(MIME)[application/octet-stream]] と同じように扱います。
また、実装が知っている媒体型であっても、知らない [ABBR[[[CTE]]]] で転送符号化されているときには、やはり
[CODE(MIME)[application/octet-stream]] として扱うことになっています。
つまり、 [CODE(MIME)[application/octet-stream]]
は最も基本的な媒体型と言うことができます。

[EG[
[37] たとえば、 [SAMP(MIME)[application/x-foobar]] という媒体型を知らない MIME [ABBR[[[UA]]]] は、 [CODE(MIME)[aplication/x-foobar]] の実体を [CODE(MIME)[application/octet-stream]] の実体と同じように処理します。
]EG]

[38] この[[MIME型]]は、対象となるデータのファイル形式が明確でない時や、
明確にしたくない時 (例えば[[Webブラウザー]]にファイルを解釈させず、
[[ダウンロード]]させたい時) に使われることがあります。

* 仕様書

[REFS[
- [32] [CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]] ([TIME[2015-03-22 13:14:46 +09:00]] 版) <http://tools.ietf.org/html/rfc2046#section-3>
- [23] '''[CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]] ([TIME[2015-03-22 13:14:46 +09:00]] 版) <http://tools.ietf.org/html/rfc2046#section-4.5.1>'''
]REFS]

* 意味

[24] [[MIME型]] [CODE(MIME)@en[[[application/octet-stream]]]] は、
任意の[[バイナリーデータ]]を表します [SRC[>>23, >>32]]。

[36] 「[RUBYB[[[オクテット列]]]@en[octet stream]]」 (= [[バイト列]]) という名前に反して、
実は任意の[[ビット列]]を扱えます。
8ビット単位になっている必要はありません。

;; [35] ただし8ビット以外で実装されたり使用されたりしているのを見たことはありません。

* 呼称

[48] 
[DFN[[CODE[application/octetstream]]]]
とされることがありますが、
'''誤り'''です。

* 引数

[12] 次の[[引数]]があります。

[FIG(short list)[ [44] [CODE(MIME)@en[application/octet-stream]] の[[引数]]
- [CODE(MIME)@en[[[codecs]]]]
- [CODE(MIME)@en[[[conversions]]]]
- [CODE(MIME)@en[[[name]]]]
- [CODE(MIME)@en[[[padding]]]]
- [CODE(MIME)@en[[[type]]]] (>>25)
]FIG]

* 文脈

[19] 何らかの[[バイナリデータ]]があり、その[[MIME型]]が分からない場合や、
敢えて [[MIME型]]を明確にせずに扱いたい時に、 [CODE(MIME)@en[[[application/octet-stream]]]]
を使います。

;; [20] そのような場合に [CODE(MIME)@en[[[text/plain]]]] を使う実装もありますが、
不適切です。

* 処理

[10] MIME [ABBR[UA]] が [CODE(MIME)[application/octet-stream]]
の実体を受取った時に、これをどう処理するかは、
他のほとんどの媒体型同様に、実装依存です。

しかしながら、未知のバイナリ・データなのですから、
直接表示しないで[[利用者]]の指示を仰ぐか、
[[バイナリ・エディタ]]の類のように十六進数などで表示するのが望ましいでしょう。
実際ほとんどの実装はそのように扱います。

[30] 実装は、受信したデータを ([[CTE]] を[[復号]]してから)
[[ファイル]]に保存することを提示したり [SRC[>>23, >>32]]、
[[利用者]]が指定した処理への入力として使ったり [SRC[>>23]] 
することが[RUBYB[推奨]@en[recommended]]されています。

[31] 危険な入力を与えられる可能性があるので、
[CODE(MIME)@en[[[Content-Type:]]]] の[[引数]]から任意の[[プログラム]]を決定して実行するような実装とはしないことを強く推奨されています [SRC[>>23]]。

** 電子メール

[17] [[MUA]] は、[[添付ファイル]]として扱います。

** Web

[16] [[Webブラウザー]]は、[[ダウンロード]]として扱います。

;; [18] [[MIME型]]がわかっていて、なおかつ[[添付ファイル]]や[[ダウンロード]]としたいときは、
[CODE(MIME)@en[[[Content-Disposition:]] [[attachment]]]] を使うのがより適切です。

;; [41] [CODE(DOMa)@en[download]] [[属性]]も参照。

[43] 
[[MIME Sniffing]] も参照。

* [CODE(MIME)@en[type]] 引数

[25] [DFN[[CODE(MIME)@en[[[type]]]]]] [[引数]]は、
バイナリーデータの[RUBYB[一般的な型や種別]@en[general type or category]]を表します
[SRC[>>23]]。

[28] この[[引数]]は、省略可能です [SRC[>>23]]。

[26] これは自動処理のためのものではなく、[[人間]][[受信者]]に対する情報として使うことが想定されています [SRC[>>23]]。

[29] この[[引数]]の値は特に規定されておらず、任意の値を記述できるようです。

[27] 次のような値が見られます。

- 2002-09-14 (Sat) 16:08:24 ''[[名無しさん]]'' : "emacs-lisp" [[elisp]] script (program?)
- 2002-09-15 (Sun) 14:51:04 ''[[名無しさん]]'' : "patch" [[patch]] file
- 2002-09-16 (Mon) 20:55:53 ''[[名無しさん]]'' : "gzip" [[gzip]]ed data

[50]

>
[PRE(MIME code)[
Content-Type: application/octet-stream; type=tar+gzip
]PRE]

[1] [[電子メール]]では以前はたまに使われているのを見かけました。

[2] [[HTTP]] ではほとんど使われていないと思われます。

* 関連

[21] [CODE(MIME)@en[[[application/*]]]]、[CODE(MIME)@en[[[Content-Disposition:]] [[attachment]]]]、
[CODE(HTMLa)@en[[[download]]]] [[属性]]も参照。

[33] 未知の [CODE(MIME)@en[[[charset]]]] の未知の [CODE(MIME)@en[[[text/*]]]]
[[部分型]]は、 [CODE(MIME)@en[[[application/octet-stream]]]] として扱われるべきです。

;; [CODE(MIME)@en[[[text/*]]]] 参照。

[34] [CODE(MIME)@en[[[multipart/*]]]] や [CODE(MIME)@en[[[text/*]]]]
を除き、各[[最上位型]]の未知の[[MIME型]]は、
[CODE(MIME)@en[[[application/octet-stream]]]] として扱われるべきです。

;; 各項参照。

* 歴史

[FIG(quote)[
[FIGCAPTION[
[13] RFC 2046 4.5.1.  Octet-Stream Subtype
]FIGCAPTION]

The "octet-stream" subtype is used to indicate that a body contains
arbitrary binary data.  The set of currently defined parameters is:

"octet-stream" 亜型は本文が任意のバイナリ・データであることを
示すのに使います。現在定義されているパラメーターの集合は、
次の通りです。

[PRE[
    (1)   TYPE -- the general type or category of binary data.
          This is intended as information for the human recipient
          rather than for any automatic processing.
]PRE]

TYPE バイナリ・データの一般的な型や分類。これは自動処理ではなく
人間受信者向けの情報を意図しています。

[PRE[
    (2)   PADDING -- the number of bits of padding that were
          appended to the bit-stream comprising the actual
          contents to produce the enclosed 8bit byte-oriented
          data.  This is useful for enclosing a bit-stream in a
          body when the total number of bits is not a multiple of
          8.
]PRE]

PADDING 実際の内容のビット列を8ビット・バイト指向のデータに
するために付け足した埋めビットの数。これはビットの合計数が8の倍数
でないビット列を本文に包むのに便利です。

訳注: RFC 1521 によると取りうる値は "0" 〜 "7" です。
[[application/*媒体型]]参照。 RFC 2046 にこの規定はありませんが、
常識的に考えてこの範囲でしょう。 (これより大きな値を受け取った時は
どうしましょうか?)

Both of these parameters are optional.

両パラメーターとも省略可能です。

[PRE[
   An additional parameter, "CONVERSIONS", was defined in RFC 1341 but
   has since been removed.  RFC 1341 also defined the use of a "NAME"
   parameter which gave a suggested file name to be used if the data
   were to be written to a file.  This has been deprecated in
   anticipation of a separate Content-Disposition header field, to be
   defined in a subsequent RFC.
]PRE]

追加のパラメーター "CONVERSIONS" が RFC 1341 で定義されていましたが
削除されました。 RFC 1341 はデータをファイルに書くときに
使われるファイル名を提案する "NAME" パラメーターの使用も
定義していました。これは後の RFC で定義される別の Content-Disposition
頭領域を使うことを期待するものです。

;; 意訳。

The recommended action for an implementation that receives an
"application/octet-stream" entity is to simply offer to put the data
in a file, with any Content-Transfer-Encoding undone, or perhaps to
use it as input to a user-specified process.

"application/octet-stream" 実体を受け取った実装の推奨される動作は、
Content-Transfer-Encoding を戻して、単にデータをファイルに入れるか
または利用者の指定する処理の入力として使うかです。

To reduce the danger of transmitting rogue programs, it is strongly
recommended that implementations NOT implement a path-search
mechanism whereby an arbitrary program named in the Content-Type
parameter (e.g., an "interpreter=" parameter) is found and executed
using the message body as input.

浮浪プログラムの転送の危険を減らすため、実装は Content-Type パラメーター
(例えば "interpreter=" パラメーター) で指名された任意のプログラム
があればメッセージ本文を入力に使って実行する経路検索機構を
実装'''しない'''ことを強く推奨します。
]FIG]

[FIG(quote)[
[FIGCAPTION[
[14] RFC 1341 7.4.1 から抜粋
]FIGCAPTION]

・・・

[PRE[
                 NAME -- a suggested name for the  binary  data  if
                 stored as a file.
]PRE]

NAME バイナリ・データがファイルとして保管される時の名前の提案。

・・・

[PRE[
                 CONVERSIONS -- the set  of  operations  that  have
                 been  performed  on  the data before putting it in
                 the mail (and before any Content-Transfer-Encoding
                 that   might   have  been  applied).  If  multiple
                 conversions have occurred, they must be  separated
                 by  commas  and  specified  in the order they were
                 applied -- that is, the leftmost conversion   must
                 have  occurred  first,  and conversions are undone
                 from right  to  left.   Note  that  NO  conversion
                 values   are   defined   by  this  document.   Any
                 conversion values that that do not begin with "X-"
                 must  be preceded by a published specification and
                 by  registration  with  IANA,  as   described   in
                 Appendix F.
]PRE]

CONVERSIONS データをメイルに入れる前 (で Content-Transfer-Encoding
が適応されたかもしれない前) に施された処理の集合 複数の変換があった場合は、
読点(comma)で区切って施された順に指定します。つまり左端の変換が
最初に行われたもので無くてはならず、逆変換は右から左へと戻していきます。
この文書では変換値は定義'''しません'''。 "X-" で始まらない変換値
は予め仕様書を出版して IANA に附属書 F で説明する通り登録する
必要があります。

・・・

[PRE[
            The values  for  these  attributes  are  left  undefined  at
            present,  but  may  require specification in the future.  An
            example of a common (though UNIX-specific) usage might be:
]PRE]

これらの属性の値は現時点で未定義のままですが、将来規定する必要がある
かもしれません。共通な (UNIX 特有だけど) 例は、次の通りです。

[PRE[
                 Content-Type:  application/octet-stream;
                      name=foo.tar.Z; type=tar;
                      conversions="x-encrypt,x-compress"
]PRE]

[PRE[
            However, it should be noted that the use of such conversions
            is  explicitly  discouraged due to a lack of portability and
            standardization.   The  use  of  uuencode  is   particularly
            discouraged,   in  favor  of  the  Content-Transfer-Encoding
            mechanism, which is both more standardized and more portable
            across mail boundaries.
]PRE]

ですが、このような変換の使用は移植性と標準化を欠いているので、
明白に非推奨であることに注意して下さい。 uuencode の使用は特に非推奨です。
より標準化されているしよりメイル境界を越えて移植性がある
Content-Transfer-Encoding 機構があります。

・・・
]FIG]

* メモ

[FIG(amazon)[
[[Web]] 開発
]FIG]

- [3] >>2 octet‐stream とは、読んで字の如く、オクテットの連続体のことです。 MIME 的には、任意の[[オクテット]]列, すなわち任意のバイナリを意味します。
- [4] また、 octet という名前ではありますが、実は仕様的にはオクテット (= 8ビット) 単位になっていない任意のビット列を扱うこともできます。 (実際に扱える実装があるのかはしらないけど)

- [5] ''cbfext98 v0.7.1'' <http://www.iucr.org/iucr-top/cif/imgcif/cbfext98.html#_array_data.data> : 圧縮方式を表すのに [CODE(MIME)[conversions]] 引数を使っています。値は [CODE(MIME)[x-CBF_CANONICAL]] と [CODE(MIME)[x-CBF_PACKED]]。
- [6] ''Bommanews technical'' <http://b-news.sourceforge.net/tech.html> : 内部的な保管形式ですが、 [CODE(MIME)[name]] 引数の意味で [CODE(MIME)[file]] 引数を使っています。
- [7] [Q[ファイルをダウンロードさせたいときは [CODE(MIME)[application/octet-stream]] を使えばいい]]と言うのはいろいろな意味で間違いであり、気持ち悪い。 (1) ダウンロード ≠ 保存。 (2) [CODE(MIME)[application/octet-stream]] は保存と言う意味でもダウンロードという意味でもない。 [CODE(MIME)[[[Content-Type]]]] 欄などはあくまで[[実体本体]]の[[媒体型]]を記述するべきであって、受信者の動作を記述するべきではない。 [WEAK[(MIME や HTTP では他に内容の記述形式を表す方法がないと言うのに、動作の表現に使ってどうするのさ。)]] [WEAK[(受信者の動作の指針を与えるためには [CODE(MIME)[[[Content-Disposition]]]] を使うのが正しい。)]]

[11] [[W3C]] のサイトの [[tar]]+[[gz]] な資源、
なぜか [CODE(MIME)[application/octet-stream]]
になってます。ブラウザで展開ソフトウェアに関連付けることができないので不便。なんとかしてほしいなあ。

[15]

[PRE(MIME example code)[
Content-Type: application/octet-stream; type=gzip
]PRE]

[FIG(quote)[
[FIGCAPTION[
[22] [CITE@en[RFC 2911 - Internet Printing Protocol/1.1: Model and Semantics]]
([TIME[2015-02-15 17:22:27 +09:00]] 版)
<https://tools.ietf.org/html/rfc2911#section-4.1.9.1>
]FIGCAPTION]

> One special type is 'application/octet-stream'.  If the Printer
>    object supports this value, the Printer object MUST be capable of
>    auto-sensing the format of the document data using an
>    implementation-dependent method that examines some number of octets
>    of the document data, either as part of the create operation and/or
>    at document processing time.

]FIG]

[FIG(quote)[
[FIGCAPTION[
[39] [CITE@ja-jp[拡張子を持たないファイルが Application/Octet-Stream にマップされる]]
( ([TIME[2017-02-03 21:00:26 +09:00]]))
<https://support.microsoft.com/ja-jp/help/264968/files-without-extensions-are-mapped-to-application-octet-stream>
]FIGCAPTION]

> IIS で、拡張子を持たないファイルが見つかると、Content-Type が application/octet-stream としてブラウザへ送り返されます。この動作はユーザー インターフェイスでは変更できません。AOL Netscape ブラウザでは、このヘッダー設定が原因でファイルが表示されず、代わりにファイルのダウンロードが開始されます。

]FIG]

[40] それ自体は妥当な仕様だと思いますが、こういう説明になっているのは、
[CODE(MIME)@en[application/octet-stream]] のとき [[IE]] が [[sniffing]] 
する仕様だったため、 [[IE]] では[[Webブラウザー]]内で表示され、 [[Netscape]]
では[[ダウンロード]]扱いになり、困った人がたくさんいたということなのでしょうね。

[FIG(quote)[
[FIGCAPTION[
[42] [CITE[Buck: HTTP Cache API]]
( ([TIME[2017-03-28 18:39:38 +09:00]]))
<https://buckbuild.com/concept/http_cache_api.html>
]FIGCAPTION]

> If the artifact is cached, the response should be:
> status 200
> content-type application/octet-stream
> 32 bit big endian signed integer denoting the number of length in bytes of the metadata
> (1) bytes of metadata
> The artifact's data

]FIG]

[45] [CITE@en[Fix overrideMimeType() again]]
([[annevk]]著, [TIME[2018-04-17 17:54:28 +09:00]])
<https://github.com/whatwg/xhr/commit/121cee50b6f51215f046266642964b4c53a02a7c>

[46] [CITE@en[918731 - XMLHttpRequest's overrideMimeType() does not follow the standard]]
([TIME[2018-04-18 13:58:46 +09:00]])
<https://bugzilla.mozilla.org/show_bug.cgi?id=918731>

[47] [CITE@en[No longer render resources requested via FTP]]
([[mikewest]]著, [TIME[2018-12-13 23:59:41 +09:00]])
<https://github.com/whatwg/fetch/commit/c6b3a750f811cb4f628def0313ac317d9dcec88a>

[49] [CITE@en[RFC 2911 - Internet Printing Protocol/1.1: Model and Semantics]]
([TIME[2021-04-04T10:05:58.000Z]], [TIME[2021-04-16T07:45:30.947Z]])
<https://tools.ietf.org/html/rfc2911#section-4.1.9.1>

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)