Сегодня я использовал сценарий JavaScript для создания инструмента меню на странице ASP.NET и сохранил его как MenuScript.js. Используйте <script Language="javascript" src="../js/MenuScript.js"></script. на странице >Вызов, и во время работы произошло странное явление: китайские иероглифы на странице отображались нормально, но китайские иероглифы в меню отображались искаженно.
Не надо спрашивать, если подумать на коленях, что-то не так с кодировкой. Переключение между кодировками UTF-8 и GB2312 в опции "Вид"-"Кодировка" страницы. символы на странице и китайские иероглифы в меню попеременно искажаются.
Решение. В файле конфигурации есть настройки кодировки: <globalization requestEncoding="utf-8" responseEncoding="utf-8" />
При сохранении файла MenuScript.js есть опция кодировки (вы можете открыть этот файл с помощью Word и сохранить его как другой, выберите кодировку), просто сохраните две кодировки одинаковыми.
Чтобы лучше понять проблему кодирования, я нашел статью об этом в CSDN, автор: fmddlmyy. Перепечатайте его здесь для справки:
Поговорим о кодировании Давайте поговорим о кодировании #region Давайте поговорим о кодировании
/**//*
0. с прямым порядком байтов и прямым порядком байтов
с прямым порядком байтов и с прямым порядком байтов — это разные способы обработки многобайтовых чисел процессором. Например, кодировка символа «汉» в Юникоде — 6C49. Итак, при записи в файл следует писать впереди 6C или 49? Если впереди написано 6C, то это обратный порядок байтов. Или напишите впереди 49, что соответствует прямому порядку байтов.
Слово «эндиан» пришло из «Путешествий Гулливера». Гражданская война в лилипутии возникла из-за того, разбить яйца с большого конца (Big-Endian) или с маленького конца (Little-Endian). В результате произошло шесть восстаний, один из императоров погиб, а императоры погибли. другой потерял свой трон.
Обычно мы переводим порядок байтов как «порядок байтов», а прямой и прямой порядок байтов называются «большим концом» и «младшим концом».
1. Кодировка символов и внутренний код. Кстати, символы китайской кодировки должны быть закодированы, прежде чем они смогут быть обработаны компьютером. Методом кодирования по умолчанию, используемым компьютером, является внутренний код компьютера. Ранние компьютеры использовали 7-битную кодировку ASCII. Для обработки китайских символов программисты разработали GB2312 для упрощенного китайского языка и big5 для традиционного китайского языка.
GB2312 (1980 г.) содержит в общей сложности 7445 символов, включая 6763 китайских иероглифов и 682 других символа. Диапазон внутреннего кода области китайских символов составляет от B0-F7 в старшем байте до A1-FE в младшем байте, а занятые биты кода составляют 72*94=6768. Среди них 5 вакансий D7FA-D7FE.
GB2312 поддерживает слишком мало китайских иероглифов. Спецификация расширения китайских символов GBK1.0 1995 года включает 21 886 символов, которые разделены на область китайских символов и область графических символов. Область китайских символов включает 21 003 символа. GB18030 2000 года является официальным национальным стандартом, пришедшим на смену GBK1.0. Этот стандарт включает 27 484 китайских иероглифа, а также тибетский, монгольский, уйгурский и другие языки основных этнических меньшинств. Текущая платформа ПК должна поддерживать GB18030, и требований к встраиваемым продуктам нет. Поэтому мобильные телефоны и MP3 обычно поддерживают только GB2312.
Эти методы кодирования, от ASCII, GB2312, GBK до GB18030, обратно совместимы, то есть один и тот же символ всегда имеет одну и ту же кодировку в этих схемах, а более поздние стандарты поддерживают больше символов. В этих кодировках английский и китайский языки могут обрабатываться одинаково. Отличить китайскую кодировку можно по тому, что старший бит старшего байта не равен 0. Согласно тому, как их называют программисты, от GB2312 до GBK18030 все они принадлежат к двухбайтовым наборам символов (DBCS).
Внутренним кодом некоторых китайских Windows по умолчанию по-прежнему является GBK, который можно обновить до GB18030 с помощью пакета обновления GB18030. Однако символы, добавленные GB18030 по сравнению с GBK, сложны для использования обычными людьми. Обычно мы по-прежнему используем GBK для обозначения внутреннего кода Windows на китайском языке.
Вот еще некоторые подробности:
Исходный текст GB2312 по-прежнему является кодом города. От кода города до внутреннего кода необходимо добавить A0 к старшему и младшему байту соответственно.
В DBCS формат хранения внутреннего кода ГБ всегда имеет обратный порядок байтов, то есть старший бит идет первым.
Оба старших бита двух байтов GB2312 равны 1. Но этому условию удовлетворяют только 128*128=16384 кодовых точки. Следовательно, старший бит младшего байта GBK и GB18030 может быть не равен 1. Однако это не влияет на анализ потока символов DBCS: при чтении потока символов DBCS, если встречается байт со старшим битом 1, следующие два байта могут быть закодированы как двойной байт, независимо от младший байт. Что такое старшая позиция.
2. Юникод, UCS и UTF.
Как упоминалось ранее, методы кодирования от ASCII, GB2312, GBK до GB18030 обратно совместимы. Юникод совместим только с ASCII (точнее, с ISO-8859-1) и не совместим с кодом GB. Например, кодировка символа «汉» в Юникоде — 6C49, а код GB — BABA.
Unicode также является методом кодирования символов, но он разработан международной организацией и может использовать схемы кодирования для всех языков мира. Научное название Unicode — «Универсальный набор символов с многооктетной кодировкой», или сокращенно UCS. UCS можно рассматривать как аббревиатуру «Набор символов Юникода».
Согласно Википедии ( http://zh.wikipedia.org/wiki/ ): Исторически существовало две организации, которые пытались разработать Unicode независимо, а именно Международная организация по стандартизации (ISO) и ассоциация производителей программного обеспечения (unicode. орг). ISO разработала проект ISO 10646, а Консорциум Unicode разработал проект Unicode.
Примерно в 1991 году обе стороны признали, что миру не нужны два несовместимых набора символов. Поэтому они начали объединять работу обеих сторон и работать вместе над созданием единого списка кодирования. Начиная с Unicode2.0, проект Unicode использует те же шрифты и шрифты, что и ISO 10646-1.
Оба проекта до сих пор существуют и независимо друг от друга публикуют свои стандарты. Последней версией Консорциума Unicode является Unicode 4.1.0, выпущенная в 2005 году. Последний стандарт ISO — 10646-3:2003.
UCS определяет, как использовать несколько байтов для представления различного текста. Способ передачи этих кодировок определяется спецификацией UTF (формат преобразования UCS). Общие спецификации UTF включают UTF-8, UTF-7 и UTF-16.
В документах IETF RFC2781 и RFC3629 методы кодирования UTF-16 и UTF-8 четко, ясно и строго описаны в едином стиле RFC. Я всегда забываю, что IETF — это аббревиатура Internet Engineering Task Force. Однако RFC, поддерживаемый IETF, является основой для всех спецификаций в Интернете.
3. УКС-2, УКС-4, БМП
UCS поставляется в двух форматах: UCS-2 и UCS-4. Как следует из названия, UCS-2 кодируется двумя байтами, а UCS-4 — 4 байтами (фактически используется только 31 бит, старший бит должен быть равен 0). Давайте поиграем в простые математические игры:
UCS-2 имеет 2^16=65536 кодовых точек, а UCS-4 имеет 2^31=2147483648 кодовых точек.
UCS-4 разделен на 2^7=128 групп в соответствии со старшим байтом, причем старший бит равен 0. Каждая группа разделена на 256 плоскостей в зависимости от следующего старшего байта. Каждая плоскость разделена на 256 строк по третьему байту, каждая строка содержит 256 ячеек. Разумеется, ячейки в одной строке отличаются только последним байтом, а остальные одинаковы.
Плоскость 0 группы 0 называется базовой многоязычной плоскостью или BMP. Или в UCS-4 биты кода, у которых два старших байта равны 0, называются BMP.
UCS-2 получается путем удаления первых двух нулевых байтов BMP UCS-4. Добавьте два нулевых байта перед двумя байтами UCS-2, чтобы получить BMP UCS-4. В текущей спецификации UCS-4 нет символов, выделенных за пределами BMP.
4. Кодировка UTF UTF-8 кодирует UCS в 8-битных единицах. Кодировка UCS-2 в UTF-8 выглядит следующим образом:
Кодировка UCS-2 (шестнадцатеричная) Поток байтов UTF-8 (двоичный)
0000-007F 0xxxxxxx
0080-07FF 110xxxxxx 10xxxxxx
0800 – FFFF 1110xxxx 10xxxxxx 10xxxxxx
Например, кодировка Unicode символа «Китайский» — 6C49. 6C49 находится в диапазоне 0800-FFFF, поэтому необходимо использовать 3-байтовый шаблон: 1110xxxx 10xxxxxx 10xxxxxx. Запись 6C49 в двоичном формате: 0110 110001 001001. Используя этот битовый поток для замены x в шаблоне по очереди, мы получаем: 11100110 10110001 10001001, что равно E6 B1 89.
Читатели могут использовать Блокнот, чтобы проверить правильность нашего кода.
UTF-16 кодирует UCS в 16-битных единицах. Для кодов UCS меньше 0x10000 кодировка UTF-16 равна 16-битному целому числу без знака, соответствующему коду UCS. Для кодов UCS не менее 0x10000 определен алгоритм. Однако, поскольку BMP фактически используемых UCS2 или UCS4 должен быть меньше 0x10000, на данный момент можно считать, что UTF-16 и UCS-2 по сути одинаковы. Однако UCS-2 — это всего лишь схема кодирования, а UTF-16 используется для фактической передачи, поэтому необходимо учитывать вопрос порядка байтов.
5. Порядок байтов UTF и спецификация
UTF-8 использует байты в качестве единицы кодирования, и проблем с порядком байтов нет. UTF-16 использует два байта в качестве единицы кодирования. Прежде чем интерпретировать текст UTF-16, вы должны сначала понять порядок байтов каждой единицы кодирования. Например, полученная кодировка Unicode для «Kui» — 594E, а кодировка Unicode для «B» — 4E59. Если мы получим поток байтов UTF-16 «594E», это «Ку» или «Б»?
Рекомендуемый метод обозначения порядка байтов в спецификации Unicode — это спецификация. Спецификация — это не список спецификаций «Спецификации», а метка порядка байтов. Спецификация — это немного умная идея:
В кодировке UCS есть символ «ZERO WIDTH NO-BREAK SPACE», и его кодировка — FEFF. FFFE — это символ, которого нет в UCS, поэтому он не должен появляться в реальной передаче. Спецификация UCS рекомендует передавать символы «НУЛЕВАЯ ШИРИНА БЕЗ РАЗРЫВОВ» перед передачей потока байтов.
Таким образом, если получатель получает FEFF, это указывает на то, что поток байтов имеет обратный порядок байтов; если он получает FFFE, это указывает на то, что поток байтов имеет прямой порядок байтов; Поэтому символ «НУЛЕВАЯ ШИРИНА БЕЗ РАЗРЫВОВ» также называется спецификацией.
UTF-8 не требует спецификации для указания порядка байтов, но может использовать спецификацию для указания метода кодирования. Кодировка UTF-8 символа «ZERO WIDTH NO-BREAK SPACE» — EF BB BF (читатели могут проверить это, используя метод кодировки, который мы представили ранее). Таким образом, если получатель получает поток байтов, начинающийся с EF BB BF, он знает, что он закодирован UTF-8.
Windows использует спецификацию для обозначения кодировки текстовых файлов.
6. Дополнительные справочные материалы Основным справочным материалом для этой статьи является «Краткий обзор ISO-IEC 10646 и Unicode» ( http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html ).
Я также нашел две части информации, которые выглядели хорошо, но, поскольку у меня уже были ответы на мои первоначальные вопросы, я не стал их читать:
«Понимание Unicode. Общее введение в стандарт Unicode» ( http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a )
«Основы кодирования набора символов. Понимание кодировок набора символов и устаревших кодировок» ( http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03 )
Я написал пакеты программного обеспечения для преобразования UTF-8, UCS-2 и GBK друг в друга, включая версии, использующие Windows API, и версии, которые не используют Windows API. Если у меня будет время в будущем, я разберу это и выложу на своей личной домашней странице ( http://fmddlmyy.home4u.china.com ).
Я начал писать эту статью, обдумав все вопросы, и думал, что смогу закончить ее через некоторое время. Неожиданно для обдумывания формулировки и проверки деталей потребовалось много времени, и я писал ее с 1:30 до 9:00 дня. Надеюсь, что некоторые читатели смогут извлечь из этого пользу.
*/
#конечныйрегион