UTR #37

Edit New

異体選択子

[380] 基底文字に異 (い) 体 (たい) 選 (せん) 択 (たく) 子 (し) (variation selector) を組合せた異 (い) 体 (たい) 列 (れつ) (variation sequence) は、 基底文字が表す字形を限定したものです。

[381] IVS は漢字を対象としたもの、 EVS は絵文字を対象としたもの、 SVS はその他のものです。

仕様書

意味

[31] Unicode文字は、 いろいろなグリフによって表現 (represent) され得ます。 ときにテキスト処理において文字を表現するのに使うグリフの集合を制限したり、 変更したりする必要が生じることがあります。 >>30

[32] 通常それはリッチテキスト文書でフォントやスタイルを選ぶことで示します。 しかし特殊な状況 (※ >>382) では、 そうした通常の見た目 (appearance) の範囲との違い (variation) を、 平文で書式付きテキストを交換するのが不可能か不便であるとしても、 同じ文書に並べて表現する必要があったりもします。 >>30

[33] 例えばモンゴル文字を使う言語では、 特定のテキスト的な目的 (textual purpose) のため「汎用 (generic) 」のグリフ群の範囲では不適切と考えられるときに、 特定の異体 (variant) のグリフ群の範囲が必要となる場合があります。 >>30

[34] そこで異体選択子は特定の文字の表現に使うグリフの集合に対して制限を指定する仕組みを提供するのであります。 >>30

[35] 加えて、 異体選択子は、 CJK漢字やモンゴル文字におけるような、 本質的 (essentially) に同じ (same) 意味 (semantics) を持ちながら実質的 (substantially) に違ったグリフの範囲を持った、 異体 (variant) を指定する仕組みを提供するのであります。 >>30

[36] つまるところ、 異体選択子は、 Unicode が過剰に統合 (unify) して 1つの文字として扱っているものを、 より細かく区別して扱うための救済措置的に使えるものとなっています。

[382] なお Unicode のいう「特殊な状況」とは、 Unicode の世界観で「特殊」とされるものです。 それは世界各地の一般の人々の文字生活上「特殊」とは限りません。

[383] 例えば少なくない日本人が、 自分の名前の通常の表記のために IVS を必要としています。

[37] Unicode文字が必ずしも一般に認識される 「文字」 と一致しない Unicode文字 のと同じように、 異体選択子が扱うものは一般にいう「異体字」 と必ずしも同じではありません。

[472] たまに文字コードや漢字をちょっと齧ったくらいの知識の人が、 「新しい符号位置を追加しないで異体字セレクタで異体字を表現するべきだ」 と主張することがあります。 しかしほとんどの場合この主張は誤りで、その人が思っている「異体字」 は Unicode の異体字セレクタが表現可能な「異体字」ではありません。 意図的ではないにせよ 「今の Unicode を破壊して自分の思う新しいアーキテクチャーを採用するべきだ」 という主張になってしまっています。

なお>>90も参照。

[473] 例えば広と廣は Unicode ではまったく異なる符号位置が与えられた互いに独立した文字です。 これらの一方を他方の異体字選択子で表すことはできません。

[125] ある文字のグリフ的 (てき) 部 (ぶ) 分 (ぶん) 集 (しゅう) 合 (ごう) (glyphic subset) とは、 その文字の表示 (display) に適切なグリフ群の部分集合です。 >>19 符号点が文字を表すように、 異体列はグリフ的部分集合を表すものです。 このグリフ的部分集合という語はなぜか The Unicode Standard ではなく UTS #37 で定義され IVS の説明にしか使われていませんが、 その定義された意味は他の異体列にもそのまま通用するはずです。

[204] 「グリフ」 (単数) ではなく「グリフ群」の集合と説明されていますが、 蒙古文字のように文脈でグリフが変化する場合はもちろん、 漢字のような文脈変化がない場合でも、 特定フォントの特定グリフだけを指すような限定的な指定ではなく、 もう少し広い範囲の「同じようなグリフ」を指しています。 ただしその「同じような」の具体的範囲は定められていません。

[205] 異体列のグリフ的部分集合だけでなく、 文字のグリフ群についても具体的範囲を Unicode は定めていません。 むしろ逆に異体列が定義されて代表グリフが提示されることで、 Unicode文字の代表グリフ以外にもこんな字形までその Unicode文字の範囲に含まれていたのかと知ることができます。

[137] ある文字に関する各異体列のグリフ的部分集合は、 互いに素とは限りません。 このことは IVS について明記されています >>19 が、 他の異体列についても同様です。 IVS でもそれ以外でも、 代表グリフが同じように見えるものすら散見されます。

[87] 異体列は、 元の Unicode文字の意味的範囲に含まれる字形のうちの一部分を表す、 という立て付けで規定されています。 元の Unicode文字と同じ意味の別の文字を指すものではありません。 従って元の Unicode文字の範囲に含まれないと思われるような、 著しく異なるものが異体列で表されることはありません。 この設計ゆえに、異体選択子に未対応だとしても、 基底文字だけを見て処理できるということになっています。

[88] そのため、 異体の区別のためには、 元のUnicode文字と異体列との区別では意味がなく、 異体列と異体列との区別にしなければいけません。

[89] 「令」 c について 「明朝体の令」と「楷書体の令」が異体選択子 v1, v2 で区別されるとするとき、 c と <c, v1> や c と <c, v2> の区別では意味がなく、 <c, v1> と <c, v2> で区別しなければなりません。

[90] かつては、異体字のために膨大な符号空間を占用されるのはけしからんから枝番形式にしろ、 という主張をする人達もいたようです。 Unicode の異体選択子は、 微小な違いを枝番形式で「節約」することにはなりますが、 微小でない違いは別の Unicode文字を追加しないといけないのですから、 「節約」にはなりません。

[91] 異体字を枝番方式で表せば、枝番部分を無視すれば簡単に曖昧検索できて便利だ、 といわれていました。異体選択子にもそれは当てはまりますが、 既に異なるUnicode文字として区別されている (または今後追加される)、 違いの大きな異体字の同一視もしないといけないので、 検索処理の効率化にはあまり貢献しません。

[390] 異体列として登録されたグリフ的部分集合と同じものを含む別のUnicode文字が後から追加されるというおかしなこともたまに起こっています。

[391] 例えば 2022-09-13 版の IVD >>377 は Unicode 15 によって新しく追加された CJK統合漢字 U+31350 用の IVS <U+31350, U+E0100> を追加しました。

[392] これは Adobe-Japan1 の CID+19130 を表すものでしたが、 CID+19130 には以前から <U+793A, U+E0100> が登録されていました。

[393] <U+31350, U+E0100> と <U+793A, U+E0100> は同じもの (Duplicate Sequence) として IVD_Stats.txt に示されています。

[92] Unicode文字 ⊃ 異体列という構造は Unicode のアーキテクチャ的にはそれでいいのでしょうが、 実際の運用を思うと厄介なことも少なくありません。

例えばある文字 c の符号点がほとんどの場合その一般的な字形 v1 で表示されていて、 たまに使われる異体 v2 と区別したいとき、 確実に区別するなら <c, v1>, <c, v2> と書き分けなければなりません。

ですが、現実的にほとんどの場合 c が <c, v1> の意味で使われているのです。普通の人が普通の入力方法で作った文書には c と書かれているのに、それが通用しなくなるのは困りものです。

異体列

[39] 異体列 (いたいれつ) (variation sequence) は、 1つの基底文字または spacing mark (General_Category=Mc) に、 1つの異体選択子文字を続けたものです。 これを基底文字または spacing mark の異体 (いたい) (variant) といいます。 >>30

