юникод же

Разглядел в теме Qt. Используй Qt'ные классы и должно всё быть ОК.

http://stackoverflow.com/questions/5444959/read-a-text-file-line-by-line-in-qt

Низя, на Qt только гуйня, зачем оно мне в уже готовом бэке? Там половину переписывать придется.

Консоль?

ну так приведи все к локали текущей. Или консоль сделай не досовой кодировки. Этож венда. вот тебе кривой лисапед. А в с++11 уже есть изкоробки вроде.

    static std::string w2mb( LPCWSTR src, UINT CodePage = CP_ACP )
    {
        int cch = WideCharToMultiByte( CodePage, 0, src, -1, 0, 0, 0, 0 );
        if( 0 != cch ) {
            std::vector<char> data;
            data.resize( cch + 1 );

            WideCharToMultiByte( CodePage, 0, src, -1, &data[0], (DWORD)data.size( ), 0, 0 );
            return &data.front( );
        }
        return "";
    }

    static std::wstring mb2w( LPCSTR src, UINT CodePage = CP_ACP )
    {
        int cch = MultiByteToWideChar( CodePage, 0, src, -1, 0, 0 );
        if( 0 != cch ) {
            std::vector<wchar_t> data;

            data.resize( cch + 1 );
            MultiByteToWideChar( CodePage, 0, src, -1,  &data[0], (DWORD)data.size( ));
            return &data.front( );
        }

        return L"";
    }

Тогда плюсую анонима выше. С++11 можно?

Низя, на Qt только гуйня, зачем оно мне в уже готовом бэке?

А зачем вы используете русские имена файлов, если это бэкэнд, и юзеру не видно?

Да, конечно можно.

Имя файла в std::cout выводит верно, но файл не открывает.

http://paste.omsklug.com/5209/

А зачем вы используете русские имена файлов, если это бэкэнд, и юзеру не видно?

Юзеры, к сожалению, используют.

Юзеры используют backend? Значит это не совсем backend...

Исходники в какой кодировке?

UTF-8, вестимо.

Это виртуальное разделение.

ПО не задумывалось для онтопика, GUI приделывать тоже не предпологалось.

Проблема в том, что винда UTF-16, поэтому либо Qt, раз разделение виртуальное, либо пробуй как аноним написал выше. Можешь ещё вот тут посмотреть http://stackoverflow.com/questions/30829364/open-utf8-encoded-filename-in-c-w...

Грусть, думаю пойду по пути рефакторинга.

(boost::)nowide

(boost::)nowide

Да, я читал это, но по религиозным причинам не потащу ошметки буст туда, где уже укоренились ошметки Qt.

utf8nowhere

Хих)

boost скорее дополняет STL, чем Qt. Но это на любителя, да. В backend я б его включил, но это имхо.

не потащу ошметки буст

http://cppcms.com/files/nowide/html/#standalone_version

Я тебя люблю :*

Рабочий сниппет: http://paste.omsklug.com/5210/

Зависимости: вот это.

Ты автор этой Cppcms?

Читаешь ввод в вектор байт. В зависимости от кодировки перекодируешь в то что тебе нужно каким нибудь codecvt.

Рабочий сниппет: http://paste.omsklug.com/5210/

А что, без такой акробатики с QString не работает?

Я автор статей, текстов и постов

Ты автор этой Cppcms?

Нет. Ещё я не автор манифеста «UTF-8 Everywhere». И многого другого.

Можно без 'toUtf8()', сразу 'toStdString()'.

Вот так? Не работает.

А сразу argv[1], как на сайте, не работает?

Совсем не так.

Зависимости: вот это.

В какой среде и как это под винду собрать? Пробовал в msys2 mingw64, cmake жалуется на неизвестную конфигурацию, но генерирует Makefile. При сборке валится на линковке тестов.

Или ты просто скопировал .h-файлы и .cpp-файл в проект?

Проблема в том, что винда UTF-16

