一意の符号化

重複符号化

[22] ある文字コードで同じ文字を複数の方法で表現できる(ようにする)ことを、 重複符号化といいます。

[28] 歴史的に文字コード規格はなるべく重複符号化が起こらないようにしてきました。 同じ文字列が複数の方法で表現し得るとしたら処理が複雑になり混乱の元だからです。

[29] 実際にはそれを徹底するのは難しく、かなりよく起こっていました。 単純な作業ミスで起こったものもあれば、 文字の同一性とは何かという哲学的、本質的な課題から導かれたものもあります。 文字コードの技術的特性から生じたものもあります。

[30] 現在使われている Unicode には重複符号化が平然と行われている例が多数あります。

Unicode における重複符号化

[31] Unicode符号化済文字の中には、 他の規格との互換性のためと称して、 1つの抽象文字が複数の符号点に対応することがあります。 >>35 D11

[32] 「Å」は、 U+00C5 LATIN CAPITAL LETTER A WITH RING ABOVEU+212B ANGSTROM SIGN に対応します。 >>34 D11

[33] 単一の抽象文字が、 単一の符号点だけでなく、 符号点の列でも表現できることがあります。 >>35 D11


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

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

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

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

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


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

[80] 異なる基底文字グリフ部分集合として同じものが IVS として登録されていることがあります。同じ IVC でもあります。 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 の順) から符号化表現表現される。 この場合、たとえ高位番号の符号要素が既に呼び出されていて、かつ、 その文字が割り当てられている下位番号の符号要素が呼び出されていないときでも、 高位番号の符号要素文字符号化表現は、 使用しない。 JIS X 0202:1998 (ISO/IEC 2022:1994) 7.5

[2] 例えば、 ISO/IEC 646 IRVJIS X 0208:1997 は共に LATIN CAPITAL LETTER A を定義しています。この2つを符号要素として使う場合、 >>1 によれば、 どちらの符号要素で定義されている符号位置によっても LATIN CAPITAL LETTER A表現できます。

しかし、一意符号化が求められる場合は、例えば EUC-JP のように G0IRV, G1JIS X 0208指示するなら、 LATIN CAPITAL LETTER A は常に G 番号の小さい IRV の方で表現しなければなりません。

但し、 ISO-2022-JP のように IRVJIS X 0208G0指示する場合は、 どちらも G 番号は等しいので、一意符号化制限を適用する場合であっても 2種類の符号化表現が認められます。

[3] ところで、 同じ文字文字名前によって判断するとされています。 ISO/IECJIS の最近の符号化文字集合の規格では文字名前ISO/IEC 10646 式の統一された命名法に従っていますが、 古い規格はそうではありません。 ISOREG や原規格の名前を常に適用してしまってよいのでしょうか。 (あるいは JIS X 0202:1998 5.3 文字の名前の規定が適用されるのでしょうか。)

[13] ISO/IEC 2022 のこの規定は第4版 (1994年) で追加されました。 JIS X 0202:1998 C.4

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

[5] JIS X 0208:1997 7. 符号化文字集合には次の規定があります (JIS X 0213:2000 7. 符号化文字集合にもほぼ同様の規定があります)。

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 とは独立に定義されています (JIS X 0202 を実装した環境で用いることもできますが、そうである必要はありません)

[4] JIS X 0208:1997 9.2 指示JIS X 0213:2000 9.2 指示 には次のような規定もあります。

JIS X 0201 又は ISO/IEC 646漢字集合を同時に指示する場合、 これまでの慣用的な利用との互換を目的としてだけ、附属書5表2 に規定する文字JIS X 0201 又は ISO/IEC 646 で規定される文字とは異なった図形文字として用いてもよい。

参考 JIS X 0202 では、同じ図形文字が複数の符号化文字集合中に現れ G0G3指示されているとき、 G 番号の小さいほうが優先され、 G 番号の大きいほうに現れる同じ図形文字は使用禁止とされる。

(挿入部は JIS X 0213:2000 にだけあって、 JIS X 0208:1997 には無い部分。)

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

