Классические ASP gremlims, вставляющие в текст всякий раз, когда используется специальный символ HTML

Question

Я работаю над старым классическим ASP-сайтом, и есть форма, которая позволяет пользователю вводить некоторый текст (в многострочное текстовое поле), и если они добавляют HTML-символ, такой как & reg; (зарегистрировать товарный знак) он вставляет его правильно. Но когда они перейдут к редактированию данных, используя ту же форму, обновление добавит случайный «Â» (акцент на обводный круг) перед зарегистрированным товарным знаком. Тип контента - utf-8.

Есть идеи?

Спасибо за то, что вы дали это. Это сводит меня с ума. -m

Answer 1

Основной проблемой является влияние Response.Codepage на сообщения в форме.

Когда вы отправляете клиенту форму с указанием, что контент закодирован как UTF-8, браузер будет предполагать, что контент постов формы должен быть отправлен в кодировке UTF-8.

Теперь страница действий, которая получает сообщение, будет (несколько нелогично) использовать значение Response.Codepage, чтобы сообщить ему, как кодируются символы в сообщении. Это не очевидно, потому что мы склонны считать, что отправитель определяет кодировку того, что он отправляет. Также не является естественным скачком думать, что свойство, связанное с кодировкой того, что мы хотим отправить в нашем ответе, будет иметь какое-либо отношение к тому, как получен первоначальный запрос. В этом случае это так.

Что происходит, если ваша форма публикует версию символа в кодировке UTF-8, но на странице, которая получает, не задана страница Response.Code для 65001 (кодовая страница UTF-8). Вероятно, он установлен на системную кодовую страницу OEM, например 1252. Следовательно, кодировка UTF-8 для символа интерпретируется как два отдельных символа.

Мои рекомендации по хорошей обработке символов в ASP: -

• Сохранить все страницы как UTF-8
• Включить <% @ codepage = 65001 вверху всех страниц </li>
• Включить <% Response.CharSet = "UTF-8"%> вверху всех страниц
• Хранение опубликованных данных в типе поля Юникод, например, тип сервера SQL Server NVARCHAR.

Здесь важно то, что перед чтением значений формы на странице ASP необходимо убедиться, что для Response.Codepage задана кодовая страница, соответствующая кодировке отправителей, и это не происходит автоматически.

Answer 2

Я предполагаю, что используемый вами редактор не работает с UTF-8, а конвертирует все в ASCII.

Простой ответ - прекратить использование специальных символов на страницах HTML. Символ авторского права должен быть написан как © или ©.

Answer 3

Исходя из моего опыта с этой конкретной проблемой, я обнаружил, что эти символы появляются очень часто, потому что 1) пользователь использовал неанглийский набор символов (и клавиатуру), когда вводился контент (т.е. испанский), и 2) содержимое не было преобразовано в UTF-8. Вы на правильном пути, проверяя тип контента в заголовке, но вам действительно нужно запустить контент и через конвертер, если это будет продолжаться. Эта проблема доставляла мне много боли много лет назад из-за Classic ASP (хотелось бы, чтобы у меня все еще был доступ к коду для дальнейшей помощи).

Answer 4

® - это то, на что похоже, если оно хранится как UTF-8, но отображается как ASCII / ISO-8859-1 / Windows-1252. Использование тега meta недостаточно, чтобы убедиться, что ваша страница обслуживается как UTF-8. Вам также необходимо установить кодировку в HTTP-заголовке Content-Type. Этот заголовок обычно устанавливается с некоторыми настройками для всего сервера или программно.

Я не знаю ASP, но, похоже, вы должны установить этот заголовок:

HtmlEncode UTF-8

И это может предоставить дополнительную информацию:

http://technet.microsoft.com/en-us/library/bb742422.aspx#EBAA

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