Должен ли я преобразовать слишком длинные строки UTF-8 в их кратчайшую нормальную форму?

Question

Я только что переработал свой Encoding :: FixLatin Модуль Perl для обработки слишком длинных байтовых последовательностей UTF-8 и преобразования их в кратчайшую нормальную форму.

Мой вопрос довольно прост: " это плохая идея "?

Ряд источников (включая этот RFC ) предполагают, что любой слишком длинный UTF-8 следует рассматривать как ошибку и отклонять. Они предостерегают от «наивных реализаций» и оставляют у меня впечатление, что эти вещи небезопасны по своей природе.

Поскольку цель моего модуля - очистить файлы с беспорядочными данными смешанными кодировками и преобразовать их в nice clean utf8, мне кажется, что это еще одна вещь, которую я могу очистить, чтобы прикладному уровню не приходилось иметь дело с Это. Мой код не касается какого-либо семантического значения, которое могут иметь результирующие символы, он просто преобразует их в нормализованную форму.

Я что-то упустил? Есть ли скрытая опасность, которую я не учел?

Answer 1

Да, это плохая идея.

Может быть, некоторые данные в одном из этих грязных файлов данных были проверены, чтобы убедиться, что они не содержат опасную последовательность символов ASCII.

Канонический пример, вызвавший много проблем: '\xC0\xBCscript>'. «Исправьте» слишком длинную последовательность в обычном ASCII <, и вы случайно создали дыру в безопасности.

Ни один инструмент никогда не создавал оверлинги для каких-либо законных целей. Если вы пытаетесь восстановить файлы со смешанной кодировкой, вам следует рассмотреть возможность встретить их как признак того, что вы ошиблись в кодировке.

Answer 2

Я не думаю, что это плохая идея с точки зрения безопасности или удобства использования.

С точки зрения безопасности вы должны дезинфицировать ввод пользователя перед использованием. Таким образом, вы можете запустить процедуры очистки, а затем убедиться, что данные не содержат символов больше / меньше чем <>, прежде чем они будут распечатаны. Вы также должны убедиться, что вызываете mysql_real_escape_string (), прежде чем вставить его в базу данных. Имейте в виду, что проблемы кодирования языка, такие как GBK против Latin1, могут привести к внедрению sql, когда вы не используете mysql_real_escape_string (). (Это имя функции должно быть очень похожим независимо от привязок библиотеки mysql для вашей платформы)

Очистка всего пользовательского ввода, как правило, ужасная идея, потому что вы не знаете, как будет использоваться конкретная переменная. Например, в инъекциях sql и xss используются очень разные управляющие символы, и одна и та же сенсибилизация для обоих часто приводит к уязвимостям.

Answer 3

Я не знаю, является ли это плохой идеей в вашем сценарии, однако, поскольку такого рода изменения не являются биективными, это может привести к потере данных.

Если вы неправильно определили кодировку своих данных, вы можете интерпретировать данные как допустимые превышения UTF-8 и изменить их в кратчайшей нормальной форме. Позже будет невозможно получить исходные данные.

Как личный опыт, я знаю, что когда такие вещи могут произойти, они БУДУТ, и вы потенциально не заметите ошибку, пока не станет слишком поздно ...