[6] JIS X 0208:1997 附属書1 (規定) シフト符号化表現JIS X 0213:2000 附属書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 附属書3 (規定) EUC-JISX0213 符号化表現には、 次の規定があります。

備考 (前略) 漢字集合1面の図形文字のうち、 国際基準版図形文字と同じ図形文字は用いてはならない。 ただし、これまでの慣用的な利用との互換を目的としてだけ、 附属書5表2に規定する文字国際基準版で規定される文字とは異なった図形文字として用いてもよい。

この規定は >>1 に基づくものですが、 ここで規定されている符号化文字集合はあくまで JIS X 0202 とは独立に定義されています (JIS X 0202 を実装した環境で用いることもできますが、そうである必要はありません)

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

[37] NS39012siba, , 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 を読んでもわからないな。 例えば

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

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

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

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

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

代替名称という逃げ道

代替名称

[7] JIS X 0202>>1 の通り一意符号化ないものも認めていますが、 JIS X 0208>>4 のように厳しく受け止めているらしく、 >>5>>6 のように同じ名前を持つ文字が 1つの符号化文字集合に複数存在することを避けています。

しかし実際には半角全角と称した重複符号化が行われています。 そのためこれまでの慣用的な利用との互換を目的としてだけなどと訳の分からない条件の下で代替名称を与え、 ISO/IEC 646 IRVLATIN CAPITAL LETTER AJIS X 0208:1997 の FULLWIDTH LATIN CAPITAL LETTER A名前が違うから違う文字だ。違う文字なのだから1つの符号化文字集合で同時に使用してもよい。 という理屈をつけて現状と摺り合わせています。

[14] 余談になりますが、構成する文字が1文字でも異なるのであれば、それは異なる文字集合である と言われます。であれば、 JIS X 0208:1997 本体は本来の文字集合IRV と併用するための文字集合JIS X 0201 と併用するための文字集合で3つの異なる文字集合を規定していることになります。 異なる文字集合ISO/IEC 2022 環境下で使うためには指示のための終端バイトも普通異なるものだと考えたいところですが、 なぜか ISOREGJIS X 0208:1997 9.1 によれば 1種類の終端バイトしか用意されていません。

[8] FULLWIDTH OVERLINE: JIS X 0208:1997 の1区17点の文字OVERLINE ですが、 附属書5 によれば代替名称FULLWIDTH OVERLINE です。誰が見ても至極尤も自然なことです。

ところが、同じ命名法で文字名前をつけている ISO/IEC 10646 には FULLWIDTH OVERLINE は存在せず、似たようなもので FULLWIDTH MACRON があります。

それでは・・・という話は FULLWIDTH MACRON の項をご覧下さい。

ちなみに、 JIS X 0213:2000 附属書5 によれば 1面1区17点の代替名称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 から変えていないものの、区点位置とそこに割り当てられた符号化文字の解釈が変化したと思われる事例が多い。 しかし終端バイトは変更されておらず、図形文字集合として等しいと認識されているらしい。 JIS X 0208

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

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

[9] JIS X 0208IRV を併用する場合: >>5 には IRV と併用する場合附属書5に従うとありますが、 JIS X 0208:1997 附属書5 には REVERSE SOLIDUS代替名称が欠けていますから、 この1文字に関してだけ これまでの慣用的な利用との互換を目的とした利用に問題が出ます。 (なお、附属書5 には TILDE もありませんが、 JIS X 0208:1997 には TILDE は存在しないので問題はありません。)

JIS X 0213:2000 附属書5 にはこの問題はありません。

[15] IRVとJIS X 0201で異なる2組4文字:

問題は2つあります:

  • JIS X 0208IRVを併用する場合に代替名称がない2文字をどうするのか (>>9)
  • 附属書5表2を適用する場合、全文字に対して適用しなければならないのか、 重複する文字についてのみなのか、任意の文字について適用してよいのか (>>16)

