Разрешенные символы в формах отправки (включая UTF-8)

Question

Предположим, что я разрешаю своим пользователям отправлять форму, содержащую некоторые текстовые поля (я не говорю о паролях). Мои пользователи иногда используют символы, отличные от ASCII, такие как русский, китайский и т. Д., Поэтому я использую кодировки UTF-8 в моей базе данных. Вопрос в том, должен ли я действительно разрешать все возможные символы UTF-8? Я взглянул на таблицу ASCII и увидел, что символы от 0 до 31 не имеют никакого отношения к тексту, за исключением строк новой строки и пробелов. Персонажи от 176 до 223 кажутся для декоративных целей: стр. Должен ли я их ограничивать?

Answer 1

Убедитесь, что это действительно UTF-8 и Unicode? Да

Удостоверьтесь, что в него не включены определенные символы, такие как коды управления? Вероятно, нет необходимости

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

• сверхдолгим кодировок (что может привести к проблемам безопасности)
• Другие недопустимые символы UTF-8 последовательности байтов, которые могут свидетельствовать о том, что агент пользователя игнорируется кодирование символов и вместо этого отправил что-то вроде Windows-1252 или ISO-8859-1.
• Кодовые точки, которые лежат в зарезервированной суррогатной пространстве в Unicode

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

Если вы хотите, чтобы служить правильный HTML или XHTML, которые используют подмножество Unicode, вам потребуется также нужно отфильтровать (или на входе или выходе): коды

• C0 управления 0x00 к 0x19 (помимо вкладки, пространства, новой линии, провозная возврат)
• 0x7F
• C1 коды управления 0x80 до 0xBF
• (возможно) любая точка выше код 0x10FFFF

Answer 2

В W3C пропускает эти символы в их примере регулярное выражение в Multilingual form encoding:

$field =~ 
    m/\A(
    [\x09\x0A\x0D\x20-\x7E]   # ASCII 
    | [\xC2-\xDF][\x80-\xBF]    # non-overlong 2-byte 
    | \xE0[\xA0-\xBF][\x80-\xBF]  # excluding overlongs 
    | [\xE1-\xEC\xEE\xEF][\x80-\xBF]{2} # straight 3-byte 
    | \xED[\x80-\x9F][\x80-\xBF]  # excluding surrogates 
    | \xF0[\x90-\xBF][\x80-\xBF]{2}  # planes 1-3 
    | [\xF1-\xF3][\x80-\xBF]{3}   # planes 4-15 
    | \xF4[\x80-\x8F][\x80-\xBF]{2}  # plane 16 
)*\z/x; 

Answer 3

No.

Это очень плохая идея, чтобы попытаться «предварительно чистой» ввод данных пользователем. То, что вы считаете «декоративным», может быть абсолютно необходимо читателям другого языка. Лучшее решение - хранить текст как есть в базе данных, а затем дезинфицировать его перед записью на страницу.

Answer 4

Когда вы говорите «таблицу ASCII», вы говорите о this page, не так ли? Эта страница - мусор. Только первые 128 символов (т. Е. 0,127) являются «ASCII»; сопоставления, которые они показывают для чисел 128..255, - это расширение ASCII, называемое cp437. Существует множество «расширенных ASCII», а cp437 - далеко не самый общий.

Но я отвлекся. Ваш вопрос не о кодировке символов, а о фильтрации, а фильтр должен основываться на свойствах символов: это буква, цифра, контрольный символ?Большинство современных языков программирования предоставляют методы или функции для получения такой информации, и большинство из них также обеспечивают поддержку регулярных выражений. Что касается , то, что вы должны фильтровать, или вы должны фильтровать вообще, только вы можете это знать.

Похоже, вам нужно больше узнать о кодировке символов и Unicode. Start here.