[38] 異体列
  1. |
    1. 基底文字
    2. Mc
  2. 異体選択子

[107] 異体選択子は、適用対象の直後に置きます。 >>105 結合文字や ZWJ や ZWNJ を間に挟むことはできません。

[110] 自由異体選択子の古い実装は、 ZWJ を併用する時、 基底文字、 ZWJ, 自由異体選択子の順としていました。 古い The Unicode Standard でないドキュメントがこの順としていたためだといいます。 >>105

[111] The Unicode Standard はこのことにわざわざ言及しているのですが、 古めの実装がそうしている、 と書いているだけで、新しい実装がどうするべきか明確にしていません。 SVS でないものは無視するべきとも書いているので、 新しい実装はこの方法を採るべきではないと暗に示しているのでしょうか。 しかし古い実装がこの方法を使っていて、 この方法を使った文書が現に存在しているのだとすると、 後方互換性のためこの方法も意図通りに解釈できるべきでしょう。

[47] 異体列には、 SVS, IVS, EVS の3種類があります。 >>30

被演算子

[196] 適用対象となる文字が、 異体列の1文字目となります。 1文字目は基底文字か、 spacing mark です。

[40] 基底文字が使われることが多く、 spacing mark があまりありません >>30。 そこで The Unicode Standard は、 簡潔のため基底文字のみ記述するが spacing mark も同様である >>30、 というやや曖昧な規定の方法を採っています。

[51] 異体列の最初の文字が、 nonspacing combining mark や正準分解可能文字になることは、ありません。 これは、 正規化文における異体列の解釈の問題を防ぐための制限です。 >>30

[203] IVS には更に互換分解可能文字でないこととの制約が付きます (>>50)。

[197] 異体選択子は必ず適用対象の直後に来るとされています。 そのため基底文字に結合文字が続く列に異体選択子を適用することはできず、 合成済文字に異体選択子を適用することもできません。

[198] 例えば「ざ」の異体を区別したくても、「ざ」 + 異体選択子とすることはできません。 「ざ」は「さ」 + 結合文字の濁点と正準等価なので、 「さ」 + 異体選択子 + 結合文字の濁点、 と表現することになります。

[199] 変体仮名は現行仮名 + 異体選択子とすることが検討されたようですが、 濁音、半濁音が複雑になることから別の文字とされたようです。 (字源も字形も違う仮名まで現行仮名と同じ文字の異体とみなすのは濫用がすぎると思われ、 結果それで良かったのでしょうが。)

異体選択子

[93] 異体選択子の符号点は3種類あります。

[101] 兼用でもいいはずなのに、なぜか VS の種類ごとに使い分けられています。 既に種類ごとに違う方法で実装されてしまっていて、 今更兼用にもできないみたいです >>363。

[102] Unicode 4.0 追加分は第14面にあって、 UTF-8 でも UTF-16 でも4バイトで表されます (それ以外の文字は、 UTF-8 で3バイト、 UTF-16 で2バイトです)。 Unicode 4.0 時点では BMP に押し込められるだけの空き領域があったはずですが... SIP の漢字の IVS だと UTF-8 でも UTF-16 でも1つ8バイトにもなってしまいます。

[103] Unicode で欧米以外の文字を使うという時点で、 バイト数的な効率が悪いことはわかりきっているので、 いまさら気にするなということかもしれませんが...
[104] それにしたって、いちばん需要が大きそうな漢字の IVS に使う異体選択子がいちばんバイト長が大きくなる冷遇ぶりw

[138] 違う基底文字に対して同じ異体選択子が適用可能だからといって、 それによって表される異体の関係性が同じとは限りません。 このことは IVS については明記されています >>19 が、他の異体列でも同様です。

[210] 例えばある文字に対して U+E0100 が2点しんにょうを表していても、 他の文字に対して1点しんにょうを表しているかもしれませんし、 さらに他の文字に対しては異体列が定義されていないかもしれません。

[139] IVS に使える異体選択子は 240 個あります。 Unicode Consortium は、 240 以上の IVS の登録が必要となった時、 新しい異体選択子を追加する >>19 とされています。

[194] それがどの程度現実性があるのか不明ですが、 実装は既存の異体選択子だけと決め打ちにせず、 将来の追加も想定しておく必要があるでしょう。

SVS

[48] 標準化済異体列 (ひょうじゅんかずみいたいれつ) (standardized variation sequence) (SVS) は、 UCD の StandardizedVariants.txt >>17 で定義されます。 >>30

[24] StandardizedVariants.txt にはコメントとして SVS をいくつかの種類に分けています >>17。 それによると:

... があります。 (今後他の種類が増えることもあるでしょう。)

[80] Manichaean と Mongolian は、 適用される shaping environment が、 isolate, initial, medial, final のうち1つ以上のみに限定されるとあります。 >>17

[81] このうち Mongolian だけは、 専用の自由異体選択子文字を使います。

[378] 書字方向との関係は縦書き字形参照。

蒙古文字自由異体選択子

[67] 蒙古文字の異体は、 SVS に分類されていますが、 特別な扱いを受けています。 蒙古文字用には特別な異体選択子が3つ用意されています (>>8) >>105。 この異体選択子は蒙古文字だけに使われています。 蒙古文字には他の異体選択子は使われていません。 (この原則が将来にわたって維持されるのかは不明。)

[106] この蒙古文字の自由異体選択子 (じゆういたいせんたくし) (free variation selector) は、 機械的に決定できないグリフ形が必要な時 (例えば外来語 (foreign word) を書く時) に使います。 >>105

[109] 利用者は、 レンダリングシステムが自動的に正しいグリフを選択できないときのみ、 自由異体選択子を使うべき (should) です。 >>105

数学記号

[200] ちなみに Unicode には数学用と称して太字、 フォント違いなどラテン文字のバリエーションが大量に、 ASCII文字とは別に用意されています。 それらはなぜか異体列ではなく独立した文字となっています。 ラテン文字

[201] 「数学用」という制限が守られるはずもなく、 フォント指定機能がない SNS で装飾付きの英数字の記述のために広く使われるようになっています。

CJK互換漢字SVS

[56] 各CJK互換漢字用に1つずつ、計1002個の SVS が定義されています。 >>30

[57] これは CJK互換漢字の正規化の問題の対策として定義されました。 CJK互換漢字を相当するCJK統合漢字と区別したい時がありますが、 CJK互換漢字はCJK統合漢字に正準等価な写像を持つ故、 正規化によってその区別が失われてしまいます。 そこでかわりに SVS を使えるのです。 >>30

[58] CJK互換漢字用 SVS は、 CJK互換漢字の符号点と一対一対応するものです。 IVD に登録された実装依存グリフに対応付けられた IVS とは違います。 >>30

[202] SVS と IVS は独立した判断で別の基準で追加されたため、 同じ字形のように見える漢字が SVS と IVS とで2種類以上 (+ 元々の CJK互換漢字でもう1種類) 存在する事例が多々あります。 混乱させたくてわざとやっているのではないかと思いたくなるほどの重複符号化祭です。

[59] CJK互換漢字用の SVS は、 CJK互換漢字に異体選択子を付けたものではなく、 相当するCJK統合漢字に異体選択子を付けたものとなります。 CJK互換漢字は正準写像を持つので、 異体列に使えないのです。

[60] CJK互換漢字の正準写像はCJK統合漢字単体であって、 CJK互換漢字用 SVS ではありません。 SVS に正準写像が変更されればさほど問題は生じなかったのですが、 正規化の仕様変更は認められていないのです。

それゆえ、 正規化をおそれて CJK互換漢字を避けるなら、 CJK統合漢字 + 異体選択子を使うことになりますが、 それが正しく表示されるのは適切なフォントを持っている環境のみ、 正しく処理されるのは対応した環境だけです。