[16] 附属書5表2を適用する場合、その表に含まれるすべての文字/符号位置について代替名称を用いなければならないのか、 重複符号化となるものについてのみ用いなければならないのか、 任意のものについてのみ用いてよいのかが明記されていません。 文脈を汲むなら重複符号化となるものについてのみとするべきなのかもしれませんが・・・・・・。

例えば、IRVJIS X 0213と附属書5表2のすべてを用いると、 符号化文字集合からYEN SIGNOVERLINEが存在しなくなります。

[17] ISO/IEC 646とはなにか: >>5 (IRVを用いたJIS独自の符号化文字集合) の規定ではIRVと明記されていますが、 >>4 (ISO/IEC 2022を用いた符号拡張) の規定では単にISO/IEC 646としかありません。 ISO/IEC 646にはISO/IEC 646規格票内で規定されたIRVと、 各国等の規格で規定されるISO/IEC 646の版があり、 >>4 がいずれを指しているのかは明確ではありません。

JIS X 0201 (ISO/IEC 646の版の1つ) と併記されていることからIRVを指しているとも考えられますが、 >>5 では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 附属書 2 (参考) 他の JIS の符号化文字集合との対応には、 JIS X 0201, JIS X 0208, JIS X 0212, JIS X 0213UCS の対応関係が説明されています。

要点をまとめると、次の通りです。

[11] どの道同じ内容であるにはせよ、 JIS X 0213 と併用する場合は JIS X 0213 附属書5を参照するように指示した方が良いのでは、 と思ったりもします。

[12] この附属書に従うのであれば、 JIS X 0212TILDE代替名称として FULLWIDTH TILDE を使うことはできません

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

現実

[20] この規定はほとんど理論上の整合性のためのようなもので、現実には無視されていました。 JIS が「慣用的な利用」と呼ぶ、94図形文字集合なら半角942図形文字集合なら全角として異なる文字として扱う実装がほとんどすべてで、 全角部分を利用しないこととする、あるいは半角と同じ文字とみなす実装は、 実用上あり得ませんでした。

[21] ISO-2022-JPG0 しか使わないので、 ISO/IEC 2022 の規定の適用範囲外でした。 EUC-JPShift_JIS では禁止されるはずの全角文字も、 ISO-2022-JP では使えることになります。 JIS の立場では重複でないから禁止する必要もないし、 「慣用的な利用」を認める必要もないということになるのでしょうが、 同時に、94図形文字集合942図形文字集合も区別できない同じ文字として扱うことになります。 もちろんそのような実装は、実用上あり得ませんでした。 ISO-2022-JPEUC-JPShift_JIS の3者で相互変換でき、 半角全角の区別も保存される、というのは90年代の日本語文字コード処理の大原則でしたから、 後から JIS がそれと矛盾する規定を加えても、誰も従いませんでした。

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

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

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

規定の実装可能性と需要

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

[62] ただそのための文字の同定を当該仕様または ISO-IR 登録における文字の名前に求めた点には、 些か問題がないでもありません。文字の名前が仕様横断的に共通の命名規則に統一されたのは、 おおむね ISO/IEC 10646 の制定以後となります。 文字の名前 それ以前に制定・登録された文字集合文字や、 それ以後であっても従来の慣習を引きずった文字集合文字は、 名前が何も示されていなかったり、 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 番号に指示される図形文字集合に属する場合ばかりとは限りません。

[68] 例えば ISO/IEC 646の版G0指示し、 それ以外の94集合96集合G1指示し、 各国第1の942集合G1指示し、 各国第2の942集合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 0208JIS X 0213 の考え方です。が、それは同じ英数字半角全角と区別して扱ってきた、 今となっては排除不能な慣習を無視していて、実装不可能です。 だとすると1バイト集合と2バイト集合で重複禁止の規定の適用は不可能ということになります。

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

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

[73] まとめると,

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

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

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

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

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

[41] CP932NEC特殊文字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 0213NEC特殊文字をほぼそのまま標準化しました。 JIS X 0208 と重複する面区点位置は空き領域にされています。

JIS の代替名称の表

Big5 における重複符号化

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

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

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

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

なにが重複なのだろうか

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

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

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

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

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

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

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

メモ