-
Notifications
You must be signed in to change notification settings - Fork 4
/
221.txt
350 lines (288 loc) · 20.5 KB
/
221.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
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
[22] ある[[文字コード]]で同じ[[文字]]を複数の方法で表現できる(ようにする)ことを、
[DFN[重複符号化]]といいます。
[28] 歴史的に[[文字コード]]規格はなるべく[[重複符号化]]が起こらないようにしてきました。
同じ文字列が複数の方法で表現し得るとしたら処理が複雑になり混乱の元だからです。
[29] 実際にはそれを徹底するのは難しく、かなりよく起こっていました。
単純な作業ミスで起こったものもあれば、
[[文字]]の同一性とは何かという哲学的、本質的な課題から導かれたものもあります。
[[文字コード]]の技術的特性から生じたものもあります。
[30]
現在使われている
[[Unicode]]
には[[重複符号化]]が平然と行われている例が多数あります。
* Unicode における重複符号化
[31]
[[Unicode]]
の[[符号化済文字]]の中には、
他の[[規格]]との[[互換性]]のためと称して、
1つの[[抽象文字]]が複数の[[符号点]]に対応することがあります。
[SRC[>>35 D11]]
[EG[
[32] 「Å」は、
[CODE[U+00C5]] [CODE(charname)@en[LATIN CAPITAL LETTER A WITH RING ABOVE]]
と
[CODE[U+212B]] [CODE(charname)@en[ANGSTROM SIGN]]
に対応します。
[SRC[>>34 D11]]
]EG]
[33]
単一の[[抽象文字]]が、
単一の[[符号点]]だけでなく、
[[符号点]]の列でも表現できることがあります。
[SRC[>>35 D11]]
[EG[
[34]
[CODE[U+01F5]] [CODE(charname)@en[LATIN CAPITAL LETTER G WITH ACUTE]]
は、
[CODE[<[[U+0047]] [CODE(charname)@en[LATIN CAPITAL LETTER G]], [[U+0301]] [CODE(charname)@en[COMBINING ACUTE ACCENT]]>]]
でも表現できます。
[SRC[>>35 D11]]
]EG]
[REFS[
- [35] [CITE[[[The Unicode Standard]], Version 13.0 - ch03.pdf]], [TIME[2020-03-09T17:53:34.000Z]], [TIME[2020-12-20T02:08:18.239Z]] <https://www.unicode.org/versions/latest/ch03.pdf#G2212>
]REFS]
* Unicode 以前の単一文字集合内の重複符号化
[23] [[Big5]] では2つの[[漢字]]が誤って2組ずつ収録されています。
[[Big5]] との互換性のため[[CJK互換漢字]]にも重複収録されています。
[24] [[KS X 1001]] では[[漢字]]が[[韓国語]]の読みごとに区別されて収録されています。
[[KS X 1001]] との互換性のため[[CJK互換漢字]]にも重複収録されています。
[25] [[シフトJIS]]は[[NEC]]由来の拡張と[[IBM]]由来の拡張でいくつかの[[文字]]が重複収録されています。
[27] [[KPS 9566]] は[[将軍様]]の名前を表す[[チョソングル]]を通常用の[[チョソングル]]と別個に収録しています。
[26] 歴史的に同源で見た目が同じでも、異なる[[用字系]]に属するとされて別個に収録されていることはよくあります。
[FIG(list)[
- [[ラテン文字]] vs [[ギリシャ文字]] vs [[キリル文字]] vs [[ローマ数字]]
- [[平仮名]] vs [[片仮名]]
- [[漢字]] vs [[部首]]
]FIG]
* ISO/IEC 2022 における一意符号化規定
[19] [[ISO/IEC 2022]] は、同じ[[図形文字]]を複数の方法で表現することを禁止できるとしていました。
[1]
>
'''7.5 図形文字の一意な符号化'''
同じ[[文字]]が[[8ビット]]又は[[7ビット]]の[[符号]]の[[符号要素]]の
[[G0]], [[G1]], [[G2]] 及び [[G3]] として、
[[指示]]される複数の[[図形文字集合]]に現れることがある。
このような[[文字]]は、二つの[[集合]]を定義する仕様又は [[ISO]]
[[符号化文字集合]]の[[国際登録簿]]で同じ[[名前]]をもつ場合、
同じ[[文字]]とみなされる。
> 同一の[[文字]]が複数の[[集合]]に割り当てられている場合、
その[[文字]]は、その[[文字]]が割り当てられた任意の[[符号要素]]の
[[G0]], [[G1]], [[G2]] 又は [[G3]]
から取り出された[[符号化表現]]で[[表現]]されてよい。
> この[[規格]]を適用する場合、[[情報交換]]の際にすべての[[文字]]が[[一意]]の[[符号化表現]]をもつことを要求されるとき、
[[符号]]の[[版]]の規定 (10.1 参照) で、その制限を明らかにしなければならない。
> [[符号]]の一意化の制限を適用した場合、
その[[文字]]が割り当てられた最下位番号の[[符号要素]]
([[G0]], [[G1]], [[G2]] 及び [[G3]] の順) から[[符号化表現]]が[[表現]]される。
この場合、たとえ高位番号の[[符号要素]]が既に呼び出されていて、かつ、
その[[文字]]が割り当てられている下位番号の[[符号要素]]が呼び出されていないときでも、
高位番号の[[符号要素]]の[[文字]]の[[符号化表現]]は、
使用しない。 [SRC[[[JIS X 0202]]:1998 ([[ISO/IEC 2022]]:1994) 7.5]]
[2] 例えば、 [[ISO/IEC 646]] [[IRV]] と
[[JIS X 0208]]:1997 は共に [CODE(charname)[[[LATIN CAPITAL LETTER A]]]]
を定義しています。この2つを[[符号要素]]として使う場合、 >>1 によれば、
どちらの[[符号要素]]で定義されている[[符号位置]]によっても
[CODE(charname)[[[LATIN CAPITAL LETTER A]]]]
を[[表現]]できます。
しかし、一意符号化が求められる場合は、例えば [CODE(charset)[[[EUC-JP]]]]
のように [[G0]] に [[IRV]], [[G1]] に [[JIS X 0208]]
を[[指示]]するなら、 [CODE(charname)[[[LATIN CAPITAL LETTER A]]]]
は常に G 番号の小さい [[IRV]] の方で[[表現]]しなければなりません。
但し、 [CODE(charset)[[[ISO-2022-JP]]]] のように
[[IRV]] も [[JIS X 0208]] も [[G0]] に[[指示]]する場合は、
どちらも G 番号は等しいので、一意符号化制限を適用する場合であっても
2種類の[[符号化表現]]が認められます。
[3] ところで、
[Q[同じ[[文字]]]]は[[文字]]の[[名前]]によって判断するとされています。
[[ISO/IEC]] や [[JIS]] の最近の[[符号化文字集合]]の規格では[[文字]]の[[名前]]が
[[ISO/IEC 10646]] 式の統一された命名法に従っていますが、
古い規格はそうではありません。 [[ISOREG]]
や原規格の[[名前]]を常に適用してしまってよいのでしょうか。
(あるいは [[JIS X 0202]]:1998 5.3
[CSECTION[文字の名前]]の規定が適用されるのでしょうか。)
[13]
[[ISO/IEC 2022]] のこの規定は第4版 (1994年) で追加されました。
[SRC[[[JIS X 0202]]:1998 C.4]]
[5]
[[JIS X 0208]]:1997 7. [CSECTION[符号化文字集合]]には次の規定があります
([[JIS X 0213]]:2000 7. [CSECTION[符号化文字集合]]にもほぼ同様の規定があります)。
> '''7.2 [[ISO/IEC 646]] の[[国際基準版]] ([[IRV]]) と同時に用いる場合の[[符号]]'''
6.5.1 で規定する[[漢字集合]]と [[ISO/IEC 646]] の[[国際基準版]]とを同時に用いる場合、
[[ISO/IEC 646]] で規定される[[図形文字]]と同じ[[図形文字]]は用いてはならない。
ただし、これまでの慣用的な利用との互換を目的としてだけ、
附属書5表2に規定する[[文字]]を [[ISO/IEC 646]]
で規定される[[文字]]とは異なった[[図形文字]]として用いてもよい。
> '''7.3 [[JIS X 0201]] の[[ラテン文字]]と同時に用いる場合の[[符号]]'''
6.5.1 で規定する[[漢字集合]]と [[JIS X 0201]] の[[ラテン文字用図形文字集合]]とを同時に用いる場合、
[[JIS X 0201]] で規定される[[図形文字]]と同じ[[図形文字]]は用いてはならない。
ただし、これまでの慣用的な利用との互換を目的としてだけ、
附属書5表2に規定する[[文字]]を [[JIS X 0201]]
で規定される[[文字]]とは異なった[[図形文字]]として用いてもよい。
この規定は >>1 に基づくものですが、 [[JIS X 0208]]
のこの部分で規定されている[[符号化文字集合]]はあくまで
[[JIS X 0202]] とは独立に定義されています
[WEAK[([[JIS X 0202]] を実装した環境で用いることもできますが、そうである必要はありません)]]。
[4] [[JIS X 0208]]:1997 9.2 [CSECTION[指示]]
や [[JIS X 0213]]:2000 9.2 [CSECTION[指示]]
には次のような規定もあります。
> [[JIS X 0201]] 又は [[ISO/IEC 646]] と[[漢字集合]][INS[と]]を同時に[[指示]]する場合、
これまでの慣用的な利用との互換を目的としてだけ、附属書5表2
に規定する[[文字]]を [[JIS X 0201]] 又は [[ISO/IEC 646]]
で規定される[[文字]]とは異なった[[図形文字]]として用いてもよい。
> '''参考''' [[JIS X 0202]] では、同じ[[図形文字]]が複数の[[符号化文字集合]]中に現れ
[[G0]]〜[[G3]] に[[指示]]されているとき、 G 番号の小さいほうが優先され、
G 番号の大きいほうに現れる同じ[[図形文字]]は使用禁止とされる。
(挿入部は [[JIS X 0213]]:2000 にだけあって、
[[JIS X 0208]]:1997 には無い部分。)
[6] [[JIS X 0208]]:1997 [CSECTION[附属書1 (規定) シフト符号化表現]]や
[[JIS X 0213]]:2000 [CSECTION[附属書1 (参考) Shift_JISX0213 符号化表現]]
には、次の規定があります。
> '''4.5 代替名称を用いるビット組合せ''' 附属書1表1及び附属書1表2
に示す[[ビット組合せ]]は、原則として使用しない。ただし、
これまでの慣用的な利用との互換を目的としてだけ、
これらの[[ビット組合せ]]を使用してもよい。この場合には、[[文字名称]]は、
それぞれ附属書5表1及び附属書5表2の[[代替名称]]を用いなければならない。
> '''参考''' これらは、本体及び [[JIS X 0201]]
の両方で定義されている[[文字]]である。
[[シフト符号化表現]]や [[Shift_JISX0213]] 符号化表現や
[[Shift_JISX0213-plane1]] 符号化表現や
[[Shift_JIS-2004]] 符号化表現や
[[Shift_JIS-2004-plane1]] 符号化表現は [[ISO/IEC 2022]]
に基づく[[符号化文字集合]]ではありませんが、
考え方としては >>1 に拠っているようです。
[[JIS X 0213]]:2000 [CSECTION[附属書3 (規定) EUC-JISX0213 符号化表現]]には、
次の規定があります。
> '''備考''' [INS[(前略)]] 漢字集合1面の[[図形文字]]のうち、
[[国際基準版]][[図形文字]]と同じ[[図形文字]]は用いてはならない。
ただし、これまでの慣用的な利用との互換を目的としてだけ、
附属書5表2に規定する[[文字]]を[[国際基準版]]で規定される[[文字]]とは異なった[[図形文字]]として用いてもよい。
この規定は >>1 に基づくものですが、
ここで規定されている[[符号化文字集合]]はあくまで
[[JIS X 0202]] とは独立に定義されています
[WEAK[([[JIS X 0202]] を実装した環境で用いることもできますが、そうである必要はありません)]]。
ちなみに、[[JIS X 0208]]:1997 [CSECTION[附属書2 (規定) RFC 1468 符号化表現]]
([CODE(charset)[[[ISO-2022-JP]]]] もどき) や
[[JIS X 0213]]:2000 [CSECTION[附属書2 (参考) ISO-2022-JP-3 符号化表現]]
には相当する規定がありません
(>>2 と同じ理由)。
** 代替名称という逃げ道
[7]
[[JIS X 0202]] は >>1 の通り[[一意符号化]]で''ない''ものも認めていますが、
[[JIS X 0208]] は >>4 のように厳しく受け止めているらしく、
>>5 や >>6 のように同じ[[名前]]を持つ[[文字]]が
1つの[[符号化文字集合]]に複数存在することを避けています。
しかし実際には[[半角]]や[[全角]]と称した[[重複符号化]]が行われています。
そのため[Q[これまでの慣用的な利用との互換を目的としてだけ]]などと訳の分からない条件の下で[DFN[代替名称]]を与え、
[Q[[[ISO/IEC 646]] [[IRV]] の [CODE(charname)[[[LATIN CAPITAL LETTER A]]]] と [[JIS X 0208]]:1997 の [CODE(charname)[[[FULLWIDTH LATIN CAPITAL LETTER A]]]] は[[名前]]が違うから違う[[文字]]だ。違う[[文字]]なのだから1つの[[符号化文字集合]]で同時に使用してもよい。]]
という理屈をつけて現状と摺り合わせています。
[14]
余談になりますが、[Q[構成する[[文字]]が1[[文字]]でも異なるのであれば、それは異なる[[文字集合]]である]]
と言われます。であれば、 [[JIS X 0208]]:1997 本体は本来の[[文字集合]]、
[[IRV]] と併用するための[[文字集合]]、 [[JIS X 0201]]
と併用するための[[文字集合]]で3つの異なる[[文字集合]]を規定していることになります。
異なる[[文字集合]]を [[ISO/IEC 2022]]
環境下で使うためには[[指示]]のための[[終端バイト]]も普通異なるものだと考えたいところですが、
なぜか [[ISOREG]] や [[JIS X 0208]]:1997 9.1 によれば
1種類の[[終端バイト]]しか用意されていません。
[8] '''[CODE(charname)[FULLWIDTH OVERLINE]]''':
[[JIS X 0208]]:1997 の1区17点の[[文字]]は
[CODE(charname)[[[OVERLINE]]]] ですが、
附属書5 によれば[[代替名称]]は [CODE(charname)[[[FULLWIDTH OVERLINE]]]]
です。誰が見ても至極尤も自然なことです。
ところが、同じ命名法で[[文字]]に[[名前]]をつけている
[[ISO/IEC 10646]] には [CODE(charname)[[[FULLWIDTH OVERLINE]]]]
は存在せず、似たようなもので [CODE(charname)[[[FULLWIDTH MACRON]]]]
があります。
それでは・・・という話は [CODE(charname)[[[FULLWIDTH MACRON]]]]
の項をご覧下さい。
ちなみに、 [[JIS X 0213]]:2000 附属書5 によれば
1面1区17点の[[代替名称]]は
[CODE(charname)[[[FULLWIDTH MACRON]]]] です。
[9] '''[[JIS X 0208]] と [[IRV]] を併用する場合''':
>>5 には [[IRV]] と併用する場合附属書5に従うとありますが、
[[JIS X 0208]]:1997 附属書5 には
[CODE(charname)[[[REVERSE SOLIDUS]]]] の[[代替名称]]が欠けていますから、
この1[[文字]]に関してだけ
[Q[これまでの慣用的な利用との互換を目的とし]]た利用に問題が出ます。
(なお、附属書5 には [CODE(charname)[[[TILDE]]]]
もありませんが、 [[JIS X 0208]]:1997 には [CODE(charname)[[[TILDE]]]]
は存在しないので問題はありません。)
[[JIS X 0213]]:2000 附属書5 にはこの問題はありません。
[15] '''IRVとJIS X 0201で異なる2組4文字''':
- [[JIS X 0208]]:1997 附属書5表2には[[JIS X 0201]]で規定された
[CODE(charname)@en[[[YEN SIGN]]]]と[CODE(charname)@en[[[OVER LINE]]]]
[WEAK[([[JIS X 0208]]と[[JIS X 0213]]と[[JIS X 0221]]では[CODE(charname)@en[[[OVERLINE]]]])]]
を考慮した[[代替名称]]が規定されています。
- [[JIS X 0213]]:2000 附属書5表2にはそれに加えて[[ISO/IEC 646]]
[[IRV]]で規定された[CODE(charname)@en[[[REVERSE SOLIDUS]]]]と[CODE(charname)@en[[[TILDE]]]]を考慮した[[代替名称]]が規定されています。
- [[JIS X 0208]]でも[[JIS X 0213]]でも、
[[JIS X 0201]]と併用する場合附属書5表2を適用できるとされています。
- [[JIS X 0208]]でも[[JIS X 0213]]でも、
[[ISO/IEC 646]]と併用する場合附属書5表2を適用できるとされています。
問題は2つあります:
- [[JIS X 0208]]と[[IRV]]を併用する場合に[[代替名称]]がない2文字をどうするのか (>>9)
- 附属書5表2を適用する場合、全文字に対して適用しなければならないのか、
重複する文字についてのみなのか、任意の文字について適用してよいのか (>>16)
[16] 附属書5表2を適用する場合、その表に含まれるすべての[[文字]]/[[符号位置]]について[[代替名称]]を用いなければならないのか、
[[重複符号化]]となるものについてのみ用いなければならないのか、
任意のものについてのみ用いてよいのかが明記されていません。
文脈を汲むなら[[重複符号化]]となるものについてのみとするべきなのかもしれませんが・・・・・・。
例えば、[[IRV]]と[[JIS X 0213]]と附属書5表2のすべてを用いると、
[[符号化文字集合]]から[CODE(charname)@en[[[YEN SIGN]]]]と[CODE(charname)@en[[[OVERLINE]]]]が存在しなくなります。
[17] '''ISO/IEC 646とはなにか''':
>>5 ([[IRV]]を用いた[[JIS]]独自の[[符号化文字集合]])
の規定では[Q@en[[[IRV]]]]と明記されていますが、
>>4 ([[ISO/IEC 2022]]を用いた[[符号拡張]])
の規定では単に[Q@en[[[ISO/IEC 646]]]]としかありません。
[[ISO/IEC 646]]には[[ISO/IEC 646]]の[[規格票]]内で規定された[[IRV]]と、
各国等の規格で規定される[[ISO/IEC 646の版]]があり、
>>4 がいずれを指しているのかは明確ではありません。
[[JIS X 0201]] ([[ISO/IEC 646の版]]の1つ)
と併記されていることから[[IRV]]を指しているとも考えられますが、
>>5 では[Q@en[[[IRV]]]]と明記されているのに >>4
では明記されていないのも気になります。
[18] 仮に[[IRV]]のみを指すとした場合、
厳密に解釈すれば[[ASCII]] ([[ISO/IEC 646の版]]の1つで、
[[ISO/IEC 646]]:1991 [[IRV]]と同じ[[符号化文字集合]]のように見えます。)
と併用する際に[[代替名称]]が使用できるとする根拠も弱くなります。
[10] '''JIS X 0221 による UCS と JIS の対応付け''':
[[JIS X 0221]]‐1:2001 [CSECTION[附属書 2 (参考) 他の JIS の符号化文字集合との対応]]には、
[[JIS X 0201]], [[JIS X 0208]], [[JIS X 0212]], [[JIS X 0213]]
と [[UCS]] の対応関係が説明されています。
要点をまとめると、次の通りです。
- [[JIS]] の[[文字]]と [[UCS]] の[[文字]]で[[名前]]が一致するものがあれば、
対応させる。
- [[代替名称]]に関しても[[文字]]の[[名前]]の一致をもって対応させることができる。
- 一致するものが無ければ、対応させない。
- [[ISO/IEC 2022]] 環境では、 G
番号が小さい[[符号化文字集合]]の[[表現]]に対応させる。
- [[JIS X 0201]] の[[片仮名用図形文字集合]]の[[文字]]の[[名前]]は、
[[JIS X 0208]] や [[JIS X 0213]] の1面と併用する場合、
[[JIS X 0208]] 附属書5表1の[[代替名称]]を使ってもよい。
- [[JIS X 0212]] の2区20点の[[名前]]は [CODE(charname)[[[MACRON]]]]。
- [[JIS X 0212]] の2区23点の[[名前]]は [CODE(charname)[[[TILDE]]]]。
[11]
どの道同じ内容であるにはせよ、 [[JIS X 0213]]
と併用する場合は [[JIS X 0213]]
附属書5を参照するように指示した方が良いのでは、
と思ったりもします。
[12]
この附属書に従うのであれば、 [[JIS X 0212]]
の [CODE(charname)[[[TILDE]]]] に[[代替名称]]として
[CODE(charname)[[[FULLWIDTH TILDE]]]]
を使うことは'''できません'''。
** 現実
[20] この規定はほとんど理論上の整合性のためのようなもので、現実には無視されていました。
[[JIS]] が「慣用的な利用」と呼ぶ、[[94図形文字集合]]なら[[半角]]、
[[94[SUP[2]]図形文字集合]]なら[[全角]]として異なる[[文字]]として扱う実装がほとんどすべてで、
[[全角]]部分を利用しないこととする、あるいは[[半角]]と同じ[[文字]]とみなす実装は、
実用上あり得ませんでした。
[21] [[ISO-2022-JP]] は [[G0]] しか使わないので、 [[ISO/IEC 2022]]
の規定の適用範囲外でした。 [[EUC-JP]] や [[Shift_JIS]] では禁止されるはずの[[全角]]文字も、
[[ISO-2022-JP]] では使えることになります。 [[JIS]] の立場では重複でないから禁止する必要もないし、
「慣用的な利用」を認める必要もないということになるのでしょうが、
同時に、[[94図形文字集合]]も[[94[SUP[2]]図形文字集合]]も区別できない同じ文字として扱うことになります。
もちろんそのような実装は、実用上あり得ませんでした。
[[ISO-2022-JP]] と [[EUC-JP]] と [[Shift_JIS]] の3者で相互変換でき、
[[半角]]と[[全角]]の区別も保存される、というのは90年代の日本語文字コード処理の大原則でしたから、
後から [[JIS]] がそれと矛盾する規定を加えても、誰も従いませんでした。