221.txt

[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]

[36] 
[[異体列]]は[[重複符号化]]の制約がないので、むしろ積極的に展開されています。

[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]


* 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]]

[38] 
実際の[[符号化文字集合]]でこれに関係する規定は
[[JIS X 0208:1997]]
や
[[JIS X 0213]]
にあります。

[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 には無い部分。)

[52] 
[[JIS X 0202]] ではそう制限しても良い、と選択式に読めるのですけど、
ここの参考は使用禁止だと断言しちゃってますね。なんで?

[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]] を実装した環境で用いることもできますが、そうである必要はありません)]]。

[60] 
ちなみに、[[JIS X 0208]]:1997 [CSECTION[附属書2 (規定) RFC 1468 符号化表現]]
([CODE(charset)[[[ISO-2022-JP]]]] もどき) や
[[JIS X 0213]]:2000 [CSECTION[附属書2 (参考) [[ISO-2022-JP-3]] 符号化表現]] 
には相当する規定がありません
(>>2 と同じ理由)。

[37] [CITE[NS39012siba]], [TIME[2021-01-09T06:15:14.000Z]], [TIME[2000-09-03T22:07:58.800Z]] <https://web.archive.org/web/20000903220115/http://www.itscj.ipsj.or.jp/jp/ns39012.html>

>そして,2375では,646/2022/4873で規定する構造に即した符号化文字集合を登録する手続きを規定している.この中では,646の図形文字の一意な符号化の概念をより明確化し,図形文字のデザイン差は,別の文字とみなさないと規定している.2022では,同じ文字については,どの符号化文字集合中の文字を優先するかを規定し,一意な符号化を保証している.

[53] 
G番号が同じなら一意符号化が要求されないのは、どうしてですかねえ。
G番号が同じということは[[指示]]で入れ替わっていくわけだから、
その切り替えオーバーヘッドを減らしたいから許容したいみたいな?

[54] 
G番号が小さいけど[[指示]]されていない状態のとき、
どう解釈するべきか [[JIS X 0202]] を読んでもわからないな。
例えば

- [[G0]] [[ASCII]] または [[JIS X 0201]] [[片仮名用図形文字集合]]
- [[G1]] [[JIS X 0208]]

... という[[符号化文字集合]]で、
[[ASCII]] が[[指示]]されているときと [[JIS X 0201]]
が[[指示]]されているときとで、
使用しても構わない [[JIS X 0208]] 
の[[文字]]は変化するのだろうか?


[55] 
[[JIS X 0202]] は文字の同一性の判定基準が[[文字の名前]]だとしているから、
当該規格による割り当てられた[[符号化文字]]の解釈の違いは無視される。
例えば

- [[G0]] [[JIS X 0208:1997]]
- [[G1]] [[JIS X 0212-1990]]

... としても、 [[JIS X 0212]] の「乄」や「鷗」は使用禁止にはならないということだ。
([[JIS X 0212]] の[[文字の名前]]は [[JIS X 0221]] の規定に従うとして。)

[56] 
ところで >>55 のように [[JIS X 0208:1997]] を[[指示]]するのは、
自然言語による[[符号]]の記述なら兎も角、
[[指示シーケンス]]を使って行うことはできない疑いがある
([[JIS X 0208:1997]] は [[JIS X 0208-1990]] と同じ[[指示シーケンス]]が使えると書いているが、
それが意味論的に正しいか疑わしい [SEE[ [[JIS X 0208]] ]])。
[[ISO-IR]] に登録されているのはあくまで
[[JIS X 0208-1990]] 
だから、当該[[指示シーケンス]]が使われたら [[JIS X 0208-1990]]
を参照するべきだとの解釈もあり得る。
([[JIS X 0208-1990]] は改正により失効したという解釈もあり得るが、
その説を採ると [[JIS C 6226-1978]] や [[JIS C 6226-1978]]
の[[指示シーケンス]]を解釈する方法がなくなってしまう。)
その場合において、

