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

Есть файл с 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)
}

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

Здравствуйте, 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 — имени. Вот и все.

Юрий

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

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

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


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

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


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

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

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

+

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

Здравствуйте, 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 она будет мужественно щурить глаза и пытаться коды русских букв интепретировать
как коды иероглифов.

Здравствуйте, 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>как коды иероглифов.

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