「踊り字」など、Web入力フォームを作成する時のバリデーションで弾かれないように気をつけるべきこと

U3
2026/4/15
2026/4/15

踊り字（ゝゞ々〻）や機種依存文字、全角・半角の揺れ、不可視文字などは、Webフォームのバリデーションで“意図せず弾かれる”代表例。 特に日本語入力を扱うフォームでは、「禁止する」よりも「許容する」方向で設計する方が安全になることが多い。

以下、Web入力フォームを作るときに必ず気をつけるべきポイントを体系的にまとめるよ。

まず押さえるべき前提

  1. 踊り字は Unicode 正規の文字
  2. → 本来は弾く理由がない
  3. ただし、古いバリデーションルールや正規表現が「想定外文字」として弾くことがある
  4. 特に「ひらがな・カタカナのみ」といった制限をかけると、踊り字が漏れやすい

気をつけるべきポイント一覧

1. 踊り字（ゝゞヽヾ々〻）を許容する

よくある失敗例は、 ^[ぁ-んー]+$ のように範囲指定してしまい、踊り字が入らないケース。

対策

  1. Unicode プロパティを使う（例：\p{Hiragana} や \p{Katakana}）
  2. もしくは踊り字を明示的に追加する 例：[ぁ-んゝゞー]+

2. 機種依存文字（①㈱㊤Ⅲなど）をどう扱うか決める

  1. これらは Unicode では問題ないが、システム側の処理（DB・外部API）で弾かれることがある
  2. 入力フォームで禁止するか、保存時に変換するかを決める

対策

  1. 許容する場合：UTF-8 で統一し、DB も UTF-8 に
  2. 禁止する場合：エラーメッセージを明確にする

3. ゼロ幅スペース・不可視文字の混入

コピペで入りやすい代表例：

  1. ゼロ幅スペース（U+200B）
  2. ゼロ幅ノンジョイナー（U+200C）
  3. ゼロ幅ジョイナー（U+200D）
  4. 改行コードの違い（LF / CRLF）

対策

  1. 入力時にトリム（前後の空白除去）
  2. 不可視文字を除去するフィルタを入れる
  3. ただし「名前」などは除去しすぎると危険なので注意

4. 全角・半角の揺れ

  1. メールアドレス
  2. 電話番号
  3. 郵便番号
  4. カタカナ（全角/半角）

対策

  1. 入力時に正規化（NFKC）
  2. ただし、人名・住所は正規化しすぎると誤変換の原因になる

5. Unicode 正規化（NFC / NFD）問題

Mac の日本語 IME は NFD を使うことがあるため、 「ガ」が「カ + ゛」の分解文字列になることがある。

対策

  1. サーバー側で NFC に統一
  2. DB も NFC で保存

6. 絵文字の扱い

  1. 絵文字はサロゲートペアを含むため、古いバリデーションで弾かれやすい
  2. 入力禁止にするか、許容するかを明確に決める

対策

  1. 絵文字を禁止するなら、Unicode プロパティで除外
  2. 許容するなら、DB の文字コードを UTF8MB4 に

7. 改行の扱い

  1. テキストエリアで改行を許可するか
  2. 1行入力欄で改行を入れたときの挙動

対策

  1. 改行コードを統一（LF）
  2. 1行欄では改行を禁止

---

実務でのおすすめバリデーション方針

1. 「禁止リスト」ではなく「許可リスト」を使わない

禁止リストは漏れが出る。 許可リストも範囲指定が難しい。

→ Unicode プロパティベースのバリデーションが最も安全

2. 入力時に軽い正規化、保存時に厳密な正規化

  1. 入力時：トリム、NFKC（用途による）
  2. 保存時：NFC に統一
  3. 表示時：元の文字を保持

3. 人名・住所は「ほぼ自由入力」にする

  1. 日本語の名前は例外が多すぎる
  2. 住所も同様
  3. 不要なバリデーションは UX を壊す

---


まとめ

Webフォームで気をつけるべきは以下の7つ：

  1. 踊り字を許容する
  2. 機種依存文字の扱いを決める
  3. 不可視文字の混入
  4. 全角・半角の揺れ
  5. Unicode 正規化（NFC/NFD）
  6. 絵文字の扱い
  7. 改行の扱い


特に日本語フォームでは、「弾きすぎない」設計が最重要。

コメント

コメントはまだありません。