CJK互換漢字をそのまま使っていれば、 正規化以外はまったく支障がなかったのが、 SVS に置き換えるとまったく使い物にならなくなってしまいますw (フォントの問題は過渡期の今だけだと思いたいですが...)

[61] それどころか同じ表現が CJK互換漢字と SVS の2通りになって、しかも両者は正規化で同一視される対象ではありませんから、 検索などで新規に個別対応が必要となってしまいます。 むしろ面倒事は増えています。

[62] 正規化は破壊的操作なので、オリジナルデータや重要なデータには使うべきではありません。 正規化 正規化を使わない日常の用途には CJK互換漢字の SVS は出番がなさそうです。

[428] Wayback Machine, https://web.archive.org/web/20110709094418/http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg30/IRGN1468IVS_Recommendation.pdf

[358] IRG N1676 (IRG 34) - 10211-irgn1676-adj1-ivs-upd.pdf, , https://unicode.org/L2/L2010/10211-irgn1676-adj1-ivs-upd.pdf#page=13

[359] >>358 この時点の構想では当時登録済みの Adobe-Japan1 IVS と重複するものは共用しようとしていたようです。

定義済みSVSの削除

[82] 次の2件は、 Unicode 3.2 で定義されたものの、 誤りとわかり SVS から削除された、 と StandardizedVariants.txt にコメントがあります。 >>17

[354] この削除された列が今後どういう扱いになるのか (再割り当てされるのか) よくわかりません。

未成SVS

[485] >>484 は CJK統合漢字の代表字形の誤りを SVS で区別することを提案していたが、 実現せず字形の変更のみが行われた。

非標準の SVS

EVS

[49] 絵文字異体列 (えもじいたいれつ) (emoji variation sequence) (EVS) は、 UTS #51 emoji-variation-sequences.txt で定義されます >>30。

[66] 古い Unicodeの版では EVS は SVS に含まれていました。 当時 StandardizedVariants.txt に記述されていた EVS は、現在の版では削除されているようです。

