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

M>В принципе верно. Но как теперь в SOAP у которого на входе должна быть строка отдать этот массив байт?

В этой теме упоминалась кодировка Base64. Полученный массив байт передаешь в функцию base64encode (или как там она называется) и получаешь строку. На другой стороне делают base64decode и получают массив байт в кодировке UTF-8, из которых создают строку

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

M>String cp1251text = "Иван";
M>String utf8text = new String(cp1251text.getBytes("utf-8"));

1) в Java все строки — UCS-2, поэтому неразумно пытаться называть переменные типа String utf8 или cp1251, раз они таковыми не являются
2) понятие кодировки применимо только к последовательности байтов
3) предлагаю свой вариант твоего примера, после которого должно всё стать ясно:

String text1 = "\u0418\u0432\u0430\u043d";
String text2 = new String(text1.getBytes("utf-8"), "utf-8");
assert text2.equals(text1);

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

Пример:

String cp1251text = "Иван";
String utf8text = new String(cp1251text.getBytes("utf-8"));

В итоге текст utf8text имеет вид �?ван
С другими буквами русского алфавита как с заглавными так и с прописными все нормально.

Не помогают и более изощренные способы — например перекодировка с помощью всяких там файлов, буферов ввода и прочими шаманскими замолодями.
Даже был такой вариант:

byte[] bytes = utf8text.getBytes();
...
//Заменяем последовательности -48, 63 на -48, 104
utf8text = new String(bytes);

всеравно остается -48, 63. Заколдовано просто...

На MacOS X все нормально. Там нативный UTF-8 и перекодировки все работают без проблем. На Windows XP хуже. Кто что подскажет?

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

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

M>>>>String fio = new String(jtextfield1.getBytes("utf-8"));
B>>>WTF?
M>>А по конкретнее...
B>У JTextField вроде бы нет такого метода. И для чего здесь указание кодировки, если JTextField и так возвращает строку?

Пардон. String text = new String(jtextfield1.getText().getBytes("utf-8"));
Если использовать String text = jtextfield1.getText(); то возвращается строка в текущей кодировке системы. А мне нужен уже Utf-8.

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

M>Я уже 48 раз ответил — помогите найти правильное решение. А если сказать нечего, кроме того что "надо найти правильное решение", то зачем спамить в топик?

что за base64encode? По-хорошему, она должна брать массив байт, а не строку. Равно как и base64decode должна возвращать массив байт (или что-то в этом роде)

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

M>При перекодировке строки в Cp1251 в кодировку UTF-8 возникает ошибка в букве И. Она кодируется как {-48, 63), а должна быть {-48, 104}.
Большинство проблем с кодировками именно из-за того что не все понимают что такое кодировка. А кодировка это представление строки в двоичном виде. Строка сама по себе не имеет кодировке. Это просто строка конкретного текста. Кодировки используются для того чтобы строку представить в двоичном виде для последующей передачи или хранения.

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

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

C0s>

M>>String cp1251text = "Иван";
M>>String utf8text = new String(cp1251text.getBytes("utf-8"));
C0s>

C0s>1) в Java все строки — UCS-2, поэтому неразумно пытаться называть переменные типа String utf8 или cp1251, раз они таковыми не являются
C0s>2) понятие кодировки применимо только к последовательности байтов
C0s>3) предлагаю свой вариант твоего примера, после которого должно всё стать ясно:

C0s>

C0s>String text1 = "\u0418\u0432\u0430\u043d";
C0s>String text2 = new String(text1.getBytes("utf-8"), "utf-8");
C0s>assert text2.equals(text1);
C0s>

Запустил ваш пример. Ошибок не выдало.

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

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

M>>При перекодировке строки в Cp1251 в кодировку UTF-8 возникает ошибка в букве И. Она кодируется как {-48, 63), а должна быть {-48, 104}.
B>Большинство проблем с кодировками именно из-за того что не все понимают что такое кодировка. А кодировка это представление строки в двоичном виде. Строка сама по себе не имеет кодировке. Это просто строка конкретного текста. Кодировки используются для того чтобы строку представить в двоичном виде для последующей передачи или хранения.

