Данные HTML превышают длину поля после шестнадцатеричной обработки

Question

Проблема в том, что вы не можете сказать пользователю, сколько символов разрешено в поле, потому что экранированное значение, очевидно, содержит больше символов, чем не экранированное.

Я вижу несколько решений, но ни одно не выглядит очень хорошо:

• Один белый список для каждого поля (слишком много работы и не совсем решает проблему)
• Один черный список для каждого поля (как указано выше)
• Используйте длину поля, которая может содержать данные, даже если экранированы все символы (плохо)
• Раскройте размер для поля базы данных (хуже)
• Сохранить данные в шестнадцатеричном виде и передать всю ответственность за фильтрацию выходных данных (не очень хорошо)
• Позвольте пользователю угадать максимальный размер (худший)

Есть ли другие варианты? Есть ли «лучшая практика» для этого случая?

Пример кода:

$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, экранированные данные не уместятся.

Answer 1

Не создавайте свое приложение вокруг базы данных - создайте базу данных для приложения!

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

В общем, не сбегайте до сохранения в базе данных - сохраняйте необработанные данные в базе данных и форматируйте их для отображения. Если что-то будет выводиться много раз, сохраните обработанную версию.

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

Answer 2

делая некоторые дикие предположения о контексте здесь:

• если поле может содержать 32 символа, то есть 32 неэкранированных символа
• позволяет пользователю ввести 32 символа
• escape / unescape - не проблема пользователя
• почему это проблема?
  • если это ввод данных формы, это не имеет значения,
  • если по какой-то причине вы сбрасываете данные и возвращаете их обратно, то перед сохранением снимите их с экрана

без дополнительного контекста, похоже, что вы боретесь с проблемой, которой на самом деле не существует или которая не должна существовать

Answer 3

• Почему вы разрешаете пользователям вводить экранированные символы?
• Если вам нужно разрешить явно экранированные символы, то интерполируйте экранированный символ перед проверкой его работоспособности

Вы должны в значительной степени никогда выполнять какую-либо значительную работу с любой строкой, если она каким-то образом все еще закодирована. Сначала расшифруйте его, , затем выполняйте свою работу.

Я считаю, что некоторые люди склонны использовать экранирующие функции, такие как addSlashes() (или что-то еще в PHP), слишком рано, или слишком поздно декодировать вещи (например, удалять HTML-сущности). Декодируйте сначала , делайте свое дело, , затем применяйте любую кодировку, необходимую для сохранения / вывода / и т. Д.

Answer 4

Это интересная проблема.

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

Вот моя идея: сделать поле базы данных на 150% больше размера ввода. Этот дополнительный размер служит «заполнением» для пространства шестнадцатеричной очистки, и максимальный размер, показанный пользователю и валидатору, является фактическим желаемым размером. Таким образом, если вы проверяете длину ввода до санации, и она ниже 66% предела длины ваших санированных данных, то должно быть хорошим. Если они превышают это дополнительное 34% -ое пространство поля для буфера, то ввод, вероятно, не должен быть принят.

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

Редактировать: Учитывая ваш пример, я думаю, что вы слишком много избегаете. Либо используйте меньший диапазон очистки с HTMLSpecialChars() на выходе, либо увеличьте поля вашей базы данных до 200% от их нынешнего размера. Это просто раздутый, если вы спросите меня.