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

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

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

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

Unicode における重複符号化

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

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

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

[34] U+01F5 LATIN CAPITAL LETTER G WITH ACUTE は、 <U+0047 LATIN CAPITAL LETTER G, U+0301 COMBINING ACUTE ACCENT> でも表現できます。 >>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 IRV と JIS X 0208:1997 は共に LATIN CAPITAL LETTER A を定義しています。この2つを符号要素として使う場合、 >>1 によれば、 どちらの符号要素で定義されている符号位置によっても LATIN CAPITAL LETTER A を表現できます。

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

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

[3] ところで、 同じ文字は文字の名前によって判断するとされています。 ISO/IEC や JIS の最近の符号化文字集合の規格では文字の名前が 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:1997 や JIS 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 では、同じ図形文字が複数の符号化文字集合中に現れ G0〜G3 に指示されているとき、 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:1997 は JIS X 0208-1990 と同じ指示シーケンスが使えると書いているが、 それが意味論的に正しいか疑わしい 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 の指示シーケンスを解釈する方法がなくなってしまう。) その場合において、

... としたとき文字の同一性はどう判定するべきか。 文字の名前がないから判定できないのか。 それとも日本語通用名称で代用するのか。 大きな丸はどうなるのか。 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 IRV の LATIN CAPITAL LETTER A と JIS X 0208:1997 の FULLWIDTH LATIN CAPITAL LETTER A は名前が違うから違う文字だ。違う文字なのだから1つの符号化文字集合で同時に使用してもよい。 という理屈をつけて現状と摺り合わせています。

[14] 余談になりますが、構成する文字が1文字でも異なるのであれば、それは異なる文字集合である と言われます。であれば、 JIS X 0208:1997 本体は本来の文字集合、 IRV と併用するための文字集合、 JIS X 0201 と併用するための文字集合で3つの異なる文字集合を規定していることになります。 異なる文字集合を ISO/IEC 2022 環境下で使うためには指示のための終端バイトも普通異なるものだと考えたいところですが、 なぜか ISOREG や JIS 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 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 には REVERSE SOLIDUS の代替名称が欠けていますから、 この1文字に関してだけ これまでの慣用的な利用との互換を目的とした利用に問題が出ます。 (なお、附属書5 には TILDE もありませんが、 JIS X 0208:1997 には TILDE は存在しないので問題はありません。)

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

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

問題は2つあります:

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

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

[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 0213 と UCS の対応関係が説明されています。

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

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

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

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

現実

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

[21] ISO-2022-JP は G0 しか使わないので、 ISO/IEC 2022 の規定の適用範囲外でした。 EUC-JP や Shift_JIS では禁止されるはずの全角文字も、 ISO-2022-JP では使えることになります。 JIS の立場では重複でないから禁止する必要もないし、 「慣用的な利用」を認める必要もないということになるのでしょうが、 同時に、94図形文字集合も942図形文字集合も区別できない同じ文字として扱うことになります。 もちろんそのような実装は、実用上あり得ませんでした。 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 の制定以後となります。 文字の名前 それ以前に制定・登録された文字集合の文字や、 それ以後であっても従来の慣習を引きずった文字集合の文字は、 名前が何も示されていなかったり、 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 0208 や JIS X 0213 の考え方です。が、それは同じ英数字を半角、全角と区別して扱ってきた、 今となっては排除不能な慣習を無視していて、実装不可能です。 だとすると1バイト集合と2バイト集合で重複禁止の規定の適用は不可能ということになります。

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

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

[73] まとめると,

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

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

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

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

[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 の代替名称の表

Big5 における重複符号化

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

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

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

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

なにが重複なのだろうか

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

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

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

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

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

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

[108] Unicode は合成済文字と結合文字列の2通り(以上)の方法で表現できる文字を多数収録しています。

[109] Unicode は互換分解によって同じ文字になるような文字を多数収録しています。

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

[101] 数式用英数字等フォント情報付きの文字と通常の文字は、 見た目で区別できることもあれば、区別できないこともあります。

[100] フォント依存符号化は、細かい見た目の調整を目的に、同じ文字の微小な差異を異なるビット組合せに割り当てていることが多いです。 これはそのような符号化モデルなのであり、重複符号化というのは適切ではないかもしれません。

関連

往復変換

メモ