/[pub]/test/sw/ids/0/92.txt
Suika

Contents of /test/sw/ids/0/92.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (hide annotations) (download)
Mon Nov 10 03:04:06 2008 UTC (17 years, 5 months ago) by wakaba
Branch: MAIN
CVS Tags: HEAD
File MIME type: text/plain
converted from SuikaWiki3 <http://suika.fam.cx/gate/cvs/suikawiki/wikidata/page/6170706C69636174696F6E2F6F637465742D73747265616D.txt>

1 wakaba 1.1 [8] [DFN[[[媒体型]] [CODE(MIME)[application/octet-stream]]]]
2     は、''任意のバイナリ(二進)・データ''を表します。
3     すなわち、 [CODE(MIME)[application/octet-stream]]
4     と札付けされた[[実体]]の[[本体]]は何らかの意味を持つ
5     (あるいは持たない) 任意のビット列です。
6    
7     「[[オクテット列]]」という名前に反して、
8     実は任意の[[ビット列]]を扱えます。
9     [WEAK[(8ビット単位になっている必要はありません。)]]
10     [WEAK[(ただし実装されたり使用されたりしているのを見たことはありません。)]]
11    
12     [9] [[MIME]] の媒体型の仕組みの中では、この媒体型はやや特殊な位置付けです。
13     [CODE(MIME)[[[text/[VAR[*]]]]]] や
14     [CODE(MIME)[[[multipart/[VAR[*]]]]]] 以外の媒体型は、
15     もし実装がその具体的な媒体型を知らなければ、
16     [CODE(MIME)[application/octet-stream]] と同じように扱います。
17     [WEAK[たとえば、 [SAMP(MIME)[application/x-foobar]] という媒体型を知らない MIME [ABBR[[[UA]]]] は、 [CODE(MIME)[aplication/x-foobar]] の実体を [CODE(MIME)[application/x-foobar]] の実体と同じように処理します。]]
18     また、実装が知っている媒体型であっても、知らない [ABBR[[[CTE]]]] で転送符号化されているときには、やはり
19     [CODE(MIME)[application/octet-stream]] として扱うことになっています。
20     つまり、 [CODE(MIME)[application/octet-stream]]
21     は最も基本的な媒体型と言うことができます。
22    
23     [10] MIME [ABBR[UA]] が [CODE(MIME)[application/octet-stream]]
24     の実体を受取った時に、これをどう処理するかは、
25     他のほとんどの媒体型同様に、実装依存です。
26    
27     しかしながら、未知のバイナリ・データなのですから、
28     直接表示しないで[[利用者]]の指示を仰ぐか、
29     [[バイナリ・エディタ]]の類のように十六進数などで表示するのが望ましいでしょう。
30     実際ほとんどの実装はそのように扱います。
31    
32    
33    
34    
35    
36     [14]
37     これまたいったい何のプログラムを貼り付けたんだか。
38     ([[名無しさん]] [WEAK[2004-07-16 11:10:50 +00:00]])
39    
40     [[#comment]]
41    
42    
43     * type パラメーター
44    
45     値:
46     - 2002-09-14 (Sat) 16:08:24 ''[[名無しさん]]'' : "emacs-lisp" [[elisp]] script (program?)
47     - 2002-09-15 (Sun) 14:51:04 ''[[名無しさん]]'' : "patch" [[patch]] file
48     - 2002-09-16 (Mon) 20:55:53 ''[[名無しさん]]'' : "gzip" [[gzip]]ed data
49     - [1] [WEAK[2003-09-14 15:54:03 +00:00]] ''[[Powerpoint]]'': Application Winme
50     - [2] [WEAK[2003-09-29 02:20:45 +00:00]] ''[[名無しさん]]'': octet-streamとは
51     - [3] >>2 octet‐stream とは、読んで字の如く、オクテットの連続体のことです。 MIME 的には、任意の[[オクテット]]列, すなわち任意のバイナリを意味します。
52     - [4] また、 octet という名前ではありますが、実は仕様的にはオクテット (= 8ビット) 単位になっていない任意のビット列を扱うこともできます。 (実際に扱える実装があるのかはしらないけど)
53     [[#comment]]
54    
55    
56     * RFC 2046 4.5.1. Octet-Stream Subtype
57    
58     The "octet-stream" subtype is used to indicate that a body contains
59     arbitrary binary data. The set of currently defined parameters is:
60    
61     "octet-stream" 亜型は本文が任意のバイナリ・データであることを
62     示すのに使います。現在定義されているパラメーターの集合は、
63     次の通りです。
64    
65     [PRE[
66     (1) TYPE -- the general type or category of binary data.
67     This is intended as information for the human recipient
68     rather than for any automatic processing.
69     ]PRE]
70    
71     TYPE バイナリ・データの一般的な型や分類。これは自動処理ではなく
72     人間受信者向けの情報を意図しています。
73    
74     [PRE[
75     (2) PADDING -- the number of bits of padding that were
76     appended to the bit-stream comprising the actual
77     contents to produce the enclosed 8bit byte-oriented
78     data. This is useful for enclosing a bit-stream in a
79     body when the total number of bits is not a multiple of
80     8.
81     ]PRE]
82    
83     PADDING 実際の内容のビット列を8ビット・バイト指向のデータに
84     するために付け足した埋めビットの数。これはビットの合計数が8の倍数
85     でないビット列を本文に包むのに便利です。
86    
87     訳注: RFC 1521 によると取りうる値は "0" 〜 "7" です。
88     [[application/*媒体型]]参照。 RFC 2046 にこの規定はありませんが、
89     常識的に考えてこの範囲でしょう。 (これより大きな値を受け取った時は
90     どうしましょうか?)
91    
92     Both of these parameters are optional.
93    
94     両パラメーターとも省略可能です。
95    
96     [PRE[
97     An additional parameter, "CONVERSIONS", was defined in RFC 1341 but
98     has since been removed. RFC 1341 also defined the use of a "NAME"
99     parameter which gave a suggested file name to be used if the data
100     were to be written to a file. This has been deprecated in
101     anticipation of a separate Content-Disposition header field, to be
102     defined in a subsequent RFC.
103     ]PRE]
104    
105     追加のパラメーター "CONVERSIONS" が RFC 1341 で定義されていましたが
106     削除されました。 RFC 1341 はデータをファイルに書くときに
107     使われるファイル名を提案する "NAME" パラメーターの使用も
108     定義していました。これは後の RFC で定義される別の Content-Disposition
109     頭領域を使うことを期待するものです。
110    
111     ;; 意訳。
112    
113     The recommended action for an implementation that receives an
114     "application/octet-stream" entity is to simply offer to put the data
115     in a file, with any Content-Transfer-Encoding undone, or perhaps to
116     use it as input to a user-specified process.
117    
118     "application/octet-stream" 実体を受け取った実装の推奨される動作は、
119     Content-Transfer-Encoding を戻して、単にデータをファイルに入れるか
120     または利用者の指定する処理の入力として使うかです。
121    
122     To reduce the danger of transmitting rogue programs, it is strongly
123     recommended that implementations NOT implement a path-search
124     mechanism whereby an arbitrary program named in the Content-Type
125     parameter (e.g., an "interpreter=" parameter) is found and executed
126     using the message body as input.
127    
128     浮浪プログラムの転送の危険を減らすため、実装は Content-Type パラメーター
129     (例えば "interpreter=" パラメーター) で指名された任意のプログラム
130     があればメッセージ本文を入力に使って実行する経路検索機構を
131     実装'''しない'''ことを強く推奨します。
132    
133    
134     * RFC 1341 7.4.1 から抜粋
135    
136     ・・・
137    
138     [PRE[
139     NAME -- a suggested name for the binary data if
140     stored as a file.
141     ]PRE]
142    
143     NAME バイナリ・データがファイルとして保管される時の名前の提案。
144    
145     ・・・
146    
147     [PRE[
148     CONVERSIONS -- the set of operations that have
149     been performed on the data before putting it in
150     the mail (and before any Content-Transfer-Encoding
151     that might have been applied). If multiple
152     conversions have occurred, they must be separated
153     by commas and specified in the order they were
154     applied -- that is, the leftmost conversion must
155     have occurred first, and conversions are undone
156     from right to left. Note that NO conversion
157     values are defined by this document. Any
158     conversion values that that do not begin with "X-"
159     must be preceded by a published specification and
160     by registration with IANA, as described in
161     Appendix F.
162     ]PRE]
163    
164     CONVERSIONS データをメイルに入れる前 (で Content-Transfer-Encoding
165     が適応されたかもしれない前) に施された処理の集合 複数の変換があった場合は、
166     読点(comma)で区切って施された順に指定します。つまり左端の変換が
167     最初に行われたもので無くてはならず、逆変換は右から左へと戻していきます。
168     この文書では変換値は定義'''しません'''。 "X-" で始まらない変換値
169     は予め仕様書を出版して IANA に附属書 F で説明する通り登録する
170     必要があります。
171    
172     ・・・
173    
174     [PRE[
175     The values for these attributes are left undefined at
176     present, but may require specification in the future. An
177     example of a common (though UNIX-specific) usage might be:
178     ]PRE]
179    
180     これらの属性の値は現時点で未定義のままですが、将来規定する必要がある
181     かもしれません。共通な (UNIX 特有だけど) 例は、次の通りです。
182    
183     [PRE[
184     Content-Type: application/octet-stream;
185     name=foo.tar.Z; type=tar;
186     conversions="x-encrypt,x-compress"
187     ]PRE]
188    
189     [PRE[
190     However, it should be noted that the use of such conversions
191     is explicitly discouraged due to a lack of portability and
192     standardization. The use of uuencode is particularly
193     discouraged, in favor of the Content-Transfer-Encoding
194     mechanism, which is both more standardized and more portable
195     across mail boundaries.
196     ]PRE]
197    
198     ですが、このような変換の使用は移植性と標準化を欠いているので、
199     明白に非推奨であることに注意して下さい。 uuencode の使用は特に非推奨です。
200     より標準化されているしよりメイル境界を越えて移植性がある
201     Content-Transfer-Encoding 機構があります。
202    
203     ・・・
204    
205    
206     * See also
207    
208     - [[MIME]]
209     -- [[媒体型]]
210     --- [[application/*媒体型]]
211     --- [[Content-Type:領域]]
212     -- [[Content-Transfer-Encoding:領域]]
213     -- [[Content-Disposition:領域]]
214     -- RFC 1341 <urn:ietf:rfc:1341>
215     -- RFC 1521 <urn:ietf:rfc:1521>
216     -- RFC 2045 <urn:ietf:rfc:2045>
217     -- RFC 2046 <urn:ietf:rfc:2046>
218     -- RFC 2048 <urn:ietf:rfc:2048>
219    
220    
221     * License
222    
223     See [[RFCのライセンス]]
224    
225     - [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]]。
226     - [6] ''Bommanews technical'' <http://b-news.sourceforge.net/tech.html> : 内部的な保管形式ですが、 [CODE(MIME)[name]] 引数の意味で [CODE(MIME)[file]] 引数を使っています。
227     - [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]]]] を使うのが正しい。)]]
228    
229     [11] [[W3C]] のサイトの [[tar]]+[[gz]] な資源、
230     なぜか [CODE(MIME)[application/octet-stream]]
231     になってます。ブラウザで展開ソフトウェアに関連付けることができないので不便。なんとかしてほしいなあ。
232    
233     [15]
234    
235     [PRE(MIME example code)[
236     Content-Type: application/octet-stream; type=gzip
237     ]PRE]
238    

admin@suikawiki.org
ViewVC Help
Powered by ViewVC 1.1.24