Последние несколько дней я изучал кодировку UTF-8 и настолько растерян, что обсужу с вами свое мнение. Добро пожаловать, чтобы одобрить. Ниже приведены мои мысли. Если что-то не так, пожалуйста, просветите меня и помогите мне указать на это.
Сопутствующие отступления:
1. Операционная система
Вся оконная система внутри использует Unicode. Имена папок, имена файлов и т. д. имеют кодировку Unicode и могут нормально отображаться в любой языковой системе.
2. Метод ввода:
Вывод Microsoft Pinyin — это Юникод, а вывод Smart ABC — упрощенный китайский (поэтому Smart ABC вообще нельзя использовать в системах, не использующих упрощенный китайский язык, и можно вводить только на английском языке).
3. Текстовая область веб-страницы.
Текстовая область веб-страницы отображается в формате unicode. Поэтому все, что вы введете в него, будет отображаться. Но некоторые поля ввода, созданные во Flash, работать не будут.
4. Доступ2000
Данные, сохраненные в доступе, имеют формат Unicode и могут отображаться в любой языковой системе.
Если некоторые символы не являются нормальными при просмотре в представлении данных, это связано с тем, что шрифт, используемый для отображения, не является шрифтом Unicode.
Измените шрифт Arial Unicode MS, чтобы отобразить все. (доступ к справке, поиск, ввод юникода, инструкции доступны)
5. Слово
Преобразование между традиционным китайским и упрощенным китайским языком в Word. После преобразования из упрощенного китайского в традиционный китайский код по-прежнему остается упрощенным китайским. Фактически это просто символы традиционного китайского языка в упрощенном китайском языке.
6. ASP внутренне поддерживает Unicode, и весь текст хранится в Unicode. При необходимости преобразуйте в указанный набор символов.
Сначала сделаем вывод:
<%@ codepage=936%>Упрощенный китайский
<%@ codepage=950%>Традиционный китайский
<%@ codepage=65001%>UTF-8
Кодовая страница определяет кодировку, в которой IIS считывает переданную строку (отправка формы, передача адресной строки и т. д.).
Также указывает кодировку, в которую преобразуются все текстовые переменные из Unicode,
Он также определяет кодировку, в которую преобразуются данные, полученные из базы данных, из Unicode. (Обратите внимание, это очень важно.)
Ключевые слова:
Чтение: строка, если читать на упрощенном китайском, то это будет несколько символов, если читать на традиционном китайском, то будет несколько символов, кодировка самой строки не изменилась.
Преобразование: система активно преобразует, например, символ «化» Юникода в символ «化» Big5, внутренний код становится кодом Big5. Если в Big5 нет соответствующего слова, сохраняется форма Unicode (&#xxxx;).
Упрощенный китайский: шесть выводов
Шестнадцатеричная форма Unicode: шесть выводов
Десятичная форма Unicode: шесть выводов
Ниже приведен процесс преобразования кодировки, который я предположил:
Клиент: метод ввода Unicode -- поле ввода unicode -- конвертировать из Unicode в соответствующую кодировку по charset() -- формировать кодировку отправки
Серверная часть: IIS декодирует форму - читает в соответствии с кодировкой, указанной кодовой страницей - преобразует в соответствующий Unicode - может быть прочитан с помощью запроса ("") - выполняет некоторую обработку - сохраняет в базе данных в кодировке Unicode
На стороне сервера: прочитайте данные Unicode из базы данных и преобразуйте их в кодировку, указанную кодовой страницей --- сгенерируйте исходный код -- IE читает и отображает их в соответствии с кодировкой.
Вот несколько примеров:
Пример 1:
Предположим, есть три страницы asp, типичная страница сообщений:
1.write.asp — это простая форма ввода, которая передается в add.asp.
<META http-equiv="Content-Type" content="text/html; charset=big5">
2.add.asp получает сообщения и сохраняет их в базе данных.
<%@кодовая страница=936%>
3.read.asp получает сообщения из базы данных и отображает их.
<%@ codepage=936%> charset=GB2312 или
<%@ codepage=950%> charset=big5
Вы можете догадаться, что я использовал метод ввода Microsoft Pinyin для ввода «Обсуждение Хуа Лю» в write.asp. Что в итоге отобразится в read.asp?
У вас головокружение? Давайте проанализируем это с самого начала.
Пример 2:
Что произойдет, если мы изменим <%@ codepage=936%> в add.asp в примере 1 на <%@ codepage=950%>?
Что ты здесь нашел?
1. Если входной текст отличается от соответствующей кодировки, после преобразования могут появиться символы в форме Юникода. Вот почему. С этого момента весь процесс сохраняется.
2. Кодовая страница в Add.asp определяет текст, сохраняемый в базе данных, и язык, соответствующий Юникоду. Например, кодовая страница=936.
Затем база данных сохраняет Unicode упрощенного китайского языка (база данных возвращает систему упрощенного китайского языка, все нормально),
Кодовая страница = 950 сохраняет традиционный китайский Unicode (было бы неправильно возвращать систему упрощенного китайского языка).
3． Обратите внимание на процесс изменения строки:
1) Метод ввода --- CharsetUnicode ---- определяет отображение набора символов.
2) Кодировка ---- строка кодировки формы, простая кодировка
3) Процесс, обратный предыдущему этапу декодирования формы, два шага смещены.
4) Строка нажмите кодовую страницу, чтобы прочитать строку, и строка не изменилась. Этот шаг может вызвать «неправильное понимание чтения».
5) Преобразование в соответствующий набор символов, указанный в кодовой странице Unicode ---- сопоставление Unicode.
6) Промежуточная обработка, без изменений в базе данных, прямой ввод в форме Юникода.
7) Нажмите кодовую страницу, чтобы прочитать базу данных Unicode ---- сопоставление набора символов с указанной кодовой страницей.
8) Это показывает, что строка, прочитанная из набора символов, указанного в Charset, не изменилась.
Проиллюстрируем примером 1:
Пример 2:
Испытывающий головокружение. Теперь давайте применим полученные знания.
Случай 1.
Код, который хорошо работает в системе упрощенного китайского языка, искажается в базе данных при размещении в чужом пространстве, и исходные данные также искажаются.
Анализ: Поскольку большинство людей обычно используют упрощенную китайскую систему, кодовая страница по умолчанию = 936, поэтому не имеет значения, пишут ли ее не все.
Но когда мы выезжаем за границу, возникают космические проблемы. Юникод в базе данных был преобразован в английскую кодировку, поэтому после преобразования исходного упрощенного китайского языка в базе данных в английский отображение ГБ будет естественным образом искажено.
Как показано на картинке, вновь введенный текст отображается нормально, но английский Unicode сохраняется в базе данных.
Решение: добавьте ко всем <%@codepage=936%>.
Весь процесс включает только преобразование между упрощенным китайским языком и соответствующим Unicode.
Случай 2:
Что мне делать, если я хочу преобразовать код и данные упрощенного китайского языка в полную версию традиционного китайского языка?
Анализ: 1. Кодировка всех файлов кода изменена на Big5, а сам файл сохранен на традиционном китайском языке.
2. <%@ кодовая страница=936 %>
3.Кодировка=big5
4. Версия доступа не имеет значения, поскольку данные в доступе — Unicode.
5. Хорошо, код может работать в чисто традиционной китайской системе.
6. Остающиеся проблемы: при чтении исходных данных на упрощенном китайском языке будут появляться некоторые вопросительные знаки. Эффект тот же, что и при показании 950 в примере 1, дисплей big5. Поскольку Юникод упрощенного китайского языка преобразуется в традиционный китайский, некоторые символы не соответствуют традиционному китайскому языку, поэтому появляются вопросительные знаки.
7. Решение. Используйте временную страницу asp, кодовая страница = 65001, прочитайте ее как упрощенный китайский Unicode, используйте функцию Unicode->Big5, чтобы преобразовать ее в традиционный китайский, а затем записать ее обратно в базу данных. Это должно работать, верно?
Оба случая полностью выведены мной на основе теории и не подтверждены.
Критика и исправления приветствуются, если у вас есть подобный опыт.