Это не проблема, это wchar_t такой. А в оффтопном приложениии может быть в зависимости от настроек проекта MultiByte character set, Unicode charachter set и т.д. А на входе может быть чоугодно: в локали UTF-8 c BOM и без — энивей, под оффтопиком или под онтопиком There Ain't No Such Thing As Plain Text :) Аналогично под онтопиком wchar_t UTF-32 — и UTF-8 надо в него таки конвертить и обратно, иначе можно получать от частично читабельной кашки (в части совпадения UTF-8 с ASCII) до совершенно нечитабельной: «множество приложений Linux делают „глупые предположения“, что UTF-8 означает, что они не должны ничего менять, чтобы сделать их код работать правильно w.r.t. стандарт Unicode, и по-прежнему можете использовать обычный char * S везде и не обращать внимание на вещи» (c) Пользуешься внутре L"Литераламе" или wchar_t — не делай предположений о входном тексте, если не сам его генерил :)

wchar_t

В этом и фишка, что его без надобности мало кто использует. Хорошо это или плохо - хз.

В этом и фишка

Это не фишка, это предпосылки для багов от ручного байтоебства, если им не пользуются, там где надо :)

там где надо

Я не про ручное байтоёбство, а про то, что в 90% случаях хватает std::string / char.

Именно в этом и заключается профанация: наивное предположение что это «хватает в 90% случаев» — тупо отложенный выстрел в ногу и «таймбомб» (это даже хуже чем преступление, это ошибка чем буфер

char buf[100500];

предположение что это «хватает в 90% случаев»

Неверное предположение, т.к. этого хватает в 100% случаев.

Еще один :) Перепись мамкиныйх хакиров продолжается.

Хорошо это или плохо - хз.

Само существование wchar_t — это величайшая катастрофа. wchar_t это главный экспонат в IT Hall of Shame.

Да-да, мистер виндузятник, 640 КБ и двух байт на символ хватит всем.

Пф... Использование std::string или велосипедов ничем не лучше :) Обычное игнорирование граблей до первого попадания на них желательно с мат. ответственностью :)

Мистер упоротый красноглазик, аргументов кроме вашего личного синдрома пингвиненка у вас нет :)

Обычное игнорирование граблей до первого попадания на них

— это типичный вендоподход. До сих пор куча «unicode-aware» софта предполагает, что «2 байта это символ».

Нет. Это типичное высокомерие дезориентированных в детстве «люникс-погромистов» «эффективных кодеров»(ТМ), которым не кому было ебнуть по рукам стальной линейкой«сделать код ревью ВЫТЕКЛИ ГЛАЗА КРОВЬ КИШКИ» :) — поэтому они на зло мамке морозят ушипублично и не стесняясь голосуют за прибивание гвоздями, хардкод буферов, предположения о других системах и условиях использования кода (внезапная писанина логов внутрь установочного пакета на маке :)), велосипеды для манипуляций с мультибайт-последовательностями или игнор их природы внутри std::string («ой, какой-то мусор в буфере с паролем и длина какая-то странная»), подбор решения методом тыка и пр. дурные привычки под соусом «все так делают» и экстраполяция сложившегося подхода «хорошо слежавшегося говна» в будущее пока Леннарт не найдет фатальный недостаток :)

Это типичное высокомерие дезориентированных в детстве «люникс-погромистов» «эффективных кодеров»

Выражаю вам искренние соболезнования в связи дезориентированным детством. Уверен, у вас ещё есть шанс перестать быть «эффективным кодером».

Сейчас бы указатели на локальные объекты повозвращать

А где там?

А, там же неявное конструирование строки из char*, не увидел сначала.

Качаешь архивчик, распаковываешь. Открываешь cmd.exe и идешь в эту директорию. Выполняешь cmake.exe и опосля mingw32-make (разумеется у тебя должен иметься и CMake и конпелятор). На выходе получается libnowide.a.

В свой проект втыкаешь вот ето:

if(WIN32)
    # nowide
    include_directories("C:/nowide_standalone")
    add_library(nowide STATIC IMPORTED)
    set_target_properties(nowide PROPERTIES IMPORTED_LOCATION "C:/nowide_standalone/libnowide.a")
    target_link_libraries(${PROJECT_NAME} nowide)
endif(WIN32)

Вуаля!

Из UTF-8 емулятора терминала от баша вроде работает, но мне это не надо, это не мой кейс.

Покажи как надо.

Это замечательно.