е за все не указан ключик-encoding. p> Якщо Ви побачите "??????" (Або будь-які інші символи крім "АБВ" на місці другої трійки літер), значить висновок у Вас працює невірно. p> Набудувавши висновок і компіляцію вже можна легко розібратися і з входом. Після налаштування всього ланцюжка проблеми повинні зникнути. p> Про утиліті native2ascii p> Ця утиліта входить до складу Sun JDK і призначена для перетворення вихідних текстів до ASCII-увазі. Вона читає вхідний файл, використовуючи зазначену кодування, а на виході записує символи у форматі "uXXXX". Якщо вказати ключик -Reverse, то виконується зворотна конвертація. Ця програма дуже корисна для конвертації файлів ресурсів (. properties) або для обробки початкових кодів, якщо Ви припускаєте, що вони можуть компіляться на комп'ютерах з відмінними від російських регіональними настройками. p> Якщо запустити програму без параметрів, вона працює зі стандартним входом (stdin), а не виводить підказку по ключах, як інші утиліти. Це призводить до того, що багато хто і не здогадуються про необхідність вказівки параметрів (крім, може бути, тих, хто знайшов у собі сили і мужність зазирнути таки в документацію :-). Тим часом цю утиліту для правильної роботи необхідно, як мінімум, вказати використовувану кодування (ключик-encoding). Якщо цього не зробити, то буде використана кодування за замовчуванням (file.encoding), що може дещо розходиться з очікуваною. В результаті, отримавши невірні коду букв (Через невірну кодування) можна витратити дуже багато часу на пошук помилок в абсолютно вірному коді. p>
Про метод перекодування символів p> Цей метод багато хто використовує неправильно, напевно, не зовсім розуміючи його суть і обмеження. Він призначений для відновлення вірних кодів літер, якщо вони були невірно проінтерпретовано. Суть методу проста: з отриманих невірних символів, використовуючи відповідну кодову сторінку, відновлюється вихідний масив байтів. Потім з цього масиву байтів, використовуючи вже коректну сторінку, виходять нормальні коду символів. Приклад:
String res = new String (src.getBytes ("ISO-8859-1"), "Cp1251");
Проблем у використанні цього прийому може бути декілька. Наприклад, для відновлення використовується невірна сторінка, або ж вона може змінитися в деяких ситуаціях. Інша проблема може бути в тому, що деякі сторінки виконують неоднозначне перетворення byte char. Дивіться, наприклад, опис помилки за номером 4296969. p> Тому користуватися цим методом варто тільки в самому крайньому випадку, коли вже ніщо інше не допомагає, і Ви чітко собі уявляєте, де саме відбувається невірне перетворення символів. p> Російські літери і MS JVM p> Незрозуміло з яких міркувань, але в ній відсутні всі файли кодувань російських букв, Акрома Cp1251 (напевно, вони таким чином намагалися зменшити розмір дистрибутива). Якщо Вам потрібні інші кодування, наприклад, Cp866, то потрібно додати відповідні класи в CLASSPATH. Причому класи від останніх версій Sun JDK ...
