プロンプトとコンテキスト
コードレビューツール、アカウントシステム、またはドメイン表示が、視覚的に類似した文字や、読み取り順序を変更する双方向制御文字を受け取ります。論理順序と表示順序の違いを説明し、Confusable検出とポリシー適用の違いを区別した上で、正当な多言語テキストを維持するフローを設計してください。
面接官が見ているポイント
- Unicode双方向アルゴリズムが論理コードポイント順序をそのまま維持しつつ表示順序のみを変更することを理解しているか。
- オーバーライド、アイソレート、混在スクリプト、およびConfusable検出を区別できるか。
- UTS #39のskeleton（スケルトン）が中間値であり、画面に表示したりUnicodeバージョンをまたいで再利用したりしてはならないことを把握しているか。
- 入力検証、表示、監査、認可のための比較、およびアップグレードが個別の関心事として設計されているか。
確認すべき明確化のための質問
まず、対象フィールドがソースコード、ログイン識別子、国際化ドメイン名、検索テキスト、または一般的な文章のどれであるかを特定します。許可されるスクリプト、対象言語、および表示サポートを確認します。次に、検出結果が処理をブロックするのか、レビューを必要とするのか、警告を出すのか、あるいはログに記録するだけなのかを質問します。Unicodeデータのバージョン、元のテキストの保持要件、および許容される偽陽性率（誤検知率）を確認します。
30秒の簡潔な回答
Unicodeテキストには論理順序と表示順序があります。UAX #9は方向プロパティから表示順序を再構成しますが、Bidi制御文字によって比較、パース、数値解析の結果が変わることはありません。セキュリティポリシーでは危険な制御文字を制限し、スクリプトおよびConfusableチェックにはUTS #39を使用すべきです。スケルトンはバージョン管理された比較用の中間キーであり、表示用テキストではありません。原文を保持し、バージョン付きの診断結果を付与し、高リスクな識別子をブロックまたはレビュー対象とし、認可にはフィールドプロトコルの厳密な比較ルールを使用します。
ステップごとの詳細解説
1. 論理順序と表示順序の分離
アラビア語やヘブライ語が数字と混在する場合、UAX #9は強い（Strong）、弱い（Weak）、中立（Neutral）の方向タイプに基づいて表示順序を計算します。RLOやLROなどのオーバーライドは方向を強制し、アイソレートは内部セグメントが周囲に与える影響を制限します。レンダリングによってメモリ内のコードポイントシーケンスが書き換えられることはなく、レンダリング順をパースや比較のルールにしてはなりません。
2. Bidi制御文字と混在スクリプトのリスク特定
ソースコード、ファイル名、アカウント名などの構造化された識別子では、任意の方向制御文字が必要になることはほとんどありません。入力層でBidi_Control文字を拒否またはマークし、表示層でエスケープシーケンスや明示的な境界を表示できます。混在スクリプトのポリシーは、すべての非ASCII文字を悪意あるものとして扱うのではなく、ビジネスで許可された言語セットに準拠させる必要があります。
3. バージョン管理されたConfusable検出の適用
UTS #39は、視覚的ConfusableチェックのためのConfusablesデータとスケルトン機構を提供します。混同しやすさはフォント、スクリプト、コンテキストに依存するため、絶対的な同値関係ではありません。原文、Unicodeバージョン、スクリプト分析、および検出結果を保存します。データアップグレード後に再計算を行い、新たな衝突をレビューする一方で、認可処理では引き続きプロトコルの厳密な比較ルールを使用します。
質の高い模範回答
まず、フィールドのリスク分類から始めます。ソースコード、ユーザー名、ドメインなどの構造化された識別子については、原文を保持した上でスクリプトや方向制御文字を制限します。通常の多言語文章については正当な双方向レイアウトを維持すべきです。UAX #9が表示順序を決定しますが、Bidi制御文字がパース、比較、数値解析を変更してはならないため、監査ツールでは論理コードポイント順序とレンダリング出力の両方を表示する必要があります。検出ではUTS #39の制限レベル、混在スクリプト規則、およびConfusablesデータを組み合わせます。スケルトンはある1つのUnicodeデータバージョンに対する中間キーであり、表示用テキストでもバージョンをまたいだ恒久的な識別子でもありません。RLO、異常なスクリプトの混在、既存の高リスク識別子との衝突は、ブロックまたはレビュー対象とすべきであり、一般的な文章であれば警告を出す程度にとどめます。比較と認可には、視覚的類似性ではなく、フィールドプロトコルが定義する正規化、大文字・小文字、エンコーディングの規則を使用する必要があります。Unicodeデータのアップグレード時には、変更を追跡可能かつ可逆的にするため、検出結果を一括で再計算し、衝突をレビューします。
よくある落とし穴
- 表示順序をストレージに保存されている文字列順序として扱ってしまう。
- すべての右横書き文字を削除すれば問題が解決すると主張し、正当なアラビア語やヘブライ語のテキストを破壊してしまう。
- スケルトンを安定したハッシュ、表示値、またはバージョンをまたいだプロトコルフィールドとして扱ってしまう。
- ASCIIのみをチェックし、フォント、スクリプト、結合文字、コンテキストを無視してしまう。
- 認可、署名、または一意性の検証に、フィールドの厳密な比較ルールではなく視覚的類似性を使用してしまう。
追加の質問と回答
なぜすべての入力からBidi制御文字を一括削除しないのですか？
なりすましに悪用される可能性がある一方で、正当なドキュメントやレイアウトに方向制御文字が必要な場合があるためです。フィールドのリスクとターゲットプラットフォームに応じて、ブロック、エスケープ、アイソレーション、警告のいずれかを選択し、監査可能な証拠を保持します。
スケルトンをそのままユーザー名にすることはできますか？
できません。スケルトンは検出用の中間形式であり、Unicodeデータとともに変化します。原文とプロトコルで定義された比較キーを保持し、スケルトンは衝突診断やレビューのために使用します。
多言語データにおける誤検知をどのように減らしますか？
許可される言語とスクリプトのセットを定義し、CLDR言語データ、フィールドのコンテキスト、および人的レビューを組み合わせます。一般的な文章には警告を出すにとどめ、ログイン識別子、ドメイン、コード識別子にはより厳格な制限を適用します。