Unicode完全ガイド：UTF-8/UTF-16・正規化・絵文字・セキュリティまで実務で使えるチェックリスト
エバープレイ編集部Unicodeとは何か — 目的と歴史
Unicode（ユニコード）は、世界中の文字を一元的に扱うための文字集合（符号化文字セット）と、それを扱うための仕様群です。1991年にUnicode Consortiumが最初の仕様を公開して以来、継続的に拡張・改訂され、ISO/IEC 10646と協調して世界中の文字や記号に一意の符号位置（コードポイント）を割り当てています。目的は「あらゆるテキストを相互運用可能にする」ことであり、複数の符号化方式やロケール固有の問題にも対応するための技術的基盤を提供します。
基本概念：コードポイント、コードユニット、文字（グラフェム）
コードポイント（code point）：U+XXXX の形式で表される抽象的な番号。例：U+0041 は大文字 'A'、U+1F600 は絵文字 😀。
コードユニット（code unit）：実際のメモリやバイト列で表現される単位。UTF-8では1バイト単位、UTF-16では16ビット単位、UTF-32では32ビット単位です。
グラフェム（ユーザーが知覚する文字）：複数のコードポイントが結合されて1つの表示単位（例：地域指標2つで国旗、ベース文字＋結合文字でアクセント付き文字）。これを正しく扱うには「グラフェムクラス」の理解が必要です（UAX #29）。
Unicodeの構造：平面（Plane）とBMP
Unicodeのコード空間は0x0000から0x10FFFFまでの範囲です。これを17の「平面（Plane）」に分割し、最初の平面（Basic Multilingual Plane, BMP）は U+0000〜U+FFFF を含み、主要な現代言語や多くの記号が収められます。BMP外の文字（例：多くの絵文字や歴史文字）は補助平面に配置されます。
主なエンコーディング：UTF-8、UTF-16、UTF-32
UTF-8：可変長（1〜4バイト）。ASCIIと互換性があり、現在のウェブや多くのプロトコルで最も広く使われます。RFC 3629 によって4バイトまでに制限されています。先頭ビットによりバイト数を判断します。過長エンコーディング（同じコードポイントを不必要に長いバイト列で表す）はセキュリティ上禁止されています。
UTF-16：基本的に16ビット単位。BMP内の文字は1つのコードユニットで表現されますが、BMP外（U+10000〜U+10FFFF）はサロゲートペア（上位サロゲートと下位サロゲート）を使い2単位で表します。古い実装や一部のAPIで使われています。
UTF-32：固定長（4バイト）。コードポイントを直接格納するため扱いは単純だが、メモリ効率が悪いため実運用では限定的に使われます。
正規化（Normalization）と互換性
同じ見た目の文字でも、Unicodeでは異なるコードポイント列で表現できる場合があります（例：é は U+00E9 の単一符号、あるいは 'e'（U+0065）＋結合アクセント U+0301 の組み合わせ）。これによりテキスト比較や検索で不整合が起きるため、Unicodeは正規化（NFC, NFD, NFKC, NFKD）を定義しています。
NFC：可能な限り合成（合成済み文字）を使う正規形。多くのアプリで推奨される。
NFD：分解形（分解された構成要素）にする。
NFKC/NFKD：互換分解を行い、互換文字（例えば全角/半角や合字）を正規化する。セキュリティ上の比較に用いることがあるが、意味の変化に注意が必要です。
結合文字、合字、ゼロ幅文字、ZWJ
Unicodeには結合文字（combining marks）やゼロ幅スペース（U+200B）、ゼロ幅結合子（Zero Width Joiner, U+200D）など特殊なコードポイントがあります。ZWJは複数の絵文字を連結して単一の合成絵文字（例：家族の絵文字）を作るときに使われます。Variation Selector（U+FE0E/FE0Fなど）は文字の表示（テキスト形式か絵文字形式か）を指示します。
双方向テキストと並び替え（BiDi と Collation）
アラビア語やヘブライ語など右から左（RTL）言語と左から右（LTR）言語が混在する場合、Unicodeの双方向アルゴリズム（UAX #9）が表示順を決めます。文字列の並べ替え（ソート）は言語や文化によって異なり、Unicode Collation Algorithm（UCA, UAX #10）とCLDRのローカライズデータを使って適切に実装します。
テキスト分割、行送り、レンダリング
テキストの単語境界、文境界、行折返しなどのルールはUAX #29（テキスト分割）やUAX #14（改行分離）で定義されています。さらに、実際の表示ではフォントやグリフ合成（合字）、言語固有のシェーピングが必要で、HarfBuzz、Uniscribe、Core Text、Pango といったシェーピングエンジンが用いられます。
絵文字（Emoji）と拡張
絵文字はUnicodeで定義されますが、その仕様は頻繁に更新され、絵文字のシーケンス（ZJW を使った結合、SKIN_TONE 修飾子、地域指標の組合せでの国旗など）もサポートされます。絵文字の取り扱いはフォントとプラットフォーム依存の部分も大きいです（UAX/UTRの絵文字仕様を参照）。
セキュリティと課題
ホモグリフ／似た文字攻撃：似た形の文字（ラテンの 'a' とキリルの 'а' など）を悪用した IDN ホモグラフ攻撃が知られており、対策としてUnicodeのセキュリティ勧告（UTS #39）やIDNA規格が利用されます。
無効シーケンスや過長エンコーディング：不正なUTF-8や過長エンコーディングは脆弱性の原因になります。実装では厳密なデコーダを使いバリデーションを行うことが重要です。
正規化の不一致：正規化済みの保存・比較ルールがプロジェクトで統一されていないと、ログインや検索などで問題が生じます。
実装とツール
Unicodeの仕様は膨大で、実装には専用のライブラリやデータが役立ちます。代表的なものに ICU（International Components for Unicode）、各言語の標準ライブラリによるUnicodeサポート、フォント（OpenType/Graphite）とシェーピングエンジンがあります。また、Unicode Character Database（UCD）やCLDR（Common Locale Data Repository）は言語・地域依存の処理に不可欠です。
現場での注意点（チェックリスト）
入力・保存・通信の全経路で同一のエンコーディング（推奨：UTF-8）を使う。
外部データを受け取るときはエンコーディング検証と正規化を行う。
ユーザー表示用の単位と内部処理用の単位（コードポイント／コードユニット／グラフェム）を混同しない。
検索や比較は正規化を前提に設計する（NFCなど）。
IDNやユーザー名などセキュリティが重要な箇所ではUnicodeセキュリティ勧告を参照する。
まとめ
Unicodeは単なる「文字表」ではなく、多言語処理に関わる一連の仕様とデータベース群です。正しく利用するには、エンコーディング、正規化、テキスト分割、レンダリング、セキュリティといった複数の側面を理解し、既存の成熟したライブラリや標準（ICU、CLDR、UAX/UTR）を活用することが重要です。特にウェブやネットワークを扱う現代のアプリケーションでは、UTF-8 を軸に考えるのが現実的かつ互換性に優れた選択です。
参考文献
- Unicode Consortium — 公式サイト
- The Unicode Standard — 概要と仕様
- Unicode Normalization Forms (UAX #15)
- Unicode Bidirectional Algorithm (UAX #9)
- Unicode Text Segmentation (UAX #29)
- Unicode Collation Algorithm (UAX #10)
- Unicode Emoji (UTR #51)
- Unicode Security Considerations (UTS #39)
- Unicode Character Database (UCD)
- CLDR — Common Locale Data Repository
- ICU — International Components for Unicode
- RFC 3629 — UTF-8（IETF）
- RFC 2781 — UTF-16（IETF）
投稿者プロフィール
