Java: Русские буквы и не только…

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

Java: Русские буквы и не только…

Курсовой проект

Компьютеры, программирование

Другие курсовые по предмету

Компьютеры, программирование

Сдать работу со 100% гаранией
метров имя кодировки (или, если вы уверены в текущей кодировке броузера, использовать предопределённую кодировку) и использовать метод перекодировки символов:

public void doPost(HttpServletRequest request,HttpServletResponse response)

throws ServletException, IOException

{

// Кодировка сообщений, использованная engine

// Некоторые используют ISO-8859-1, некоторые кодировку

// по умолчанию - единообразия тут нет

String requestEnc = "ISO-8859-1";

// Кодировка, установленная в броузере

String clientEnc = request.getParameter("charset");

if( clientEnc==null ) clientEnc="Cp1251";

// Получение параметра

String value = request.getParameter("value");

//

if( value!=null )

value = new String(value.getBytes(requestEnc),clientEnc);

...

JSP

Технология JSP (Java Server Pages) очень похожа на сервлеты. По сути дела сервер, при запросе в первый раз на лету генерит из jsp-страниц код сервлета, компилирует его и запускает его как обычный сервлет. Поэтому у JSP возникают схожие проблемы при работе с русскими буквами. Однако решаются они немного по другому. Есть три места где могут возникнуть трудности - русские буквы внутри самой jsp-страницы, в ответе клиенту и в запросе от клиента. Первые два решаются заданием в начале страницы тега page:

<%@page contentType="text/html;charset=Windows-1251" %>

Увидев эту директиву сервер понимает, что страница записана в указанной кодировке, и что в сгенерённый код надо добавить вызов response.setContentType() с указанным contentType. Если сервер поддерживает спецификацию Servlet 2.3, то он также добавит и вызов request.setCharacterEncoding() с нужной кодировкой, таким образом автоматом решая и третью проблему. Для более старых серверов для раскодирования параметров в запросе клиента надо применять ухищрения, аналогичные описанным в разделе по сервлетам.

Для примера, для того, чтобы настроить JSP-форум Jive для работы с русскими буквами надо откорректировать следующие файлы:

/jive/header.jsp

/jive/admin/header.jsp

В них надо в начало добавить строчку

<%@page contentType="text/html;charset=UTF-8" %>

Вместо UTF-8 можно использовать любую кодировку, поддерживающую русские буквы - всё зависит от вкусов и предпочтений. Информацию об этом прислал Алексей Епишкин, за что ему отдельное спасибо.

В некоторых серверах встречаются баги, связанные с русскими буквами в JSP. Например, сервер Orion не любит русскую букву "Т" - он вместо неё в сгенерённый сервлет подставляет символ кавычки. Там во внутренностях есть примерно такой код:

...

switch( charstring.c1(i) )

...

public final char c1(int i)

{

if(i < 0 || i >= length)

throw new StringIndexOutOfBoundsException(i);

else

return (char)(data[offset + i] & 0xff);

data - это массив типа char[]. Как видно, ошибка тут тривиальна - разработчик почему-то был уверен что символы с кодами больше 255 - это ошибка природы. :-)

JavaMail

Пакет JavaMail предназначен для работы с электронными письмами. При помощи этого пакета Вы можете отправлять и принимать письма через различные протоколы. Разные протоколы по разному обрабатывают национальные символы. Самые распространённые на данный момент протоколы Internet основаны на старом стандарте RFC-822. Согласно этому стандарту в служебных полях (заголовках) писем разрешено посылать только символы кодировки ASCII, т.е. только латинские буквы (первые 128 символов Unicode). Очевидно, что это неудобно, т.к. часто очень хочется писать, например в поле Subject (тема письма) или в полях From/To (имя и адрес отправителя/получателя) русский текст. Для того, чтобы решить эту проблему был придуман стандарт кодирования MIME (RFC 2047). Он позволяет в некоторых полях заголовка (не во всех) использовать национальные символы при помощи специального кодирования (Base64 или QuotedPrintable).

Для представления писем в JavaMail используется класс javax.mail.Message. Это абстрактный класс, реальное же поведение определяется наследниками. Методы, определённые в нём работают только с обычными Java-строками (String). Для протоколов Internet обычно используется наследник javax.mail.internet.MimeMessage, который помимо базовых методов добавляет методы, в которых можно дополнительно указывать кодировку, которую следует использовать для писем. Для кодирования используется вспомогательный класс javax.mail.internet.MimeUtility. Класс MimeMessage обычно сам обращается к нему для кодирования/раскодирования заголовков, но, если Вы напрямую обращаетесь к заголовкам (методы getHeader()/setHeader()/addHeader()), то для их кодирования/раскодирования Вам придётся обращаться к методам MimeUtility самому.

Если Вы не указываете кодировку письма, то будет использована кодировка по умолчанию - обычно используется file.encoding, но её можно перекрыть специальной системной настройкой "mail.mime.charset". Это разумно, т.к. часто кодировка по умолчанию в системе отличается от стандартной кодировки Internet. Для русскоязычных писем в Internet стандартом де-факто стала кодировка КОИ-8. Вы, конечно, можете указать и другую, но шанс, что принимающая сторона не сможет прочитать такое письмо очень велик.

Надо учитывать также, что в JavaMail различаются два стандарта наименования кодировок - стандарт MIME и стандарт Java. Для большинства кодировок имена MIME уже поддерживаются в Java при помощи механизма синонимов. Например, для кодировки "Cp1251" (название Java) существует синоним "Windows-1251" (название MIME). Для тех кодировок, для которых такие синонимы отсутствуют, они поддерживаются внутри JavaMail. Для этого загружается файл javamail.charset.map из подкаталога "/META-INF" из того jar-файла, откуда был загружен пакет JavaMail. Для указания кодировки при вызове методов JavaMail следует использовать только MIME-имена, в противном случае получатель не сможет распознать использованную кодировку (если только на другом конце не тоже Java :-).

Вот простой пример отправки письма при помощи JavaMail:

import java.util.Properties;

import javax.mail.Session;

import javax.mail.Message;

import javax.mail.Transport;

import javax.mail.internet.MimeMessage;

import javax.mail.internet.InternetAddress;

public class MailTest

{

static final String ENCODING = "koi8-r";

static final String FROM = "myaccount@mydomail.ru";

static final String TO = "myaccount@mydomail.ru";

public static void main(String args[]) throws Exception

{

Properties mailProps = new Properties();

mailProps.put("mail.store.protocol","pop3");

mailProps.put("mail.transport.protocol","smtp");

mailProps.put("mail.user","myaccount");

mailProps.put("mail.pop3.host","mail.mydomail.ru");

mailProps.put("mail.smtp.host","mail.mydomail.ru");

Session session = Session.getDefaultInstance(mailProps);

MimeMessage message = new MimeMessage(session);

message.setFrom(new InternetAddress(FROM));

message.setRecipient(Message.RecipientType.TO, new InternetAddress(TO));

message.setSubject("Тестовое письмо",ENCODING);

message.setText("Текст тестового письма",ENCODING);

Transport.send(message);

}

}

XML/XSL

При разработке формата XML особое внимание уделялось поддержке различных кодировок символов. Для указания того, какая кодировка была использована используется заголовок XML-документа. Пример:

<?xml version="1.0" encoding="Windows-1251"?>

Если кодировка указана не была, то по умолчанию предполагается кодировка UTF-8. На XML-парсер возложена обязанность корректно прочитать заголовок и использовать соответствующую кодировку для получения Unicode-символов. Разные парсеры могут поддерживать разные наборы кодировок, но UTF-8 обязаны поддерживать все. Здесь также, как и в случае с JavaMail наименования кодировок, описанные в стандарте XML могут расходится с наименованиями, принятыми в Java. Разные парсеры по разному выходят из положения. Crimson просто использует некоторое кол-во дополнительных синонимов, а в остальном полагается на синонимы кодировок из Java. Xerces же по умолчанию использует внутреннюю таблицу (класс org.apache.xerces.readers.MIME2Java), а если не находит там кодировку, то бросает исключение о неподдерживаемой кодировке. В Xerces версии 1.4.0 русских кодировок там всего две - KOI8-R и ISO-8859-5. Однако это поведение по умолчанию можно изменить при помощи разрешения у парсера специального feature "http://apache.org/xml/features/allow-java-encodings". Если этот feature разрешён (при помощи метода setFeature()), то парсер после поиска в таблице будет пытаться использовать стандартный Java-вский механизм и соответственно Java-вский набор кодировок. В случае использования интерфейса SAX сделать это можно таким, например, образом (при использовании JAXP):

SAXParserFactory parserFactory = SAXParserFactory.newInstance();

SAXParser parser = parserFactory.newSAXParser();

parser.getXMLReader().setFeature("http://apache.org/xml/features/allow-java-encodings",true);

Для DOM, к сожалению, подобного механизма feature-ов не предусмотрено, но мож

Похожие работы

<< < 1 2 3 4 5 6 7 8 9 > >>