Edit

Page

Page title:

Page body:

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

-*-*-

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

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

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

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

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

-*-*-

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

[80] 
異なる[[基底文字]]の[[グリフ部分集合]]として同じものが
[[IVS]]
として登録されていることがあります。同じ [[IVC]] でもあります。
[SEE[ [[Adobe-Japan1]] ]]

[99] [[CJK互換漢字SVS]]

-*-*-

[85] 
[[Unicode]] の[[漢字]]には、重複とされるものが何組かあります。

[86] 
重複のように見えて、字義が違うなど訳あり (怪しい) ものもあります。

* 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]]]]
を使うことは'''できません'''。

[98] 
[[代替名称]]と同じ[[文字の名前]]が [[UCS]] に存在しない
[CODE(charname)@en[FULLWIDTH OVERLINE]]
はこの附属書に従うと [[UCS]] と対応しないことになります。

** 現実

[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]] はいったい何を考えているのでしょうか。
市場から相手にされていないとはいえ、
それが何十年も放置されているのも大問題ではないでしょうか。

** 規定の実装可能性と需要

[61] 
そもそもの [[ISO/IEC 2022]] の規定が、
[[符号化文字集合]]は[[重複符号化]]を禁止していい (ししなくてもいい)
というだけのことで、
常識的に考えて[[符号化文字集合]]の仕様にはその程度の裁量は認められるはずです。
それを明文規定として委任しているに過ぎないと解するなら、
これ自体は当たり障りのない条項といえます。

[62] 
ただそのための[[文字]]の同定を当該仕様または [[ISO-IR]] 登録における[[文字の名前]]に求めた点には、
些か問題がないでもありません。[[文字の名前]]が仕様横断的に共通の命名規則に統一されたのは、
おおむね [[ISO/IEC 10646]] の制定以後となります。 [SEE[ [[文字の名前]] ]]
それ以前に制定・登録された[[文字集合]]の[[文字]]や、
それ以後であっても従来の慣習を引きずった[[文字集合]]の[[文字]]は、
名前が何も示されていなかったり、
[[ISO/IEC 10646]] の[[文字の名前]]の体系と整合していなかったりします。
登録数と普及・利用数でいえば [[ISO/IEC 10646]] 以後の[[文字集合]]より以前の[[文字集合]]こそ
[[ISO/IEC 2022]] にとっては重要なはずなのに、それらに対して[[文字の名前]]による同定はほぼ機能しないのです。

[63] 
それが機能する珍しい例である [[JIS]] の新しめの規格ですら、
[[代替名称]]を使って同じ[[区点位置]]を別の[[文字の名前]]とみなして良いと意味不明なことを言っています。
[[JIS X 0201:1997]] は[[文字の名前]]と矛盾する[[字形]]を一部認めています。
[[JIS X 0213]] に至っては暫定的な[[文字の名前]]というよくわからない概念を持ち込んだり、
規格改正で[[文字の名前]]を変更したり (でも [[ISO-IR]]
の再登録はしないで同じ[[文字集合]]だと主張したり) しています。

[64] 
複数の[[図形文字集合]]を併用する場合で、
[[重複符号化]]が発生するので禁止したいことって、
そんなにあるものでしょうか。

[65] 
少数の[[図形文字集合]]を組合せた[[符号化文字集合]]を設計するなら、
普通は基本集と補助集のような相互補完的な組合せが
([[図形文字集合]]の設計段階から)
おおむね決まっていて、重複はそうそう発生しないはずです。
発生する場合も、たぶんその重複する[[文字]]の性質は当事者にはよくわかっているはず。
なので[[符号化文字集合]]の規定でそこをちょっと調整してやればいい。
使用禁止にするなり、どちらを優先するか決めるなり、フォールバックの実装方法を決めるなり。

[66] 
多数の[[図形文字集合]]を組合せた[[符号化文字集合]]を設計するなら、
きっと別の目的で別の団体により作られた[[図形文字集合]]を組み合わせることになるでしょうから、
重複は大いにあり得ます。
その重複はある言語用のアルファベットが一式丸々重複しているような場合もあれば、
散発的に重複が出現することもあるでしょう。
ときには[[包摂規準]]の違いにより包含関係にある、
重複かどうか判断し辛い事例もあるかもしれません。
同じような[[字形]]なのに[[文字合成]]や[[書字方向]]の性質が違って定義されていて、
重複と判断すると困ることもあるかもしれません。
そんなとき[[文字の名前]]で機械的に重複を排除するのは楽かもしれませんが、
多数の[[図形文字集合]]を組合せて実現したい利便性・多様性には逆行するようにも思われます。
(しかも[[文字の名前]]が利用できない >>62 可能性も高いです。)

[67] 
更に言えば、多数の[[図形文字集合]]を使うなら、
それらを同時に[[呼び出し]]できないので、
どれか G 番号を選んで切り替えながら利用していく形にならざるを得ません。
そうすると重複が都合よく違う G 番号に[[指示]]される[[図形文字集合]]に属する場合ばかりとは限りません。

