Русские буквы в именах файлов.

[BBB]

Не знаю, там ли занаю вопрос, но попробую.
Исходные данные несколько запутанные.
Имеется библиотека в исходных текстах на Java (работающая с PDF-файлами, но это, думаю, не суть важно).
Библиотека была скомпиллирована компилятором MinGW, причем ее в итоге стало можно использовать из C++.

Проблема. Если попытаться использовать функции этой библиотеки для файлов, имена которых содержат русские буквы (не важно - в самом имени, или в имени каталога), то получаем сообщение, что это файл не найден.
Причем, дело, похоже, именно в русских буквах, а не в длинных именах или пробелах (и то, и то без русских букв проходит "на ура").

Может быть, кто-нибудь подскажет, как это можно побороть?

Заранее спасибо.

[DeeJayC]

unicode нас спасёт! надо ставить отладку - какую строку получает жаба. если делать в unicode, должно работать.

[BBB]

unicode нас спасёт! надо ставить отладку - какую строку получает жаба. если делать в unicode, должно работать.

У меня была мысль, что надо как-то в этом направлении копать. Но не ясно - как.
Вот сейчас некий класс на вход "конструктора" получат строку. Если я там указываю имя, к примеру, "C:\file.pdf" (т.е. "обычную" строку), то файл находится.
А если утда передать что-то вроде "\u0043\u003A\u005C\u0066\u0069\u006C\u0065\u002E\u0070\u0064\u0066", то как этот класс (процедура) поймет, что там Unicode строка, а не "однобайтная" строка?
(кстати, попробовал таким образм - результат не впечатляет, конечно "файл или ресурс не найден")

К слову (вдруг, это важно), исходный вызов происходит из C++. При компиляции исходников Java (т.е. файлов *.java) компилятор "породил" соответствующие *.h-файлы с описанием классов. Ну и эти классы можно использовать в исходнике, написанном на C++.

[Absurd]

У меня была мысль, что надо как-то в этом направлении копать. Но не ясно - как.
Вот сейчас некий класс на вход "конструктора" получат строку. Если я там указываю имя, к примеру, "C:\file.pdf" (т.е. "обычную" строку), то файл находится.
А если утда передать что-то вроде "\u0043\u003A\u005C\u0066\u0069\u006C\u0065\u002E\u0070\u0064\u0066", то как этот класс (процедура) поймет, что там Unicode строка, а не "однобайтная" строка?
(кстати, попробовал таким образм - результат не впечатляет, конечно "файл или ресурс не найден")

К слову (вдруг, это важно), исходный вызов происходит из C++. При компиляции исходников Java (т.е. файлов *.java) компилятор "породил" соответствующие *.h-файлы с описанием классов. Ну и эти классы можно использовать в исходнике, написанном на C++.

Если кодировка - UTF-8, то английские буквы передаются по одному октету на символ, а русские - по два. Надо наверно попытасться трансформировать UTF-8 в UTF-16, принятую в win32.

[Absurd]

Только что прочитал документацию - таки да, java передает в JNI строки в формате UTF-8

[BBB]

Только что прочитал документацию - таки да, java передает в JNI строки в формате UTF-8

То есть что из этого следует? Можно побороть проблему или глухо? /может быть, я просто что-то не понял из пояснения, в Java я практичсеки совсем не специалист/

[Absurd]

То есть что из этого следует? Можно побороть проблему или глухо? /может быть, я просто что-то не понял из пояснения, в Java я практичсеки совсем не специалист/1

В C++ коде можно сконвертировать это дело с помощью MultiByteToWideChar(UTF-8, ....).

[BBB]

Absurd, но если в прототипа Java-вской функции стоит тип параметра String:

Код: Выделить всё

    public PdfReader(String filename) throws IOException {
        this(filename, null);
    }

, то как Java разберется (и разберется ли?), что ей подсунули не "обычную" строку, а UTF8?

[Absurd]

Внутри себя java использует UTF-16, но при пересечении границы между JVM и Native кодом они транслируются в UTF-8, по моему так.

[BBB]

В C++ коде можно сконвертировать это дело с помощью MultiByteToWideChar(UTF-8, ....).

Absurd, спасибо, вроде в итоге все как-то где-то каким-то образом заработало
Использовал и MultiByteToWideChar (...), и еще почитал про "внутренний мир" Java-вских типов char и string (вот тут: "Java:Русские буквы и не только")

Правда, первым параметром MultiByteToWideChar указывал не UTF-8, а CP_ACP (ANSI code page), и а третьим (LPCSTR lpMultiByteStr) - "обычную" строку (где каждый символ - один байт).
Правда теперь вот думаю, а как это ф-я MultiByteToWideChar разобралась, что переданная ей строка содержит русские буквы, а не западноевропейские (т.е., например символ с кодом 192 - это русская 'А', а не что-нибудь вроде немецкой 'A с крыжиком' ). Ведь, как я понял, функции MultiByteToWideChar не указывается "кодовая страница" (кажется, это так называется). Остается предположить, что эта функция использует какие-то настройки данной Windows?