- [[G0]] [[JIS X 0213:2000]]
- [[G1]] [[JIS X 0208-1990]]

... としたとき文字の同一性はどう判定するべきか。
[[文字の名前]]がないから判定できないのか。
それとも[[日本語通用名称]]で代用するのか。
[[大きな丸]]はどうなるのか。
[[JIS X 0221]] の対応表を援用するのか。
[[指示シーケンス]]を [[JIS X 0208-1990]] と解したときと
[[JIS X 0208:1997]] ([[文字の名前]]がある。) 
と解したときとで結果は変わるか、変わらないか?

** 代替名称という逃げ道

[SEE[ [[代替名称]] ]]

[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]]]] です。



[102] 
[[JIS X 0208:1997]]
3.1.2
参考2
は[[空き領域]]の[[外字]]利用を禁止、使用するなら[[私用終端バイト]]を使えと定めたことについて、
[[ISO-IR]] では1文字でも追加削除があれば異なる[[符号化文字集合]]となると説明しています。

[103] 
同じ規格の 9. では[[指示]]の[[エスケープシーケンス]]が定められていて、
登録された[[エスケープシーケンス]]を使って[[指示]]する場合に[[代替名称]]を使っても良いとされています。

[104]
どうやら[[文字の名前]]の違いがあっても[[符号化文字集合]]としては変化しないと解釈しているようです。
([[複数バイト集合]]の [[ISO-IR]] 登録は[[符号表]]だけで[[文字の名前]]がないから?)

;; [107] [[JIS X 0208:1997]] は[[例示字形]]こそ [[JIS X 0208-1990]]
から変えていないものの、[[区点位置]]とそこに割り当てられた[[符号化文字]]の解釈が変化したと思われる事例が多い。
しかし[[終端バイト]]は変更されておらず、[[図形文字集合]]として等しいと認識されているらしい。
[SEE[ [[JIS X 0208]] ]]

[105] 
[[JIS X 0208:1997]]
は
7. の[[符号]]の規定と 9. の[[エスケープシーケンス]]の規定で、
[[ISO/IEC 646 IRV]] や [[JIS X 0201]] [[ラテン文字用図形文字集合]]との併用時に
[[JIS X 0208]] 側を[[代替名称]]とすることを認めています。
[[JIS X 0213:2000]]
も同様。

[106] 
[[JIS X 0208:1997]] の[[シフト符号化表現]]と
[[JIS X 0213:2000]] の [[Shift_JISX0213]] は[[漢字集合]]のいくつかの文字 
([[JIS X 0201]] [[ラテン文字用図形文字]]相当)
と
[[JIS X 0201]] [[片仮名用図形文字]]に[[代替名称]]を使えると定めていました。



[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]] がそれと矛盾する規定を加えても、誰も従いませんでした。

[57] 
どの規格も[[代替名称]]を使わなければならないと定めるのではなく、
[[代替名称]]を使っても良いし使わないことにしても良いとしています。
つまり少なくても2種類の実装方法が存在するということです。

[58] 
[[重複符号化]]の禁止という理論的な潔癖性を目的に[[相互運用性]]を犠牲にするのは、
いかがなものでしょうか。
そんな非現実的な規格が相手にされないのは当然ですし、
無視されてよかったとも思えます。

[59] 
[[相互運用性]]の実現が目的であるはずの標準規格が、
逆に[[相互運用性]]が失われる方向に誘導するなど言語道断です。
こんなふざけた規格を制定した [[JISC]] はいったい何を考えているのでしょうか。
市場から相手にされていないとはいえ、
それが何十年も放置されているのも大問題ではないでしょうか。


* シフトJIS における重複符号化

[39] 
[[JIS X 0208]] や [[JIS X 0213]] は[[シフトJIS]]においても
[[ISO/IEC 2022]] と同じような[[重複符号化]]の禁止と、
[[代替名称]]の許容を規定しています。
[SEE[ [[シフトJIS]] ]]

