нням включений перший режим, а для нормальної роботи з російською мовою необхідно використовувати ENCODING_UTF_16. Причому що найважливіше, цю установку необхідно виконувати для кожної, створюваної осередки. Приклад коду:
HSSFWorkbook wb = new HSSFWorkbook ();
HSSFSheet sheet = wb.createSheet ("Sheet1");
HSSFRow row = sheet.createRow ( (Short) 0);
for (int i = 0; i <10; i + +)
{p> HSSFCell cell = row.createCell ((short) i);
cell.setEncoding ((short) cell.ENCODING_UTF_16);
cell.setCellValue ("Тест російської мови");
}
Створити лист з назвою містить російські символи, на жаль, не вдається. Дане опис надіслав В'ячеслав Яковенко, за що йому окреме спасибі. p> CORBA p> У стандарті CORBA передбачений тип, відповідний Java-івської типу String. Це тип wstring. Все б добре, але деякі CORBA-сервера не підтримують його повною мірі. Типові виключення, що виникають при спотикання на російських буквах: org.omg.CORBA.MARSHAL: minor code 5 completed No або org.omg.CORBA.DATA_CONVERSION. Найкраще, звичайно, замінити CORBA-сервер. До жаль у мене немає статистики, тому я не можу сказати, з якими проблем не буде. Якщо змінити систему не представляється можливим, можна замість типу wstring використовувати тип string в парі з нашим улюбленим перетворенням:
// Серверна частина
a = new Answer (new String ( src.getBytes ("Cp1251"), "ISO-8859-1"));
...
// Клієнтська частина
Answer answer = serverRef.getAnswer ();
res = new String ( answer.msg.getBytes ("ISO-8859-1"), "Cp1251");
Тип wstring при цьому краще не використовувати, тому як тим самим Ви кривизна сервера будете компенсувати кривизна своїх компонентів, а це практично завжди чревате різноманітними проблемами в майбутньому. p> Замість Cp1251 можна використовувати будь-яке кодування російських букв, за бажанням. Це буде кодування, в якій будуть передаватися рядки в компоненти на інших мовах. Також, аналогічний код може знадобитися, якщо необхідно організувати зв'язок з готовими НЕ-Java компонентами, які вже використовували тип string. p> Чесно кажучи, не лежить у мене душа до таких рішень, ну так що поробиш, іноді воно єдине. p> JNI p> JNI (Java Native Interface) - це стандарт по взаємодії з C/C + +-ним кодом. Як і слід було очікувати, на цьому вододілі теж відбувається зіткнення байтів і символів. Більшість C/C + +-них програм пишеться без урахування Unicode, багато програмісти навіть не знають про нього. Я сам, за 7 років письменства на C/C + +, поки не почала писати на Java, про Unicode знав тільки з чуток. Більшість строкових операцій в C/C + + зроблені для 8-бітового сішного типу char. В принципі, є деякі зрушення в цьому напрямку, зокрема для Windows NT можна відкомпілювати код, який буде взаємодіяти з Unicode-варіантами Win32 API, але, на жаль, цього часто недостатньо. p> Таким чином головне завдання - отримати тип char * з типу jstring...
