はじめに
アプリやゲームにおいて、「自由入力」のテキストボックスやそれを表示するラベル (ユーザ名・コメント欄・etc.) などを安易に設置すると、想定の斜め上を行く妙な文字(列)を入力され、意図しない表示・処理になることが多々あります。
本稿では、そのテストに使えるような文字(列)を記載していきます。なるべくコードポイント (U+xxxx) も併記するようにしました。
想定環境は主に PC ・スマートフォンで動作するクライアント (もっと具体的には Unity の TextMeshPro InputField) です。
Web やデータベース周りでは、例えば古典的な XSS や 寿司ビール問題 など別種の気を付けるべきポイントがあるかもしれませんが、あまり詳しくないのでここには記載しません。
なお、特に注記がない場合は Unicode / UTF-8 であるものとします。
環境によっては正しく表示されない可能性がありますがご了承ください。逆に考えると、その環境ではこれらのテストが有効であったことを意味します…
執筆環境は Windows 10 (游明朝が利用可能) / Firefox です。
省エネのため箇条書きスタイルでお送りしますが、ご了承ください。
- はじめに
- テストに使える文字(列)
- 空文字列
- 空白文字
- 改行文字
- RTL (Right-to-Left)
- その他の制御文字・特殊な文字
- その環境における制御文字(列)
- 長い文字列
- 大きなスペースをとる文字
- 大きなスペースをとる文字列
- スペースをとらない・不可視の文字
- 複数の表現がある文字 (正規化)
- UTF-16 において 2 バイトで表現できない (U+10000 以降の) 文字
- フォントに含まれない文字
- 異体字セレクタ
- 国と地域の旗の絵文字
- 外字
- 最近追加された文字
- 複数のコードポイントで表現される文字
- 色がある前提の絵文字・色を付ける絵文字
- 合字 (リガチャ)
- 非常に似ている文字
- 環境に依存して見た目が変わる文字
- 1 文字あたりのバイト数が大きい文字
- 不正な文字列・バイト列
- 余談
- おわりに
テストに使える文字(列)
空文字列
- それはそう
空白文字
- U+0020 " " (半角スペース)
- U+3000 " " (全角スペース)
- U+0009 " " (Tab)
- 環境によってサイズが大きく異なる
- U+200B "" (ゼロ幅スペース)
- その他 → スペース / 幅の比較
- U+2800 "⠀" (点字カテゴリの点がない文字)
- 見た目上空白だが So (Symbol, Other) カテゴリのため、 Zs (Separator, Space) カテゴリを禁止してもすり抜ける
- 空白文字のみで構成された文字列を許容するか？
改行文字
- U+000D U+000A (CR LF), U+000A (LF) のどちらか？
- 連打された場合にレイアウトが破綻しないか
- あるいは、そもそも入力できるのが適切かどうか
- 末尾の空行を行数にカウントするか
RTL (Right-to-Left)
- 右から左へ描画するシステム (アラビア文字など)
- العربية
- U+0627 U+0644 U+0639 U+0631 U+0628 U+064A U+0629
- データ上の並び順としては ا ـل ـعـ رـ ـب ـيـ ةـ となっている
- العربية
- U+202E (Right-to-Left Override)
- 後続文字の描画順を強制的に「右から左」にする
- ABCD と DCBA
- 上記 2 つは同じに見えるが、後者はデータ上 U+202E に続けて DCBA と並んでいる
- 禁止ワードフィルタをすり抜ける、正しいファイル名に見せかけるなど大問題になりうる
- "正規ファイルだよxcod.exe" はデータ上 "正規ファイルだよ
U+202Excod.exe" であるので、実行ファイルとして開けてしまう
- "正規ファイルだよxcod.exe" はデータ上 "正規ファイルだよ
- RTL と LTR の混在
- 例: アラビア文字 (RTL) の文章中でも、数字は LTR (Left-to-Right) として描画されるべき
- لدي 100 تفاحة.
- == I have 100 apples.
- لدي 100 تفاحة.
- 例: アラビア文字 (RTL) の文章中でも、数字は LTR (Left-to-Right) として描画されるべき
その他の制御文字・特殊な文字
- U+0000 "�" (␀)
- U+0007 "" (␇)
- ベル
\a - ターミナルで出力すると音が鳴るなどする
- ベル
- U+FFFD � (REPLACEMENT CHARACTER)
- UTF-8 として不正なバイト列を読んだ場合などで出現
- コピペなどで正規に(?)入力することもできるが、一般のユーザにはバグ・文字化けに見えそう
その環境における制御文字(列)
- データベース (?) が csv の場合における
,や" - Unity (TextMeshPro) における
<b>や<s>,<color=red>など
長い文字列
- テスト例
- Lorem ipsum
- 青空文庫 (あのイーハトーヴォのすきとおった風…)
- KB ～ MB オーダーの文字列を突然コピペされたときに動作するか
- IME の変換前状態で、一時的にテキストボックスの文字数制限を突破できる場合がある
- 毎フレーム処理したり、文字変更イベントを都度受け取ったりするタイプの環境では注意
- 文字の正規化処理で長くなる可能性 → 正規化
- U+FDFA ﷺ は NFKD ・ NFKC 正規化 で 18 文字に分解されうる
- U+0635 U+0644 U+0649 U+0020 U+0627 U+0644 U+0644 U+0647 U+0020 U+0639 U+0644 U+064A U+0647 U+0020 U+0648 U+0633 U+0644 U+0645
- صلى الله عليه وسلم
- C# では
"\ufdfa".Normalize(System.Text.NormalizationForm.FormKD)で確認可能
- 正規化が必要な場合、正規化→長さチェックの順に行う (逆だと限界突破しうる)
- U+FDFA ﷺ は NFKD ・ NFKC 正規化 で 18 文字に分解されうる
大きなスペースをとる文字
- 以下原寸大。特に最初の 2 つは入力・表示できてしまう環境が多いため注意
- U+A9C5 ꧅
- U+FDFD ﷽
- U+A9C1 U+A9C2 ꧁꧂
- U+12031 𒀱
- U+1242B 𒐫
大きなスペースをとる文字列
- U+0E14 U+0E47 (x10) ด็็็็็็็็็็
- U+05D1 U+059F (x10)
- ב֟֟֟֟֟֟֟֟֟֟
スペースをとらない・不可視の文字
- U+200B "" (ゼロ幅スペース)
- U+200C "" (Zero width non-joiner; ZWNJ)
- U+2063 "" (Invisible Separator) やほかにもたくさん
- U+180E "" (Mongolian Vowel Separator)
- 上記と異なり General Punctuation ブロックではないので注意
- なりすましや文字数稼ぎに利用されうる
- アカウント名の末尾に追加して重複判定を回避する、4 文字以上必須のユーザ名を (見た目上) 空文字列にする、など
- U+05D1 U+05BC (x10) בּּּּּּּּּּ
- U+05BC を大量に重ねても幅をとらない
複数の表現がある文字 (正規化)
- 同一の文字に複数の表現方法がある場合
- U+304C が
- 単一の文字としての「が」
- U+304B U+3099 が
- 「か」 + 濁点
- その他、アルファベットでのダイアクリティカルマークなど → 参照
- U+304C が
- これらが混在していると、検索・ソートなどを愚直に (バイト一致判定で) 行った場合に問題になる
- 正規化 によってこれらを直感的に正しく行える
- ただし、非可逆な操作なので保存する場合は注意
UTF-16 において 2 バイトで表現できない (U+10000 以降の) 文字
- U+29E3D 𩸽 (ほっけ)
- U+1F97A 🥺 など多くの絵文字が該当する
- UTF-16 ベースで、サロゲートペアを正しく扱えないシステムにおいて問題になる
- 例: C# において文字列長を
string.Lengthでとっているとズレが生じる
- 例: C# において文字列長を
フォントに含まれない文字
- 明らかに文化の異なる文字は自明
- U+1740 ᝀ ブヒッド文字や U+10000 𐀀 線文字 B など
- Unicode の比較的小さな部分にある漢字は機械的に弾きにくいかもしれない
- U+34C7 㓇 など
- JIS X 0213 の第 4 水準 あたりは対応していないものが多そう
- もし対応文字数が少ないフォントを利用している場合は、デザインのずれが許容できるフォールバックフォントを用意するか、厳しめの (ホワイトリストのような) 文字制限をかける
異体字セレクタ
- U+FE00 ～ U+FE0F, U+E0100 ～ U+E01EF を後ろにつけると文字の細かなバリエーションが変わる
- 漢字
- 絵文字のスタイル選択
国と地域の旗の絵文字
- U+1F1EF U+1F1F5 🇯🇵 (日本の国旗)
- 2 文字で表すタイプ → Regional indicator symbol
- 🇯 と 🇵 (JP) からなる
- 仕様上、検索などで問題になりうる
- 2 文字で表すタイプ → Regional indicator symbol
- U+1F3F4 U+E0067 U+E0062 U+E0065 U+E006E U+E0067 U+E007F 🏴 (イングランドの旗)
- 旗 + 地域コード(ここでは gbeng) + 終了 で表すタイプ → Emoji tag sequences
外字
- U+E000 ～ U+F8FF, U+F0000 ～ U+FFFFD, U+100000 ～ U+10FFFD
- そもそも入力できて良いのか？を検討すべき
- 有名どころでは Apple の U+F8FF (林檎のロゴ) や Twitter の U+EA00 (例の鳥) など
- それ以外の用例は → Private use areas
- 特殊なところでは Ninja cat 🐱👤 → ニンジャキャット
最近追加された文字
- 2022/06/01 現在最新の Unicode 14.0 (2021/09) で追加された文字
- U+1FAE0 🫠 (溶ける顔) など
- 超マイナーな文字ならともかく、絵文字は比較的入力しやすいので危ない
- 文字が追加される前提で設計しなければならない
複数のコードポイントで表現される文字
- 👨🏻👩🏿👦🏽👦🏼 → ソース (図6)
- 分割すると 👨 + 🏻 + ZWJ + 👩 + 🏿 + ZWJ + 👦 + 🏽 + ZWJ + 👦 + 🏼
- U+1F468 U+1F3FB U+200D U+1F469 U+1F3FF U+200D U+1F466 U+1F3FD U+200D U+1F466 U+1F3FC
- 1 書式素に 11 コードポイント、 UTF-8 では 41 バイト
- 書式素 (Grapheme) : 人間が見て "1 文字" と思える単位 (要約)
- これを正しく "1 文字" として判定するには、書式素単位でカウントできる
StringInfo.GetTextElementEnumerator()や GraphemeSplitter ライブラリなどを利用する
- 👩👩👩👩👩👩👩👩👩👩👩👩👩👩👩👩👩👩
- U+1F469 U+200D を繰り返している。 35 コードポイント、 UTF-8 で 122 バイト
- カーソルを動かす / 選択すると分かるように、これでも 1 文字扱いされる
- 👩⚕️ (Woman health worker)
- U+1F469 U+200D U+2695 U+FE0F
- 👩 + ZWJ + ⚕ + 異体字セレクタ (emoji; ⚕️)
- → Unicode 14.0 における emoji ZWJ sequence の一覧
- 👨🏿🦳
- U+1F468 U+1F3FF U+200D U+1F9B3
- 👨 + 🏿 (dark skin tone) + ZWJ + 🦳 (white hair)
- skin tone の範囲は U+1F3FB ～ U+1F3FF
- hair の範囲は U+1F9B0 ～ U+1F9B3
- #️⃣
- ஙொ
- U+0B99 U+0BCA
- U+0BCA ொ は直前の文字を挟み込む形で作用する
色がある前提の絵文字・色を付ける絵文字
- モノクロ描画の場合、識別が難しくなる可能性はある
- 例 (上が通常、下は異体字セレクタ U+FE0E を後続させてテキストスタイルにしたもの)
- U+26AA U+26AB U+1F534 U+1F535 U+1F7E0 U+1F7E1 U+1F7E2 U+1F7E3 U+1F7E4
- ⚪⚫🔴🔵🟠🟡🟢🟣🟤
- ⚪︎⚫︎🔴︎🔵︎🟠︎🟡︎🟢︎🟣︎🟤︎
- U+2B1B U+2B1C U+1F7E5 U+1F7E6 U+1F7E7 U+1F7E8 U+1F7E9 U+1F7EA U+1F7EB
- ⬛⬜🟥🟦🟧🟨🟩🟪🟫
- ⬛︎⬜︎🟥︎🟦︎🟧︎🟨︎🟩︎🟪︎🟫︎
- Unicode の字形例 ではハッチで描き分けている
- U+26AA U+26AB U+1F534 U+1F535 U+1F7E0 U+1F7E1 U+1F7E2 U+1F7E3 U+1F7E4
- 複数のコードポイントを利用する場合
- U+1F408 U+200D U+2B1B 🐈⬛ (黒猫)
- U+1F44F U+1F3FB 👏🏻 (skin tone)
合字 (リガチャ)
- 連続すると見た目が変わる文字
- コードポイント的には ae と æ (U+00E6) など
- フォント(描画システム)側で解決する場合もあり
- 文字体系がリガチャ前提な デーヴァナーガリー など
- द्ध्र्य は、 द ् ध ् र ् य で構成されている
- U+0926 U+094D U+0927 U+094D U+0930 U+094D U+092F
- → 参照
- द्ध्र्य は、 द ् ध ् र ् य で構成されている
非常に似ている文字
- A А Α
- システム的には問題なくとも、なりすましや誤認に利用できる場合がある → ホモグラフ攻撃
環境に依存して見た目が変わる文字
- ロケール
- 骨 骨 骨 骨 骨 骨
- コードポイントはすべて U+9AA8
- lang にそれぞれ
zh-CN,zh-TW,zh-HK,ja-JP,ko-KR,vi-VN(中国, 台湾, 香港, 日本, 韓国, ベトナム) を指定している
- OS
- 絵文字は環境によって大幅に字形 (イラスト?) が異なる場合がある
- U+1F3AB 🎫 (チケット)
- → 様々な環境での見え方
- 確かに「チケット」だが、色合い・向きなどは多種多様
- 色や向きなどに意味を持たせた表現をすると、別の表示になる受け手の解釈が変わってくる
- どうしても統一したい場合は画像埋め込みか？ (それでも IME とは表示が異なる)
1 文字あたりのバイト数が大きい文字
- コードポイント単位
- 書式素単位
- 文字数制限がバイト・ワード単位でしか設定できない環境 (C# の
string.Lengthに依存している場合など) では、上記の文字を入力した場合に「見た目上の文字数」が著しく少なくなってしまう- 逆に、書式素単位で設定すると非常に大きいバイト数の文字を入力される可能性がある
- 厳密に判定するなら書式素の数を数える。また、十分余裕を持ったバッファを用意しておく
- 正規化で大きくなる文字 (前述)
- U+FDFA ﷺ は 1 文字から 18 文字に (UTF-8 では 3 バイトから 33 バイトに) 膨らむ
不正な文字列・バイト列
- 解釈できないバイト列
- UTF-8 における
C0 AF- U+002F
/を 2 バイトで表現した…ともとれるが、/は2Fの 1 バイトで表現しなければならないため不正 - これを
/と解釈するとディレクトリトラバーサル対策の回避などに利用できてしまうため → セキュリティ
- U+002F
- UTF-16 における
D8 D8(サロゲートペアの片割れ)- サロゲートペアを用いる文字を入力した際、一時的に現れる場合がある
char単位でしか検証できない環境 (Unity のInputField.OnValidateInput) など
- 文字数制限でペアの片割れだけ弾いてしまう、片割れのままログ出力してしまうなどでエラーになりうる
- サロゲートペアを用いる文字を入力した際、一時的に現れる場合がある
- ただ、一般的な IME から直接入力・コピペする手段はないはず
- 不正な部分は U+FFFD � に置き換えられうる (VSCode で確認)
- 環境によってはより深刻なエラーにもなりうるため、存在させない
- UTF-8 における
- 非文字
- 未定義の文字
- 将来的に定義されうる
- U+32FF ㋿ をあらかじめ入力しておくことで「元号を予言」する
- 将来的に定義されうる
余談
上記に載せるほどではない、文字関連の余談です。
幽霊文字
- 実際の利用例がない文字 → Wikipedia
- プログラム的には気にしなくてよい。しいて言えばフォントが対応しているかぐらい
- その定義からして使われることはまずないが…
- マシュマロでは U+5F41 彁 を伏せ字に利用している
- 利用例がないことを逆手に取っている → 参照
点字
- U+2800 ～ U+28FF → Wikipedia
- ドットアートが可能 ⠠⠵
- U+2800 "⠀" は見た目上空白だがカテゴリが Other Symbol のため、空白カテゴリを禁止してもすり抜ける可能性がある (上述)
Methematical Alphanumeric Symbols
- 𝑰𝑵𝑻𝑬𝑹𝑵𝑬𝑻 𝑨𝑵𝑮𝑬𝑳
- 文字だけで (フォントを変えることなく) 書体を変えることができる → リスト
- A 𝐀 𝐴 𝑨 𝖠 𝗔 𝘈 𝘼 𝒜 𝓐 𝔄 𝕬 𝙰 𝔸
- U+0041 U+1D400 U+1D434 U+1D468 U+1D5A0 U+1D5D4 U+1D608 U+1D63C U+1D49C U+1D4D0 U+1D504 U+1D56C U+1D670 U+1D538
- 基本的にコードポイントは連続しているが、一部既に存在した文字 (U+210E ℎ など) の箇所は未割り当てになっているので注意 (前述の ℎ に対応する U+1D455 など)
- また、既存だった文字は書体がずれがちなので注意
- ... 𝑓 𝑔 ℎ 𝑖 𝑗 ...
- きちんとやりたいならフォントを変えるべき
- また、既存だった文字は書体がずれがちなので注意
実際に問題を起こした文字列
- Black dot bug
- テルグ文字 (の一部の組み合わせ)
ひらがなは 2 バイト文字か？
- UTF-8 において "2 バイト文字" ではないのは自明。 2 バイトなのは U+07FF までで、平仮名ブロックは U+3040 から始まる
- では「すべてのひらがなは 3 バイト」と言えるか?
- U+1B001 𛀁 (や行え) はひらがなであり 4 バイト (UTF-8 で
F0 9B 80 81) なので、つまり一概には言えない
おわりに
以上のように、個性豊かな文字(列)がたくさん存在します。
たかが文字、されど文字…
全部 Unicode が悪い… と思いましたが文字は実世界の映しではあるので、つまり人類が悪い
また、本稿は問題になりうる文字を網羅したものではなく、あくまでそれらの一部です。
テキストボックス実装の際は、全部対応… するのは骨が折れるどころか複雑骨折するので、何らかのライブラリを利用するか、目立つところは処理してあとは心の隅に置いておくか、とするとよさそうです。
コピペが簡単になるように以上をまとめたテキストファイルをご用意いたしました。
上述の文字(列)たちを LF 改行で記載しています。テストにご利用ください。
※ U+0000 (ヌル文字) だけは gist に入力できなかったため省略しています。ご了承ください。
