У меня есть несколько приложений Windows, которые считывают путь к файлу из аргументов командной строки. Все работает без нареканий, кроме случаев передачи путей с не-ANSI-символами. Я ожидал этого, но не знаю, как с этим бороться. Вероятно, вопрос начального уровня, но это сводит меня с ума.
Мой текущий код выглядит так:
int main(int argc, char* argv[]) {
namespace po = boost::program_options;
po::options_description po_desc("Allowed options");
po_desc.add_options()
("file", po::value<std::string>(), "path to file");
po::variables_map po_vm;
try {
po::store(po::parse_command_line(argc, argv, po_desc), po_vm);
po::notify(po_vm);
} catch (...) {
std::cout << po_desc << std::endl;
return false;
}
const std::string file_path = po_vm["file"].as<std::string>();
// ...
}
Я обнаружил, что если я заменю тип file_path
с std::string
на boost::filesystem::path
, некоторые пути теперь читаются. Я точно не знаю, почему, но могу сделать вывод, что это должно быть с переводом из кодировки Latin1.
Например, имея следующие файлы:
malaga.txt
málaga.txt
mąlaga.txt
Первый всегда читается правильно, а второй терпит неудачу при использовании std::string file_path
, но не boost::filesystem::path file_path
. Третий всегда терпит неудачу.
Я пробовал переключить основную функцию на int main(int argc, wchar_t* argv)
и использовать std::wstring
в качестве типа аргумента, но это несовместимо с парсером boost::program_options
.
Как я могу правильно прочитать такие имена файлов Unicode?
chcp 65001
? - person daxim   schedule 02.12.2019main
среды выполнения C анализирует кодировку ANSI командной строки изGetCommandLineA
вместо командной строки Unicode изGetCommandLineW
. Нестандартная точка входаwmain
основана на собственной командной строке Unicode. Затем строкиwchar_t
могут быть закодированы как UTF-8 черезWideCharToMultiByte
, если приложению нужны байтовые строки. - person Eryk Sun   schedule 02.12.2019