IVS: How Unicode Represents 47 Versions of the Same KanjiIVS 完全解説: 同じ漢字の47通りの字形を表示する

Han Unification merged characters that share the same origin into single code points. But what happens when you need to specify an exact glyph variant? Japanese names, historical documents, and calligraphic traditions demand precise glyph control beyond what a font's default rendering provides.

For example, the character 辻 (U+8FBB, “tsuji”, a common Japanese surname) has two accepted forms: one with one dot on the left radical (一点しんにょう) and one with two dots (二点しんにょう). Both are “correct” — but which one appears depends on the font, and there is no way to choose using the base code point alone.

Unicode's solution is Variation Sequences: a base character followed by a special variation selector character that specifies the exact glyph form.

Ideographic Variation Sequences (IVS) use variation selectors from the range U+E0100 through U+E01EF (240 selectors, called VS17 through VS256). An IVS is a two-character sequence:

Base character + Variation Selector = IVS

Example:
葛 (U+845B) + VS17 (U+E0100) = 葛󠄀 (specific variant)
葛 (U+845B) alone            = 葛  (default glyph)

The variation selector is invisible — it produces no glyph of its own. But a font that supports IVS will render a different glyph when it encounters the sequence.

In JavaScript, each variation selector in this range requires a surrogate pair (2 UTF-16 code units), so an IVS takes 3–4 code units total despite being one grapheme cluster.

Standardized Variation Sequences (SVS) use a different, smaller set of variation selectors: U+FE00 through U+FE0F (VS1 through VS16). These are used for:

The most widely known SVS usage is the text/emoji toggle. Many characters have both a text presentation (monochrome, simple) and an emoji presentation (colorful). VS15 forces text style, VS16 forces emoji style:

// Same base character, different presentations:
"\u2764"           // ❤ (default, usually emoji)
"\u2764\uFE0E"    // ❤︎ (text presentation, VS15)
"\u2764\uFE0F"    // ❤️ (emoji presentation, VS16)

// The selectors are invisible but change rendering:
"❤️".length  // 2 (base + VS16, both in BMP)

Unlike IVS selectors (which are in the SMP and need surrogates), SVS selectors are in the BMP (U+FE00–FE0F) and each take just one UTF-16 code unit.

Which variation selectors map to which glyphs is not arbitrary — it is recorded in the Ideographic Variation Database (IVD), maintained by the Unicode Consortium. The IVD contains named collections:

Adobe-Japan1 is the most widely supported collection. It maps IVS sequences to specific CID (Character ID) numbers in the Adobe-Japan1-7 character collection, which professional Japanese fonts implement. A font that supports Adobe-Japan1 IVS can render thousands of glyph variants.

Moji_Joho (文字情報) is maintained by Japan's Information-technology Promotion Agency (IPA) and focuses on character variants used in official government documents and the family register system (戸籍).

IVS only works if the font supports it. A font must contain:

• The glyph variants for each supported IVS sequence
• A cmap table (specifically format 14, Unicode Variation Sequences) that maps base+selector pairs to glyphs

Major fonts with IVS support include:

If a font does not support a particular IVS, it simply renders the base character's default glyph and ignores the variation selector. This is a graceful fallback — the text remains legible, just not in the specific variant requested.

The character 邉 (U+9089) holds the record for the most registered IVS sequences. It has approximately 47 variant forms in the Moji_Joho collection, reflecting the many ways this character has been written in Japanese family registers over the centuries.

The surname 渡邉 (Watanabe) is notorious in Japan for having dozens of variant spellings. Municipal offices maintaining family registers need to faithfully reproduce the exact variant used in each family's records, which is why the Moji_Joho collection registers so many forms.

This is a case where IVS is essential: without it, government systems could not accurately record the legally distinct name variants that Japanese law requires preserving.

// The 邉 character with different IVS:
"邉"                    // Default glyph
"邉\u{E0100}"          // Variant 1 (VS17)
"邉\u{E0101}"          // Variant 2 (VS18)
// ... up to ~47 registered variants

// Each is one grapheme cluster:
const seg = new Intl.Segmenter();
[...seg.segment("邉\u{E0100}")].length  // 1

漢字統合（Han Unification）は同じ起源を共有する文字を単一のコードポイントに統合しました。しかし、正確なグリフ変種を指定する必要がある場合はどうすればよいでしょうか? 日本人の名前、歴史文書、書道の伝統は、フォントのデフォルトレンダリングを超えた精密なグリフ制御を要求します。

