Какие допустимые управляющие символы в формах HTML / XHTML - PullRequest
0 голосов
/ 02 июня 2009

Я пытаюсь создать модуль проверки формы, который, помимо «регулярных» проверок, проверяет а также кодирование.

Согласно этой статье http://www.w3.org/International/questions/qa-forms-utf-8 допустимыми символами являются CR, LF и TAB в диапазоне от 0 до 31, DEL = 127 не допускается.

С другой стороны, есть контрольные символы в диапазоне 0x80-0xA0. В разных источниках Я видел, что им разрешено, а что нет. Также я видел, что это отличается для XHTML, HTML и XML.

В некоторых статьях говорилось, что FF также разрешен?

Может ли кто-нибудь дать хороший ответ с источниками, что можно дать, а что нет?

РЕДАКТИРОВАТЬ: Даже там http://www.w3.org/International/questions/qa-controls некоторая двусмысленность

Поддерживается диапазон C1

Но из таблицы видно, что они недопустимы, и предыдущие показанные проверки UTF-8 позволяют им?

Ответы [ 8 ]

7 голосов
/ 12 июня 2009

Я думаю, что вы смотрите на это неправильно. Ресурсы, на которые вы ссылаетесь, указывают, какие закодированные значения действительны в (X) HTML , но похоже, что вы хотите проверить «ответ» из веб-формы - как, например, значения различных элементов управления формы, как передано обратно на ваш сервер. В этом случае вы должны смотреть не на то, что действительно в (X) HTML, а на то, что действительно в application / x-www-form-urlencoded и, возможно, также multipart / form- данные , MIME типы. В стандартах HTML 4.01 для <FORM> элементов четко указано, что для application / x-www-form-urlencoded "не буквенно-цифровые символы заменяются на"% HH "":

Это тип содержимого по умолчанию. Формы, представленные с этим типом содержимого, должны быть закодированы следующим образом:

  1. Имена и значения элементов управления экранированы. Символы пробела заменяются на «+», а затем зарезервированные символы экранируются, как описано в [RFC1738] , раздел 2.2: не буквенно-цифровые символы заменяются на «% HH», знак процента и две шестнадцатеричные цифры представляющий ASCII-код символа. Разрывы строк представляются в виде пар "CR LF" (т. Е. `% 0D% 0A ').
  2. Имена / значения элементов управления перечислены в порядке их появления в документе. Имя отделяется от значения символом '=', а пары имя / значение отделяются друг от друга знаком '&'.

Что касается того, какая кодировка символов содержится (т. Е. Является ли %A0 неразрывным пробелом или ошибкой), это согласовывается атрибутом accept-charset вашего элемента <FORM> и ответ (ну, на самом деле GET или POST запрос) Content-Type заголовок.

6 голосов
/ 10 июня 2009

Закон Постеля: будь консервативен в том, что делаешь; будь либеральным в том, что ты принимаешь от других.

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

1 голос
/ 20 октября 2010

Символы Юникода в этих диапазонах действительны в HTML 4.01:

0x09..0x0A
0x0D
0x20..0x7E
0x00A0..0xD7FF
0xE000..0x10FFFF    

В XHTML 1.0 ... неясно. Смотри http://cmsmcq.com/2007/C1.xml#o127626258

1 голос
/ 10 июня 2009

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

Это цитата из второй ссылки:

HTML, XHTML и XML 1.0 не поддерживают диапазон C0, кроме HT (Горизонтальная табуляция) U + 0009, LF (Перевод строки) U + 000A и CR (каретка Вернуться) U + 000D. Диапазон С1 поддерживается, т.е. вы можете кодировать контролирует напрямую или представляет их как NCR (ссылки на цифровые символы).

То, как я читаю это:

Любой управляющий символ в диапазоне C1 поддерживается, если вы кодируете их (используя представления base64 или Hex) или представляете их как NCR.

В диапазоне C0 поддерживаются только U + 0009, U + 000A и U + 000D. Никакой другой контрольный код в этом диапазоне не может быть представлен.

1 голос
/ 07 июня 2009

Прежде всего, любой октет действителен. Упомянутое упомянутое регулярное выражение для последовательностей UTF-8 просто опускает некоторые из них, поскольку на практике они довольно редки для ввода пользователем. Но это не значит, что они недействительны. Они просто не ожидаются.

0 голосов
/ 10 июня 2009

Правильно ли я понимаю ваш вопрос: вы хотите проверить, правильны ли данные, представленные в форме, и правильно ли они закодированы?

Если так, то почему несколько вещей одновременно? Было бы намного проще разделить эти проверки и выполнять их шаг за шагом, ИМХО.

  1. Вы хотите проверить, что данные отправленной формы правильно закодированы (в UTF-8, я понимаю). Как говорит арх. Канцлер Ридкулли, это легко проверить на большинстве языков.
  2. Затем, если кодировка верна, вы можете проверить, правильные ли это данные формы.
  3. Затем, если данные формы верны, вы можете проверить, содержат ли данные то, что вы ожидаете.
0 голосов
/ 10 июня 2009

Какой язык программирования вы используете? По крайней мере, для Java существуют библиотеки для проверки кодировки строки (или байтового массива). Я полагаю, что подобные библиотеки существуют и для других языков.

0 голосов
/ 02 июня 2009

Если документ известен как XHTML, вам следует просто загрузить его и проверить его по схеме.

...