Я как раз и говорю о представлении строки в двоичном виде. В байтах. Мне как раз и нужно превратить строку в UTF-8 перед отправкой на другой сервер. Так как с приложением работают люди с MacOS, Windows и других операционных систем, то нужно единое представление данных. В UTF-8. А так как в MacOS все данные уже в UTF-8, а на Windows в Cp1251 то нужно чтото делать, чтобы данные на сервер доходили в единой кодировке. И соответственно приходили с него тоже.

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

M>>>При перекодировке строки в Cp1251 в кодировку UTF-8 возникает ошибка в букве И. Она кодируется как {-48, 63), а должна быть {-48, 104}.
B>>Большинство проблем с кодировками именно из-за того что не все понимают что такое кодировка. А кодировка это представление строки в двоичном виде. Строка сама по себе не имеет кодировке. Это просто строка конкретного текста. Кодировки используются для того чтобы строку представить в двоичном виде для последующей передачи или хранения.

M>Я как раз и говорю о представлении строки в двоичном виде. В байтах. Мне как раз и нужно превратить строку в UTF-8 перед отправкой на другой сервер. Так как с приложением работают люди с MacOS, Windows и других операционных систем, то нужно единое представление данных. В UTF-8. А так как в MacOS все данные уже в UTF-8, а на Windows в Cp1251 то нужно чтото делать, чтобы данные на сервер доходили в единой кодировке. И соответственно приходили с него тоже.

Поздно пить боржоми когда у тебя уже строка в объекте java.lang.String

A String represents a string in the UTF-16

Сценарий перекодировок такой

