Здравствуйте, cl-user, Вы писали:


M>>Да я не становлюсь в позу=) Я просто проверил все на практике. Если не делать тех манипуляций с перекодировками то до сервера приходит строка в cp1251.

CU>Тебе уже 48 раз сказали — у строк (java.lang.String) кодировка прибита гвоздями — UTF-16.

Эээ, точно? Ткните в спецификацию где это написано. Так как строка это вообще ортогональное кодировке понятие, кто помешает сделать реализацию VM на представлении UTF-32? Для программ это вообще никак не изменит ничего(ну, памяти сожрет поболее, но на алгоритм не повлияет никак), если не увлекаться кастами char<->int и арифметическими операциями с ними.

Ну, и строго говоря, там не совсем честные UTF-16...

Здравствуйте, Eugeny__, Вы писали:

E__>Эээ, точно? Ткните в спецификацию где это написано.

по-моему, это следует из того, что внутри String мы видим

    /** The value is used for character storage. */
    private final char value[];

а формат char специфицирован.

с одной стороны, ничто не мешает сделать внтури String по-другому, с другой — при альтернативном подходе к реализации будет трудно эффективно поддержать основные методы этого класса

> Наткнулся на эту же проблему.
>
> во многих примерах рекомендуют
> message.getBytes("UTF-8") и получается нормальный массив байтов готовый
> для записи куда угодною Он корректный.
> запись проводить любым байтовым выводом
>
> но иногда есть соблазн выводить чуть более удобным способом, через
> BufferedWriter(new FileWriter(file))
> а тут нужна строка
> поэтому ошибочно делаем "неправильную" строку new
> String(message.getBytes("UTF-8"))
> а ее выводим...
> BufferedWriter out = new BufferedWriter(new FileWriter(file));
> out.write(xml);
>
> забавно, все здорово выводится кроме буквы И, сам от лени наткнулся на
> проблему.
>
> Но тут никто не гарантирует вывод не правильных пчел с неправильным медом.
> Поэтому вывод тока байтам и ему подобными способами без не правильных
> перекодировок.

Я понятия не имею что делает FileWriter... IMHO это он должен
позаботиться о правильной кодировке.

Вот такой вариант думаю подойдет.

FileOutputStream fos = new FileOutputStream(file); // Работаем с файлом
// как с байтовым потоком.

OutputStreamWriter osw = new OutputStreamWriter(fos, "UTF-8"); // На
// байтовый поток цепляем writer, и при этом конкретно указываем в какой
// кодировке должен получиться байтовый поток.

BufferedWriter bw =  new BufferedWriter(osw); // Собственно ваш
// буферизирующий writer.

// Но я бы буфер вешал на самый низ, где-нибудь вокруг fos.

Здравствуйте, Madjack, Вы писали:

M>Доброго времени суток.
M>При перекодировке строки в Cp1251 в кодировку UTF-8 возникает ошибка в букве И. Она кодируется как {-48, 63), а должна быть {-48, 104}.

Почитайте вот это: http://www.skipy.ru/technics/encodings.html

Здравствуйте, Аноним, Вы писали:

А>Поэтому вывод тока байтам и ему подобными способами без не правильных перекодировок.

Можно проще — разобраться, что такое кодировки и как с ними работать в Java. http://www.skipy.ru/technics/encodings.html

Здравствуйте, Eugeny__, Вы писали:

E__>Эээ, точно? Ткните в спецификацию где это написано.
E__>Ну, и строго говоря, там не совсем честные UTF-16...

Тыкаю:

http://java.sun.com/javase/6/docs/api/java/lang/String.html

A String represents a string in the UTF-16 format in which supplementary characters are represented by surrogate pairs (see the section Unicode Character Representations in the Character class for more information).

> Так как строка это вообще ортогональное кодировке понятие,

С каких пор? Строка содержит символы. А символы получаются из байтов с помощью кодировки. Один и тот же символ 'Ф' может быть представлен по-разному — сравните 0x04 0x24 (UTF-16), 0xD0 0xA4 (UTF-8), 0xD4 (Cp1251), 0xE6 (koi8-r), 0x94 (Cp866), 0xC4 (iso-8859-5). И какой из вариантов байтов должна хранить VM, если кодировка строки не прибита гвоздями?

> кто помешает сделать реализацию VM на представлении UTF-32?

Спецификация языка: http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.1

The Java programming language represents text in sequences of 16-bit code units, using the UTF-16 encoding. A few APIs, primarily in the Character class, use 32-bit integers to represent code points as individual entities. The Java platform provides methods to convert between the two representations.

Здравствуйте, Skipy, Вы писали:

S>Здравствуйте, Eugeny__, Вы писали:

E__>>Эээ, точно? Ткните в спецификацию где это написано.
E__>>Ну, и строго говоря, там не совсем честные UTF-16...

S>Тыкаю:

S>http://java.sun.com/javase/6/docs/api/java/lang/String.html

Да, здесь явно сказано. В более старой доке, которую мне сразу гугл выдал, этой строки нет.

>> Так как строка это вообще ортогональное кодировке понятие,

S>С каких пор? Строка содержит символы. А символы получаются из байтов с помощью кодировки. Один и тот же символ 'Ф' может быть представлен по-разному — сравните 0x04 0x24 (UTF-16), 0xD0 0xA4 (UTF-8), 0xD4 (Cp1251), 0xE6 (koi8-r), 0x94 (Cp866), 0xC4 (iso-8859-5). И какой из вариантов байтов должна хранить VM, если кодировка строки не прибита гвоздями?

Вот в том-то и дело, что строка — это последовательность символов. А кодировки — это представление символов в байтах. Понятно, что нужно как-то строку хранить в памяти компьютера. Но это никак не влияет на саму абстракцию.
Сейчас максимально удобно использовать UCS-16, потому в джаве и шарпе именно так и делается. Но теоретически вполне можно представить, скажем, char переменной длины(т.е. будем хранить символы в UTF-8). Да, реализация этого будет не очень оптимальна(скажем, операция вычисления адреса начала символа по индексу усложнится радикально), но на поведение самой строки это не повлияет никак. Класс String можно не менять: он как работал с UCS-16 символами, так и будет работать с UTF-8.
То есть поинт в том, что кодировка — это средство представления строки в памяти компьютера, но не более.

Здравствуйте, Eugeny__, Вы писали:

E__>То есть поинт в том, что кодировка — это средство представления строки в памяти компьютера, но не более.

С этим согласен. А поскольку существует спецификация — этот способ зафиксирован. И вряд ли в обозримом будущем кто-то реализует VM с представлением строки в 32bit.

Здравствуйте, Eugeny__, Вы писали:

E> Сейчас максимально удобно использовать UCS-16, потому в джаве и шарпе именно так и делается. Но теоретически вполне можно представить, скажем, char переменной длины(т.е. будем хранить символы в UTF-8). Да, реализация этого будет не очень оптимальна(скажем, операция вычисления адреса начала символа по индексу усложнится радикально), но на поведение самой строки это не повлияет никак.

Так в UTF-16 символ тоже переменной длины. Все что выше BMP, представляется суррогатной парой. Если же речь идет только о BMP, то это не UTF-16, а UCS-2.