例えば、辻（U+8FBB、一般的な日本の姓）には2つの認められた字形があります: 左の部首に点が1つのもの（一点しんにょう）と2つのもの（二点しんにょう）。どちらも「正しい」のですが、どちらが表示されるかはフォントに依存し、基本コードポイントだけでは選択できません。

Unicode の解決策が異体字シーケンス（Variation Sequences）です: 基底文字の後に特別な異体字セレクタ文字を続けることで、正確なグリフ形式を指定します。

漢字異体字シーケンス（IVS: Ideographic Variation Sequences）は U+E0100 から U+E01EF の範囲の異体字セレクタ（VS17〜VS256、240個）を使用します。IVS は2文字のシーケンスです:

基底文字 + 異体字セレクタ = IVS

例:
葛 (U+845B) + VS17 (U+E0100) = 葛󠄀 (特定の異体字)
葛 (U+845B) 単体            = 葛  (デフォルトグリフ)

異体字セレクタは不可視です — それ自体はグリフを生成しません。しかし IVS 対応フォントはこのシーケンスを検出すると異なるグリフをレンダリングします。

JavaScript では、この範囲の各異体字セレクタはサロゲートペア（2 UTF-16 コードユニット）を必要とするため、IVS は1書記素クラスタにもかかわらず合計3〜4コードユニットを占めます。

標準化異体字シーケンス（SVS: Standardized Variation Sequences）は、より小さな異体字セレクタセット U+FE00〜U+FE0F（VS1〜VS16）を使用します。用途は以下の通りです:

最も広く知られた SVS の用法はテキスト/絵文字の切り替えです。多くの文字にはテキスト表示（モノクロ、シンプル）と絵文字表示（カラフル）の両方があります。VS15 でテキストスタイル、VS16 で絵文字スタイルを強制します:

// 同じ基底文字、異なる表示:
"\u2764"           // ❤（デフォルト、通常は絵文字）
"\u2764\uFE0E"    // ❤︎（テキスト表示、VS15）
"\u2764\uFE0F"    // ❤️（絵文字表示、VS16）

// セレクタは不可視だがレンダリングを変更:
"❤️".length  // 2（基底 + VS16、両方 BMP 内）

IVS セレクタ（SMP にあり要サロゲート）と異なり、SVS セレクタは BMP（U+FE00〜FE0F）にあり、各1 UTF-16 コードユニットです。

どの異体字セレクタがどのグリフにマッピングされるかは任意ではなく、Unicode コンソーシアムが管理する漢字異体字データベース（IVD: Ideographic Variation Database）に記録されています。IVD には名前付きのコレクションが含まれます:

Adobe-Japan1 は最も広くサポートされているコレクションです。IVS シーケンスを Adobe-Japan1-7 文字コレクションの特定の CID（Character ID）番号にマッピングし、プロフェッショナルな日本語フォントがこれを実装しています。Adobe-Japan1 IVS 対応フォントは数千のグリフ変種をレンダリングできます。

Moji_Joho（文字情報）は IPA（情報処理推進機構）が管理し、公式な政府文書や戸籍システムで使用される文字変種に焦点を当てています。

IVS はフォントがサポートしている場合のみ機能します。フォントには以下が必要です:

• サポートする各 IVS シーケンスのグリフ変種
• 基底文字+セレクタのペアをグリフにマッピングする cmap テーブル（具体的にはフォーマット14、Unicode Variation Sequences）

IVS をサポートする主なフォント:

フォントが特定の IVS をサポートしていない場合、単に基底文字のデフォルトグリフを描画し、異体字セレクタを無視します。これは優雅なフォールバックです — テキストは読める状態のまま、ただし要求された特定の変種ではありません。

邉（U+9089）は登録 IVS シーケンス数の最多記録を保持しています。Moji_Joho コレクションに約47の変種形式があり、この文字が数世紀にわたって日本の戸籍でどれほど多様に書かれてきたかを反映しています。

姓の「渡邉」（わたなべ）は日本で数十の異体字綴りがあることで悪名高い存在です。戸籍を管理する市区町村役場は各家庭の記録に使用された正確な変種を忠実に再現する必要があり、これが Moji_Joho コレクションがこれほど多くの字形を登録している理由です。

これは IVS が不可欠なケースです: IVS なしでは、日本の法律が保存を要求する法的に異なる名前の変種を政府システムが正確に記録することができません。

// 邉の異なる IVS:
"邉"                    // デフォルトグリフ
"邉\u{E0100}"          // 異体字1（VS17）
"邉\u{E0101}"          // 異体字2（VS18）
// ... 約47の登録変種まで

// 各々は1書記素クラスタ:
const seg = new Intl.Segmenter();
[...seg.segment("邉\u{E0100}")].length  // 1