[EG[
[68] 
例えば [[ISO/IEC 646の版]]は [[G0]] に[[指示]]し、
それ以外の[[94集合]]や[[96集合]]は [[G1]] に[[指示]]し、
各国第1の[[94[SUP[2]]集合]]は [[G1]] に[[指示]]し、
各国第2の[[94[SUP[2]]集合]]は [[G2]] に[[指示]]する、
という設計にすると、
[[G0]] 集合相互に大量に存在する[[ラテン文字]]同士の重複は排除できません。
[[G1]] 集合にある[[アクセント]]付き[[ラテン文字]]や一部記号も重複は排除できません。

[69] 
強いて言えば [[ISO/IEC 646の版]]と [[96集合]]の [[ISO/IEC 8859]] [[右側]]に共通する[[アクセント]]付き[[ラテン文字]]の重複は排除できるかもしれませんが、
古い欧州各国の [[ISO/IEC 646の版]]より [[ISO/IEC 8859]] を優先する規定を作りたいところです
(がそれは [[ISO/IEC 2022]] に違反してしまいます)。
敢えて古い欧州各国の [[ISO/IEC 646の版]]を[[符号化文字集合]]に取り込むとしたらそれは[[後方互換性]]のためなので、
そちらに寄せるのは好ましくないですし、その一部が使用禁止されると互換性の便宜を図った意味がなくなりますし、
重複を禁止するべきではないという結論にならざるを得ません。

[70] 
[[G0]] の[[半角英数字]]と [[G1]] の[[全角英数字]]が重複するとみなし、
[[G0]] が優先されるべきというのが [[JIS X 0208]] や [[JIS X 0213]]
の考え方です。が、それは同じ[[英数字]]を[[半角]]、[[全角]]と区別して扱ってきた、
今となっては排除不能な慣習を無視していて、実装不可能です。
だとすると1バイト集合と2バイト集合で重複禁止の規定の適用は不可能ということになります。

[71] 
[[G1]] の2バイト集合相互には重複も多いですが、
[[非漢字]]も[[漢字]]もほとんどがその同定に問題を抱えていると言わざるを得ません。
[[G1]] 同士なら重複排除規定は適用されませんが、
仮に適用されるとしてもどれとどれを重複とみなし、どちらを優先するか、
決めて運用するのは非現実的です。
何か基準を設けるとすれば、それは [[CJK統合漢字]]でしょう。
それで済むなら初めから [[ISO/IEC 2022]] ではなく [[ISO/IEC 10646]] にすればいい。

[72] 
[[G1]] と [[G2]] の間でも、以上の検討の組合せで、重複禁止の適用はほとんど不可能でしょう。

]EG]

[73] まとめると,

- [74] 汎用的な [[ISO/IEC 2022]] の実装が汎用的な重複禁止の機構を実装するのは困難
- [75] 個別の [[ISO/IEC 2022]] ベースの符号が個別の事情を勘案して重複禁止の規定を設けることは理屈上可能
- [76] 実際それをやっているのが [[JIS]] だが現実と乖離している
- [77] そこで [[JIS]] 自体が回避策を用意していて重複禁止は機能していない
- [78] それ以外に重複禁止が有効に機能しそうな事例がありそうにない

* シフト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]] と重複する[[面区点位置]]は空き領域にされています。

* JIS の代替名称の表

- [87] [[JIS X 0208:1997]]
-- [88] 附属書1(規定) 表1 [CSECTION[代替名称を用いる1バイト図形文字]]
-- [89] 附属書1(規定) 表2 [CSECTION[代替名称を用いる2バイト図形文字]]
-- [90] 附属書5(規定) 表1 [CSECTION[JIS X 0201 の片仮名用図形文字の代替名称]]
-- [91] 附属書5(規定) 表2 [CSECTION[数字・ラテン文字・特殊文字の代替名称]]
- [92] [[JIS X 0213:2000]]
-- [93] 附属書1(参考) 表1 [CSECTION[代替名称を用いる1バイト図形文字]]
-- [94] 附属書1(参考) 表2 [CSECTION[代替名称を用いる2バイト図形文字]]
-- [95] 附属書5(規定) 表1 [CSECTION[JIS X 0201 の片仮名用図形文字の代替名称]]
-- [96] 附属書5(規定) 表2 [CSECTION[数字・ラテン文字・特殊文字の代替名称]]
-- [97] 附属書11(参考) 最終ページ: [[代替名称]]利用時の 
[[UCS符号位置]]による索引

* Big5 における重複符号化

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

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

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

[81] 
[[GCCS]] には重複や[[統合][包摂]]可能な微細な違いだけの[[文字]]が多く含まれており、
その改訂である [[HKSCS]] では削除 (空き領域化) されました。

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

[26] 歴史的に同源で見た目が同じでも、異なる[[用字系]]に属するとされて別個に収録されていることはよくあります。

- [[ラテン文字]] vs [[ギリシャ文字]] vs [[キリル文字]] vs [[ローマ数字]] 
[SEE[ [[アルファベット]] ]]
- [[平仮名]] vs [[片仮名]]
- 標準[[平仮名]] vs [[変体仮名]]
- [[漢字]] vs [[部首]] vs [[漢数字]] vs [[筆画]] vs [[訓点]]
- [[漢字]] vs [[複音節仮名]]

[82] 
[[Unicode]] ではそれらが完全に別になっていたり、
[[正準等価]]や[[互換等価]]になっていたり、
で扱いがあまり一貫していません。

[84] 
[[ISCII]] は歴史的関係を持つ[[インド系文字]]各種を同じ[[ビット組合せ]]に統合していましたが、
[[Unicode]] は細かく分離しています。

[79] 
[[CCCII]] は[[繁体字]]と[[簡体字]]が対応する符号構造で、
2つの[[繁体字]]が1つの[[簡体字]]に対応する時に[[重複符号化]]が生じます。
[SEE[ [[CCCII]] ]]

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

[27] [[KPS 9566]] は[[将軍様の名前を表すチョソングル][将軍様専用文字]]を通常用の[[チョソングル]]と別個に収録しています。
将軍様の名前は[[太字]]表記するので、通常の[[チョソングル]]とは一応区別できます。
しかし1代目と2代目の姓は区別が付かないのに別に符号化されています。

[83] 
[[蒙古文字]]と[[満州文字]]は[[闇が深い]]です。
[SEE[ [[Unicode蒙古文字]] ]]

* メモ

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)