Данные HTML превышают длину поля после шестнадцатеричной дезинфекции
Проблема в том, что вы не можете сказать пользователю, сколько символов разрешено в поле, потому что экранированное значение содержит больше символов, чем неэкранированное.
Я вижу несколько решений, но ни одно из них не выглядит очень удачным:
- Один белый список для каждого поля (слишком много работы и не совсем решает проблему)
- Один черный список для каждого поля (то же, что и выше)
- Используйте длину поля, которая может содержать данные, даже если все символы экранированы (плохой)
- Снимите колпачок с размера поля базы данных (хуже)
- Сохраните данные без экранирования в шестнадцатеричном формате и полностью передайте ответственность выходной фильтрации (не очень хорошо)
- Позвольте пользователю угадать максимальный размер (худший)
Есть ли другие варианты? Есть ли «лучшая практика» для этого случая?
Образец кода:
$string = 'javascript:alert("hello!");';
echo strlen($string);
// outputs 27
$escaped_string = filter_var('javascript:alert("hello!");', FILTER_SANITIZE_ENCODED);
echo strlen($escaped_string);
// outputs 41
Если длина поля базы данных равна, скажем, 40, экранированные данные не поместятся.
Извините, это HTML. Несколько тегов были добавлены для пояснения.
Извините, я не совсем понимаю ваш вопрос ... Вы пробовали неэкранировать значения? Они должны вернуться к нормальной длине. Вы можете разместить код?
Ответы 4
делая некоторые дикие предположения о контексте здесь:
- если поле может содержать 32 символа, то есть 32 неэкранированных символа
- позвольте пользователю ввести 32 символа
- escape / unescape - это не проблема пользователя
- почему это проблема?
- если это ввод данных формы, это не имеет значения, и
- если вы по какой-то причине экранируете данные и передаете их обратно, отключите их перед сохранением
без дополнительного контекста похоже, что вы боретесь с проблемой, которой на самом деле не существует или которая не должна существовать
Это интересная проблема.
Я думаю, что решение будет проблемой, если вы возложите на них какую-либо ответственность из-за санитарной обработки. Если они ответственны за угадывание максимальной длины, то они вполне могут сдаться и выбрать что-то другое (и не понять, почему их ввод был недействительным).
Вот моя идея: сделать поле базы данных на 150% больше размера ввода. Этот дополнительный размер служит «заполнением» для пространства шестнадцатеричной дезинфекции, а максимальный размер, показываемый пользователю и валидатору, является фактическим желаемым размером. Таким образом, если вы проверяете длину ввода перед дезинфекцией, и она ниже 66% ограничения длины ваших очищенных данных, должен будет хорошо. Если они превышают эти дополнительные 34% поля для буфера, то ввод, вероятно, не следует принимать.
Единственная проблема в том, что ваши таблицы базы данных будут больше. Если вы хотите избежать этого, вы всегда можете избежать только чувствительных символов SQL и обработать все остальное на выходе.
Редактировать: Учитывая ваш пример, я думаю, вы слишком много убегаете. Либо используйте меньший диапазон очистки с HTMLSpecialChars() на выходе, либо сделайте поля базы данных равными 200% от их текущего размера. Это просто раздуто, если вы спросите меня.
- Почему вы позволяете пользователям вводить экранированные символы?
- Если вам действительно нужно разрешить явно экранированные символы, интерполируйте экранированный символ до, проверяя его работоспособность.
Вы должны в значительной степени никогда проделать какую-либо значительную работу с любой строкой, если она каким-то образом все еще закодирована. Сначала расшифруйте его, потом сделает вашу работу.
Я обнаружил, что некоторые люди склонны слишком рано использовать функции экранирования, такие как addSlashes() (или что-то еще в PHP), или слишком поздно декодировать вещи (например, удалять HTML-объекты). Декодируйте первый, делайте свое дело, потом примените любую кодировку, которая вам нужна для хранения / вывода / и т. д.
Не создавайте свое приложение вокруг базы данных - создайте базу данных для приложения!
Сначала спроектируйте, как вы хотите, чтобы интерфейс работал для пользователя, определите максимально допустимую длину поля и используйте ее.
В общем, не убегайте перед сохранением в базе данных - сохраните необработанные данные в базе данных и отформатируйте их для отображения. Если что-то будет выводиться много раз, сохраните обработанную версию.
Помните, что дисковое пространство относительно дешево - не тратьте усилия на то, чтобы сделать базу данных компактной.
Я просто хотел дополнительно согласиться с точкой зрения о хранении необработанного ввода в базе данных. Если вы до HTML-экранирования ваших данных и обнаружите проблему с вашими подпрограммами экранирования позже, вам не повезло.
В какой среде программирования? Win32, HTML, ...?