В какой кодировке имена файлов windows

Обновлено: 03.07.2024

1. Версия Windows.
2. Что нужно (пдробно опиши)?
3. Чего так много смайликов?

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

Видел текст с крякозяблами? Ну а это то же самое, но с именами файлов и папок.

1. В папке с файлами в командной строке:
dir /b > list1.txt

2. Полученный текстовый файл list1.txt перевести в нужную кодировку и сохранить как list2.txt. Перекодировщиков много.

4. Сохранить полученный файл с расширением .bat и запустить в командной строке.


Добавлено:
Не прокатит, если в именах есть пробелы.

ren "строка1 из list1" "строка1 из list2"
ren "строка2 из list1" "строка2 из list2"

момент интересный.
если скопировать такое кривое имя в редактор: который умеет перекодировать текст, то все будет ок.

если же, в консоли (cmd.exe) вывод кинуть в текстовый файл, то такой текстовый файл уже не перекодировать.

исходная кодировка иникод UTF-8. виндовс никак не хочет понять ее через консоль.

Для меня это странно. Я считал, что виндовс имеет, как говорят, эту самую сквозную уникодность. консоль гонит код в DOS кодировку и если чего не понимает, то такой код - пиши пропало, вообще.

Там несколько программ упоминаются, может, подойдет какая.

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

кстати, какой аналог униховой команде "cat", в cmd?
в справке висты, вообще, ничего не нашел по этой консольке.
одни темы:
как открыть команд промт?
зачем открывать команд промт?
а что такое команд промт?
вы ли открываете команд промт?

Я уже начинаю думать. А что это? А команд промт ли это?! А как мне может помочь команд промт? А я ли это?

фиг с ней. поставлю Linux, скопирую в него нужные файлы и перекодирую. иначе с ума сойду.

Но, все равно, спасибо. Я все понимаю. Это же не униховая ось. Тут уже о таких мелочах никто из разработчиков и не думает. Все ручками, если что.
цигвин, с этой локалью, думаю, тоже ничего не поймет.

copy /b file1 + file2 file3
результат: file3 = file1 + file2

copy /b file1 + file2 + file3 + . + fileN fileOUT
результат: fileOUT = сумма всех file1..fileN
Ограничение: полная длина ком. строки <= 255 (вроде бы, точно не помню ) символов. Плюсы можно ставить без пробелов.

Вывод на экран: type file

Чем-то похоже на "векторный фидонет" Медведева ))))

Надо будет запомнить )

Что такое "koi-8 раздел", что-то Unix-овское?

Ага Russian partition table с медведЯми По улицам.. ))

Google не находит такую программку, можно ссылку?

Надо будет попробовать.

Автору названия, сказанного здесь, Спасибо за информацию И полезно и прикольно

Просто "file renamer"-ов огромное количество. Ты найди именно "nova file renamer"

NTFS сохраняет имена файлов в Юникоде. Напротив, в старых файловых системах FAT12, FAT16 и FAT32 используется набор символов OEM. Дополнительные сведения см. в разделе Кодовые страницы.

приложения не в юникоде, создающие файлы FAT, иногда должны использовать стандартные функции преобразования библиотеки времени выполнения C для преобразования между кодировкой кодовой страницы Windows и кодировкой кодовой страницы OEM. При реализации функций файловой системы в Юникоде нет необходимости выполнять такие переводы.

приложение может использовать универсальные строковые типы, как описано в разделе типы данных Windows для строк. Приложение также может использовать прототипы универсальных функций, используя методы, описанные в разделе соглашения о прототипах функций. Для универсальных строковых типов или прототипов универсальных функций приложение может использовать один исходный файл для компиляции либо версии Юникода, либо не поддерживающей Юникод. Чтобы это сделать, приложение предоставляет макросы для функций, которые не вызываются при компиляции для Юникода.

В файловых системах NTFS и FAT специальные символы имени файла: " \ ", "/", ".", "?" и " * ". На кодовых страницах OEM эти специальные символы находятся в диапазоне ASCII символов (от 0x00 до 0x7F). Их эквиваленты в Юникоде представляют собой одинаковые значения в 2-байтовой форме, символ 0x0000 через 0x007F.

Windows кодовые страницы и кодовые страницы OEM code, используемые в операционных системах на японском языке, содержат символ [¥) вместо обратной косой черты ( \ ). Таким словами, символ «символы» является запрещенным для файловых систем NTFS и FAT. При сопоставлении Юникода с кодовой страницей на японском языке WideCharToMultiByte и другие функции преобразования сопоставляют обратную косую черту (u + 005C) и Стандартный символ Юникода в Юникоде (u + 00A5) этому же символу. По соображениям безопасности приложения обычно не должны допускать символ U + 00A5 в строке Юникода, которую можно преобразовать для использования в качестве имени файла FAT. Дополнительные сведения см. в разделе вопросы безопасности: международные функции.

Я только начинаю программирование для обработки имен файлов с неанглийскими именами в системе WinXP. Я сделал некоторые рекомендуемые чтения на unicode, и я думаю, что я понял основную идею, но некоторые части все еще не очень ясны для меня.

в частности, какая кодировка (UTF-8, UTF-16LE/BE) является файлом имена (не содержимое, а фактическое имя файла), хранящееся в NTFS? Можно ли открыть любой файл с помощью fopen (), который принимает char*, или у меня нет выбор, но использовать wfopen (), который использует wchar_t* и предположительно принимает строку UTF-16?

Я попытался вручную подать строку в кодировке UTF-8 в fopen (), например.

