java.lang.String. Це звичайний клас, який всередині себе зберігає масив символів (char []), і який містить багато корисних методів для маніпуляції символами. Найкращі цікаві - це конструктори, що мають першим параметром масив байтів (byte []) і методи getBytes (). За допомогою цих методів Ви можете виконувати перетворення з масиву байтів в рядки і назад. Для того, щоб вказати яке кодування при цьому використовувати у цих методів є строковий параметр, який задає її ім'я. Ось, наприклад, як можна виконати перекодування байтів з ЯКІ-8 у Windows-1251:
// Дані в кодуванні ЯКІ-8
byte [] koi8Data = ...;
// Перетворимо з ЯКІ-8 в Unicode
String string = new String (koi8Data, "KOI8_R");
// Перетворимо з Unicode в Windows-1251
byte [] winData = string.getBytes ("Cp1251");
Список 8-ми бітових кодувань, доступних в сучасних JDK і підтримують російські букви Ви можете знайти нижче, в розділі "8-ми бітові кодування російських літер ".
Так як кодування - це формат даних для символів, крім знайомих 8-ми бітових кодувань в Java також на рівних присутні і багатобайтові кодування. До таких відносяться UTF-8, UTF-16, Unicode і пр. Наприклад ось так можна отримати байти в форматі UnicodeLittleUnmarked (16-ти бітове кодування Unicode, молодший байт перший, без ознаки порядку байтів):
// Рядок Unicode
String string = "...";
// Перетворимо з Unicode в UnicodeLittleUnmarked
byte [] data = string.getBytes ("UnicodeLittleUnmarked");
При подібних перетвореннях легко помилитися - якщо кодування байтових даних не відповідають вказаному параметру при перетворенні з byte в char, то перекодування буде виконано неправильно. Іноді після цього можна витягнути правильні символи, але частіше за все частина даних буде безповоротно втрачена. p> У реальній програмі явно вказувати кодову сторінку не завжди зручно (хоча більш надійно). Для цього була введена кодування за замовчуванням. За умовчанням вона залежить від системи і її налаштувань (для російських виндов прийнята кодування Cp1251), і в старих JDK її можна змінити установкою системного властивості file.encoding. У JDK 1.3 зміна цієї налаштування іноді спрацьовує, іноді - ні. Викликано це наступним: спочатку file.encoding ставиться з регіональних налаштувань комп'ютера. Посилання на кодування за замовчуванням запам'ятовується в нутрії при першому перетворенні. При цьому використовується file.encoding, але це перетворення відбувається ще до використання аргументів запуску JVM (собсно, при їх розборі). Взагалі-то, як стверджують в Sun, ця властивість відображає системну кодування, і вона не повинна змінюватися в командному рядку (див., наприклад, коментарі до BugID 4163515) Проте в JDK 1.4 Beta 2 зміна цієї налаштування знову почала чинити ефект. Що це, свідома зміна або побічний ефект, який може знову зникнути - Sun-вівці ясної відповіді поки не дали. p> Ця кодування використовується тоді, коли ...
