Здравствуйте, xmen, Вы писали:

X>Необязательно в данном случае конвертить. Например, работаю с UNICODE, а мне нужно вызвать ANSI функцию, то
X>пишу MessageBoxA(....) и никаких проблем.

X>WinUser.h
X>

X>...
X>#ifdef UNICODE
X>#define MessageBox  MessageBoxW
X>#else
X>#define MessageBox  MessageBoxA
X>#endif // !UNICODE
X>...
X>

Не совсем так. В исходном примере (который можно почитать чуть выше, если не полениться) была задача передавать один параметр как unicode строку, второй — как ansi. Таких стандартных функций (кроме функций конвертирования), насколько я знаю — нет.

Здравствуйте, stream15, Вы писали:

CS>>Проблемы возникают когда у тебя на диске наличествуют имена на русском и китайском (они хранятся как надо — в LPCWSTR).
CS>>Прграмма которая работает с LPCSTR именами файлов в лучшем случае просто не будет работать.
CS>>На русском Windows твоя программулина будет думать что китайский это такой русский.
CS>>В китайском Windows она будет мужественно щурить глаза и пытаться коды русских букв интепретировать
CS>>как коды иероглифов.

S>Благодарю, за разъяснения.

S>Что касается вопросительных знаков, то это не просто дебагер показывал. Это были натуральные
S>вопросительные знаки. Возможно потому, что у меня китайская кодовая страничка не установлена.
S> Во всяком случае функция DrawText выводила строку именно так.

DrawText к этим "???" отношения не имеет. DrawText(A/W) рисует то что им дают.
Если DrawTextу не удалось найти символ какой в установленных шрифтах то он рисует знак
"missed glyph" — эдакий прямоугольник.

"???" появляются в результате конвертирования LPWCSTR строки в LPCSTR функцией

 ::WideCharToMultiByte(CP_ACP, .... ,LPCSTR lpDefaultChar, LPBOOL lpUsedDefaultChar )

Где: lpDefaultChar это:

[in] Points to the character used if a wide character cannot be represented in the specified code page. If this parameter is NULL, a system default value is used. The function is faster when both lpDefaultChar and lpUsedDefaultChar are NULL.

system default value это очевидно и есть этот знак вопроса.

Вот такие вот индейские национальные лодки.

CS>Блин... оторвал бы все детородные органы тому челу который придумал строки называть ANSI.
CS>ANSI это American National Standard Institute. И собственно к способу кодирования символов в Windows это имеет
CS>вообще никакое отношение.

Небольшое имеет:

ANSI Windows code pages, and specially the code page 1252, are called that way since they were purportedly based on drafts submitted or intended for ANSI. However, ANSI and ISO have not standardized any of these code pages.

Ну, господи, это как RJ45 или ксерокс с памперсом — ну все привыкли так называть, так пусть называют. Или для успокоения души подходящую аббревиатуру можно придумать, которая будет не американский институт стандартов, но тоже будет сокращенно "ANSI" — как сделали с RSS.

Здравствуйте, Аноним, Вы писали:

А>Как можно его переименовать в ansi — имя
А>или получить к нему доступ
А>по ansi-имени. "Смешанных" функций
А>типа MoveFile(LPCWSTR, LPCSTR) в API
А>по-видимому нет.

Вам надо преобразовать ANSI'ную строку в UNICODE, и использовать MoveFileW, с двумя юникодными строками на входе.

Здравствуйте, stream15, Вы писали:

S> Но Функция GetShortFileName дает ansi-путь к файлу. И это имеет — в моем случае- свои преимущества.

Это очень кривое решение. Например, эти короткие имена могут быть просто выключены на файловой системе.

А> Есть файл с unicode — именем.
А>Как можно его переименовать в ansi — имя
А>или получить к нему доступ
А>по ansi-имени.

MutliByteToWideChar + CreateFileW

Вообще, про ANSI в виндах пора забывать.

X>просто я думал, что у меня все имена файлов в UNICODE.

Да. Вообще вся ОС работает в Юникоде, а ANSI поддерживается только как обертка над Юникодом.

S>вопросительные знаки. Возможно потому, что у меня китайская кодовая страничка не установлена.

Это означает, что китайские иероглифы _в ANSI_ на этом компе не могут быть поняты. Никак.

Совет: навсегда забудьте про ANSI/DBCS тут же и сразу, если речь о китайском.

CS>>На русском Windows твоя программулина будет думать что китайский это такой русский.
CS>>В китайском Windows она будет мужественно щурить глаза и пытаться коды русских букв интепретировать
CS>>как коды иероглифов.

Реально зависит все не от языка локализации, а от настройки Language For Non-Unicode Programs

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, stream15, Вы писали:

S>> Но Функция GetShortFileName дает ansi-путь к файлу. И это имеет — в моем случае- свои преимущества.

Pzz>Это очень кривое решение. Например, эти короткие имена могут быть просто выключены на файловой системе.

Спасибо за информацию. Тогда это решение действительно годится только для домашнего использования.

Юрий

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Аноним, Вы писали:

А>>Как можно его переименовать в ansi — имя
А>>или получить к нему доступ
А>>по ansi-имени. "Смешанных" функций
А>>типа MoveFile(LPCWSTR, LPCSTR) в API
А>>по-видимому нет.

Pzz>Вам надо преобразовать ANSI'ную строку в UNICODE, и использовать MoveFileW, с двумя юникодными строками на входе.

Спасибо, я понял.
Других надежных вариантов нет.

Здравствуйте, stream15, Вы писали:

S>Каждый файл в системе имеет DOS — alias 8.3

файл на NTFS может не иметь такого алиаса. это настраивается в реестре.