IDにおける視覚的に紛らわしい文字の理解と回避

 (gajus.com)
4 ポイント 投稿者 GN⁺ 2024-04-24 | 3件のコメント | WhatsAppで共有

IDにおける視覚的に紛らわしい文字を理解する

  • 視覚的に紛らわしい文字とは、特定のフォントや手書きで見分けにくい文字を指す
    • O/0, I/l/1/7, 5/S, 2/Z, 8/B, 6/G, 9/q/g などが該当
  • こうした文字は、データ入力時にエラーや混乱を引き起こす可能性がある
    • ユーザーが O と 0 を区別しにくく、誤ったコードを入力してしまうなど、不便なユーザー体験につながる
  • IDが口頭で伝えられたり、手書きしなければならない場面では特に重要
    • カスタマーサポート、割引コード、追跡コード、エラーID、製品ID など

大文字・小文字を区別するかどうかを決める

  • IDで大文字・小文字を区別するかどうかを決める必要がある
    • 区別する場合、視覚的な曖昧さを除外したうえで選択可能な文字は53個
    • 区別しない場合、選択可能な文字は22個
  • IDの長さが5文字の場合のID総数:
    • 大文字・小文字を区別: 53^5 = 418,195,493通り
    • 大文字・小文字を区別しない: 22^5 = 5,153,632通り
  • ただし、IDの長さが増えるほど、生成可能なIDの数は指数関数的に増加する
  • そのため、IDの長さと視覚的曖昧さの可能性のあいだで妥当な折衷点を見つける必要がある
  • また、大文字・小文字の両方を使うと、大文字・小文字を区別しないサードパーティ製システムで予期しない問題が起こる可能性もある

視覚的に明確な文字セット

  • 可読性を最優先するなら、次のような文字セットの利用を推奨:
    • [ "a", "b", "c", "d", "e", "f", "h", "i", "j", "k", "m", "n", "o", "p", "r", "s", "t", "w", "x", "y", "3", "4"]

追加で考慮すべき点

  • 特定の文字の組み合わせが別の文字に見えることがある（例: rn は m のように、3 は w のように見える）
    • ID生成の段階でこうした組み合わせを避けるのが望ましい
  • 発音が似ている文字も避けたほうがよい（例: b と p）
    • 特にIDが口頭で伝えられる場面では重要

既存の事例

  • Crockford's Base32: 紛らわしい文字を同じ値としてデコードし、偶発的な罵倒語も考慮している
  • Open Location Code: 23456789CFGHJMPQRVWX の文字セットを使用。視覚的曖昧さの回避に加え、一般的な言語の単語が形成されることも避けようとしている。ただし 6/G、9/Q は含む。

GN⁺の見解

  • ID生成では、使いやすさと可読性を最優先で考えるべき。特にIDが口頭で伝えられたり、手書きで記録されたりすることが多いならなおさらである。
  • 視覚的曖昧さを最小化できる文字セットを選びつつ、IDの長さと生成可能な組み合わせ数のあいだで適切な折衷点を見つけることが重要。
  • また、サードパーティ製システムとの連携時に予期しない問題が起こる可能性があるため、大文字・小文字を区別するかどうかは慎重に決める必要がある。
  • ID生成ロジックでは、特定の文字の組み合わせを除外したり、発音が似ている文字を避けたりといった追加の配慮も必要。
  • Crockford's Base32 や Open Location Code のような事例を参考に、プロジェクト要件に合った最適な文字セットを設計するのが望ましい。

関連記事

3件のコメント

 
roxie 2025-01-29

これもよさそうです: https://stackoverflow.com/a/58098360/8556340
 
roxie 2025-01-29

発音まで考慮しているなんて、本当に驚異的ですね。
 
GN⁺ 2024-04-24
Hacker Newsのコメント
  • 実際の現場で、曖昧な文字を含むシリアル番号を数百万台のデバイスに使ってしまい、カスタマーサポートで大きな苦労をした事例がある。正規表現でタイプミスのバリエーションを生成し、DBと照合して実際のシリアル番号を推定するという悪夢のような経験をした。
  • ユーザーに応じてエンコーディング方式を変えるべき。Base32は明確な文字集合を持っているため適しており、口頭で伝えるときは単語リスト表現（例: "TIDE ITCH SLOW REIN RULE MOT"）を使うのがよい。ただし、慣用句、同音異義語、方言などの落とし穴が潜んでいるので、独自の単語リストは作らないほうがよい。
  • CPANに冗談半分で公開した任意基数演算モジュール(Math::Fleximal)のせいで、思いがけないサポート依頼を受けたことがある。16進数を英数字コードに変換するデモコードを、誰かが本番環境で使っていたのが原因だった。
  • Nintendo SwitchのDLCシリアル番号入力画面では、紛らわしい文字のキーを無効化してUXを改善している。
  • 筆記体で書いたときに区別しにくい文字も避けるべき。特に「7」と「1」は混同しやすい。
  • 大文字と小文字を両方使うと、大文字小文字を区別しないシステムやプロトコルによって後で痛い目を見ることがある。ユーザーの利便性を理由に、これをバグだと認めない商用システムもある。
  • 2FAのバックアップコードを紙に書くたびに、特定の文字（o/0、v/u、5/S など）に不安を感じる。これを避けるために文字に装飾を加えることがある。
  • Wi‑Fiパスワードには、3年生の子どもでも正確に綴れる日常的な単語（"vacation"）を選んでいる。
  • KeepassXCは、文字の種類（大文字、小文字、数字、記号など）ごとに色を変えることで可読性を大きく高めている。
  • ビットコインアドレスは、修正版のBase58エンコーディングを使用している。
  • 記事ではArialフォントをArielと誤記している。