;; [40] 市場に無視されている点も同じです。

[43] [[JIS X 0208:1997]] の[[シフト符号化表現]]は、
過去の規格との互換性の絡みで、一部[[重複符号化]]を認めています。
[SEE[ [[シフト符号化表現]] ]]

[41] 
[[CP932]] は [[NEC特殊文字]]、[[NEC選定IBM拡張文字]]、[[IBM拡張文字]]を含んでいますが、
いくつか[[重複符号化]]しています。 普通 [[JIS X 0208]] が最優先、
次に[[NEC特殊文字]]が優先され、
その次に [[IBM拡張文字]]が優先され、それらですべてカバーされる
[[NEC選定IBM拡張文字]]は使わないことになっています。

[46] 
といっても [[IBM拡張文字]]には [[JIS X 0208:1997]] 
によれば[[包摂規準]]により表内字と区別されないはずのものが含まれています。
普通の [[CP932]] の実装ではそれを[[重複符号化]]とはみなしていません。

[42] [[CP932]] から派生した [[ISO-2022-JP]] のバリエーションでは、
符号領域の関係から、[[NEC選定IBM拡張文字]]が [[IBM拡張文字]]より優先されています。

[47] 
[[JIS X 0213]] は [[NEC特殊文字]]をほぼそのまま標準化しました。
[[JIS X 0208]] と重複する[[面区点位置]]は空き領域にされています。

* Big5 における重複符号化

[23] [[Big5]] では2つの[[漢字]]が誤って2組ずつ収録されています。

[25] [[Big5]] との互換性のため [[Unicode]]
の[[CJK互換漢字]]にも重複収録されています。

[48] [[Big5]] とほぼ同じ[[文字集合]]である [[CNS 11643]] (第1字面・第2字面)
には重複分なく、1つずつしか含まれていません。

* なにが重複なのだろうか

[26] 歴史的に同源で見た目が同じでも、異なる[[用字系]]に属するとされて別個に収録されていることはよくあります。
[FIG(list)[
- [[ラテン文字]] vs [[ギリシャ文字]] vs [[キリル文字]] vs [[ローマ数字]]
- [[平仮名]] vs [[片仮名]]
- [[漢字]] vs [[部首]]
]FIG]

[24] [[KS X 1001]] では[[漢字]]が[[韓国語]]の読みごとに区別されて収録されています。
[[KS X 1001]] との互換性のため
[[Unicode]]
の[[CJK互換漢字]]にも重複収録されています。


[27] [[KPS 9566]] は[[将軍様の名前を表すチョソングル][将軍様専用文字]]を通常用の[[チョソングル]]と別個に収録しています。

[44] 
[[Unicode]] の[[正準等価]]は、
[[Unicode]] の基準によれば同じものを表していることになっています。
すなわち[[重複符号化]]です。

;; [45] それらには必ずしも同じとは言い切れないものも含まれています。
例えば[[CJK互換漢字]]の多くはそれに対応する[[CJK統合漢字]]と、
何かが違うにも関わらず、 [[Unicode]] の基準で区別されないことになっており、
しかしそれでは何かが困るので、存在しています。

[49] 
[[Unicode]] の[[互換等価]]は、
まったく交換可能ではないものの、
書式情報など本質的に[[文字]]の一部とはいえない情報が混じっていて、
それを除けば等しいことを表しています。
[[半角片仮名]]や[[全角英数字]]も含まれます。

[50] 
[[互換等価]]な[[文字]]や、[[互換等価]]性すらないが[[重複符号化]]のように思える[[文字]]は、
その必要性をうまく説明できればどんどん追加されているように見えます。

[51] 
数学用と称して書式付き[[ラテン文字]]が数種類分まとめて追加されているにも関わらず、
[[将軍様専用文字]]は提案され続けても却下されているように、
[[政治的]]判断が大きいみたいです。


* メモ