но это вышло как 'ê°€.txt'.

У меня создалось впечатление (которое может быть неправильным), что строки с кодировкой UTF8 будет достаточно для открытия любого имени файла под Windows, потому что я, кажется, смутно помню, что какое-то приложение Windows проходило (char*), а не (wchar_t*) и не имело проблемы.

может кто-нибудь пролить свет на это?

NTFS хранит имена файлов в UTF16, однако fopen использует ANSI (не utf8).

чтобы использовать имя файла в кодировке UTF16, вам нужно будет использовать версии Unicode открытых вызовов файлов. Этого defineing Unicode и символ _unicode в вашем проекте. Затем используйте вызов CreateFile или вызов wfopen.

fopen ()-в MSVC в windows (по умолчанию) не принимает кодировку utf-8*.

к сожалению, utf-8 был изобретен сравнительно недавно в великой схеме вещей. API Windows разделены на версии Unicode и Ansi. Windows api, который принимает или имеет дело со строками, фактически доступен с W или суффиксом-W для "широкого" символа / Unicode и A для Ansi. Macro magic скрывает все это от разработчика, поэтому вы просто вызываете CreateFile с помощью char* или wchar_t* в зависимости от конфигурации сборки, не зная разницы.

кодировка "Ansi" на самом деле не является конкретной кодировкой:- но означает, что кодировка, используемая для строк "char", специфична для настройки локали ПК.

теперь, поскольку функции C-runtime-такие как fopen - должны работать по умолчанию без знаний разработчика - в системах windows они ожидают получить свои строки в локальной кодировке windows. msdn указывает на microsoft C-runtime api setlocal может изменить локаль текущего потока , но конкретно говорит, что он потерпит неудачу для любых локалей, которым требуется более 2 байтов на символ, подобный utf - 8.

Итак, в Windows нет ярлыка. Вы нужно использовать wfopen или собственный API CreateFileW (или создать проект с помощью параметров сборки Unicode и просто вызвать Createfile) со строками wchar_t*.

однако этот подход не поможет при вызове библиотек, которые используют fopen() безусловно, потому что они не поддерживают Unicode или потому, что они написаны в портативном C. В этом случае все еще можно использовать устаревшие "короткие пути" для преобразования строки в кодировке UTF-8 в форму ASCII с fopen , но это требует некоторой беготни:

преобразовать представление UTF-8 в UTF-16 с помощью MultiByteToWideChar .

использовать GetShortPathNameW чтобы получить "короткий путь", который является ASCII-only. GetShortPathNameW вернет его в виде широкой строки с содержимым all-ASCII, которое вам нужно будет тривиально преобразовать в узкую строку с помощью копирования без потерь каждый wchar_t char .

1 вместо kinto-un-筋斗雲 ).

хотя это не совсем рекомендуемая долгосрочная стратегия, поскольку короткие пути Windows являются устаревшей функцией, которую можно отключить на том, Это, вероятно, единственный способ передать имена файлов в код, который использует fopen() и другие вызовы API, связанные с файлами ( stat , access , ANSI версии CreateFile и подобные).

Здравствуйте. У меня вопрос связанный с кодировочными таблицами в операционных системах. Изрыл весь интернет по своему вопросу, 3 дня искал на разных поисковиках, ответа так и не нашёл, возможно кто-то из спецов здесь поможет в данном вопросе?

Windows XP/Vista/7 - в них я создаю файл/папку и первым-же делом машина мне присваивает на файл/папку имя ("Новая папка" или "Текстовый документ.txt") дальше уже меняешь имя как хочешь, т.е. ни файл ни папка вообще без имени существовать не могут.

Вопрос такой: в какой кодировке он мне прописал это русское имя созданной папки/файла? Например винда русская делает это в ASCII но если я создам папку/файл в Linux Ubuntu 14.04 с русским именем, то он мне должен русские символы создать в UTF-8, но как это проверить. ведь в убунте может для русских автоматически тот-же ASCII использовать. И проблема в том, что когда я всё это скину на USB-флешку и воткну её в др. систему, например Mac OS X у меня будет что-то вроде: лдвтлдмвы если конечно-же в Маке нет ASCII <- будет ли такое на самом деле?

И вообще, как проверить кодировку русских символов ? Например я хотел в какой нить оси (пусть даже portable или урезанной) найти её кодировочные таблицы, удалить все кроме UTF-8 (русской/китайской/корейской) и на ней я сразу бы знал что пишу я имя файла русскими символами из кодовой таблице UTF-8, вставив флешку с папками/файлами сразу бы увидел кракозябры которые могут быть чем угодно но не UTF-8 и *знал бы это* - своего рода получился бы детектор кодировок не utf8.

В поисках места нахождения кодировочных таблиц у windows xp понял что их там тупо нет! она использует псевдо-кодировку вытаскивая всякие символы из всяких там шрифтов так чтоб в итоге соответствовало кодовым стандартным таблицам, но самих таблиц нет.

Может кто нибудь посоветовать операционную систему, которая использует кодовые таблицы, в которой я оставлю только таблицы utf8 - разных языков, в том числе и русских симвоов (система не запорится т.к. ось пишется на англ. символах и цифрах а их местоположение во всех кодировках одинаково (вроде)).

Или может ли помочь какой нить дистрибутив который не знает ASCII будет писать русские имена файлов в utf? но тут ещё вопрос, мне нужен именно utf-8, не 16 не 32 не KOI*** а именно utf8.

Читайте также: