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


S> Нет другого выбора как использовать unicode — вариант функции DragQueryFileW

S>иначе мы получим ansi — строку вопросительных знаков. То есть, в приложении мы имеем Unicode — имя

Это так тебе показывает дебагер. Символы там те которые тебе надо — суть иероглифы.
Просто в этой строке символы содержатся в multibyte encoding.
А именно DBCS в случае китайского Windows.

S>файла. И в то же время к этому файлу необходим доступ по ansi — имени. Вот и все.

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

Рубим себе на носу следующее:

LPCWSTR в Windows это строка в кодировке UTF-16 — в простонародье сие известно как unicode строка.
LPCSTR в Windows это строка в системной (не точное имя) кодировке (одно и двухбайтовые). Программисты-механизаторы называют это ANSI-строками.
Для русского Windows например это CP-1251 кодировка.
Эта системная кодировка в Windows устанавливается в
"Control Panel"
"Regional Language Options"
"Advanced"
"Language for non-unicode programs"

Имя файла представленное в LPCSTR и в этой системной кодировке всегда может быть переведено в
LPCWSTR и наоборот.

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

вы не понимаете что делаете

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

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

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

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

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

X>>А как различить ansi имя файла от UNICODE?

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

X>Вот функция CreateFileA:
X>

X>.7C801A28|  mov         edi,edi
X>.7C801A2A:  push        ebp
X>.7C801A2B:  mov         ebp,esp
X>.7C801A2D:  push        d,[ebp][08]
X>.7C801A30:  call       .07C80E104  ---↓ (1)  // Имя файла ANSI -> UNICODE
X>.7C801A35:  test        eax,eax
X>.7C801A37:  je         .07C801A57  ---↓ (2)
X>.7C801A39:  push        d,[ebp][20]
X>.7C801A3C:  push        d,[ebp][1C]
X>.7C801A3F:  push        d,[ebp][18]
X>.7C801A42:  push        d,[ebp][14]
X>.7C801A45:  push        d,[ebp][10]
X>.7C801A48:  push        d,[ebp][0C]
X>.7C801A4B:  push        d,[eax][04]
X>.7C801A4E:  call        CreateFileW  ---↓ (3) // Вызов CreateFileW имя файла уже в UNICODE.
X>                                              // Отсюда следует, что все имена файлов в UNICODE.
X>.7C801A53:  pop         ebp
X>.7C801A54:  retn        0001C
X>.7C801A57:  or          eax,-001
X>.7C801A5A:  jmps       .07C801A53  ---↑ (4)
X>.7C801A5C:  nop
X>

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

Хочу еще раз более конкретно описать ситуацию, надеюсь это расставит все точки над i.

Файл для обработки бросают в окно приложения операцией D&D. У файла имя — китайские иероглифы.

Нет другого выбора как использовать unicode — вариант функции DragQueryFileW

иначе мы получим ansi — строку вопросительных знаков. То есть, в приложении мы имеем Unicode — имя

файла. И в то же время к этому файлу необходим доступ по ansi — имени. Вот и все.

Юрий

Здравствуйте!

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

И соответственно обратная задача,
Ansi — имя -> unicode — имя

Спасибо,

Юрий

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

А>вы не понимаете что делаете

Возможно, но проблема в том, что у меня есть файл
с UNICODE именем. Есть модуль, в который
мне нужно передать этот файл при запуске как аргумент.
и этот модуль принимает на входе ansi — строку.
Пока я просто создаю новый файл с ansi — именем
и копирую в него файл с Unicode — именем.
Возможно есть более красивое решение.

По крайней мере для чего мне это нужно я понимаю.

Юрий

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

А> Здравствуйте!

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

А>И соответственно обратная задача,
А>Ansi — имя -> unicode — имя

А>Спасибо,

А>Юрий

WideCharToMultiByte, MultiByteToWideChar — оно?

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

А>>вы не понимаете что делаете

S>Возможно, но проблема в том, что у меня есть файл
S>с UNICODE именем. Есть модуль, в который
S>мне нужно передать этот файл при запуске как аргумент.
S>и этот модуль принимает на входе ansi — строку.
S> Пока я просто создаю новый файл с ansi — именем
S>и копирую в него файл с Unicode — именем.
S> Возможно есть более красивое решение.

есть две функции:

FILE *fopen( const char *filename, const char *mode );
FILE *wfopen( const wchar_t *filename, const wchar_t *mode );

Они обе позволяют открыть один и тот же файл:

FILE *f = fopen( "vasya.txt", "r" );
FILE *f = wfopen( L"vasya.txt", L"r" );

Операционная система внутри хранит все файлы с именами в unicode.

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

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

А>>>вы не понимаете что делаете

S>>Возможно, но проблема в том, что у меня есть файл
S>>с UNICODE именем. Есть модуль, в который
S>>мне нужно передать этот файл при запуске как аргумент.
S>>и этот модуль принимает на входе ansi — строку.
S>> Пока я просто создаю новый файл с ansi — именем
S>>и копирую в него файл с Unicode — именем.
S>> Возможно есть более красивое решение.

CS>есть две функции:

CS>

CS>FILE *fopen( const char *filename, const char *mode );
CS>FILE *wfopen( const wchar_t *filename, const wchar_t *mode );
CS>

CS>Они обе позволяют открыть один и тот же файл:
CS>

CS>FILE *f = fopen( "vasya.txt", "r" );
CS>FILE *f = wfopen( L"vasya.txt", L"r" );
CS>

CS>Операционная система внутри хранит все файлы с именами в unicode.

c-smile и SaZ, благодарю за предложения.

SaZ, здесь вопрос не в том чтобы перекодировать строку из Unicod в ANSI,
а в том, чтобы переименовать файл, который имеет Unicode имя в Ansi
имя.

с-smile, Как мне кажется Ваше решение не совсем годится. Если я правильно
понял, вы предлагаете преобразовать unicode строку имени в ansi-строку
и уже по этой ansi-строке получить доступ у файлу с unicode — именем.
Для случая китайских иероглифов, которые, как я представляю, не имеют
аналога в ANSI, это не сработает, Вы получите строчку вопросительных знаков.

Мне предложили такое решение. Каждый файл в системе имеет DOS — alias
8.3 И узнав его, можно работать с файлом через этот alias, так же как
через имя. Аlias можно получить с помощью функции GetShortFileNameW
Правда alias вернется в unicode. но в нем только ansi символы и полученную
строку можно преобразовать в ansi — имя с помощью соответствующей функции
и работать с файлом уже через это имя.

stream

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

S>Мне предложили такое решение. Каждый файл в системе имеет DOS — alias
S>8.3 И узнав его, можно работать с файлом через этот alias, так же как
S>через имя. Аlias можно получить с помощью функции GetShortFileNameW
S>Правда alias вернется в unicode. но в нем только ansi символы и полученную
S>строку можно преобразовать в ansi — имя с помощью соответствующей функции
S>и работать с файлом уже через это имя.

Работайте везде с юникодом. Чем плохо?

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

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

S>>Мне предложили такое решение. Каждый файл в системе имеет DOS — alias
S>>8.3 И узнав его, можно работать с файлом через этот alias, так же как
S>>через имя. Аlias можно получить с помощью функции GetShortFileNameW
S>>Правда alias вернется в unicode. но в нем только ansi символы и полученную
S>>строку можно преобразовать в ansi — имя с помощью соответствующей функции
S>>и работать с файлом уже через это имя.

SaZ>Работайте везде с юникодом. Чем плохо?

С эитм трудно не согласится. Но не всегда есть выбор.
Если вы используете чужой модуль, которому нужно при
запуске передать имя файла в ansi, а у вас он с unicode
именем, то других вариантов нет.

А как разлечить ansi имя файла от UNICODE?

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

X>А как различить ansi имя файла от UNICODE?

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

Вот функция CreateFileA:

.7C801A28|  mov         edi,edi
.7C801A2A:  push        ebp
.7C801A2B:  mov         ebp,esp
.7C801A2D:  push        d,[ebp][08]
.7C801A30:  call       .07C80E104  ---↓ (1)  // Имя файла ANSI -> UNICODE
.7C801A35:  test        eax,eax
.7C801A37:  je         .07C801A57  ---↓ (2)
.7C801A39:  push        d,[ebp][20]
.7C801A3C:  push        d,[ebp][1C]
.7C801A3F:  push        d,[ebp][18]
.7C801A42:  push        d,[ebp][14]
.7C801A45:  push        d,[ebp][10]
.7C801A48:  push        d,[ebp][0C]
.7C801A4B:  push        d,[eax][04]
.7C801A4E:  call        CreateFileW  ---↓ (3) // Вызов CreateFileW имя файла уже в UNICODE.
                                              // Отсюда следует, что все имена файлов в UNICODE.
.7C801A53:  pop         ebp
.7C801A54:  retn        0001C
.7C801A57:  or          eax,-001
.7C801A5A:  jmps       .07C801A53  ---↑ (4)
.7C801A5C:  nop

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

SaZ>>Работайте везде с юникодом. Чем плохо?

S> С эитм трудно не согласится. Но не всегда есть выбор.
S>Если вы используете чужой модуль, которому нужно при
S>запуске передать имя файла в ansi, а у вас он с unicode
S>именем, то других вариантов нет.

Ну тогда чуть выше, я написал, какие функции юзать. Конвертируете и используете.

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

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

SaZ>>>Работайте везде с юникодом. Чем плохо?

S>> С эитм трудно не согласится. Но не всегда есть выбор.
S>>Если вы используете чужой модуль, которому нужно при
S>>запуске передать имя файла в ansi, а у вас он с unicode
S>>именем, то других вариантов нет.

SaZ>Ну тогда чуть выше, я написал, какие функции юзать. Конвертируете и используете.

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

WinUser.h

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

S>Мне предложили такое решение. Каждый файл в системе имеет DOS — alias
S>8.3 И узнав его, можно работать с файлом через этот alias, так же как
S>через имя. Аlias можно получить с помощью функции GetShortFileNameW
S>Правда alias вернется в unicode. но в нем только ansi символы и полученную
S>строку можно преобразовать в ansi — имя с помощью соответствующей функции
S>и работать с файлом уже через это имя.

А почему тебе не предложили GetShortFileNameA?

Имена файлов храняться в юникоде, CreateFileA не что иное как говоря языком грубого псевдокода
CreateFileA(some ansi params)
{
..convert ansi strings to unicode
return CreateFileW(converted params)
}

Соответственно ваш вопрос смысла не имеет.
А пареименовать можно файл из имени которое содержит непредставимые в текущей анси кодировки символы в имя, которое таковых не содержит. Конечно это уже будет другое имя.
А может вам просто достаточно строки сконвертировать из юникода в анси?

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

А>Имена файлов храняться в юникоде, CreateFileA не что иное как говоря языком грубого псевдокода
А>CreateFileA(some ansi params)
А>{
А>..convert ansi strings to unicode
А>return CreateFileW(converted params)
А>}

А>Соответственно ваш вопрос смысла не имеет.
А>А пареименовать можно файл из имени которое содержит непредставимые в текущей анси кодировки символы в имя, которое таковых не содержит. Конечно это уже будет другое имя.
А>А может вам просто достаточно строки сконвертировать из юникода в анси?


В принципе конечно можно переименовать файл вначале в unicode строку состоящую из ansi — символов
, а затем получить к нему доступ по конвертированной ansi-строке. Я об этом как — то не подумал.
И это можно использовать в моем случае.

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


Благодарю,
Юрий

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

А>вы не понимаете что делаете

+

Давно не видел такого точного ответа!

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

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


S>> Нет другого выбора как использовать unicode — вариант функции DragQueryFileW

S>>иначе мы получим ansi — строку вопросительных знаков. То есть, в приложении мы имеем Unicode — имя

CS>Это так тебе показывает дебагер. Символы там те которые тебе надо — суть иероглифы.
CS>Просто в этой строке символы содержатся в multibyte encoding.
CS>А именно DBCS в случае китайского Windows.

S>>файла. И в то же время к этому файлу необходим доступ по ansi — имени. Вот и все.

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

CS>Рубим себе на носу следующее:

CS>LPCWSTR в Windows это строка в кодировке UTF-16 — в простонародье сие известно как unicode строка.
CS>LPCSTR в Windows это строка в системной (не точное имя) кодировке (одно и двухбайтовые). Программисты-механизаторы называют это ANSI-строками.
CS>Для русского Windows например это CP-1251 кодировка.
CS>Эта системная кодировка в Windows устанавливается в
CS>"Control Panel"
CS> "Regional Language Options"
CS> "Advanced"
CS> "Language for non-unicode programs"

CS>Имя файла представленное в LPCSTR и в этой системной кодировке всегда может быть переведено в
CS>LPCWSTR и наоборот.

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

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

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

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

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

+ От души посмеялся

Здравствуйте, 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, с двумя юникодными строками на входе.

А> Есть файл с 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 может не иметь такого алиаса. это настраивается в реестре.