byte[] cp1251array = ...;
String str = new String(cp1251array, "cp1251"); // перекодировка CP 1251 -> в String
byte[] utf8array = str.getBytes("UTF-8); // перекодировка String -> UTF-8

Тут вам не C\С++ его строками

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

GIV>Тут вам не C\С++ его строками

Объясню всю ситуацию. Есть некое приложение Java. В нем есть один диалог. В диалоге есть поле ввода JTextField и кнопка JButton. Пользователь запускает приложение, вводит свою фамилию и жмет кнопку. После нажатия кнопки:

//Забираем введенный текст сразу в UTF-8
String fio = new String(jtextfield1.getBytes("utf-8"));
//Отправляем данные юзера на сервак.
soapclient.sendUserFio(base64encode(fio));

Скомпилено и собрано все UTF-8 на макинтоше. На томже макинтоше все работает наура. Проблемы на винде.

Собственно когда строка приходит на сервер то получаем все в UTF-8 за исключением большой заглавной русской буквы И. Она отображается как знак вопроса в ромбике + знак вопроса без ромбика. Никакие шаманства не катят. Подскажите как в String fio получить данные из JTextField в UTF-8 независимо от операционной системы юзера и его кодировки.

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

M>Я как раз и говорю о представлении строки в двоичном виде. В байтах. Мне как раз и нужно превратить строку в UTF-8 перед отправкой на другой сервер. Так как с приложением работают люди с MacOS, Windows и других операционных систем, то нужно единое представление данных. В UTF-8. А так как в MacOS все данные уже в UTF-8, а на Windows в Cp1251 то нужно чтото делать, чтобы данные на сервер доходили в единой кодировке. И соответственно приходили с него тоже.
В твоей ситуации выходит чот строка изначально интерпретировалась неверной кодировкой. В результате чего в объекте находится текст отличный от ожиидаемого. Исправление значения приведенным образом не есть нормальный подход, к тому же, как показывает пример, он не всегда выполним. Нормальный подход должен недопустить появления экземпляра испорченой строки.

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

M>//Забираем введенный текст сразу в UTF-8
M>String fio = new String(jtextfield1.getBytes("utf-8"));

WTF?

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

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

M>>//Забираем введенный текст сразу в UTF-8
M>>String fio = new String(jtextfield1.getBytes("utf-8"));

B>WTF?
А по конкретнее...

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

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

M>>Я как раз и говорю о представлении строки в двоичном виде. В байтах. Мне как раз и нужно превратить строку в UTF-8 перед отправкой на другой сервер. Так как с приложением работают люди с MacOS, Windows и других операционных систем, то нужно единое представление данных. В UTF-8. А так как в MacOS все данные уже в UTF-8, а на Windows в Cp1251 то нужно чтото делать, чтобы данные на сервер доходили в единой кодировке. И соответственно приходили с него тоже.
B>В твоей ситуации выходит чот строка изначально интерпретировалась неверной кодировкой. В результате чего в объекте находится текст отличный от ожиидаемого. Исправление значения приведенным образом не есть нормальный подход, к тому же, как показывает пример, он не всегда выполним. Нормальный подход должен недопустить появления экземпляра испорченой строки.

Ну так я обратился на форум чтобы мне помогли организовать нормальный подход. Так как у самого не получается.

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

M>>>String fio = new String(jtextfield1.getBytes("utf-8"));
B>>WTF?
M>А по конкретнее...
У JTextField вроде бы нет такого метода. И для чего здесь указание кодировки, если JTextField и так возвращает строку?

09.03.2010 12:49, Madjack пишет:

> //Забираем введенный текст сразу в UTF-8
> String fio = new String(jtextfield1.getBytes("utf-8"));

Проблема здесь. Это бессмысленное с точки зрения java деяние, т.к.
реально вызовется что-то вроде.

String fio = new String(jtextfield1.getBytes("utf-8"),
платформо_зависимая_кодировка_по_умолчанию);

А вам скорее всего нужно это:

String fio = field.getText(); // или что там нужно
byte[] bytes = fio.getBytes("utf-8"); // если дальше нужны именно bytes

Поищите статью Сергея Астахова "Java. Русские буквы и не только" — мне
после длительного программирования на C именно она помогла понять что я
делал неправильно.

--
WBR,
Serge.

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

H>09.03.2010 12:49, Madjack пишет:

>> //Забираем введенный текст сразу в UTF-8
>> String fio = new String(jtextfield1.getBytes("utf-8"));

H>Проблема здесь. Это бессмысленное с точки зрения java деяние, т.к.
H>реально вызовется что-то вроде.

H>String fio = new String(jtextfield1.getBytes("utf-8"),
H>платформо_зависимая_кодировка_по_умолчанию);

H>А вам скорее всего нужно это:

H>String fio = field.getText(); // или что там нужно
H>byte[] bytes = fio.getBytes("utf-8"); // если дальше нужны именно bytes

H>Поищите статью Сергея Астахова "Java. Русские буквы и не только" — мне
H>после длительного программирования на C именно она помогла понять что я
H>делал неправильно.

H>--
H>WBR,
H>Serge.

Мне нужны не байты. До байтов я докапался когда искал проблему, в каком месте коржется буква И. Механизм прост. Пользователь вводит строку, мне нужно эту строку получить в utf-8 и отправить на удаленный сервер.

H>String fio = field.getText(); // или что там нужно

Здесь строка fio будет в кодировке системы. Если на винде то в cp1251. А мне нужна в utf-8. Соответственно вместо:
String text = jtextfield1.getText();
bytes[] bytes = text.getBytes("utf-8");
String utftext = new String(bytes);

я пишу одной строчкой
String text = jtextfield1.getText().getBytes("utf-8");

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

M>Собственно когда строка приходит на сервер то получаем все в UTF-8 за исключением большой заглавной русской буквы И. Она отображается как знак вопроса в ромбике + знак вопроса без ромбика. Никакие шаманства не катят. Подскажите как в String fio получить данные из JTextField в UTF-8 независимо от операционной системы юзера и его кодировки.

А вы уверенны, что проблема ДО передачи данных на сервер?
Каким образом данные поступают на сервер?

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

M>Пардон. String text = new String(jtextfield1.getText().getBytes("utf-8"));
M>Если использовать String text = jtextfield1.getText(); то возвращается строка в текущей кодировке системы. А мне нужен уже Utf-8.
Ну, вот. Ты снова не разобрался. Хотя становишься в защитную позу

Автор: Madjack
Дата: 09.03.10

. В строке
String text = jtextfield1.getText()
нет понятия кодировки, так как здесь нет никакого двоичного представления.

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

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

M>>Пардон. String text = new String(jtextfield1.getText().getBytes("utf-8"));
M>>Если использовать String text = jtextfield1.getText(); то возвращается строка в текущей кодировке системы. А мне нужен уже Utf-8.
B>Ну, вот. Ты снова не разобрался. Хотя становишься в защитную позу

Автор: Madjack
Дата: 09.03.10

. В строке
B>String text = jtextfield1.getText()
B>нет понятия кодировки, так как здесь нет никакого двоичного представления.

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

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

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

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

M>Мне нужны не байты. До байтов я докапался когда искал проблему, в каком месте коржется буква И. Механизм прост. Пользователь вводит строку, мне нужно эту строку получить в utf-8 и отправить на удаленный сервер.
Для удаленной передачи вам нужны именно байты. Иначе никак.

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

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

Тебе уже 48 раз сказали — у строк (java.lang.String) кодировка прибита гвоздями — UTF-16. Всё остальное касается только байт/ввода/вывода. Найденный тобою костыль ни разу не решение проблемы. Не там роешь.

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

Тебе перед отправкой на сервер нужно получить массив байт из строки, которую ввел пользователь, в кодировке UTF-8, правильно?

H>>String fio = field.getText(); // или что там нужно
M>Здесь строка fio будет в кодировке системы. Если на винде то в cp1251. А мне нужна в utf-8. Соответственно вместо:
Нет, здесь строка будет во внутренней кодировке ява-платформы (UTF-16), но для тебя это не имеет значения.

M>String text = jtextfield1.getText();
M>bytes[] bytes = text.getBytes("utf-8");
M>String utftext = new String(bytes);
Этот код не имеет смысла. Ты получаешь строку, потом получаешь из нее массив байт в кодировке UTF-8, потом из этого массива байт снова пытаешься создать строку, но кодировку не указываешь, а значит подставляется кодировка по умолчанию, равная кодировке ОС. Для винды это windows-1251. Естественно, что ты получаешь фигню.

M>я пишу одной строчкой
M>String text = jtextfield1.getText().getBytes("utf-8");
Почему String text? Вот так правильно из строки получить массив байт в кодировке utf-8:
byte[] textBytes = jtextfield1.getText().getBytes("UTF-8");

Если хочешь проверить, что все правильно, то можно создать из этого массива байт строку:
String test = new String( textBytes, "UTF-8" );

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

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

M>>Собственно когда строка приходит на сервер то получаем все в UTF-8 за исключением большой заглавной русской буквы И. Она отображается как знак вопроса в ромбике + знак вопроса без ромбика. Никакие шаманства не катят. Подскажите как в String fio получить данные из JTextField в UTF-8 независимо от операционной системы юзера и его кодировки.

GW>А вы уверенны, что проблема ДО передачи данных на сервер?
GW>Каким образом данные поступают на сервер?

Уверен абсолютно. Все неоднократно проверялось на практике прежде чем выстроить эту теорию. + Я не одинок в своей проблеме. Так как данный вопрос поднимается с 2007года на различных форумах. И именно только с буквой "И".

Данные на сервер передаются с помощью SOAP. Алгоритм следующий:

Клиент:
String text = "строка в utf-8";
String base64text = base64encode(text);
soapclient.SendText(base64text);

Сервер:
textutf8 = base64decode(soapserver.GetText(base64text));
pgsql->exec("insert into sometable (....) values (..., 'textutf8', ...);

Как собственно выяснилась ошибка. При неизменном коде программа запускалась на MacOs и Windows. На Макинтоше проблем нет. На винде проблема с буквой И.
После получения данных от клиента на сервере делался дампфайл с пришедшими данными и затем смотрелся в браузере с изменением кодировок. С Макоса данные всегда в utf-8 с винды всегда в cp1251. после перекодировки и от туда и от туда в utf-8. но вот буква И бьется.

Затем на клиенте сделалось так:
Скажем text равен "И":

String text = jtextfield1.getText();
System.out.println(Arrays.toString(text.getBytes());
String text_u = new String(text.getBytes("utf-8");
System.out.println(Arrays.toString(text_u.getBytes());

При выводе байтов строки text байты символа были корректными
При выводе байтов строки text_u байты символов были не корректными. Вместо {-48, 104} было {-48, 64}

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

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

M>>Да я не становлюсь в позу=) Я просто проверил все на практике. Если не делать тех манипуляций с перекодировками то до сервера приходит строка в cp1251.
B>Логично предположить что манипуляции производятся ошибочно и решение должно быть другое.

Логично. Это и было сделано. Но результата пока нет. За этим и обращаюсь на форум.

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

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

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

CU>Тебе уже 48 раз сказали — у строк (java.lang.String) кодировка прибита гвоздями — UTF-16. Всё остальное касается только байт/ввода/вывода. Найденный тобою костыль ни разу не решение проблемы. Не там роешь.

Я уже 48 раз ответил — помогите найти правильное решение. А если сказать нечего, кроме того что "надо найти правильное решение", то зачем спамить в топик?

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

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

D>Тебе перед отправкой на сервер нужно получить массив байт из строки, которую ввел пользователь, в кодировке UTF-8, правильно?

H>>>String fio = field.getText(); // или что там нужно
M>>Здесь строка fio будет в кодировке системы. Если на винде то в cp1251. А мне нужна в utf-8. Соответственно вместо:
D>Нет, здесь строка будет во внутренней кодировке ява-платформы (UTF-16), но для тебя это не имеет значения.

M>>String text = jtextfield1.getText();
M>>bytes[] bytes = text.getBytes("utf-8");
M>>String utftext = new String(bytes);
D>Этот код не имеет смысла. Ты получаешь строку, потом получаешь из нее массив байт в кодировке UTF-8, потом из этого массива байт снова пытаешься создать строку, но кодировку не указываешь, а значит подставляется кодировка по умолчанию, равная кодировке ОС. Для винды это windows-1251. Естественно, что ты получаешь фигню.

M>>я пишу одной строчкой
M>>String text = jtextfield1.getText().getBytes("utf-8");
D>Почему String text? Вот так правильно из строки получить массив байт в кодировке utf-8:
D>byte[] textBytes = jtextfield1.getText().getBytes("UTF-8");

D>Если хочешь проверить, что все правильно, то можно создать из этого массива байт строку:
D>String test = new String( textBytes, "UTF-8" );

В принципе верно. Но как теперь в SOAP у которого на входе должна быть строка отдать этот массив байт?

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

M>Уверен абсолютно. Все неоднократно проверялось на практике прежде чем выстроить эту теорию. + Я не одинок в своей проблеме. Так как данный вопрос поднимается с 2007года на различных форумах. И именно
только с буквой "И".
Вопрос много раз поднимается не потому что актуален, а потому что многие точно так же заблуждаются.

M>Данные на сервер передаются с помощью SOAP. Алгоритм следующий:

M>Клиент:
M>String text = "строка в utf-8";
M>String base64text = base64encode(text);
M>soapclient.SendText(base64text);

M>Сервер:
M>textutf8 = base64decode(soapserver.GetText(base64text));
M>pgsql->exec("insert into sometable (....) values (..., 'textutf8', ...);

M>Как собственно выяснилась ошибка. При неизменном коде программа запускалась на MacOs и Windows. На Макинтоше проблем нет. На винде проблема с буквой И.
M>После получения данных от клиента на сервере делался дампфайл с пришедшими данными и затем смотрелся в браузере с изменением кодировок. С Макоса данные всегда в utf-8 с винды всегда в cp1251. после перекодировки и от туда и от туда в utf-8. но вот буква И бьется.

В методе base64encode должна быть указана кодировка явно. Так как у вас этого нет, то под виндой у вас используется дефолтная.

M>Затем на клиенте сделалось так:
M>Скажем text равен "И":
M>String text = jtextfield1.getText();
M>System.out.println(Arrays.toString(text.getBytes());
M>String text_u = new String(text.getBytes("utf-8");
M>System.out.println(Arrays.toString(text_u.getBytes());
Это попытка исправить строку, которая уже не правильно раскодирована. Данные потерялись ещё на этапе применения неправильной кодировки при раскодировании. Поэтому восстанавливать их бессмысленно.

09.03.2010 13:34, Madjack пишет:

> Клиент:
> String text = "строка в utf-8";
> String base64text = base64encode(text);
> soapclient.SendText(base64text);

А что делает base64encode (и decode на "сервере")? Скорее всего там
что-то типа:

String base64encode(String str){
return Base64Encoder.encode(str.getBytes());
}

Если это так, то проблема понятна.

--
WBR,
Serge.

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

H>09.03.2010 13:34, Madjack пишет:

>> Клиент:
>> String text = "строка в utf-8";
>> String base64text = base64encode(text);
>> soapclient.SendText(base64text);

H>А что делает base64encode (и decode на "сервере")? Скорее всего там
H>что-то типа:

H>String base64encode(String str){
H> return Base64Encoder.encode(str.getBytes());
H>}

H>Если это так, то проблема понятна.

H>--
H>WBR,
H>Serge.

Сервер написан на PHP. Там используются стандартные средства PHP для декодинга. а именно:
$str = base64decode($in_base64str);

Да простят меня модераторы. Выкладываю код Base64coder'а

// Copyright 2003-2009 Christian d'Heureuse, Inventec Informatik AG, Zurich, Switzerland
// www.source-code.biz, www.inventec.ch/chdh
//
// This module is multi-licensed and may be used under the terms
// of any of the following licenses:
//
// EPL, Eclipse Public License, http://www.eclipse.org/legal
// LGPL, GNU Lesser General Public License, http://www.gnu.org/licenses/lgpl.html
// AL, Apache License, http://www.apache.org/licenses
// BSD, BSD License, http://www.opensource.org/licenses/bsd-license.php
//
// Please contact the author if you need another license.
// This module is provided "as is", without warranties of any kind.

/**
* A Base64 Encoder/Decoder.
*
* <p>
* This class is used to encode and decode data in Base64 format as described in RFC 1521.
*
* <p>
* Home page: <a href="http://www.source-code.biz">www.source-code.biz</a><br>
* Author: Christian d'Heureuse, Inventec Informatik AG, Zurich, Switzerland<br>
* Multi-licensed: EPL/LGPL/AL/BSD.
*
* <p>
* Version history:<br>
* 2003-07-22 Christian d'Heureuse (chdh): Module created.<br>
* 2005-08-11 chdh: Lincense changed from GPL to LGPL.<br>
* 2006-11-21 chdh:<br>
* &nbsp; Method encode(String) renamed to encodeString(String).<br>
* &nbsp; Method decode(String) renamed to decodeString(String).<br>
* &nbsp; New method encode(byte[],int) added.<br>
* &nbsp; New method decode(String) added.<br>
* 2009-07-16: Additional licenses (EPL/AL) added.<br>
* 2009-09-16: Additional license (BSD) added.<br>
*/

public class Base64Coder {

// Mapping table from 6-bit nibbles to Base64 characters.
private static char[] map1 = new char[64];
static {
int i=0;
for (char c='A'; c<='Z'; c++) map1[i++] = c;
for (char c='a'; c<='z'; c++) map1[i++] = c;
for (char c='0'; c<='9'; c++) map1[i++] = c;
map1[i++] = '+'; map1[i++] = '/'; }

// Mapping table from Base64 characters to 6-bit nibbles.
private static byte[] map2 = new byte[128];
static {
for (int i=0; i<map2.length; i++) map2[i] = -1;
for (int i=0; i<64; i++) map2[map1[i]] = (byte)i; }

/**
* Encodes a string into Base64 format.
* No blanks or line breaks are inserted.
* @param s a String to be encoded.
* @return A String with the Base64 encoded data.
*/
public static String encodeString (String s) {
return new String(encode(s.getBytes())); }

/**
* Encodes a byte array into Base64 format.
* No blanks or line breaks are inserted.
* @param in an array containing the data bytes to be encoded.
* @return A character array with the Base64 encoded data.
*/
public static char[] encode (byte[] in) {
return encode(in,in.length); }

/**
* Encodes a byte array into Base64 format.
* No blanks or line breaks are inserted.
* @param in an array containing the data bytes to be encoded.
* @param iLen number of bytes to process in <code>in</code>.
* @return A character array with the Base64 encoded data.
*/
public static char[] encode (byte[] in, int iLen) {
int oDataLen = (iLen*4+2)/3; // output length without padding
int oLen = ((iLen+2)/3)*4; // output length including padding
char[] out = new char[oLen];
int ip = 0;
int op = 0;
while (ip < iLen) {
int i0 = in[ip++] & 0xff;
int i1 = ip < iLen ? in[ip++] & 0xff : 0;
int i2 = ip < iLen ? in[ip++] & 0xff : 0;
int o0 = i0 >>> 2;
int o1 = ((i0 & 3) << 4) | (i1 >>> 4);
int o2 = ((i1 & 0xf) << 2) | (i2 >>> 6);
int o3 = i2 & 0x3F;
out[op++] = map1[o0];
out[op++] = map1[o1];
out[op] = op < oDataLen ? map1[o2] : '='; op++;
out[op] = op < oDataLen ? map1[o3] : '='; op++; }
return out; }

/**
* Decodes a string from Base64 format.
* @param s a Base64 String to be decoded.
* @return A String containing the decoded data.
* @throws IllegalArgumentException if the input is not valid Base64 encoded data.
*/
public static String decodeString (String s) {
return new String(decode(s)); }

/**
* Decodes a byte array from Base64 format.
* @param s a Base64 String to be decoded.
* @return An array containing the decoded data bytes.
* @throws IllegalArgumentException if the input is not valid Base64 encoded data.
*/
public static byte[] decode (String s) {
return decode(s.toCharArray()); }

/**
* Decodes a byte array from Base64 format.
* No blanks or line breaks are allowed within the Base64 encoded data.
* @param in a character array containing the Base64 encoded data.
* @return An array containing the decoded data bytes.
* @throws IllegalArgumentException if the input is not valid Base64 encoded data.
*/
public static byte[] decode (char[] in) {
int iLen = in.length;
if (iLen%4 != 0) throw new IllegalArgumentException ("Length of Base64 encoded input string is not a multiple of 4.");
while (iLen > 0 && in[iLen-1] == '=') iLen--;
int oLen = (iLen*3) / 4;
byte[] out = new byte[oLen];
int ip = 0;
int op = 0;
while (ip < iLen) {
int i0 = in[ip++];
int i1 = in[ip++];
int i2 = ip < iLen ? in[ip++] : 'A';
int i3 = ip < iLen ? in[ip++] : 'A';
if (i0 > 127 || i1 > 127 || i2 > 127 || i3 > 127)
throw new IllegalArgumentException ("Illegal character in Base64 encoded data.");
int b0 = map2[i0];
int b1 = map2[i1];
int b2 = map2[i2];
int b3 = map2[i3];
if (b0 < 0 || b1 < 0 || b2 < 0 || b3 < 0)
throw new IllegalArgumentException ("Illegal character in Base64 encoded data.");
int o0 = ( b0 <<2) | (b1>>>4);
int o1 = ((b1 & 0xf)<<4) | (b2>>>2);
int o2 = ((b2 & 3)<<6) | b3;
out[op++] = (byte)o0;
if (op<oLen) out[op++] = (byte)o1;
if (op<oLen) out[op++] = (byte)o2; }
return out; }

// Dummy constructor.
private Base64Coder() {}

} // end class Base64Coder

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

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

M>>Я уже 48 раз ответил — помогите найти правильное решение. А если сказать нечего, кроме того что "надо найти правильное решение", то зачем спамить в топик?

CU>что за base64encode? По-хорошему, она должна брать массив байт, а не строку. Равно как и base64decode должна возвращать массив байт (или что-то в этом роде)

http://rsdn.ru/forum/java/3728874.1.aspx

Автор: Madjack
Дата: 09.03.10

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

Как тебе и писали, проблема вот в этом:

M>/**
M>* Encodes a string into Base64 format.
M>* No blanks or line breaks are inserted.
M>* @param s a String to be encoded.
M>* @return A String with the Base64 encoded data.
M>*/
M>public static String encodeString (String s) {
M> return new String(encode(s.getBytes())); }

Ты должен не передавать строку, а уже сформированный массив байт в нужной тебе кодировке.
Дальше разжовывать?

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

M>public static String encodeString (String s) {
M> return new String(encode(s.getBytes())); }

Ну, вот о чем, собственно, и речь.

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

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

M>>В принципе верно. Но как теперь в SOAP у которого на входе должна быть строка отдать этот массив байт?

D>В этой теме упоминалась кодировка Base64. Полученный массив байт передаешь в функцию base64encode (или как там она называется) и получаешь строку. На другой стороне делают base64decode и получают массив байт в кодировке UTF-8, из которых создают строку

Спасибо. Именно так и решил эту проблему.

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

M>Спасибо. Именно так и решил эту проблему.

Пожалуйста. Но практически все в этой теме говорили примерно об этом, просто, видимо, не так понятно.

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

M>>>В принципе верно. Но как теперь в SOAP у которого на входе должна быть строка отдать этот массив байт?

D>>В этой теме упоминалась кодировка Base64. Полученный массив байт передаешь в функцию base64encode (или как там она называется) и получаешь строку. На другой стороне делают base64decode и получают массив байт в кодировке UTF-8, из которых создают строку

M>Спасибо. Именно так и решил эту проблему.

Ну вот и здорово
Надеюсь ты понял, что у тебя нет (и не было) строк в кодировке 1251

M>soapclient.SendText(base64text);

Чего-то я не понял юмора с СОАП клиентом. А почему он не парится на счёт правильной передачи УТФ-8 строк? Это какбэ в ХМЛ документах очень прозрачно поддерживается. Он самописный что ли?

Наткнулся на эту же проблему.

во многих примерах рекомендуют
message.getBytes("UTF-8") и получается нормальный массив байтов готовый для записи куда угодною Он корректный.
запись проводить любым байтовым выводом

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

забавно, все здорово выводится кроме буквы И, сам от лени наткнулся на проблему.

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

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


M>Пардон. String text = new String(jtextfield1.getText().getBytes("utf-8"));
M>Если использовать String text = jtextfield1.getText(); то возвращается строка в текущей кодировке системы. А мне нужен уже Utf-8.

Тебе же говорили: строка не может быть в какой-то кодировке. Кодировка применима исключительно и только для массива байт. В результате операции "String text = jtextfield1.getText()" у тебя в text будет всегда валидный текст в любой системе, даже если это будет китайский линукс, или парагвайская винда.
Тебе же для передачи на сервер из строки нужно получить представление в виде массива байт в определенной кодировке(в данном случае — утф8).

Здравствуйте, 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.