Форум поддержки пользователей. LibreOffice, Apache OpenOffice, OpenOffice.org

Форум поддержки пользователей. LibreOffice, Apache OpenOffice, OpenOffice.org

30 Июнь 2022, 20:16 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
Новости: Здесь можно поблагодарить участников форума Улыбка
 
   Начало   Помощь Поиск Войти Регистрация    задать вопрос  
Страниц: 1   Вниз
  Печать  
Автор Тема: rtl::OUString не читает Русский файл на Linux  (Прочитано 543 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Denis8388
Новичок
*
Offline Offline

Сообщений: 4


« Стартовое сообщение: 17 Июнь 2022, 14:01 »

 Я установил либрофис sdk. Конвертация из doc в pdf работает отлично на винде, но на линуксе идет краш программы, где пытается открыть док файл с русским названием (на английском конвертирует норм). Название хранится в типе *char (хранится правильно), но когда пытаюсь преобразовать в OUString, происходит краш. Сталкивался ли кто с такой проблемой?

ошибка в консоли "terminate called after throwing an instance of 'com::sun::star::lang::IllegalArgumentException'"
Записан
mikekaganski
Гуру
*******
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 2 774


« Ответ #1: 17 Июнь 2022, 14:08 »

когда пытаюсь преобразовать в OUString, происходит краш

... как именно преобразуете? И в какой кодировке у Вас имена файлов?
Записан

С уважением,
Михаил Каганский
Denis8388
Новичок
*
Offline Offline

Сообщений: 4


« Ответ #2: 17 Июнь 2022, 15:12 »

для винды работает так
Код:
OUString sDocUrl;

osl::FileBase::getFileURLFromSystemPath(OUString(g_currentPathFile.toStdWString().c_str()), sDocUrl);


Sequence<PropertyValue> loadProps(2);
loadProps[0].Name = OUString::createFromAscii("Hidden");
loadProps[0].Value = Any(true);
loadProps[1].Name = OUString::createFromAscii("UpdateDocMode");
loadProps[1].Value = Any(sal_Int16(com::sun::star::document::UpdateDocMode::FULL_UPDATE));
Reference <XComponent> xWriterComponent = xComponentLoader->loadComponentFromURL(sDocUrl, OUString("_blank"), 0, loadProps);
Reference <XTextDocument> xTextDocument(xWriterComponent, UNO_QUERY);

но на линуксе компилятор ругает на ".toStdWString().c_str()"

решил я так
Код:
OUString sDocUrl;

osl::FileBase::getFileURLFromSystemPath(OUString::createFromAscii(g_currentPathFile.toLocal8Bit().data()), sDocUrl);


Sequence<PropertyValue> loadProps(2);
loadProps[0].Name = OUString::createFromAscii("Hidden");
loadProps[0].Value = Any(true);
loadProps[1].Name = OUString::createFromAscii("UpdateDocMode");
loadProps[1].Value = Any(sal_Int16(com::sun::star::document::UpdateDocMode::FULL_UPDATE));
Reference <XComponent> xWriterComponent = xComponentLoader->loadComponentFromURL(sDocUrl, OUString("_blank"), 0, loadProps);
Reference <XTextDocument> xTextDocument(xWriterComponent, UNO_QUERY);

на английском работает конвертация,а на рус нет, краш. Права файлу дал все максимальные, не помогло 
Записан
Denis8388
Новичок
*
Offline Offline

Сообщений: 4


« Ответ #3: 17 Июнь 2022, 15:14 »

я делал даже еще проще, тупо путь до файла указал вместо "g_currentPathFile.toLocal8Bit().data()"
Записан
mikekaganski
Гуру
*******
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 2 774


« Ответ #4: 17 Июнь 2022, 15:24 »

Естественно, он падает. createFromAscii работает только для Ascii (коды 0-127).

Вы могли бы воспользоваться QString::toUtf8, и затем преобразовать в OUString с помощью конструктора, принимающего char*:

Код:
auto filePathUtf8 = g_currentPathFile.toUtf8();
rtl::OUString s(filePathUtf8.data(), filePathUtf8.size(), RTL_TEXTENCODING_UTF8);
Записан

С уважением,
Михаил Каганский
mikekaganski
Гуру
*******
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 2 774


« Ответ #5: 17 Июнь 2022, 15:33 »

Или даже проще - у QString внутреннее представление уже UTF-16, также как и у OUString. Достаточно сделать

Код:
osl::FileBase::getFileURLFromSystemPath(rtl::OUString(reinterpret_cast<const sal_Unicode*>(g_currentPathFile.utf16())), sDocUrl);
« Последнее редактирование: 17 Июнь 2022, 15:35 от mikekaganski » Записан

С уважением,
Михаил Каганский
Denis8388
Новичок
*
Offline Offline

Сообщений: 4


« Ответ #6: 17 Июнь 2022, 15:35 »

Спасибо большое, это помогло))
Но я вроде даже в настройках линукса установил, чтоб понимал Ascii. Но это не помогло. Я сам не давно перешел на линукс (заставили). В итоге, линукс понимает русский в кодировке utf8?
Записан
mikekaganski
Гуру
*******
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 2 774


« Ответ #7: 17 Июнь 2022, 15:43 »

Линукс понимает всё. Но это не имеет значения к данному случаю. Потому что "понимать" - это слишком широкое понятие.

Вопрос не в том, что понимает Линукс, а в том, как рассказать процедуре преобразования, из какой кодировки ей надо привести к UTF-16 (которая внутри OUString). Потому что никакие Ваши системные настройки не влияют на функцию createFromAscii. Можно использовать системную кодировку вместо Unicode (но всё равно нужно будет пользоваться указанным конструктором, принимающим char*), но тогда оно перестанет работать, как только Вы запуститесь на Linux с кодировкой KOI8, и попробуете открыть файл с иероглифами в имени.

А код, который я представил, будет работать всегда, и можно использовать и на Windows. Ну, почти всегда: ведь Linux позволяет имена файлов вообще использовать бинарные...
Записан

С уважением,
Михаил Каганский
sokol92
Мастер
*****
Offline Offline

Пол: Мужской
Сообщений: 939


WWW
« Ответ #8: 17 Июнь 2022, 15:50 »

Про Unicode и другие кодировки в Linux.

Кстати, для MS Windows код из #2 может корректно работать с русскими буквами только в случае, если кодовой страницей по умолчанию является Windows-1251.
« Последнее редактирование: 17 Июнь 2022, 15:58 от sokol92 » Записан

Владимир.
mikekaganski
Гуру
*******
Offline Offline

Пол: Мужской
Расположение: Хабаровск -> Москва
Сообщений: 2 774


« Ответ #9: 17 Июнь 2022, 16:01 »

для MS Windows код из #2 может корректно работать с русскими буквами только в случае, если кодовой страницей по умолчанию является Windows-1251.

Вы про первый или про второй фрагмент из #2? Потому что первый будет работать всегда, а второй - никогда для не-Ascii.
Записан

С уважением,
Михаил Каганский
sokol92
Мастер
*****
Offline Offline

Пол: Мужской
Сообщений: 939


WWW
« Ответ #10: 17 Июнь 2022, 16:47 »

Второй. Написал "на автомате", не посмотрев внимательно.  Грустный
Записан

Владимир.
Страниц: 1   Вверх
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!