Этот входной текст часто содержит символы, которые неверны для выходной кодировки, такие как «умные кавычки», которые взяты из документа в кодировке Windows-1252.
«Умные кавычки» (байты 147 и 148 в cp1252) — это вполне допустимые символы Юникода, U+201C и U+201D. Ваше приложение должно иметь возможность беспрепятственно их обрабатывать; если нет, то вы делаете что-то не так, и, скорее всего, все не-ASCII-символы не будут работать.
Независимо от того, пришли ли символы от кого-то, кто их напечатал, или кто-то вставил их из Word, браузер должен отправлять символы в кодировке UTF-8 в ваше приложение, которое должно хранить те же байты UTF-8 в базе данных.
Если браузер не отправляет в UTF-8, скорее всего, вы не можете установить кодировку HTML-страницы, содержащей форму. Это можно сделать с помощью:
Content-Type: text/html;charset=utf-8
Заголовок HTTP и/или:
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
элемент в ‹head>.
Могу ли я просто установить атрибут accept-charset в форме, и браузер сделает это за меня?
Нет, accept-charset в основном бесполезен благодаря IE, который неверно интерпретирует его как означающее «попробуйте использовать этот набор символов, если тот, что на странице, не может кодировать символы, которые нам нужны», вместо «всегда используйте этот набор символов». Это означает, что если вы используете accept-charset, вы можете получить смесь кодировок, отправленных одновременно, без возможности выяснить, какая из них какая. Ницца!
почему моя база данных принимает эти символы, которые являются зарезервированными/управляющими символами в UTF-8?
В MySQL UTF-8 — это просто сопоставление, используемое для сравнения и упорядочения. Он по-прежнему хранит данные в виде байтов, и ему все равно, являются ли они недействительными последовательностями UTF-8.
В любом случае рекомендуется декодировать и проверять входящие последовательности UTF-8 в вашем приложении, потому что «короткие последовательности», недопустимые в современном Unicode, могут скрывать символ «‹», который будет распознаваться более старыми браузерами (по крайней мере, до IE6). SP2, Опера 7).
Расчетное время прибытия:
Итак, я ввел строку, содержащую 146 байт
Нет, вы ввели символ Юникода U+201B. Браузер работает с символами Unicode, а не с байтами, вплоть до момента, когда он должен отправить сериализованную форму на сервер. Именно тогда он решает, как преобразовать символы в байты, и если страница обрабатывается как UTF-8, он всегда будет выбирать UTF-8.
(Если это не UTF-8, браузеры склонны обманывать несовместимым со стандартами способом: для всех символов, которые не вписываются в кодировку, они кодируются в ссылки на символы HTML, такие как '''. Это неправильно. потому что теперь вы не можете отличить экранированный браузером '&' от реального, введенного пользователем '&', и это коварно неправильно, потому что если вы затем повторите ссылку как неэкранированный HTML, это выглядит так, как будто вы его получаете правильно, что на самом деле вы только что сделали большую старую дыру в безопасности.)
В базу он вошел под номером 146.
Действительно, байт ‘\x92’, а не ‘\xC2\x92’, ‘\xE2\x80\x99’ или ‘’’?
он вышел, когда я создал (в кодировке UTF-8) XML, как 146. Нет жалоб от браузера
Тогда он не вышел как единый 146-байтный. Браузер будет жаловаться, если в XML-файле будет указано «\x92». (Не файл HTML, в котором недопустимые последовательности UTF-8 отображаются как глиф с отсутствующим символом.)
Я подозреваю, что это ссылка на символ '', которая имеет правильный формат (хотя символ U+0092 является частью набора элементов управления C1, поэтому он не будет отображаться как что-то полезное). Если это то, что происходит, ваша страница формы все-таки не воспринимается как UTF-8, и вы страдаете от описанной выше проблемы автоматического экранирования браузером.
person
bobince
schedule
15.04.2009
