Я должен преобразовать слишком долгие строки UTF-8 в их самую короткую нормальную форму?
Я просто переделывал свое Кодирование:: модуль FixLatin Perl, чтобы обработать слишком долгие последовательности байта UTF-8 и преобразовать их в самую короткую нормальную форму.
Мой вопрос вполне просто, "действительно ли это - плохая идея"?
Много источников (включая этот RFC) предлагают, чтобы любой слишком долгий UTF-8 рассматривали как ошибку и отклонить. Они предостерегают против "наивных реализаций" и оставляют меня с впечатлением, что эти вещи по сути небезопасны.
Так как целая цель моего модуля состоит в том, чтобы очистить грязные файлы данных со смешанной кодировкой и преобразовать их в хороший чистый utf8, это походит просто на еще одну вещь, которую я могу очистить так, прикладной уровень не должен иметь дело с ним. Мой код не интересуется никаким семантическим значением, что получающиеся символы могли бы иметь, он просто преобразовывает их в нормализованную форму.
Я пропускаю что-то. Существует ли скрытая опасность, которую я не рассмотрел?
3 ответа
Я не думаю, что это плохая идея с точки зрения безопасности или удобства использования.
С точки зрения безопасности вы должны дезинфицировать вводимые пользователем данные перед использованием. Таким образом, вы можете запустить свои процедуры очистки, а затем убедиться, что данные не содержат больше / меньше символов <> , прежде чем они будут распечатаны. Вы также должны убедиться, что вы вызываете mysql_real_escape_string (), прежде чем вставлять его в базу данных. Имейте в виду, что проблемы языковой кодировки, такие как GBK или Latin1, могут привести к внедрению sql, когда вы не используете mysql_real_escape_string (). (Это имя функции должно быть очень похожим, независимо от привязки библиотеки mysql к вашей платформе)
Как правило, дезинфекция всего пользовательского ввода - ужасная идея, потому что вы не знаете, как будет использоваться конкретная переменная. Например, sql-инъекция и xss имеют очень разные управляющие символы, и одинаковая сенсибилизация для обоих часто приводит к уязвимостям.
Да, это плохая идея.
Возможно, некоторые данные в одном из этих беспорядочных файлов данных были проверены, чтобы убедиться, что они не содержат опасной последовательности символов ASCII.
Канонический пример, вызвавший множество проблем: '\xC0\xBCscript>'. 'Исправьте' слишком длинную последовательность на обычную ASCII < и вы случайно создадите дыру в безопасности.
Ни один инструмент никогда не генерировал оверлонги для каких-либо законных целей. Если вы пытаетесь восстановить файлы со смешанной кодировкой, вы должны рассматривать встречу с такой кодировкой как признак того, что вы неправильно определили кодировку.
Я не знаю, плохая ли это идея в вашем сценарии, однако, поскольку такое изменение не является биективным, оно может привести к потере данных.
Если вы неправильно определили кодировку данных, вы можете интерпретировать данные как легитимные оверлонги UTF-8 и изменить их в кратчайшей нормальной форме. Впоследствии не будет возможности восстановить исходные данные.
По личному опыту я знаю, что когда такие вещи могут произойти, они ПРОИСХОДЯТ, и вы потенциально не заметите ошибку, пока не станет слишком поздно...