[44] 数字, U+0023 (#), U+002A (*) を基底文字とする絵文字異体列は、 それに対する結合文字 U+20E3 COMBINING ENCLOSING KEYCAP の色、サイズ、位置決定に影響することが想定されています。 >>30

[11] Emoji Variation Sequences () http://www.unicode.org/emoji/charts/emoji-variants.html

[351] , https://standards.iso.org/iso-iec/10646/ed-6/en/emoji-variation-sequences.txt

IVS

[50] 表意文字的異体列 (ひょういもじてきいたいれつ) (ideographic variation sequence) (IVS) は、 2つの符号化文字の列であって、 1つ目が Ideographic であって正準的分解可能でも互換的分解可能でもないもの、 2つ目が異体選択子文字 [ U+E0100, U+E01EF ] であるものです。 >>19

[124] 異体列一般よりも、 1文字目が Ideographic であることと、 2文字目の範囲に制約が増えています。

[127] IVS には、異体選択子の通常の規則が適用されます。 IVS は、 関連付けられたグリフ的部分集合にレンダリングを制限したいときのみ、 使うべきです。 >>19

IVD

[123] IVS は、 UTS #37 の定める Ideographic Variation Database (IVD) >>21 に登録されています。 IVD に登録された IVS を登録済 (とうろくずみ) (registered) IVS といい、 それ以外の IVS を未登録済 (みとうろくずみ) (unregistered) IVS といいます。 >>30

[208] SVS や EVS が Unicode Consortium の直轄で規定されるのに対し、 IVS は外部で定義されたものを Unicode Consortium に登録するという形をとっています。

[119] UTS #37 によると、 漢字その他の表意文字にあっては、 利用者の需要すべてを満足する異体列の単一の集成を構築することが不可能である、 すなわち研究者、政府、出版社の要件が異なりすぎて単一の集成に収容することが困難であるゆえに、 複数の独立した集成をもって各要件を満たせるようにしたものであります。 >>19

[121] それが不可能だと認めてしまうのなら、 CJK統合漢字がやらかしたことも間違いだったと認めてしまった方が楽なのではないかと思わんでもないw
[122] なぜ表意文字でだけそれが不可能で、 他の文字では可能なのか説明されてませんが、不思議ですね。

[120] IVD は、異体列を使ったテキストの情報交換を信頼できるものとするべく、 異体列に単一の定義を存在せしめるものであります。 IVD の目的は、 IVS を固有のグリフ的部分集合に関連付けることです。 IVS がテキストに現れたなら、 IVD をチェックすればその意図する所を特定できます。 ゆえに登録済IVS は、テキスト交換に使うのに適したもの (suitable) です。 >>19

[126] 未登録済IVSは、テキスト交換で使うべきではありません。 >>19

IVD の版

[145] IVD は、 Unicode Consortium の Webサイトで公表されています >>21。

[147] UCD とは別のデータベースになっていて、 The Unicode Standard とは同期せずに、 必要があるときに更新されているようです。 過去に公開された版はそのままで、 新しい版を公開されていく形になっています。 各版で完結しているので、 歴史的経緯を気にしないのであれば常に最新版だけを見ていれば済みます。

[236] IVD の版は日付で命名されています。 >>21

[148] 常に最新版を表す URL が提供されていないのが、少し使いづらい。

[239] 一度出版された版は変更されないこととされています。 >>21 しかし実際のものを見るとなぜか日付よりずっと新しいタイムスタンプのものが紛れ込んでいます。

IVD のファイル

[149] IVD のファイル IVD_Collections.txt, IVD_Sequences.txt は、 IVC と IVS の情報を含んだテキストファイルです。 その構造は UTS #37 で説明されています >>19 が、 UCD 同様の ; 区切りの行指向データファイルです。 UCD

[150] IVD_Collections.txt には、 Ideographic Variation Collection の情報が記述されています。 IVC を表す識別子、 IVC 内の識別子の正規表現、 IVC の説明の Webサイトの URL が書かれています。 >>19

[152] IVD_Sequences.txt には、 IVS の情報が記述されています。 IVS の各文字の符号点、 IVC を表す識別子、 IVC 内の識別子の組が並べられています。 >>19

[231] 他に代表グリフの一覧表の PDF ファイルがあります。 古い版では IVC 横断の一覧表だったようですが、 新しい版では IVC ごとの一覧表になっているようです (ファイルサイズが大きすぎるからでしょうか)。 改版のたびに変更のない IVC の PDF まで改訂されているようです (少なくても日付が書き換わっています)。 (意図しない代表グリフ変更が生じていないか、不安になりますね。)

IVC

[140] IVD では、 IVS (とそれに関連付けられたグリフ的部分集合) は、 集成 (collection) (Ideographic Variation Sequence Collection, Ideographic Variation Collection, IVC) のエントリー (entry) という形にグループ化されます。 >>19

[212] IVC は0個以上の IVS と付加情報という形を採ります。 IVD は IVC の和集合という形になります。 IVS は複数の IVC に属することがあります。

[211] IVC は特定の利用者コミュニティーの要件を満たすグリフ的部分集合を集めたものとなることが期待されます。 しかし IVC の登録は、 特定目的への適当性 (suitability) を暗示するものではありません。 IVS の有用性や IVC 全体としての有用性は、 その用途に依存します。 登録者は IVC の意図を説明するべき (encouraged) で、 利用者は IVC が自身の目的に有用かどうか評価するべき (encouraged) です。 >>19

[233] IVC は固定の集合ではありません。後から IVS を追加していくことができます。 IVC に既に含んでいる IVS の変更や削除の手続きはなく、認められていないものと思われます。

[143] 実装は、 登録済IVS を任意の組み合わせで自由に対応でき、 複数の IVC であろうとも IVC の部分集合であろうとも構いません。 >>19 つまり IVC は一応意味のある単位として想定されてはいるものの、 実装に対する要件を課すものとはなっていません。

[141] 同じグリフ的部分集合の IVS がいくつもあると実装コストが嵩み、 当該 IVC が実装される可能性は下がります。 そこで同じグリフ的部分集合の IVS を減らすため、 既存の IVC の IVS と似たものを共有することが強く推奨されます (strongly encouraged) (が必須ではありません)。 IVS の共有は、 関係する IVC の登録者間相互の合意があれば実施できます。 登録官は、 IVS の共有の可能性を登録者に警告しなければなりません。 >>19

[142] なお CJK互換漢字 の SVS (>>56) は IVC ではありません。

[213] IVC は、 識別子 (集成識別子 (しゅうせいしきべつし) (collection identifier) ) を持ちます。 特に言及はありませんが、 今の所他の IVC と重複しないものが割り当てられているようです。

[214] IVC 中の IVS は、 識別子 (列識別子 (れつしきべつし) (sequence identifier) ) を持ちます。 列識別子は IVC 内で固有の識別子です。 同じ IVS が別の IVC で共有される場合、 IVC ごとに違う識別子になることがあります。

[153] 集成識別子と列識別子は、 ASCII英字から始まり、 ASCII英数字、 _, -, + のいずれかが続くような文字列です。 >>19

[154] このうち -, + は既存の登録との後方互換性のために認められるものです。 _ に置き換えるか、または除去することで、 固有の識別子を生成できるとされます。 >>19 ということは今後は追加されない想定なのでしょうか。 (既存の IVC への追加の IVS に使われることはあるかもしれません。)

  1. ASCII英字
  2. |
    1. ASCII英字
    2. _
    3. -
    4. +

[151] IVC ごとに列識別子の正規表現が定められます。 当該 IVC のすべての IVS の列識別子は、 この正規表現に一致しなければなりません。 これは Perl 5.8 正規表現です。 IVC 登録者が定めるもので、必要となれば拡張のために変更できます。 >>19

[226] 一旦 IVD に登録された IVC の集成識別子や IVS の列識別子を変更する手続きは用意されていません。 変更は認められないものと思われますが、明記はされていません。

IVC の一覧

[344] IVD には次の IVC が登録されています。

[343] IVC

[345] 日本関係が3件、 大韓民国関係が1件、 中華人民共和国澳門特別行政区関係が1件、 Adobe 関係が2件 (重複あり) です。

非標準のIVC

[395] 未登録のまま長年放置されているものがいくつか見つかっています。 再開の見込みがあるのかどうかも不明。

[396] 未成IVC

[401] BabelStone フォントは IVD 登録済みの IVS とそうでない IVS を実装しています。 未登録のものは将来登録するつもりであるものの、 変更の可能性もあると説明されています。 >>400 ウェブページ上の日付から2年既に経過していますが、今のところ登録はされていません。 すぐに登録しようというスケジュール感ではなさそうです。 未登録 IVS がどの程度利用されているのかは不明です。

[402] Nôm Na Tống フォントは IVD にない IVS を多数実装しています。 旧版は IVD の IVS を避けていましたが、現行版は IVD の IVS と非互換に衝突しています。 Nôm Na Tống

[429] 常用標準漢喃表と漢喃復活委員会フォントは IVD にない IVS を多数実装しています。 IVD の IVS と非互換に衝突しています。 Nôm Na Tống の IVS とも違っています。 漢喃復活委員会フォント

[419] 注音IVS字型規格 (Bopomofo IVS Font Specification) は U+E01E0 からの VS を中文漢字音の区別に使っています。 >>420

[421] PanCJKV IVD Collection は U+E01E5 から U+E01EF を使っています。 注音IVS字型規格とぎりぎり衝突を回避できているのか、いないのか?

[399] Unicode非互換割当も参照。

[422] 中華民国でも IVS 利用を検討しているらしいですが、具体的な話にはなっていない模様です。

[458] >>422 少しずつ進んではいるようです >>457。でも先は長そうな雰囲気。

[426] BabelStone Khitan Small Linear は契丹小字 + VS を使っています。 >>425

[14] Wayback Machine, https://web.archive.org/web/20150104014658/http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg36/IRGN1757_ProposedIVDRegistration.pdf

(UTCソース)

[449] ChiuKongGothic/Other/IVD_Ext.csv at main · ChiuMing-Neko/ChiuKongGothic · GitHub, https://github.com/ChiuMing-Neko/ChiuKongGothic/blob/main/Other/IVD_Ext.csv

[450] >>449 U+E01EA, U+E01EB に独自に割り当てています。

[451] IPA明朝は U+E0100 を (IVD に存在しない IVS も含めて) 多くの符号位置で機械的に定義しているようです。 IPA明朝

[452] 平成時代中期以後の日本市場の多くの汎用フォントは JIS X 0213:2004 対応と称して、 JIS X 0213:2000 から JIS X 0213:2004 への改正で字形が変更された面区点位置の一部に相当する (それぞれの jp90 字形と jp04 字形の一方または両方の) AJ1 IVS を実装しています。 IPAex明朝, AJ1 そのようなフォントの多くは、 AJ1 のうち、 これに関係するごく一部のみを選んで実装しています。 中には AJ1 の例示字形との乖離が著しい (しかし AJ1 に適合性の規定がほとんどないので適合するのかしないのか明らかではない) ものもあります。

登録機関

[172] IVD の登録機関 (registration authority) は、 Unicode Consortium です。 >>19

[173] 登録機関は、 登録要求を処理する登録官 (registrar) (IVD Registrar) を任命します。 >>19 その資格や任期、待遇、人数などは UTS #37 には記載されていません。 Unicode Consortium の裁量で決められているようです。

[174] 登録機関自身が登録者 (registrant) となる IVC であっても特殊な地位は持ちません。 登録機関が提出した IVC も他の提出案と同じ登録手続きを経ます。 >>19

登録料

[163] 登録機関は、 IVC や IVS の登録に於いて、 返金不能な手数料 (processing fee) を課すことができます。 >>19

[165] 登録機関が提出したまたはスポンサーとなった IVC については、手数料は免除されます。 >>19

[164] 登録官は、 登録の出願が不完全なとき、 登録者にこれを通知し、 訂正出願を1回無償で受理します。 それ以後の訂正出願は有償となります。 >>19

[219] 具体的な価格は UTS #37 には書かれていません。

[220] ISO/IEC 10646 の制定作業に関与する national body は登録料が免除されているらしいです。 (SC2 に対し免除を表明する Unicode Consortium の書簡 >>356。)

[221] Moji_Joho の登録時には、 文字情報基盤整備事業 (独立行政法人の IPA が受託した日本政府の事業) が登録料支払いを迂回するため JSC2 (SC2 に日本の代表として参加している情報処理学会の下部組織) の協力を仰いだらしいです。

[222] 登録料を徴収している理由は不明ですが、 Unicode 関係者や各国政府関係を除いた一般の団体や民間人が安易に登録して IVS が氾濫するのを防ぐ狙いがあるのでしょうか。

[223] 既存の IVC が登録料を支払ったものなのか、免除されたものなのか、 外部からはよくわかりません。

登録手続き

[207] IVS は、 UTS #37 の登録手続きにより、 IVD に登録されます >>30。 登録者は、 登録機関に登録要求を提出します >>19。 登録手続きは登録者と登録官によって進行されます。

[175] 登録手続きは、 IVC の登録と IVS の登録の2つがあります。 まず IVC を登録し、 次にその IVC に個々の IVS (に関連付けるグリフ的部分集合) を登録していきます >>19。 ただし IVC と IVS の登録手続きは並行して開始できる >>19 とされていますから、 初期登録は同時に行われているようです。

[224] IVC と IVS の登録手続きは、 次の手順を踏みます。

  1. [225] 登録者は、 説明の Webサイトを用意します。
  2. [177] 登録者は、 登録希望の旨を登録官の指示する方法で公告するとともに、 Unicode Consortium のメーリングリストに送信します。 説明の Webページの URL を添えます。 >>19
  3. [178] そこから90日以上を評価期間とし、 登録者に対するコメントや質問を受け付けます。 登録者は、 それに返答するべき (should) です。 >>19
    1. [234] この評価期間は、 字数に基づき登録官が決定します >>21。
  4. [189] 登録者は、 評価期間終了後、 出願を提出できます。
  5. [227] 登録官は、 完備した出願と出願費を受領したら、 IVD に追加します。 >>19

[166] 登録者は、 IVC の評価期間終了後の登録時に、 次の登録事項を提出します。 >>19

[179] 登録者は、 IVC の評価期間終了後の登録時に、 次の事項を署名付きで声明します。 >>19

  • [180] 説明の URL とその Webサイトの安定性の維持を十分努力すること
  • [181] IVC に登録する IVS が制約、使用料、その他の要件なしに自由に利用できること
  • [182] 評価期間中に受信したすべてのコメントや質問に対応したこと

[184] IVC の所有者は、 登録官への通知により、 代表者と Webサイトの URL をいつでも変更できます。 IVS の列識別子の正規表現を拡張できます。 >>19

[185] IVC の所有権は、 登録官への通知により、 移転できます。 >>19

[187] IVS の登録者は、 出願に当たり IVS の列識別子が IVC 中 (既に登録済みのものも含む。) の各基底文字に対して固有であることと、 IVC の列識別子の正規表現に一致すること、 を確かめる (ensure) 責任を持ちます。 この要件を満たさない出願は、拒絶されます。 >>19

[188] 理想的には、 IVS の登録者ははじめの出願の段階で、 提案する IVS の代表グリフを含めるべき (should) です。 IVS の登録者は、 評価期間終了後の登録時に、 各 IVS に1つ以上の代表グリフを含めなければなりません。 >>19

[191] べきとなっているのは最初の出願時点で準備が整っていないことを容認する想定なのでしょうが、 それでまともな評価が出来るのでしょうか。 評価中の差し替えなども想定した規定なのかもしれませんが、 実際はどう運用されているのでしょうか。

[192] IVS の登録者は、 登録手続きとは別に、 既存の IVC の登録済の IVS に追加の代表グリフを提供できます。 >>19

[183] 登録官は、 IVC の出願を受理したら、 IVC に集成識別子を (できるだけ提案を尊重して) 割当します。 >>19

[193] 登録官は、 IVS の出願を受理したら、 IVS に異体選択子を割当します。 >>19

[230] 登録官は出願を受理したら IVD に追加するとされていますが、 具体的には関係するテキストファイルを編集して情報を追加し、 代表グリフ一覧の PDF を作成しているようです。

[337] これまで実施された評価は Unicode Consortium の Webサイトで公表されています。

[439] 20140808-12.pdf, https://warp.ndl.go.jp/info:ndljp/pid/10965918/mojikiban.ipa.go.jp/contents/2014/08/20140808-12.pdf#page=4

Moji_Joho コレクションの登録後に、公開レビュー期間を、2000 図形あた り 30 日追加するとの方針が Unicode コンソーシアムから示された。その結 果残り約 48,000 のシーケンス登録には、2 年を超える公開レビューの期間が 必要となる可能性がある。

[440] ここでいう「登録後」とは平成26年頃。

[423] IRG では他の漢字と統合可能なときに「ではそれは IVS で」 という処理になってるぽいですが、 それで新規追加が却下された結果 IVS が登録された事例はあまりなさそうに見えます。 符号位置の新規追加プロセスと IVS の新規登録プロセスがまったく繋がっていません。

[453] このプロセスの違いを利用(?)して、CJK統合漢字に追加拒否された文字を IVD に押し込むという荒業が使われているようです。 例えば注音字母参照

[468] 唯一例外として、文字情報基盤事業ではUCSへの追加ができなかったものを後から IVSとして登録することで、ほぼ全MJ文字図形が何らかの形で Unicode 化されました。 Unicode とは別に文字図形の一覧を画定させた上での、 初めから符号位置追加と IVS 追加がセットで企画されていたプロジェクトだからこのフローが実現したのでしょう。

[469] それ以外は、 IRG に参加する各国代表機関にとっては 「CJK統合漢字に不足を追加する」ことが目的 (管掌業務) になっていて、 「既存の Unicode で表現できなものを表現できるようにする」 ことを目的としていないので、CJK統合漢字に新規追加できなくても既存の符号位置に統合可能なら目的を達成できたという判断なのでしょうかね。

[424] 符号位置の追加では NB 以外からの要望でも Unicode Consortium が出典U に取り込んで新規追加してくれますが、 IVC はそのような運用がありません。 そういうのがあれば、 NB がやる気がなくても誰かやる気がある人が必要なものをどんどん申請してくれそうなものですけどねえ。

登録用 Web サイト

[176] IVC の登録者は、 IVC の意図、 原則、 その他利用者に有用なデータを説明する Webページを作成します。 >>19

[186] IVS の登録者は、 IVC を説明する Webページ (から指定されたWebページ) に、 提案する IVS を提示します。 IVD_Sequences.txt 形式のファイルとしますが、 IVS 符号点の欄には基底文字だけを示します。 >>19

[190] 異体選択子は登録機関側で決定されるようで、 登録者が提案する時点では決められません。

[144] 登録手続きは登録者が Webサイトで説明を提供することを要求しています。 そして登録後も可能な限り公衆アクセスを提供し続けることが強く推奨 (strongly encourage) されています。 しかしそれは保証されません。 利用者は、 説明への公衆アクセスの継続性が自身の目的に必要かどうか、 登録者がそれを提供できるかを、 注意深く評価するべき (should) です。 >>19

[247] IVC の Webサイトの状況をまとめると次の通り。

[333] Hanyo-Denshi は登録した汎用電子情報交換環境整備プログラムが終了して Webサイトも消滅してしまったようです。 救済措置なのか Unicode Consortium の Webサイトに紹介ページが作られました。

[405] それなら最初から資料だけ提出させて Unicode Consortium でホストしてあげたほうが、と思わんでもない。

[406] どのような手続きでこの変更が行われたのかは謎です。

[334] これらの Webサイトの情報は、登録に必要な事項はいったん登録されてしまえば IVD から入手可能になるので、 実装には不要で無くなっても困らないことは事実です。

[335] 本来なら代表グリフ以外にも実装や利用に必要なはずの詳細な情報とか、 自由に利用できる参照フォントとかが提供されていてしかるべき感はありますが。 登録手続きで要求されて仕方なく作っただけにしか見えないサイトがいくつかあります。

[336] そういう情報が提供されないなら、開発過程の履歴を残すという歴史的意義しか残らないのですが、 (GitHub を使っているサイトはともかく) どこも登録手続き中の改訂でどんどん上書きして前の版を残していないようなので、 それすら満足がいくとはいえない状況です。

[479] 「源ノ角ゴシック」バージョン 2.000 の技術的な特長について, , https://ccjktype.fonts.adobe.com/2018/11/shsans-v2-technical-tidbits-ja.html

コメント欄

Dr. Ken Lunde says:

January 7, 2019 at 8:09 AM

Supporting the Hanyo-Denshi IVD Collection is a non-starter for a variety of reasons. First and foremost, other than the glyph charts for that collection, there is no longer a stable web page that describes the collection, which is one of the requirements. As the IVD Registrar, I have repeatedly asked Japan to restore its URL so that the one that is reflected in the IVD_Collections.txt file is no longer stale.

[480] >>479 JSC2 に消えたサイトなんとかしろと言ってもどうにもならなかったのでそうなったのか... ほんと JSC2 は仕事しないだけでなく世界中に迷惑掛けまくってばかりだなあ...

[481] しかしそれにしても消えたサイトにも復活したサイトにも IVD 以上の情報はないし、 登録手続きが終わったあとにサイトを残せという要件はないので、 これを実装しない理由に挙げるのは難癖でしかないんだよなあ。 それじゃああかんと思うのだったら手続きの方をなんとかしなよ、 被害者面してるけど手続き作る側の立場の人でしょ...

[415] Moji_Joho の文字情報基盤は日本政府傘下の IPA から民間団体に令和2年に移管されました。 2022-09-13 版で登録 URL が新しいものに変更されています。

[416] しかしなぜか変更履歴にはそのことが書かれていません。 また、新しい URL はただの文字情報基盤のトップページで、 元々の IVC 登録用の情報は見当たらなくなっています。 どのような手続きによって変更されたのかは謎です。

[417] Unicode Consortium 的には登録が終わったらもう中身はどうでもいいのでしょうか?

[407] KRName も令和5年4月に GitHub から Unicode に移転しました。 これは Adobe から Unicode Consortium への登録者の移管と同時に行われたものです。

[414] KRName は移転後 IVC が更新されておらず、現時点で最新の 2022-09-13 は当然古い URL のままです。しかし IVD ウェブサイトのリンク集 (KRName 移転とほぼ同時に新設) は新しい URL に更新されています。

[418] これらもどのような手続きによるものか謎です。

IVS に使う基底文字の選択

[128] 異体選択子は default ignorable なので、 IVS に関連付けられたグリフ的部分集合は、 基底文字を単体で使った時に適切なグリフ群の部分集合である、 言い換えると IVS のグリフ部分集合が基底文字に統合可能なものである必要があり、 登録者はそれを確かめる (ensure) ことが期待されます。 Unified_Ideograph の文字の場合については、 The Unicode Standard の漢字の章と ISO/IEC 10646 附属書 S の漢字統合規則に照らし合わせることが、 その方法の1つです。 >>19

[131] encoded variants の数を削減するための取り組みとして、 Unified_Ideograph な文字に関する統合規則は、 IVD に適用される時、 次の2つの場合も含めるよう拡大されます。 >>19

  • [132] 異なる構造を持つ文字で、 その違いが別の統合漢字として符号化するほどには重大とはみなされない場合であって、 符号化済文字の異体として関連付ける強い証拠を有するもの。
    • 例: ⿱椎十 / ⿰木隼, ⿱汨皿 / ⿰氵昷, ⿱戠火 / ⿹戠火
  • [133] 同じ構造を持つ文字で、 第2 (以後) 段階の構成要素が違って通常は統合可能ではない場合であって、 符号化済文字の異体として関連付ける強い証拠を有するもの。
    • 例: ⿰月㲋 / ⿰月𣬉, ⿺𠃊西 / ⿺辶西
    • [134] 此の場合当該文字は稀にしか使われないものであるべき (should) で、 登録者はグリフ図形の類似性や異体としての許容性の根拠を提示することが期待されます。
[135] グリフ的部分集合の前提を覆す例外が、 「encoded variants の数を削減」 という意味不明な理由で追加されてることが気になりますが... 通常の統合規則に漏れているのに 「別の漢字とするほど重大ではない」 ものがあるという世界観も意味不明です。

[470] 実際の登録字形を見ると、本当にこの字形は基底文字と統合可能なのだろうか、 どの UCV によりそう判断できるのだろうか、と疑問を呈さずにはいられない異体列が数多あります。

[209] ある基底文字の異体列として登録された IVS の代表グリフが、 実は別の基底文字の代表グリフに一致する (かそちらの方がより近い) ことが後から判明する、という事例がままあるようです。

[350] 草書体フォントや篆書体フォントの字形を使った登録を試みたらどうなるのか、 おもしろそうだからどこかがやってみてくれないものかw

[476] >>475 統合分離に伴い従来IVSで使われていた字形と同形の新しい符号位置が追加される事例。 IVSと矛盾した追加であることを認識し、引き続きIVSを使うことが容認された上での分離。

データ

[441] IVS についてのデータはいろいろなところにあります。

代表グリフ

[63] ほとんどの SVS の代表グリフは、 符号表に示されています。 >>30

[69] SVS は、 符号表の文字一覧の元の文字の項に、 swung dash (~) で示されています。 >>68

[70] SVS は、 符号表の元の文字のブロックの後に代表グリフの一覧が付されています。 ただし CJK互換漢字用の SVS は、 CJK統合漢字でなく CJK互換漢字の側に示されています。 >>68

[71] Unicode 8.0 の時代まで、 CJK互換漢字用を除く SVS (後の EVS を含みます。) の字形は UCD の StandardizedVariants.html に収録されていました。 蒙古文字のものも含まれ、 語頭形など複数の字形例が示されたものもありました。 >>22

[85] StandardizedVariants.txt >>84 は Unicode 4.0 で追加されたもので、 Unicode 3.2 時代には HTML しかなかったようです。

[72] Unicode 9.0 でこのファイルの内容は削除され >>23, >>18、 Unicode 10.0 でファイル自体も削除されました。

[64] EVS の代表グリフは、 絵文字表に示されています。 >>30

[65] IVS の代表グリフは、 IVD に示された登録中にあります。 >>30

[430] 異体列が表すグリフ部分集合を代表するのが代表グリフですが、 グリフ部分集合とは基底文字が表し得るグリフ全体の集合の部分集合です。 つまり代表グリフは基底文字をある意味代表する字形の1つともいえます。

[431] 基底文字の代表字形は、大部分のUnicode文字には1つ、 CJK統合漢字やCJK互換漢字には1つ以上が符号表で示されています。 それら代表字形が異体列の代表グリフに選ばれている (ような異体列が規定または登録されている) こともあれば、そうでないこともあります。

[432] CJK統合漢字のJ字形と同じ代表グリフの IVS が登録されていることもありますが、そうでないこともあります。

[434] なお、フォントにおいて異体列に割り当てられたグリフに対して、 基底文字のみの列に対して割り当てられたグリフのことを、 文字情報基盤ではデフォルトグリフ (default glyph) と呼んでいます >>433。

[435] フォントのデフォルトグリフ = 既定グリフは、 同じフォントで異体列に割り当てられたいずれかのグリフと一致することもあれば、 どれとも一致しないこともあります。

[437] OpenType の場合、 異体列のグリフがデフォルトグリフと一致するような異体列のことを default UVS (既定UVS) といい、 そうでない異体列のことを non-default UVS (非既定UVS) といいます。 両者には別のデータ構造が用意されています。 >>436 cmap

[438] この区別は必須ではないので、すべて非既定UVS用データ構造で記述することも可能です。 既定UVSを使った方が少しファイルサイズを節約できますが、 フォントファイル (特に漢字がたくさん入ったフォントファイル) 全体の大きさに比べれば微々たるものなので、 簡単さを取ってすべて非既定UVSで表すフォントも珍しくないようです。 なお、 既定UVSを使うとフォントからグリフを探す手順が1段階増えるので表示処理が少し遅くなりますが、 これもやはり微々たる差です。

レンダリング

[41] 異体列において異体選択子は基底文字または spacing mark の見た目 (appearance) に影響します。 >>30

[42] この見た目の変化は、 後に続く文字、 とりわけ同じ基底文字または spacing mark に適用される結合文字にも視覚的 (visual) な影響を与えることがあります。 >>30

[43] 基底文字の図形 (shape) の変化に合わせて、 結合マークの図形や位置も変化するべきです。 基底文字の色の変化に合わせて、 結合マークの色も変化するべきです。 基底文字の advance width が変化すれば、 次の spacing文字の位置も変化します。 >>30

[384] 異体列に対応したフォントが存在しない時、 基底文字だけの場合と同じグリフを表示し、 異体選択子相当の表示はしない実装が普通です。

[385] この実装方法のメリットは、 受信者が対応した異体列かどうかを個別に送信者が判断せずとも、 そこそこの表示が得られる点です。

[386] この実装方法のデメリットは、 送信者の意図しない表示になっていても受信者が気づかない可能性が高いことです。

[46] 異体列は、 定義されたものを除き、 表示 (display) 上の効果を持ちません。 異体選択子によって視覚的 (visual) な見た目 (appearance) は変化しません。 >>30 適合する処理は、 未定義のものを SVS として解釈してはなりません >>105。

[108] SVS を構成しない自由異体選択子は無視されるべき (should) です。 >>105

[52] 異体選択子は、 結合マークであり結合クラス ccc = 0 で、 default ignorable です。 従って異体列に対応していない場合には、 異体選択子は不可視 (invisible) で無視されるべきです。 >>30 異体選択子は視覚的 (visual) な見た目 (appearance) を持ちません >>105。

[53] 異体選択子が可視的な見た目 (visible appearance) を与えられるモードや環境があっても構いません。 例えば「隠れたものを表示する」モードで特別なグリフで表示しても構いませんし、 基底文字に下波線を引いて現在のフォントでは対応できないことを示したりできます。 >>30

OpenType フォント

[467] 利用者:emk - GlyphWiki, https://glyphwiki.org/wiki/User:emk#i2

Windows 7でIVSを認識させるには、以下の条件をすべて満たす必要があるようです。

cmap

[375] OpenType フォントは cmap の format = 14 を使って異体列とグリフの対応関係を記述しています。 cmap

[367] TTF / OTF の異体列用 cmap format 14 に対応していないソフトウェアが意外とあります。

[368] opentype.js は API がなく存在自体が無視されます。

[369] ttfdump や Typr は存在することだけ知らせて中身は dump してくれません。

[370] Font::TTF は普通に対応しています。

GSUB

[376] Mongolian Universal White

蒙古文字の異体字選択子を cmap でなく GSUB で実現。

処理

[387] 結合列, 書記素クラスターも参照。

[360] 文字の表示上の処理の多くは、 書記素クラスターを単位にします。 異体選択子は結合文字ですから、 異体列は書記素クラスター (の一部分) になります。 多くの処理では異体列はその基底文字単体と同じように振る舞います。

[361] 例えば縦書き字形に関する Vertical_Orientation は、 多くの場合に書記素クラスターの先頭文字の Vertical_Orientation となります。 つまり異体列が横書きと縦書きで字形回転するかどうかは、 異体選択子に関わらずに決まります。

標準化

[45] 異体選択子は、 文字符号化の一般の拡張機構を想定したものではありません。 基底文字や spacing mark と異体選択子の組み合わせは、 Unicode Consortium が定義するリストにあるものを除き、 表示 (display) 上の効果を持ちません。 >>30 定義されていないものは、 将来の標準化のために予約されています >>105。

[54] 特定の異体列の標準化や対応 (support) は、 基底文字単独での表現に使うことが出来るグリフの集合を制限することにはなりません。 利用者がある文字とその特定の異体の視覚的 (visual) な区別を必要としているなら、 その区別のためにはフォントを使わなければなりません。 >>30

[55] 異体列が存在するからといって、 異なる意味 (semantics) で同じまたは重なるグリフの範囲の新しい文字が将来符号化されることを否定するものではありません。 >>30

安定性

[206] 異体列は、 誤りとして廃止された事例が2件知られています (>>82)。 今後も廃止される可能性があるのかは不明です。

[136] 登録済 IVS を使ったテキストの安定性を保証するため、 IVS とグリフ的部分集合の関連付けは恒久的なものとされます。 IVS が他のグリフ的部分集合に再割当されることはありません。 >>19 恒久的ということは、変更も削除もされることはないと解釈できそうです。

[228] IVS には後から追加の代表グリフを追加することが認められています。 その条件は特に規定されていません。 ということはある時点の代表グリフ群から推測されるその異体列の解釈の幅と、 それより後の時点の代表グリフ群から推測されるその異体列の解釈の幅が変わっていることもあり得るわけです。 (削除が認められるとは書かれていないので、幅が狭まることはないとは思われます。)

[229] SVS、 EVS の代表グリフが変更されることもありそうですが不明です。 過去あったのかも不明です。 (符号点の代表グリフはたまに変更されています。)

<ivs> (朝刊太郎)

[25] DTP ソフトウェア 朝刊太郎・改(仮称)は、 ASCII文字を使った <ivs> タグという機能で IVS を文字列表現しています。

[118] 「朝刊太郎・改(仮称)」タグの使い方, , https://www.chokantaro.com/tag/tag.html#Ivs

辻と<ivs>辻、祇園と<ivs>祇園
兵庫の芦屋市と広島の<ivs>芦田川 
辻と<ivs=2>辻、祇園と<ivs=2>祇園
兵庫の芦屋市と広島の<ivs=2>芦田川

異体字の枝番号を省略すると「0」番と判断されます。(実際の枝番号定義から逆算しやすいよう番号はゼロから指定します)

私用

[112] Unicode の異体列は標準化の対象とされ、 私用の仕組みは用意されていません。

[195] 私用文字に異体選択子を併用することも認められていません。

[113] それとは別に、 私用文字に独自に異体選択子的な機能を割り当てている応用もあります。

[114] Apple は U+F870 「transcoding hint: variant tag 16」 - U+F87F 「transcoding hint: variant tag 1」 を定義しています。 >>15

[116] Apple が Unicode 以前に使っていた各国用の文字コードにあって Unicode にない文字で、 他の Unicode文字の異体とみなされるもののために、 Unicode文字の後に置いて使われています。

[117] 例えば MacJapanese の縦書き字形に使われています。

[427] Wenlin は PUA に独自の異体字選択子を規定して使っています。 Wenlin Variation Sequences

[371] BabelStone は標準の IVS の続きの未割当の異体選択子を使っています。 >>357 独自分は追加提案する意思があると書いていますし、 変更の可能性もあるとは書かれています。 (怖くて実用できないですね...)

[474] Proposal to Encode a Set of 128 User-Defined Variation Selectors - 24148-n5266-uvs_proposal.pdf, , https://www.unicode.org/L2/L2024/24148-n5266-uvs_proposal.pdf

異体列で表せないもの

[347] 既存の Unicode文字の細かい差は表現できますが、 似た別字やまったくの新字は表現できません。

[348] Unicode Consortium が標準化または登録したものしか使えません。

[349] CJK統合漢字には国別の代表グリフが併記されていますが、 敢えて登録されたもの以外は表現できません。

セキュリティー

[471] 異体選択子 (特に意味が未割当のもの) は、 不可視の文字として悪用されることがあります。 文字のセキュリティー

関連

[29] 異体選択子とは別に、 本来算用数字を表す符号位置の表示形をアラビア文字の数字に切り替える、 numeric shape selector format characters があります。

[28] 続け字、合字に関係した異体グリフの選択には他の仕組みがあります。 続け字、合字

[16] SAPV

このウィキでの用例

Unicodeにない文字

歴史

[398] CCCII

[161] L2/08-109, https://www.unicode.org/L2/L2008/08109-ivd-update.html

[20] プレスリリース「ISO/IEC 10646の規定に基づく漢字字形データベースへの登録」 | IPSJ/ITSCJ (一般社団法人 情報処理学会 情報規格調査会 著, 版) https://www.itscj.ipsj.or.jp/oshirase/2014/06/pr_140610_sc2.html

[1] ホーム ( 版) http://ivstpc.jp/default.aspx

[6] >>1 404 Not Found () http://ivstpc.jp/ いつの間にか消滅

[2] 人名などの異体字もデータ交換可能に、MSなどが「IVS技術促進協議会」発足 -INTERNET Watch ( 版) http://internet.watch.impress.co.jp/docs/news/20101206_412176.html

[3] 『Unicode IVS Add-in for Microsoft Office』を提供 ( ( 版)) http://www.microsoft.com/japan/presspass/detail.aspx?newsid=4219

[459] Microsoft Word - wg2n4572_gvs-proposal_20140401a.doc - n4572.pdf, , https://www.unicode.org/wg2/docs/n4572.pdf

[460] >>459 (4月1日)。〓の字形を区別する Geta VS (GVS) を提案していた。

[461] SVS として普通に有用そうだし実例が示されているように横書き字形と縦書き字形の区別は本来あるべきなのに、 なぜかスルーされてるのが謎。

[463] >>462 は (4月1日)。こちらは VS とは正反対で、 本来の CJK統合漢字なら統合対象にならない粒度まで統合する新しい概念の提案。 問題設定は真面目だし、実際解決の必要性がありそうな課題を選んでいるのに、 解決案は雑で、おそらく4月1日ならではの文書だと思われるが、 いまいちその点が伝わりにくいというか、どこにユーモアがあるのかよくわからないんだよな...

[464] というかもうはっきりいってしまうと、ギャグとして滑ってるんじゃないの、って。 (ギャグなんだとしたらね。たまたま4月1日の提案になっただけで大真面目だったら申し訳ない。 ← この突っ込んでいいのか悪いのかよくわからない感じが滑ってるんよ)

[465] これがギャグだろうとなんだろうと、ここで紹介された統合対象になってない文字が、 なぜ現在まで CJK統合漢字に新規追加されず、 VS も登録されないまま放置されてるのか、がやっぱり謎。

[466] どっちの4月1日も、解決するべき問題を示すだけ示して、非現実的な解法を提示するだけで放置して逃げてるのがダサいというか困ったところ。

[4] Issue 383580 - chromium - UVS (SV or IVS) is not supported even with a UVS-capable font - An open-source project to help move the web forward. - Google Project Hosting ( 版) https://code.google.com/p/chromium/issues/detail?id=383580

[5] 新異体字セレクター作成計画 ‐ 未来情報産業 ( (未来情報産業株式会社 著, 版)) http://www.mirai-ii.co.jp/data/ivs/

[9] 異体字セレクター ‐ 通信用語の基礎知識 () http://www.wdic.org/w/WDIC/%E7%95%B0%E4%BD%93%E5%AD%97%E3%82%BB%E3%83%AC%E3%82%AF%E3%82%BF%E3%83%BC

[10] 異体字について | 文字情報基盤整備事業 () http://mojikiban.ipa.go.jp/2527.html

[12] AbemaPrime【公式】さんのツイート: "【今夜 #アベプラ】①沖縄県東村高江で米軍大型ヘリが着陸し炎上②プレイバック総選挙!05年「郵政解散」を小泉元総理に罷免された島村元農水大臣に聞く︎③元郵便局員が語る郵政民営化の実情@8bit_HORIJUN @shigekixs▷https://t.co/NdXJ5e0onb https://t.co/F5S046u1CO" () https://twitter.com/Abema_Prime/status/918056947902922752

[13] >>12 ③の直前に U+FF0E

[27] 文字コード技術部会​ | 一般社団法人 文字情報技術促進協議会 (, ) https://moji.or.jp/wg/code/

現在、文字コード技術部会では、このIVSを含む文字列のコレーションを可能にする技術的な方法について調査と検討を進めています。最終的には何らかの実現可能な方法を提案し、課題の解決につなげたいと考えています。

[235] 桐ヘルプ - IVS, 管理工学研究所, https://www.kthree.co.jp/kihelp/index.html?page=data/ivs&type=html

[346] プレスリリース:超漢字検索IVS強化版 | 超漢字検索ウェブサイト, パーソナルメディア株式会社, , http://www.chokanji.com/ckk/press_ckkivs.html

[352] , https://standards.iso.org/iso-iec/10646/ed-6/en/UCSVariants.txt

[353] , https://standards.iso.org/iso-iec/10646/ed-6/en/EmojiSrc.txt

[355] 異体字セレクタを含む漢字が縦書きのウェブページでうまく表示されないときの対策|Colorless Green Webs () https://we.fnshr.info/2016/02/14/variation-selector/

[364] 392588 - Proper font fallback for variant selectors, https://bugzilla.mozilla.org/show_bug.cgi?id=392588

[365] IPSJ-DC16102006.pdf, https://ipsj.ixsq.nii.ac.jp/ej/index.php?action=pages_view_main&active_action=repository_action_common_download&item_id=168214&item_no=1&attribute_id=1&file_no=1&page_id=13&block_id=8

[366] [css-text] [css-fonts] Variation selectors are underspecified · Issue #854 · w3c/csswg-drafts · GitHub, https://github.com/w3c/csswg-drafts/issues/854

[372] IVSとフォントの関係 - ちくちく日記, https://chiku-chiku-nikki.hatenablog.com/entry/20110930/1317339375

IVS技術促進協議会セミナー「UnicodeとIVSの基礎について」

使える文字が増えるということが、本当に便利なのかどうかをよく考えてほしい。 ある人のわがままで増えた文字が誤字であってもそれを削除する権限が行政にない。それがたまりたまってこれだけの数になって、全部そのまま符号化されている。

[373] 現に存在する文字を「わがまま」だという。こういう考え方の人がなぜか IVS を仕切っている。

[374] こういう言い方をするからには相応の根拠があるのだろうな? 「わかがま」の「誤字」が「これだけの数」あると断定するからには、 相当数の文字の来歴を調査していつどんな経緯で生まれたのか判明しているはず、 その調査報告はどこにあるの?

[397] Proposal to add standardized variation sequences for digits and various punctuation (L2/18-013) - 18013-svs-proposal.pdf, , https://www.unicode.org/L2/L2018/18013-svs-proposal.pdf

[448] L2/23-212 (Proposal to add standardized variation sequences for four quotation marks) - 23212r-quotes-svs-proposal.pdf, , https://www.unicode.org/L2/L2023/23212r-quotes-svs-proposal.pdf

[403] IVD Registrar—異体字王さんはTwitterを使っています: 「The IVD (Ideographic Variation Database) landing page now includes a new “Registered IVD collections” section that includes useful details about the registered IVD collections. https://t.co/CfXnj9qlcA」 / Twitter, , https://twitter.com/IVD_Registrar/status/1650308296124022786

[477] A Letter in Support of N5266 - 24199-support-n5266.pdf, , https://www.unicode.org/L2/L2024/24199-support-n5266.pdf

[478] Recommendations to UTC #180 on Script Proposals - 24166-script-wg-rept.pdf, , https://www.unicode.org/L2/L2024/24166-script-wg-rept.pdf#page=24

Updated: