Свежие комментарии

Да, бывает. Бывает и кирпич вместо айфона, по слухам.

Но тут - был явно не тот случай, просто по времени не сходилось.

Бывает и так:
http://virtualshopping.livejournal.com/8346963.html
http://virtualshopping.livejournal.com/8352379.html

у меня больше 10 посылок в разной степени доставки висят
с ноября - декабря
и недели две вообще с почты никаких вестей

но твой случай вообще удивительный
кто-то там явно химичит и по башке получить должен!

У Винды есть CreateFileA и CreateFileW.
Первая работает с обнобайтовыми строками в кодировке MBCS (то есть со строками, каждый символ которой занимает 1 или 2 байта; по идее может быть и большее количество, но в MSDN указывается, что символы длинее 2х байтов не поддерживаются), вторая с честными двух-байтовыми юникодными строками (каждый символ которых всегда занимает ровно 2 байта).

C-шные fopen и _wfopen внутри используют именно CreateFileA и CreateFileW, соответственно.

Более подробная информация по этим ссылкам:
http://msdn.microsoft.com/en-us/library/5z097dxa.aspx
http://msdn.microsoft.com/en-us/library/cwe8bzh0.aspx

Очень хорошо про разницу MBCS и юникода расписано тут:
http://www.codeproject.com/KB/string/cppstringguide1.aspx

В некотором смысле, виндовый MBCS - это аналог UTF8, так как тоже имеются специальные управляющие коды и разные символы кодируются различным количеством байтов.

Вообще-то под Виндой "безобидный" char*, прилетающий от системы (через GUIшные контролы или через параметры командной строки) - это вовсе не восьмибитовые ACSII-строки, как можно было бы ожидать, а строки в так называемой multi-byte кодировке.
Для русского языка этот MBCS вырождается в ASCII, так как одного байта вполне хватает для таблицы cp1251, а вот во всяких японских и китайских локалях один символ на экране соответствует двум и более char'ам в строке, которую получит приложение.

Ну и сама система работает с этим зоопарком в согласованном стиле, то есть если мы получили на вход (то есть от пользователя) строку в MBCS, то можем вполне передавать эту строку далее, во всякие там CreateFile и прочие функции. Соответственно, можно ожидать, что Cшный fopen нормально отреагирует на аргумент в MBCS (с MS VC это точно так, насчет других компиляторов нужно проверять).

Всё это, естественно, только в том случае, если по-китайски вводят имя файла в системе с установленным системным китайским языком.
Для русской системы китайская MBCS-строку - полная чушь и наоборот.
То есть если вдруг понадобится работать сразу с несколькими языками, то придется всё делать только через wchar, тут уж без вариантов.

1) Подать заявление "хочу у вас"
2) Встреча с управляющей, чтобы в глаза посмотреть, подпись договора
3) Собственно открыл счет, положил туда немного денег, подал заявление на интернет-банк
4) получил клиент-банковские потроха

Но, правда, с тех пор - ни разу не был.

Под Windoze в общем случае только _wfopen() потому что 8-битовая кодировка зависит от локали.
Впрочем, перекодировать из UTF8 довольно просто, так что один из возможных подходов - решить, что библиотека работает только в UTF8, и уже внутри перекодировать как надо.
Можно, впрочем, и в обратную сторону примерно так же.

Вот, кажется
http://nedbatchelder.com/blog/201106/filenames_with_accents.html

Что с ним делать понятно. На то в errno.h есть EBADF. А как его возвращать вызывающему - ну так же как возвррается EIO.

Но в общем я именно за то и не люблю Qt и им подобные, что они крайне плохо стыкуются со всем что должно поддерживтаь еще что-то кроме них.

Да, он есть, но в том месте, куда передается filename (LibRaw) - нельзя передать дескриптор.

И делать такой интерфейс, с дескриптором, не хочется, по куче причин. Передадут туда сокет (в котором нету seek) и что с ним делать?

В Qt все есть, но что мне с их файлов проку?

А что, в Qt еще своей обертки для открытия файлов, получающей QString нет? Я думал что там уже это, совсем для всего обертки есть. Если уж они свой database abstraction layer написали...

А в библиотеке для win32 нужно еще бы TCHAR поддержать. Который в зависимости от не помню уже каких дефайнов будет либо char, либо wchar_t.

Не надо заставлять это делать ПОЛЬЗОВАТЕЛЯ. Сильно извратиться - значит сделать это внутри программы.
Хотя, похоже проще сделать свою обертку вокруг fopen, которая будет сначала звать MultiByteToWideChar с явным указанием 65001, а потом уже _wfopen.
И #ifdef _WIN32 останется во одном include.

В Linux можно уже считать что "отдаем в utf-8 и будет счастье".
Уже несколько версий как все дистрибутивы по умолчанию ставят локаль utf-8.
А GNOME начал навязывать utf-8 как кодировку файловой системы еще несколько раньше.
Так что сейчас про фокусы с переменной среды G_FILENAME_ENCODING уже можно забыть.
Тем более что за пределами Gtk-based GUI-шных программ никто на эту переменную особо и не смотрел.
В Win32 если очень извратиться можно выставить utf-8 (aka code page 65001) в качестве "национальной" кодировки.