Вам решать на основе цели и характера вашего приложения, применять ли вы нормализацию при чтении пользовательского ввода, или сохранении его в базе данных, или при записи, или вообще. Подведем итог длинной ветке, упомянутой в комментариях к вопросу, также доступной в официальном архиве списка на http://validator.w3.org/feedback.html
- Предупреждающее сообщение исходит из экспериментальной «проверки HTML5» (которая на самом деле является носителем, в которой применяются субъективные правила в дополнение к некоторым формальным тестам).
- Сообщение основано не на каких-либо требованиях в черновиках HTML5, а на мнениях о том, что может вызвать проблемы в некоторых программах.
- Изначально высказывалось мнение, что «проверка HTML5» выдает сообщение об ошибке, теперь предупреждение.
Конечно, возможно, хотя и необычно, получать ненормализованные данные в качестве пользовательского ввода. Это зависит не от нормализации, выполняемой браузерами (они не делают таких вещей, хотя, возможно, в будущем), а от методов ввода и привычек. Например, методы ввода буквы ü (u umlaut или u с диарезом), как правило, приводят к появлению символа в заранее составленной форме, как нормализовано. Люди могут представить его как ненормализованный, в разложенном виде, как букву u, за которой следует сочетание диареза, но у них обычно нет причин для этого, и большинство людей даже не знают, как это сделать.
Если вы проводите сравнение строк в своем программном обеспечении, они могут или не могут (в зависимости от используемых процедур сравнения) обрабатывать, например, предварительно составленный как равный разложенному представлению. Простые реализации рассматривают их как разные, так как они определенно различаются на уровне простых символов (кодовые точки Unicode).
Одна из причин нормализации в какой-то момент, самое позднее на этапе написания, заключается в том, что предварительно составленные символы обычно отображаются более надежно. Чтобы представить нормализованное значение, программе просто нужно подобрать глиф из шрифта. Чтобы представить декомпозированный ü, программа должна либо распознать его как канонически эквивалентный нормализованному ü, либо написать букву u с символом диареза, правильно расположенным над ним, с должным вниманием к графическим свойствам глифа для u, и во многих программах происходит сбой в этом.
С другой стороны, в редких случаях, когда ненормализованные данные принимаются в качестве пользовательского ввода, у пользователя вполне может быть причина для его создания. У него может быть идея, что нормализованные и ненормализованные отличны и должны рассматриваться как таковые.