-
Notifications
You must be signed in to change notification settings - Fork 4
/
280.txt
187 lines (138 loc) · 8.29 KB
/
280.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
[7] [DFN[[RUBYB[バイト]@en[byte]]]]は、処理上1単位とされる[[ビット列]]です。
現代では1[[バイト]]は、8[[ビット]]です。[DFN[[RUBYB[オクテット]@en[octet]]]]は、
8[[ビット]]の[[ビット列]]です。
[12] [[バイト]]は、通常、 0 [[以上]] 255 [[以下]]のいずれかの[[整数]]を表すものと解されます。
* 仕様書
[REFS[
- [14] [CITE@en-US[Encoding Standard]] ([TIME[2016-03-18 19:08:28 +09:00]] 版) <https://encoding.spec.whatwg.org/#byte>
]REFS]
* 意味
[15] [DFN[[RUBYB[バイト]@en[byte]]]]は、
8つの[[ビット]]の[[列]]です [SRC[>>14]]。
* 呼称
[8] 本来[[バイト]]は8[[ビット]]とは限らないため、8[[ビット]]を意味する時[[オクテット]]と呼ぶのを好む人もいます。
8[[ビット]]以外の[[バイト]]は最早歴史的・理論上の存在に過ぎないため、
広く普及している[[バイト]]が好ましいとする人もいます。
* 表記
[16] [[バイト]]は、2桁の[[16進数]] (範囲 [ [CODE[0x00]], [CODE[0xFF]] ])
で表現されます [SRC[>>14]]。
[HISTORY[
[30] 歴史的には[[十進数]]表記や[[八進数]]表記もよく用いられていましたが、
現在ではあまり用いられなくなっています。
[31] [[文字列]]を構成する[[バイト]]の場合は、[[ビット組合せ]]の表記を使うのが正式とされていました。
]HISTORY]
* 分類
[19]
[FIG(short list)[
- [[ASCIIバイト]]
- [[非ASCIIバイト]]
- [[バイナリーデータバイト]]
- [[空白バイト]]
- [[タグ終端バイト]]
- [[中間バイト]]
- [[終端バイト]]
]FIG]
* 関連
[20] [[バイト]]の[[列]]を、[[バイト列]]や[[オクテット列]]といいます。
[21] [[バイト]]を表すことを意図した [[C]] [[データ型]]として [CODE(C)@en[char]]
があります。
[22] [[アルバイト]]とは無関係です。
* 歴史
[1]
>
:[INS[[[JIS X 0211]]‐1994]] 4.2.10 バイト (byte):
一つの[[単位]]として取り扱う[[ビット]]列。
[5]
>
:4.2 バイト (byte):一つの[[単位]]として[[操作]]する[[ビット列]]。
各[[ビット]]は、0又は1の[[値]]をもつ。
[SRC[[[JIS X 0202]]:1998 4.]]
[6]
>
:オクテット (octet):
1単位として取り扱う8[[ビット]]長のビット順序列。
([[JIS X 0221]]‐1:2001 4.27)
[4]
> [[実行環境]]の[[基本文字集合]]の任意の要素を保持するために十分な大きさを持つ[[データ記憶域]]の[[単位]]。
[[オブジェクト]]の個々のバイトの[[アドレス]]を、
一意に表現できなければならない。
バイトは連続する[[ビット]]の列からなる。
1バイト中のビット数は、[[処理系定義]]とする。
最も[[重み]]の小さいビットを[DFN[[[下位ビット]]]]
(low-order bit) と呼び、最も重みの大きいビットを[DFN[[[上位ビット]]]]
(high‐order bit) と呼ぶ。 [INS[([[JISX3010]]-1993 3.4)]]
[REFS[
- [17] [CITE[MIME Sniffing Standard]] ([TIME[2016-03-05 01:29:10 +09:00]] 版) <https://mimesniff.spec.whatwg.org/#byte>
]REFS]
[18] [[MIME Sniffing]] は [[Encoding Standard]] の定義を参照しています。
** メモ
[3] ''バイト''と併用される倍数接頭辞には、幾つかの流儀があります。
一番よく使われているのは、 1 [[KB]] (キロ・バイト) = 1024 B = 2[SUP[10]] B
とする方法です。[[ビット]]の2進性を中心に考えると自然な方法です。
しかし、これは [[SI]] の流儀 ([[k]] (キロ) = 1000 = 10[SUP[3]])
とは一致しません。日常的 (10進的) 感覚からすると 1024
という数は中途半端な感じがしますし、計算も面倒です。
(例えば 100,000 バイトは 100 キロ・バイトでは''ありません''。)
この方法は[[ハード・ディスク]]の製品案内などでよく使われます。
この問題を解決するための幾つかの提案があります。
まず、 KB の K と [[kg]] の k (SI のキロ) を別のものとしてしまうというものです。
この流儀の人の中には、 KB を「ケー・バイト」, MB
を「エム・バイト」のように読むべきだと言う人もいます。
(但しこの考え方は古めのもので、現在では廃れた感があります。)
しかしこの方法には致命的な欠点があります。 K と k
は区別できても、それ以上の単位, M や G は区別できません。
SI が既に大文字ですし、 SI には [[m]] (ミリ) や [[g]]
(グラム) が存在しますから、どうにもなりません。
他の回避法として、バイト系の接頭辞に i をつける方法と、
接頭辞を二重にする方法があります。前者では KiB, MiB, GiB
([RUBYB[ギビ] [gibi]]・バイト)、後者では KKB ([RUBYB[大] [large]]キロ・
バイト), MMB, TTB のような単位になります。
しかし、これらの回避法はいずれも普及したものではありません。
普及する見通しも今のところありません。
今後も 10[SUP[3]] 系と 2[SUP[10]] 系の単位による混乱は続くでしょう。
[11] ''Large Disk HOWTO: 単位とサイズ'' <http://www.linux.or.jp/JF/JFdocs/Large-Disk-HOWTO-3.html>
[2] 8ビットに相当する単位としては[[バイト]]が有名ですが、バイトの長さは環境に依存するもので、 [CODE(math)[1 byte := 8bits]] と定義されているわけではありません。8ビット単位でデータを扱うことは非常に多いことは、1バイト ≒ 8ビットと考えられていることからも皮肉にも明らかですから、不便極まりありません。そこできっちり必ず8ビットをあらわす単位としてオクテットが使い出されました。
[9] こんにちでは依然バイト優位とはいえ、オクテットの知名度も徐々に上がっていますから、どうしてもバイトである必然性の無い限りオクテットに置換えていってよいと思われます。
[FIG(quote)[
[FIGCAPTION[
[13] [CITE@en[RFC 1951 - DEFLATE Compressed Data Format Specification version 1.3]]
([TIME[2016-01-10 18:30:17 +09:00]] 版)
<https://tools.ietf.org/html/rfc1951#section-1>
]FIGCAPTION]
> Byte: 8 bits stored or transmitted as a unit (same as an octet).
For this specification, a byte is exactly 8 bits, even on machines
which store a character on a number of bits different from eight.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[23] [CITE@en[RFC 959 - File Transfer Protocol]]
( ([TIME[2016-06-05 16:18:06 +09:00]]))
<https://tools.ietf.org/html/rfc959#page-3>
]FIGCAPTION]
>
: byte size:
There are two byte sizes of interest in FTP: the logical byte
size of the file, and the transfer byte size used for the
transmission of the data. The transfer byte size is always 8
bits. The transfer byte size is not necessarily the byte size
in which data is to be stored in a system, nor the logical byte
size for interpretation of the structure of the data.
]FIG]
[24] [CITE@en[Editorial: start using the Infra Standard]]
([[annevk]]著, [TIME[2016-11-18 20:21:54 +09:00]])
<https://github.com/whatwg/encoding/commit/a26f76889bf393999e9caad84a3647ab09c39e09>
[25] [CITE@en[Editorial: start using the Infra Standard]]
([[annevk]]著, [TIME[2016-11-18 23:44:14 +09:00]])
<https://github.com/whatwg/fetch/commit/9ba4e78e5cb5fc1132f89d7e344cd2c2e1950c67>
[26] [CITE@en[Improve representation guidelines for bytes and code points]]
([[annevk]]著, [TIME[2017-03-23 22:25:17 +09:00]])
<https://github.com/whatwg/infra/commit/543b2c48b6e1babb50d77e5a3ba5b86be8b56eb9>
[27] [CITE@en[Editorial: format bytes and code points per Infra]]
([[annevk]]著, [TIME[2017-03-28 21:14:42 +09:00]])
<https://github.com/whatwg/url/commit/91cb2aa532bc2b217e6237d23649aed0d2c566bb>
[28] [CITE@en[Editorial: let code point and friends be defined by Infra]]
([[annevk]]著, [TIME[2017-03-29 17:47:15 +09:00]])
<https://github.com/whatwg/html/commit/59595d9c2ccadb9332c15048be5d30174532ee70>
[29] [CITE@en[Deal with the parentheses exception for code point/byte display]]
([[annevk]]著, [TIME[2017-03-30 13:25:34 +09:00]])
<https://github.com/whatwg/infra/commit/a743dbd7f1c9d6200d8eaae127aeeb85a701fb02>