W3C バリデーターで Web サイトの HTML コードを検証しているときに、次の警告が表示 されました。
Line 157, Column 220: Text run is not in Unicode Normalization Form C.
…i͈̭̋ͥ̂̿̄̋̆ͣv̜̺̋̽͛̉͐̀͌̚e͖̼̱ͣ̓ͫ͆̍̄̍͘-̩̬̰̮̯͇̯͆̌ͨ́͌ṁ̸͖̹͎̱̙̱͟͡i̷̡͌͂͏̘̭̥̯̟n̏͐͌̑̄̃͘͞…
PHP 5.3.x で開発しているので、Normalizerクラスを使用できます。
これを修正するにはNormalizer::normalize($output)、ユーザーが行った入力 (コメントなど) を表示するときに使用する必要Normalizer::normalize($input)がありますか?それとも、ユーザー入力をデータベースに保存する前に使用する必要がありますか?
tl;dr:ユーザー入力をデータベースに保存する前、または表示するときにUnicode 正規化を使用する必要がありますか?
アプリケーションの目的と性質に基づいて、ユーザー入力の読み取り時、データベースへの保存時、または書き込み時に正規化を適用するか、またはまったく適用しないかを決定するのは、開発者次第です。質問へのコメントで言及されている長いスレッドを要約すると、http: //validator.w3.org/feedback.htmlの公式リスト アーカイブでも入手できます。
まれではありますが、正規化されていないデータをユーザー入力として取得することは確かに可能です。これは、ブラウザが実行する正規化には依存しません (ブラウザはそのようなことはしませんが、将来的にはそうなる可能性があります) が、入力方法と習慣に依存します。たとえば、文字 ü (u ウムラウト、または分音符号付きの u) を入力する方法は、正規化された構成済みの形式で文字を生成する傾向があります。正規化されていない、分解された形式で、文字 u の後に分音記号を組み合わせて生成することもできますが、通常はそうする理由がなく、ほとんどの人はその方法さえ知りません。
ソフトウェアで文字列比較を行う場合、(使用する比較ルーチンに応じて) 処理する場合と処理しない場合があります。単純な実装では、それらは単純な文字レベル (Unicode コード ポイント) で明確に区別されるため、異なるものとして扱います。
ある時点で、遅くとも書き込み段階で正規化する理由の 1 つは、一般的に事前に構成された文字がより確実に表示されるためです。正規化された ü を表示するには、プログラムはフォントからグリフを取得するだけです。分解された ü を表示するには、プログラムはそれを正規化された ü と標準的に同等であると認識するか、u のグリフのグラフィック プロパティに十分注意して、文字 u の上に分音記号を適切に配置して u を書く必要があり、多くのプログラムは失敗します。これで。
一方、正規化されていないデータがユーザー入力として受信されるまれなケースでは、ユーザーがそれを生成した理由がある可能性があります。彼は、正規化された ü と正規化されていない ü は別のものであり、そのように扱う必要があるという考えを持っているかもしれません。