*type パラメーター 値: - 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 - [1] [WEAK[2003-09-14 15:54:03 +00:00]] ''[[Powerpoint]]'': Application Winme [[#comment]] *RFC 2046 4.5.1. Octet-Stream Subtype The "octet-stream" subtype is used to indicate that a body contains arbitrary binary data. The set of currently defined parameters is: "octet-stream" 亜型は本文が任意のバイナリ・データであることを 示すのに使います。現在定義されているパラメーターの集合は、 次の通りです。 (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. TYPE バイナリ・データの一般的な型や分類。これは自動処理ではなく 人間受信者向けの情報を意図しています。 (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. PADDING 実際の内容のビット列を8ビット・バイト指向のデータに するために付け足した埋めビットの数。これはビットの合計数が8の倍数 でないビット列を本文に包むのに便利です。 訳注: RFC 1521 によると取りうる値は "0" 〜 "7" です。 [[application/*媒体型]]参照。 RFC 2046 にこの規定はありませんが、 常識的に考えてこの範囲でしょう。 (これより大きな値を受け取った時は どうしましょうか?) Both of these parameters are optional. 両パラメーターとも省略可能です。 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. 追加のパラメーター "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=" パラメーター) で指名された任意のプログラム があればメッセージ本文を入力に使って実行する経路検索機構を 実装'''しない'''ことを強く推奨します。 *RFC 1341 7.4.1 から抜粋 ・・・ NAME -- a suggested name for the binary data if stored as a file. NAME バイナリ・データがファイルとして保管される時の名前の提案。 ・・・ 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. CONVERSIONS データをメイルに入れる前 (で Content-Transfer-Encoding が適応されたかもしれない前) に施された処理の集合 複数の変換があった場合は、 読点(comma)で区切って施された順に指定します。つまり左端の変換が 最初に行われたもので無くてはならず、逆変換は右から左へと戻していきます。 この文書では変換値は定義'''しません'''。 "X-" で始まらない変換値 は予め仕様書を出版して IANA に附属書 F で説明する通り登録する 必要があります。 ・・・ 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: これらの属性の値は現時点で未定義のままですが、将来規定する必要がある かもしれません。共通な (UNIX 特有だけど) 例は、次の通りです。 Content-Type: application/octet-stream; name=foo.tar.Z; type=tar; conversions="x-encrypt,x-compress" 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. ですが、このような変換の使用は移植性と標準化を欠いているので、 明白に非推奨であることに注意して下さい。 uuencode の使用は特に非推奨です。 より標準化されているしよりメイル境界を越えて移植性がある Content-Transfer-Encoding 機構があります。 ・・・ *See also -[[MIME]] --[[媒体型]] ---[[application/*媒体型]] ---[[Content-Type:領域]] --[[Content-Transfer-Encoding:領域]] --[[Content-Disposition:領域]] --RFC 1341 --RFC 1521 --RFC 2045 --RFC 2046 --RFC 2048 *License See [[RFCのライセンス]]