==================================
При разработке приложений Java очень часто появляются искаженные символы. В конце концов, Unicode сейчас не широко используется в системе, использующей gb2312 (включая упрощенный gbk и традиционный big5),
это самое основное требование для правильной реализации китайского отображения и отображения. хранилище базы данных.
=============================
1. Во-первых, разработчик должен понять, почему он сталкивается с искаженным кодом и с каким именно искаженным кодом он сталкивается (бессмысленные символы, строка вопросительных знаков или что-то еще).
Новички обычно теряются, когда сталкиваются с кучей беспорядочных символов. Самая прямая реакция — открыть Google и выполнить поиск по запросу «java Chinese» (эта строка часто запрашивается в поисковых системах),
а затем просмотреть символы других людей один за другим. одно. В этом нет ничего плохого, но достичь цели сложно по причинам, указанным ниже.
Короче говоря, причин искажения символов много, а решения совершенно разные. Чтобы решить проблему, необходимо сначала проанализировать собственный «контекст».
===========================
2. Конкретно какая информация нужна для определения источника искаженного кода в проекте.
а. Операционная система, используемая разработчиком.
b, имя и версия контейнера j2ee
c, имя базы данных, версия (точная версия) и версия драйвера jdbc.
d. Искаженный исходный код (например, исходящий из системы или на странице jsp. Если он находится на jsp, объявление заголовка также очень важно)
==========. === ============================================
3. Как изначально проанализировать причины искажения символов.
Используя приведенную выше информацию, вы можете обратиться за помощью. Я считаю, что если вы разместите ее на таких форумах, как Javaworld, эксперты вскоре найдут для вас эффективные решения.
Конечно, не всегда можно рассчитывать на помощь в публикации, но попытаться решить проблему самостоятельно тоже стоит. Как начать?
а. Проанализируйте, какая кодировка у вас «искаженный код». Это на самом деле не сложно, например
System.out.println(testString);
В этом абзаце есть искаженный код, поэтому вы можете использовать исчерпывающий метод, чтобы угадать его фактический формат кодировки.
System.out.println(new String(testString.getBytes(»ISO-8859-1″)»,gb2312″));
System.out.println(new String(testString.getBytes(»UTF8″)»,gb2312″));
System.out.println(new String(testString.getBytes(»GB2312″)»,gb2312″));
System.out.println(new String(testString.getBytes("GBK"),"gb2312"));
System.out.println(new String(testString.getBytes("BIG5"),"gb2312"));
Подождите, приведенный выше код означает использование указанного формата кодировки для чтения «искаженного кода» testString и преобразования его в gb2312 (здесь в качестве примера используется только китайский язык)
Затем вы увидите, какой преобразованный результат в порядке, вот и все. . .
б. Если вы можете получить правильный китайский, используя описанные выше действия, это означает, что ваши данные определенно есть, но они просто некорректно отображаются в интерфейсе. Затем вторым шагом является исправление вашей части просмотра
. Обычно необходимо проверить, выбрана ли правильная кодировка страницы в файле jsp.
Я хотел бы указать на то, что многие люди неправильно поняли, а именно на директиву <%@ page contentType="text/html; charset=GB2312″ %> и <META http-equiv=Content-Type
content="text". /html; charset= gb2312″>Разница между ними. Обычно, когда во многих статьях в Интернете упоминаются китайские проблемы, там говорится, что выбор хранилища unicode или gb2312 в базе данных можно решить
, используя
директиву page в jsp для объявления кодировки.Но я считаю это заявление очень безответственным, и оно заставило меня провести много времени в депрессии из-за искаженных кодов, которых изначально не существовало. Фактически, роль страницы
состоит в том, чтобы предоставить Java метод кодирования для «чтения» строки в выражении в процессе компиляции JSP в HTML (что-то похожее на роль третьего оператора выше), а
роль мета хорошо известен. Предоставляет параметры кодирования для браузеров IE, которые используются для «отображения» конечных данных. Но я не видел, чтобы кто-нибудь напоминал мне об этом. Я всегда использовал страницу в качестве мета,
в результате чего данные, которые изначально были в формате iso-8859, считывались командой страницы как gb2312, поэтому они были искажены, поэтому я добавил кодировку. функция преобразования для преобразования всех строковых данных. Все они изменились с iso8859 на gb2312 (
почему
я изменил это так, я тогда не особо задумывался, ведь это может отображаться нормально, поэтому я изменил это вот так, хаха). , у меня действительно тогда не было времени медленно устранять проблему).=============================================== =============
4. Какая кодировка лучше для базы данных?
В настоящее время популярные БД в основном включают sql-сервер, mysql, oracle, DB2 и т. д. Среди них MySQL является лидером среди бесплатных БД. Его производительность и функции признаны. Он относительно удобен в установке и настройке, а
соответствующий
драйвер также относительно удобен. Соотношение цена/качество абсолютное. Итак, возьмем MySQL в качестве примера.
Лично я рекомендую использовать для хранения кодировку mysql по умолчанию — iso-8859-1 (соответствует latin-1 в параметрах mysql). Есть несколько основных причин: во-первых, iso-8859-1 имеет хорошую поддержку
китайского языка
. Во-вторых, он соответствует кодировке по умолчанию в Java, что, по крайней мере, устраняет проблемы с преобразованием кодировки во многих местах. В-третьих, значение по умолчанию относительно. стабильный и совместимый.Стабильность также выше, поскольку
поддержка нескольких кодировок обеспечивается конкретными продуктами БД, не говоря уже о несовместимости с другими БД, даже разные версии самих себя могут иметь проблемы с совместимостью.
Например, в продуктах до версии mysql 4.0 многие китайские решения используют поле символаEncoding в соединении для установки кодировки, например gb2312 или что-то в этом роде. Это нормально,
поскольку исходные данные закодированы в формате ISO8859_1, а драйвер jdbc будет использовать указанный. в URL-адресе для кодирования используется набор символов, а resultSet.getString(*) извлекает закодированную
строку. Таким образом, вы можете напрямую получить данные gb2312.
Однако запуск MySQL 4.1 принес много проблем многим администраторам базы данных, поскольку MySQL 4.1 поддерживает набор символов уровня столбца. Для каждой таблицы и столбца можно указать кодировку
. Если она не указана, это будет ISO8895_1, поэтому после того, как jdbc удалит кодировку. data, он будет основан на столбце. Набор символов используется для кодирования вместо использования глобального параметра для получения всех данных.
Это показывает и с другой стороны, что проблема искаженных символов действительно сложна и имеет слишком много причин. Я просто предлагаю некоторые решения реальной ситуации, с которой я столкнулся. Если есть какие-либо
ошибки
, отправьте электронное письмо по адресу [email protected] . Я надеюсь увидеть больше собственных статей мастера, а не кучу фальшивых копий.
Только для внутреннего использования.
По любым вопросам обращайтесь по адресу [email protected].
=============================================== ==============
Наконец-то найдено самое идеальное решение китайской проблемы. . . Спасибо автору статьи онлайн. . .
Моя оригинальная статья основана на моем собственном опыте. Хотя все было в порядке, конечная причина проблемы так и не была найдена. Прочитав эту статью, я вдруг понял, хаха,
————————————————————————————————————————————— ———— ——————-
Поскольку китайская проблема в программировании на Java является распространенной проблемой, после прочтения множества решений китайских проблем на Java в сочетании с практикой программирования автора я обнаружил, что многие из методов, обсуждавшихся в прошлом, не могут четко объяснить Проблема и решение проблемы, особенно китайской проблемы при кроссплатформенности.
Поэтому я опубликовал эту статью, которая включает в себя мой анализ и предлагаемые решения китайских проблем в классах, сервлетах, классах JSP и EJB, работающих на консоли. Надеюсь, вы дадите мне несколько советов.
Аннотация: В этой статье глубоко анализируется процесс кодирования/декодирования исходных файлов Java компилятором Java и файлов классов JVM в программировании на Java. Наконец, раскрывается основная причина китайских проблем в программировании на Java. Дан предлагаемый оптимальный метод решения Java-китайских задач.
1. Источник китайской проблемы
. Кодировка, поддерживаемая исходной операционной системой компьютера, была однобайтовой кодировкой символов. Поэтому все программы обработки на компьютере изначально обрабатывались на английском языке с однобайтовой кодировкой.
С развитием компьютеров, чтобы адаптироваться к языкам других народов мира (включая, конечно, наши китайские иероглифы), люди предложили кодировку UNICODE, которая использует двухбайтовую кодировку и совместима с английскими символами. и двухбайтовые кодировки символов других стран. Поэтому в настоящее время большая часть международного программного обеспечения использует внутреннюю кодировку UNICODE. Когда программное обеспечение работает, оно получает формат кодировки, поддерживаемый по умолчанию местной системой поддержки (в большинстве случаев операционной системой). ), а затем преобразует UNICODE в программном обеспечении в формат кодировки, поддерживаемый локальной системой по умолчанию. Формат отображается.
Это относится к Java JDK и JVM. JDK, о котором я здесь говорю, относится к международной версии JDK. Большинство наших программистов используют интернационализированную версию JDK. Все следующие JDK относятся к интернационализированной версии JDK. Наши китайские иероглифы представляют собой язык двухбайтовой кодировки. Чтобы компьютеры могли обрабатывать китайский язык, мы разработали собственные стандарты, такие как gb2312, GBK и GBK2K, отвечающие потребностям компьютерной обработки.
Поэтому, чтобы адаптироваться к нашим потребностям в обработке китайского языка, большинство операционных систем имеют специальные китайские операционные системы. Они используют форматы кодировки GBK и GB2312 для правильного отображения наших китайских символов. Например: Китайская Windows по умолчанию использует для отображения кодировку GBK. При сохранении файлов в китайской Windows 2000 для сохранения файлов также используется формат кодировки GBK. То есть внутренняя кодировка всех файлов, сохраненных в китайской Windows 2000, использует GBK. кодировка по умолчанию. Примечание. GBK расширен на основе GB2312.
Поскольку язык Java использует внутреннюю кодировку UNICODE, при запуске программы Java возникает проблема преобразования входных и выходных данных из кодировки UNICODE и соответствующего формата кодировки, поддерживаемого операционной системой и браузером. Этот процесс преобразования состоит из ряда шагов. Если на каком-либо из шагов произойдет ошибка, отображаемые китайские символы будут искажены. Это наша распространенная проблема с китайским языком Java.
В то же время Java является кроссплатформенным языком программирования, а это означает, что программы, которые мы пишем, могут работать не только на китайских Windows, но также на китайских Linux и других системах. мы часто видим, как кто-то пересадил Java-программу, написанную на китайской Windows 2000, для работы на английском Linux). Эта операция по трансплантации также принесет китайцам проблемы.
Кроме того, некоторые люди используют английские операционные системы и английские браузеры, такие как IE, для запуска программ с китайскими иероглифами и просмотра веб-страниц на китайском языке. Они сами не поддерживают китайский язык и также вызывают проблемы с китайским языком.
Почти все браузеры по умолчанию передают параметры в формате кодировки UTF-8 вместо китайской кодировки. Поэтому при передаче параметров на китайском языке также могут возникнуть проблемы, приводящие к искажению символов.
Короче говоря, вышеуказанные аспекты являются основными источниками проблем китайского языка в Java. Мы называем проблемы, вызванные неправильной работой программы по указанным выше причинам: Проблемы китайского языка Java.
2. Подробный процесс преобразования кодировки Java.
Наши общие программы Java включают следующие категории:
*Классы, которые запускаются непосредственно на консоли (включая классы визуального интерфейса).
*Классы кода JSP (Примечание: JSP — это вариант класса сервлетов).
*Сервелеты. class
* EJB class
* другие вспомогательные классы, которые нельзя запустить напрямую.
Эти файлы классов могут содержать строки на китайском языке, и мы часто используем первые три типа программ Java для прямого взаимодействия с пользователями для вывода и ввода символов, например: мы используем JSP. а сервлет получает символы, отправленные клиентом, и эти символы также включают китайские иероглифы. Независимо от роли этих классов Java, жизненный цикл этих программ Java выглядит следующим образом:
*Программисты выбирают подходящее программное обеспечение для редактирования в определенной операционной системе для реализации исходного кода программы и сохраняют его в операционной системе с расширением .Java. Например, мы используем Блокнот для редактирования исходной программы Java в китайской Windows 2000.
*Программисты используют Javac.exe в JDK для компиляции этих исходных кодов в классы .class (файлы JSP компилируются контейнером, вызывающим JDK).
* Запустите эти классы напрямую или разверните их в WEB-контейнере для запуска и вывода результатов.
Итак, как во время этих процессов JDK и JVM кодируют, декодируют и запускают эти файлы?
Здесь мы возьмем китайскую операционную систему Windows 2000 в качестве примера, чтобы проиллюстрировать, как кодируются и декодируются классы Java.
Первым шагом является использование программного обеспечения для редактирования, такого как Блокнот, для написания исходного файла программы Java (включая пять вышеупомянутых типов программ Java) в китайской Windows 2000. При сохранении файла программы он использует формат кодировки GBK, поддерживаемый операционная система по умолчанию (поддерживается операционной системой по умолчанию). Формат — формат file.encoding), образующий файл .Java, то есть перед компиляцией Java-программы наш исходный файл программы Java сохраняется в файле file.encoding. формат кодирования, поддерживаемый операционной системой по умолчанию. В исходной программе Java Содержит информационные символы на китайском языке и коды программ на английском языке, чтобы просмотреть системный параметр file.encoding, вы можете использовать следующий код:
public class ShowSystemDefaultEncoding;
{
public static void main(String[] args)
{
Кодировка строки =
System.getProperty("file.encoding");
System.out.println(кодировка);
}
}
На втором этапе мы используем файл Javac.exe JDK для компиляции нашей исходной программы Java. Поскольку JDK является международной версией, при компиляции мы не используем параметр -encoding для указания формата кодирования нашего исходного кода Java. программы, то Javac.exe сначала получает формат кодировки, используемый нашей операционной системой по умолчанию. То есть, если при компиляции Java-программы мы не указываем формат кодировки файла исходной программы, JDK сначала получает параметр file.encoding. операционной системы (которая сохраняет формат кодировки по умолчанию, например Windows2000, его значение — GBK), а затем JDK преобразует нашу исходную программу Java из формата кодирования file.encoding во внутренний формат UNICODE Java по умолчанию и помещает его в память.
Затем Javac компилирует преобразованный файл формата Unicode в файл класса .class. В это время файл .class закодирован в UNICODE и временно помещается в память. Затем JDK компилирует скомпилированный класс в кодировке UNICODE. сохраняется в нашей операционной системе и образует файл .class, который мы видим.
Для нас файл .class, который мы наконец получили, представляет собой файл класса, содержимое которого сохранено в формате кодировки UNICODE. В нашей исходной программе он содержит китайскую строку, но на данный момент он был преобразован в формат UNICODE через формат file.encoding. .
На этом этапе исходный файл программы JSP отличается. Для JSP процесс выглядит следующим образом: WEB-контейнер вызывает компилятор JSP. Компилятор JSP сначала проверяет, установлен ли формат кодировки файла в файле JSP. в файле JSP нет формата кодировки файла. Чтобы установить формат кодировки файла JSP, компилятор JSP вызывает JDK, чтобы сначала преобразовать файл JSP во временный класс сервлета, используя формат кодировки символов JVM по умолчанию (то есть формат по умолчанию). file.encoding операционной системы, в которой находится WEB-контейнер), а затем он компилируется в класс формата UNICODE и сохраняется во временной папке.
Например: в китайской Windows 2000 WEB-контейнер преобразует файл JSP из формата кодировки GBK в формат UNICODE, а затем компилирует его во временно сохраненный класс сервлета для ответа на запрос пользователя.
Третий шаг — запустить класс, скомпилированный на втором этапе, который разделен на три ситуации:
A. Классы, которые запускаются непосредственно на консоли
B. Классы EJB и поддерживающие классы, которые не могут быть запущены напрямую (например, классы JavaBean)
C. Код JSP и классы сервлетов
D. Между Java-программами и базами данных
Давайте рассмотрим эти четыре ситуации ниже.
О. В случае с классом, который запускается непосредственно на консоли
, для запуска этого класса сначала требуется поддержка JVM, то есть JRE должна быть установлена в операционной системе. Выполняемый процесс выглядит следующим образом: сначала Java запускает JVM. В это время JVM считывает файл класса, сохраненный в операционной системе, и считывает его содержимое в память. В это время память представляет собой класс формата UNICODE. а затем JVM запускает его. Если в это время этому классу необходимо получить пользовательский ввод, класс по умолчанию будет использовать формат кодирования file.encoding для кодирования строки, введенной пользователем, преобразования ее в Юникод и сохранения в памяти. (пользователь может установить формат кодирования входного потока).
После запуска программы сгенерированная строка (в кодировке UNICODE) возвращается в JVM. Наконец, JRE преобразует строку в формат file.encoding (пользователь может установить формат кодировки выходного потока) и передает ее в операционную систему. интерфейс дисплея и выводит его на интерфейс. Каждый из приведенных выше шагов преобразования требует правильного преобразования формата кодировки, чтобы в конце не появлялись искаженные символы. B. Классы EJB и вспомогательные классы, которые не могут быть запущены напрямую (например, классы JavaBean)
. Поскольку классы EJB и вспомогательные классы не могут быть запущены напрямую, они обычно не взаимодействуют напрямую с пользователями для ввода и вывода. Они часто взаимодействуют с другими классами. для ввода и вывода, поэтому после их компиляции на втором этапе они образуют класс, содержимое которого имеет кодировку UNICODE, и сохраняются в операционной системе до тех пор, пока не будет взаимодействия между ним и другими классами. потерянный во время процесса передачи параметров, он будет работать правильно.
C.
После второго шага кода JSP и класса сервлета файл JSP также преобразуется в файл класса сервлетов, но он не существует в каталоге классов, как стандартные сервлеты. Он существует во временном каталоге WEB-контейнера. , поэтому на этом этапе мы также рассматриваем его как сервлеты.
Для сервлетов, когда клиент запрашивает его, WEB-контейнер вызывает свою JVM для запуска сервлета. Сначала JVM считывает класс сервлета из системы и загружает его в память. В памяти находится код класса сервлета. UNICODE. Затем JVM запускает класс сервлета в памяти. Если сервлет запущен, ему необходимо принимать символы от клиента, такие как значения, введенные в форму, и значения, передаваемые в URL-адресе. время, если программа не настроена на прием. Если в качестве параметра используется формат кодировки, WEB-контейнер по умолчанию будет использовать формат кодировки ISO-8859-1, чтобы принять входящее значение и преобразовать его в формат UNICODE в JVM и сохраните его в памяти WEB-контейнера.
После запуска сервлета он генерирует выходные данные, а выходная строка имеет формат UNICODE. Затем контейнер напрямую отправляет строку формата UNICODE (например, синтаксис HTML, строку пользовательского вывода и т. д.), созданную запуском сервлета, клиенту. браузер и выводит его. Если пользователь указывает формат кодировки для вывода при отправке в это время, он будет выводиться в браузер в указанном формате кодировки. Если он не указан, он будет отправлен в браузер клиента в формате ISO-8859-. 1 кодировка по умолчанию.
D. Между программой Java и базой данных
Почти для всех драйверов базы данных JDBC форматом кодировки по умолчанию для передачи данных между программой Java и базой данных является ISO-8859-1. Поэтому наша программа передает данные в базу данных при хранении данных, содержащих китайский язык. В программе JDBC сначала преобразует данные в формате кодировки UNICODE внутри программы в формат ISO-8859-1, а затем передает их в базу данных. Когда база данных сохраняет данные, по умолчанию используется формат ISO-8859-1. Вот почему китайские данные, которые мы часто считываем в базе данных, искажены.
3. Несколько принципов, которые необходимо понимать при анализе распространенных проблем Java на китайском языке
. Во-первых, после приведенного выше подробного анализа мы ясно видим, что в жизненном цикле любой Java-программы ключевым процессом преобразования кодировки является: первоначальная компиляция в класс. file Транскодирование и окончательный процесс транскодирования, выводимые пользователю.
Во-вторых, мы должны понимать, что Java во время компиляции поддерживает следующие часто используемые форматы кодирования:
*ISO-8859-1, 8-битный, такой же, как 8859_1, ISO-8859-1, ISO_8859_1 и другие кодировки
*Cp1252, американский. Английская кодировка, такая же, как стандартная кодировка ANSI
*UTF-8, такая же, как кодировка Unicode
*GB2312, такая же, как gb2312-80, gb2312-1980 и другие кодировки
*GBK, такая же, как MS936, это расширение gb2312 и другие кодировки, такие как корейская, японская, китайская (традиционное письмо) и т. д. В то же время следует обратить внимание на соотношение совместимости между этими кодировками следующим образом:
кодировки Unicode и UTF-8 имеют взаимно однозначное соответствие. GB2312 можно считать подмножеством GBK, то есть кодировка GBK расширена на gb2312. В то же время кодировка GBK содержит 20902 китайских символа, а диапазон кодировки: 0×8140-0xfefe. Все символы могут быть сопоставлены с UNICODE2.0 «один к одному».
В-третьих, для файла исходной программы .Java, помещенного в операционную систему, во время компиляции мы можем указать формат кодирования его содержимого, в частности, используя -encoding. Примечание. Если исходная программа содержит китайские символы и вы используете -encoding для указания других символов кодировки, очевидно, произойдет ошибка.
Используйте -encoding, чтобы указать метод кодирования исходного файла: GBK или gb2312. Независимо от того, в какой системе мы компилируем исходную программу Java, содержащую китайские символы, проблем не возникнет. файл класса.
Затем нам должно быть ясно, что формат кодировки символов по умолчанию почти во всех WEB-контейнерах использует ISO-8859-1 в качестве значения по умолчанию. В то же время почти все браузеры по умолчанию используют UTF-8 при передаче параметров. .
Таким образом, хотя в нашем исходном файле Java указан правильный метод кодирования на входе и выходе, он все равно обрабатывается как ISO-8859-1 при запуске внутри контейнера.
4. Классификация китайских проблем и их рекомендуемые оптимальные решения.
Поняв вышеизложенные принципы обработки файлов Java, мы можем предложить набор предлагаемых оптимальных решений проблем с китайскими иероглифами. Наша цель: исходные программы Java, содержащие китайские строки или китайскую обработку, которые мы редактируем в китайской системе, могут быть перенесены в любую другую операционную систему для правильной работы после компиляции или могут быть скомпилированы в других операционных системах. Они работают правильно, могут корректно. передавать параметры на китайском и английском языках и может правильно передавать строки на китайском и английском языках в базу данных. Наша конкретная идея состоит в том, чтобы ограничить метод кодирования, чтобы он был корректным на входе и выходе перекодирования программы Java и там, где программа Java выполняет преобразование ввода и вывода вместе с пользователем.
Конкретные решения следующие:
1. Для классов, которые запускаются непосредственно на консоли
, в этом случае мы рекомендуем при написании программы, если вам необходимо получить ввод от пользователя, который может содержать китайский язык, или вывод, который может содержать китайский язык, программа должна использовать потоки символов, используемые для обработки ввода и вывода. В частности, применяются следующие типы потоков узлов, ориентированных на символы:
Для файлов: FileReader, FileWrieter,
типы потоков узлов с байтовой ориентацией: FileInputStream, FileOutputStream
Для памяти (массив). ): CharArrayReader,
CharArrayWriter Типы потоков узлов: ByteArrayInputStream, ByteArrayOutputStream.
Память (строка): StringReader, StringWriter.
Каналы
: PipedReader, PipedWriter.
Типы потоков байтовых узлов: PipedInputStream, PipedOutputStream.
Должны использоваться ориентированные потоки обработки ввода и вывода:
BufferedWriter, BufferedReader,
его потоки обработки байтового типа: BufferedInputeStream, BufferedOutputStream
, InputStreamReader, OutputStreamWriter,
его потоки обработки байтового типа: DataInputStream,
DataOutputStreamReader и InputStreamWriter, используемые для преобразования
.поток байтов в соответствии с указанным набором кодировок символов, например:
InputStreamReader in = new InputStreamReader(System.in, "GB2312"); OutputStreamWriter out = new OutputStreamWriter (System.out, "GB2312"); пример: следующий пример кодировки Java может соответствовать требованиям:
//Read.Java
импортировать Java.io.*;
общественный класс Читать
{
public static void main(String[] args)
бросаетIOException
{
Строка ул =
"nКитайский тест, это внутренняя жестко закодированная строка "+"ntest английский символ";
Строка строка = "";
BufferedReader стандартный ввод =
новый BufferedReader (новый
InputStreamReader(System.in»,gb2312″));
//Устанавливаем кодировку входного интерфейса на китайском языке
BufferedWriter стандартный вывод =
новый BufferedWriter(новый
OutputStreamWriter(System.out,gb2312″));
//Устанавливаем кодировку выходного интерфейса на китайском языке
stdout.write("Пожалуйста, введите:");
стандартный вывод.flush();
строка = stdin.readLine();
stdout.write("Это строка, введенная пользователем:"+strin);
stdout.write(строка);
стандартный вывод.flush();
}}
При этом при компиляции программы мы используем следующий метод:
Javac -encoding gb2312 Read.Java
2. Для классов EJB и классов поддержки, которые невозможно запустить напрямую (например, класс JavaBean),
поскольку сами эти классы используются другими классами. Вызов не взаимодействует напрямую с пользователем, поэтому для этого типа мы рекомендуем метод обработки: внутренняя программа должна использовать потоки символов для обработки китайских строк внутри программы (в частности, как в разделе выше), и в то же время в При компиляции класса используйте параметр -encoding gb2312, чтобы указать, что исходный файл закодирован в китайском формате.
3. Для класса сервлета
мы рекомендуем следующий метод:
при компиляции исходной программы класса сервлета используйте -encoding, чтобы указать кодировку GBK или GB2312, и используйте setContentType("text" объекта ответа в кодировке часть при выводе пользователю /html;charset=GBK»); или gb2312, чтобы установить формат кодировки вывода. Аналогично, при получении пользовательского ввода мы используем request.setCharacterEncoding(»GB2312″), независимо от того, какая операционная система. наш класс сервлета пересажен только на клиент. Если ваш браузер поддерживает китайский язык, он будет отображаться правильно. Вот правильный пример:
//HelloWorld.Java
пакет привет;
импортировать Java.io.*;
импортировать Javax.servlet.*;
импортировать Javax.servlet.http.*;
общедоступный класс HelloWorld
расширяет HttpServlet
{
публичная недействительная инициализация()
выдает ServletException
{
}
общественная пустота
(запрос HttpServletRequest,
Ответ HttpServletResponse)
выдает IOException, ServletException
{
request.setCharacterEncoding("GB2312");
//Устанавливаем формат входной кодировки
ответ.setContentType
("текст/html;кодировка=GB2312");
//Устанавливаем формат выходной кодировки
PrintWriter out = response.getWriter();
//Рекомендуется использовать вывод PrintWriter
out.println(»<hr>»);
out.println("Привет, мир!
Это создано Servlet!Test Chinese!");
out.println(»<hr>»);
}
public void doPost (запрос HttpServletRequest,
Ответ HttpServletResponse)
выдает IOException, ServletException
{
request.setCharacterEncoding("GB2312");
//Устанавливаем формат входной кодировки
ответ.setContentType
("текст/html;кодировка=GB2312");
//Устанавливаем формат выходной кодировки
Имя строки = request.getParameter("имя");
Идентификатор строки = request.getParameter("id");
if(name==null) name="";
если (id==null) id="";
PrintWriter out = response.getWriter();
//Рекомендуется использовать вывод PrintWriter
out.println(»<hr>»);
out.println("Введенная вами китайская строка: " + name);
out.println("<hr>Введенный вами идентификатор: " + id);
out.println(»<hr>»);
}
общественная пустота уничтожить()
{
}
}
Пожалуйста, используйте Javac-кодировку gb2312 HelloWorld.Java для компиляции этой программы.
Программа для тестирования этого сервлета выглядит следующим образом:
< %@page contentType="text/html;
набор символов=gb2312″%>
<%request.setCharacterEncoding("GB2312");%>
<html><head><title></title>
<Язык сценария="JavaScript">
функция Отправить()
{
//Передаем строковое значение на китайском языке сервлету через URL-адрес
документ.база.действие =
"./HelloWorld?name=中文";
document.base.method = «POST»;
документ.база.submit();
}
</скрипт>
</head>
<body bgcolor="#FFFFFF"
text="#000000″ topmargin="5″>
<form name="base" метод =
«POST» target="_self">
<input name="id" type="text"
значение=”” размер=”30″>
<a href = «JavaScript:Submit()»>
Перейти к сервлету</a>
</form></body></html>
4.
Во избежание искажения данных при передаче данных между Java-программой и базой данных мы рекомендуем следующие оптимальные методы обработки:
1. Java-программу следует обрабатывать согласно указанному нами методу.
2. Измените формат кодировки, поддерживаемый базой данных по умолчанию, на GBK или GB2312.
Например: для достижения этой цели в mysql мы можем добавить следующий оператор в файл конфигурации my.ini:
добавьте:default-character-set=gbk
в область [mysqld]
и добавьте:
[client]
default-character-set=gbk
В SQL Server2K для достижения этой цели в качестве языка базы данных по умолчанию можно установить упрощенный китайский.
5. Для кода JSP,
поскольку JSP динамически компилируется WEB-контейнером во время выполнения, если мы не укажем формат кодировки исходного файла JSP, компилятор JSP получит значение file.encoding операционной системы сервера для компиляции JSP-файл. Да, скорее всего, это вызовет проблемы при пересадке. Например, jsp-файл, который хорошо работает в китайской Windows 2000, не будет работать в английском Linux, даже если клиенты те же. JSP-файла при его компиляции Вызвано разными кодировками операционных систем (file.encoding в китайском языке отличается от file.encoding в английском Linux, а file.encoding в английском Linux не поддерживает китайский язык, поэтому будут проблемы с файлом JSP при его компиляции. скомпилированный класс JSP).
Большинство проблем, обсуждаемых в Интернете, являются именно такими проблемами, в основном потому, что JSP-файл не может корректно отображаться при пересадке на платформу. Для такого рода задач мы понимаем принцип преобразования кодировки программы на Java, и это гораздо проще. решить это. Предлагаемые нами решения следующие:
1. Мы должны гарантировать, что JSP выводится в китайской кодировке при выводе клиенту, то есть, несмотря ни на что, мы сначала добавляем следующую строку в наш исходный код JSP:
< %@page contentType =» текст/html;
charset=gb2312″%>
2. Чтобы JSP корректно получал входящие параметры, добавляем в заголовок исходного файла JSP следующее предложение:
<%request.setCharacterEncoding(»GB2312″);
%>
3. Исходные файлы в заголовке исходного файла JSP
.
Или < %@page pageencoding = "gbk" %>
Это недавно добавленная инструкция в спецификации JSP 2.0.
Мы рекомендуем использовать этот метод для решения китайских проблем в файлах JSP
.
< %@Page Pageencoding = ”GB2312 ″ %>
< %@page contentype = "text/html;
charset = gb2312 ″%>
<%request.setcharacterencoding ("GB2312");
%>
<%
String action = request.getParameter ("action");
String name = "";
String str = "";
if (action! = null && action.equals ("Send"))
{
name = request.getParameter ("name");
str = request.getParameter ("str");
}
%>
<html>
<голова>
<title></title>
<Script language = "javascript">
функция отправить ()
{
document.base.action =
"Action = Send & Str = входящий китайский";
document.base.method = «post»;
document.base.submit ();
}
</скрипт>
</голова>
<body bgcolor = ”#ffffff»
Text = ”#000000 ″ Topmargin =” 5 ″>
<form name = "base" method =
«Post» target = ”_ self»>
<input type = ”text” name = ”name»
value = ”” size = ”30 ″>
<a href = «javaScript: supper ()»> отправить </a>
</форма>
<%
if (action! = null && action.equals ("Send"))
{
out.println ("<br> Введенные вами символы:"+name);
out.println ("<br> Персонажи, которые вы передали через URL:"+str);
}
%>
</тело>
</html>