Прежде всего стоит учесть, что оба UTF-8 и Windows-1252 (и ISO-8859-1 и другие) основаны на US-ASCII. Первые 128 символов во всех этих кодовых страницах идентичны. Используйте одно и то же значение байта, и все они занимают только один байт.
Во многих случаях подавляющее большинство контента находится в диапазоне US-ASCII, поэтому трудно сказать, есть ли разница между ними. Часто весь файл использует только символы US-ASCII, и, следовательно, файлы идентичны, несмотря на выбранную кодировку (возможно, сохраните спецификацию в начале файла).
Базовая обработка скриптов
Сначала процессор объединяет файл ASP со всеми включениями и включениями включений. Это делается очень просто, последовательно заменяя маркеры включения содержимым ссылочного файла включения. Это делается исключительно на уровне байтов, а не делается попытка конвертировать файлы разных кодировок.
Далее анализируется объединенная версия файла. токенизирован, «скомпилирован» даже в жесткий, дружественный к интерпретатору файл. В этот момент куски содержимого в файле (вещи вне блоков кода скрипта) превращаются в специальную форму Response.Write. Его особенность заключается в том, что в тот момент, когда выполнение сценария достигнет этих специальных записей, процессор просто копирует дословно байты, найденные в файле, непосредственно в выходной поток, и опять не делается никаких попыток преобразовать какие-либо кодировки.
Код скрипта и кодировка символов
Процессор ASP просто не справляется ни с чем, кроме ASCII. Весь ваш код и особенно строковые литералы в вашем коде должны быть только в ASCII.
Что может быть немного запутанным, когда скрипт выполняет все строковые переменные, хранящиеся с использованием кодировки Unicode.
Когда код записывает содержимое ответа, используя правильный метод Response.Write, здесь вступает в силу Response.CodePage. Он будет кодировать строку Unicode, которую скрипт предоставляет кодовой странице ответа, прежде чем добавить ее в выходной поток.
Каков эффект Response.CharSet
Добавляет атрибут CharSet в заголовок Content-Type http. Вот и все, это не имеет никакого другого влияния. Если установить этот один набор символов, но отправить другой, потому что либо ваш Response.CodePage не совпадает с ним, либо потому, что байтовое содержимое файлов не находится в этой кодировке, то вы можете ожидать проблем.
Кодировка ввода
Здесь все очень грязно. Когда данные формы публикуются на сервере, в стандарте кодировки URL-адреса отсутствует условие для объявления используемой кодовой страницы. Браузер может сказать, какую кодировку использовать, и он по умолчанию будет содержать кодировку html-страницы, содержащую форму, но нет механизма для передачи этого выбора серверу.
ASP считает, что кодовая страница опубликованных полей формы будет такой же, как кодовая страница ответа, который он собирается отправить. Потратьте немного времени на то, чтобы поглотить это ... Это означает, что довольно противное значение Response.CodePage оказывает влияние на строки, возвращаемые Request.Form. По этой причине важно установить правильную кодовую страницу заранее, выполнив некоторую обработку формы, а затем установив кодовую страницу позже, непосредственно перед отправкой ответа, что может привести к неожиданным результатам.
Классическая «веб-страница выглядит нормально, но данные в базе данных повреждены» получил
Одна распространенная ошибка, которая приводит к такому поведению, заключается в том, что разработчик установил CharSet = "UTF-8", но оставил кодовую страницу на что-то вроде "Windows-1252".
В конечном итоге пользователь вводит текст, который отправляется на сервер в кодировке UTF-8, но код сценария читает его как 1252. Эта поврежденная строка сохраняется в базе данных. Последующая веб-страница просматривает эти данные, поврежденную строку, полученную из БД. Эта строка затем отправляется response.write с использованием кодировки 1252, но целевой странице сообщается свой UTF-8. Это приводит к обращению коррупции, и все выглядит хорошо для пользователя.
Однако, когда другие компоненты, например, генератор отчетов, создают контент из базы данных, данные кажутся поврежденными, потому что это так.
Итог
Вы уже делаете правильные вещи, установите CharSet и CodePage заранее и последовательно. Если другие файлы не могут быть сохранены в формате UTF-8, у вас будут проблемы, если в них есть содержимое, отличное от ascii, но в противном случае у вас все будет хорошо.
Многие включают в себя asps - это чисто код без содержимого, и, поскольку этот код должен быть чисто в ascii, его кодировка не имеет значения.