Юникодные имена файлов что это
Обновлено: 06.07.2024
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. Дополнительные сведения см. в разделе вопросы безопасности: международные функции.
Статья рассчитана на обычных людей - неспециалистов, которые даже сейчас в век полной поддержки компьютерами любых языков вплоть до эльфийского всё-таки иногда сталкиваются с непониманием современными программами букв, отличных от основной латиницы
Иногда я с ностальгией и каким-то тёплым трепетом вспоминаю времена, которые, казалось, навсегда канули в лету. Времена, когда при включении компьютер спрашивал дату и время. Времена, когда на одну дискету помещалась операционная система, файловый менеджер и несколько игр, а цветной монитор даже с 16 цветами и соответствующей видеокартой оставался недостижимой мечтой. Характерной чертой вплоть до середины 90-х оставалась невозможность использовать кириллицу в именах файлов, папок, в командах. Да в общем-то нигде, кроме, разве что, содержимого файлов. Там можно было печатать по-русски, но и то это требовало дополнительной настройки и специальной программы.
Я рад, что застал эти времена. Рад, что до сих пор у меня в путях и именах "технических" файлов почти нет кириллических символов. Но сейчас это скорее привычка, чем необходимость. Я уже лет 15 не сталкивался с программами, предназначенными для широкого круга пользователей и не понимающих символы, отличные от основной латиницы и эта статья никогда бы не появилась, если бы не всплеск проектов на блокчейне. Проектов, среди которых встречаются интересные ещё не законченные со своими нюансами, в том числе и таким неприятным.
Установив клиент одного из таких проектов я приготовился исследовать его, тем более, это вознаграждалось и был очень быстро огорчён. Ошибки, как из рога изобилия просили меня связаться с разработчиками почти никогда не объясняя суть ошибки. Хотя в одной конкретной ситуации причина была указана - несовпадение кодировок.
Далее непосредственно решение проблемы
Начиная с Windows 2000 professional для обычных пользователей стала доступна файловая система NTFS, с которой профессионалы работали на тот момент уже давно. В ней среди функций, к которым как правило мало описания присутствует возможность для одного файла или папки назначать несколько имён .
Вы не найдёте эту функцию ни в проводнике, ни где-либо ещё в стандартных программах, кроме разве что командной строки, поэтому для удобства нужно будет скачать дополнительную программу, но если вы освоитесь в жёстких и символических ссылках, то сможете не только решить описываемую проблему, но и легко перенести на другой диск папки, которые по-умолчанию не предлагают выбора пути, например огромный массив блоков Etherium или ту же папку "Мои документы", если она у вас достаточно велика. Ведь места на диске C как правило немного.
Есть несколько программ для создания жёстких и символических ссылок. Я лично использую Total commander с нужным плагином, но здесь мы рассмотрим более простую альтернативу - Junction Link Magic . Если же кто-то захочет поэкспериментировать, то может найти самостоятельно другую утилиту. Некоторые из них были освещены в статье на Гигтаймс .
При запуске Junction Link Magic предложит сканировать компьютер на предмет уже существующих жёстких и символических ссылок и точек монтирования. Если согласитесь, то вы увидите, насколько много их уже на вашем компьютере. Да, сама Microsoft пользуется такими обходными манёврами для совместимости со старыми программами
Обратите внимание на кнопку "Remove". Эта кнопка удаляет ссылку. НИКОГДА НЕ УДАЛЯЙТЕ ССЫЛКИ, КОТОРЫЕ СОЗДАЛИ НЕ ЛИЧНО ВЫ - это может привести к серьёзным проблемам в операционной системе.
Нажимаем Create. и открывается диалог создания ссылки
Слева выбираете папку, которая превратиться в ссылку, а справа настоящую папку.
Для каждой ссылки в левом окне создавайте отдельную папку! Не используйте существующие . Указав на папку C:\Пользователи\Вася справа и на вновь созданную папку D:\vasya нажимаем Create и получаем результат - оба пути - это одно и тоже.
Внизу слева есть кнопка New folder, которая создаёт новую папку, но после создания она не отображается в диалоге (возможно это только у меня), поэтому лучше приготовиться заранее и создать нужные папки вручную
На этом всё. Перед экспериментами обязательно создайте точку восстановления системы. Это никогда не повредит.
A имя файла или имя файла - имя, используемое для однозначной идентификации компьютерного файла , хранящегося в файловая система . Различные файловые системы накладывают разные ограничения на длину файлов и допустимые символы в именах файлов.
Имя файла может включать один или несколько из следующих компонентов:
Компоненты, необходимые для идентификации файла, различаются в разных операционных системах, как и синтаксис и формат допустимого имени файла.
Содержание
История
Примерно в это же время появилась точка (точка или точка) в качестве разделителя расширений имени файла, и ограничение до трех буквенных расширений могло происходить из-за ограничений кодировки символов 16-бит RAD50 .
Традиционно большинство операционных систем поддерживали имена файлов только с верхним регистром буквенно-цифровые символы , но с течением времени количество разрешенных символов увеличивалось. Это приводило к проблемам совместимости при перемещении файлов между разными файловыми системами.
В 1985 году RFC 959 официально определил путь как строку символов, которая должна быть введена в файловую систему пользователем. для идентификации файла.
Перенос Unicode
Одной из проблем был переход на Unicode. Для этой цели несколько компаний-разработчиков программного обеспечения предоставили программное обеспечение для переноса имен файлов в новую кодировку Unicode.
- Microsoft предоставила прозрачную для пользователя миграцию в рамках технологии vfat
- Apple предоставила «Утилиту восстановления кодировки имен файлов v1.0».
- Сообщество Linux предоставило «convmv ”.
Mac OS X 10.3 ознаменовала принятие Apple декомпозиции символов Unicode 3.2, заменившей использовавшуюся ранее декомпозицию Unicode 2.1. Это изменение вызвало проблемы у разработчиков, пишущих программное обеспечение для Mac OS X.
Ссылки: абсолютные и относительные
Абсолютные ссылки включают все уровни каталогов. В некоторых системах ссылка на имя файла, которая не включает полный путь к каталогу, по умолчанию указывает на текущий рабочий каталог . Это относительная ссылка. Одним из преимуществ использования относительной ссылки в файлах конфигурации программы или сценариях является то, что разные экземпляры сценария или программы могут использовать разные файлы.
Таким образом абсолютный или относительный путь состоит из последовательности имён файлов.
Количество имен на файл
Unix-подобные файловые системы позволяют файлу иметь более одного имени; в традиционных файловых системах в стиле Unix это имена жестких ссылок на индексный дескриптор файла или его эквивалент. Windows поддерживает жесткие ссылки в файловых системах NTFS и предоставляет команду fsutil в Windows XP и mklink в более поздних версиях для их создания. Жесткие ссылки отличаются от ярлыков Windows , классических Mac OS / macOS псевдонимов или символических ссылок . Введение LFN с VFAT позволило использовать псевдонимы файлов. Например, longfi
1. . с максимум восемью плюс тремя символами был псевдонимом имени файла «длинное имя файла. . » как способ соответствия 8.3 ограничения для старых программ.
Это свойство использовалось алгоритмом команды перемещения, который сначала создает второе имя файла, а затем удаляет только первое имя файла.
Другие файловые системы, по замыслу, предоставляют только одно имя файла для каждого файла, что гарантирует, что изменение файла с одним именем файла не изменит файл с другим именем.
Ограничения длины
Особая проблема файловых систем, которые хранят информацию во вложенных каталогах, заключается в том, что можно создать файл с полным путем, превышающим ограничения реализации, поскольку проверка длины может применяться только к отдельным частям имени, а не к все имя. Многие приложения Windows ограничены значением MAX_PATH , равным 260, но имена файлов Windows могут легко превысить этот предел [1] .
Расширения имен файлов
Многие файловые системы, включая FAT , NTFS и VMS разрешают расширение имени файла , которое состоит из одного или нескольких символов, следующих за последней точкой в имени файла, разделение имени файла на две части: базовое имя или основу и расширение или суффикс, используемый некоторыми приложениями для обозначения типа файла . Несколько выходных файлов, созданных приложением, используют одно и то же базовое имя и разные расширения. Например, компилятор может использовать расширение FOR для исходного входного файла (для кода Fortran), OBJ для вывода объекта и LST для листинга. Хотя есть некоторые общие расширения, они произвольны, и другое приложение может использовать REL и RPT . В файловых системах, которые не разделяют расширения, файлы часто имеют более длинные расширения, такие как html .
Совместимость кодирования
Не существует общего стандарта кодирования для имен файлов.
Поскольку имена файлов должны обмениваться между программными средами (например, передача файлов по сети, хранилище файловой системы, программное обеспечение для резервного копирования и синхронизации файлов, управление конфигурацией, сжатие и архивирование данных и т. Д.), Очень важно не терять информацию об имени файла между приложениями. Это привело к широкому внедрению Unicode в качестве стандарта для кодирования имен файлов, хотя устаревшее программное обеспечение могло не поддерживать Unicode.
Взаимодействие индикации кодирования
Традиционно, имена файлов допускали использование любых символов в именах файлов, если они были безопасными для файловой системы. Хотя это позволяло использовать любую кодировку и, таким образом, позволяло представлять любой локальный текст в любой локальной системе, это вызывало множество проблем совместимости.
Имя файла может быть сохранено с использованием разных байтовых строк в разных системах внутри одной страны, например, если в одной из них используется японская кодировка Shift JIS и японская кодировка EUC . Преобразование было невозможно, так как большинство систем не отображали описание кодировки, используемой для имени файла, как часть расширенной информации о файле. Это заставляло дорогостоящее угадывать кодировку имени файла при каждом доступе к файлу.
Решением было принять Unicode в качестве кодировки для имен файлов.
Однако в классической Mac OS кодировка имени файла хранилась с атрибутами имени файла.
Совместимость с Unicode
Стандарт Unicode решает проблему определения кодировки.
Тем не менее, остаются некоторые ограниченные проблемы совместимости, такие как нормализация (эквивалентность) или используемая версия Unicode. Например, UDF ограничен Unicode 2.0; В файловой системе macOS HFS + применяется нормализация NFD Unicode и, возможно, учитывается регистр (по умолчанию регистр не учитывается). Максимальная длина имени файла нестандартна и может зависеть от размера единицы кода. Хотя это серьезная проблема, в большинстве случаев она ограничена.
В Linux это означает, что имени файла недостаточно для открытия файла: кроме того, точное байтовое представление имени файла на устройстве хранения необходим. Это может быть решено на уровне приложения с помощью некоторых сложных вызовов нормализации.
Проблема эквивалентности Unicode известна как «конфликт нормализованных имен». Решением является ненормализующая осведомленность о композиции Unicode, используемая в технических сообществах Subversion и Apache. Это решение не нормализует пути в репозитории. Пути нормализованы только для сравнения. Тем не менее, некоторые сообщества запатентовали эту стратегию, запрещая ее использование другими сообществами.
Перспективы
Чтобы ограничить проблемы взаимодействия, некоторые идеи, описанные Sun, заключаются в следующем:
- использовать одну кодировку Unicode ( например, UTF-8)
- выполнять прозрачное преобразование кода для имен файлов
- не хранить нормализованные имена файлов
- проверять каноническую эквивалентность между именами файлов, чтобы избежать двух канонически эквивалентных имен файлов в одном и том же каталог.
Эти соображения создают ограничение, не позволяющее переключиться на будущую кодировку, отличную от UTF-8.
Уникальность
В пределах одного каталога имена файлов должны быть уникальными. Поскольку синтаксис имени файла также применяется к каталогам, невозможно создать файлы и записи каталога с одинаковыми именами в одном каталоге. Несколько файлов в разных каталогах могут иметь одно и то же имя.
Подход к уникальности может различаться как в зависимости от регистра, так и в форме нормализации Unicode , например NFC, NFD. Это означает, что могут быть созданы два отдельных файла с одним и тем же текстовым именем файла и разной байтовой реализацией имени файла, например L "\ x00C0.txt" (UTF-16, NFC) (латинская заглавная A с могилой) и L "\ x0041 \ x0300.txt "(UTF-16, NFD) (латинская заглавная A, объединение могил).
Сохранение регистра букв
Некоторые файловые системы, такие как FAT , хранят имена файлов в верхнем регистре, независимо от того, какой регистр букв использовался для их создания. Например, файл, созданный с именем «MyName.Txt» или «myname.txt», будет сохранен с именем «MYNAME.TXT». Для обозначения одного и того же файла можно использовать любые вариации верхнего и нижнего регистра. Такие файловые системы называются без учета регистра и не с сохранением регистра . Некоторые файловые системы вообще запрещают использование строчных букв в именах файлов.
Некоторые файловые системы хранят имена файлов в том виде, в котором они были изначально созданы; они называются с сохранением регистра или с сохранением регистра . Такая файловая система может быть с учетом регистра или без учета регистра . Если учитывается регистр, то «MyName.Txt» и «myname.txt» могут относиться к двум разным файлам в одном каталоге, и при ссылке на каждый файл необходимо указывать тот же регистр, которым он назван. С другой стороны, в файловой системе без учета регистра и с сохранением регистра только одно из «MyName.Txt», «myname.txt» и «Myname.TXT» может быть именем файла в заданном каталоге в заданное время, и на файл с одним из этих имен можно ссылаться, используя любую заглавную букву имени.
С самого начала Unix и производные от нее системы сохраняли регистр. Однако не все Unix-подобные файловые системы чувствительны к регистру; по умолчанию HFS + в macOS не чувствителен к регистру, а серверы SMB обычно обеспечивают нечувствительность к регистру (даже если базовая файловая система чувствительна к регистру, например, Samba в большинстве Unix-подобных систем), а клиентские файловые системы SMB обеспечивают нечувствительность к регистру. Файловая система чувствительность к регистру представляет собой серьезную проблему для программного обеспечения, такого как Samba и Wine , которое должно эффективно взаимодействовать с обеими системами, которые обрабатывают файлы в верхнем и нижнем регистре как разные, и с системами, которые обрабатывают их как то же самое.
Зарезервированные символы и слова
Файловые системы не всегда предоставляют один и тот же набор символов для создания имени файла. До того, как Unicode стал стандартом де-факто, файловые системы в основном использовали набор символов, зависящий от локали. Напротив, некоторые новые системы допускают, чтобы имя файла состояло практически из любого символа из репертуара Unicode и даже некоторых последовательностей байтов, отличных от Unicode. Ограничения могут быть наложены файловой системой, операционной системой, приложением или требованиями к взаимодействию с другими системами.
Многие утилиты файловой системы запрещают управляющие символы появляться в именах файлов. В Unix-подобных файловых системах запрещены нулевой символ и разделитель путей / .
В Windows
Утилиты файловой системы и соглашения об именах в Windows запрещают использование определенных символов в именах файлов:
пять \ и \ шесть \ (пример экранирования)
'пять и шесть или "пять и шесть (примеры цитирования)
Символ 0xE5 не разрешался в качестве первой буквы в имени файла в 86-DOS и MS-DOS / PC DOS 1.x- 2.x, но может использоваться в более поздних версиях.
В утилитах Windows пробел и точка не допускаются в качестве последнего символа имени файла. Точка допускается в качестве первого символа, но в некоторых Windows приложения, такие как Проводник Windows , запрещают создание или переименование таких файлов (несмотря на то, что это соглашение используется в Unix-подобных системах для описания скрытых файлов и каталогов). Обходные пути включают добавление точки, когда переименование файла (который впоследствии автоматически удаляется) с использованием альтернативных файловых менеджеров , создание файла с помощью командной строки или сохранение файла с желаемым именем из приложения.
Некоторые файловые системы в данной операционной системе tem (особенно файловые системы, изначально реализованные в других операционных системах) и определенные приложения в этой операционной системе могут применять дополнительные ограничения и интерпретации. Подробнее об ограничениях см. сравнение файловых систем .
В Unix-подобных системах, DOS и Windows имена файлов "." и ".." имеют особое значение (текущий и родительский каталог соответственно). Windows 95/98 / ME также использует имена типа «. », «. » и т. Д. Для обозначения каталогов прародителей или прародителей. Все версии Windows запрещают создание имен файлов, состоящих только из точек, хотя имена, состоящие из трех точек («. ») или более, допустимы в Unix.
Кроме того, в утилитах Windows и DOS некоторые слова также зарезервированы и не могут использоваться в качестве имен файлов. Например, DOSфайлы устройств :
Системы с этими ограничениями вызывают несовместимость с некоторыми другими файловыми системами. Например, Windows не сможет обработать или создать отчеты об ошибках для этих допустимых имен файлов UNIX: aux.c, q "uote" s.txt или NUL.txt.
Имена файлов NTFS, которые используются внутри, включают:
Сравнение ограничений имени файла
Запрещает использование символов в диапазоне 1-31 (0x01-0x1F) и символов "* /: ? \ |, Если имя не помечено как находящееся в пространстве имен Posix. NTFS разрешает каждый компонент пути (каталог или имя файла) должно состоять из 255 символов.
Каким образом из-под bat-скрипта можно получить доступ к данному файлу, а также - создать файл с именем из комбинации таких же символов?
(Нужно решить задачу именно так, а не переименовав всё в ascii)
P.S.: Экспериментировал с ChCP, но ничего толкового не добился.
Тем более, NotePad++ предлагает bat-файл сохранить с юникодом…
Преобразование файлов и перенос их в папки(названия папок содержится в именах файлов)
Доброй ночи! Тяжело быть глупой, помогите автоматизировать (пишу полную задачу, но если это.
Копирование файлов из разных каталогов в каталоги с именами, соответствующими номерам в именах файлов
Добрый день! Помогите решить проблему. Есть семь папок (cam_1, cam_2, cam_3 и.т.д) с фотографиями.
Удалить оконцовку *-min в именах файлов
Приветствую всех. Помогите, пожалуйста, небольшим кодом :) Нужно удалять у всех файлов в.
Изменение формата даты в именах файлов
Друзья, добрый день! Подскажите пожалуйста, есть файлы с маской XXX_YYY-NAME.
Сохраните батник в UTF-8 без BOM.
P.S. А вот пытаться вводить такие имена в консоли не стоит - шрифты все равно не поддерживают.
Тaк в том то и дело, что запуская батю в utf-кодировке я получаю: P.S.: Пока не занимался попытками запуска utf-батника из-под ascii-батника - может поможет?(С другой стороны - не дело «плодить» батники: Надо функциональность уместить в одном файле…)
А что это за имя такое? Explorer ведь не поддерживает создание файлов содержащих эти символы в именах.
Разве что через API системы посредством специальной нотации \\?\. Хотя, насчет возможности последнего не уверен, поскольку не проверял.
В консоли cmd никакого нормального отображения большинства unicode символов не будет, поскольку шрифты консоли их просто не поддерживают.
Хотя, я так и не понял при чем тут unicode, если у вас просто невалидное NTFS имя файла.
Добавлено через 1 минуту
Да, я попробовал через python - система не дает использовать имя с “\”, “/”, “?”, “|”, “*”, “<”, “>” и “:” . Нотацией \\?\ и \\.\ получается только обойти запрет на зарезервированные имена типа AUX, CON, NUL, PRN, COM1-COM9 и LPT1-LPT9. И все.
P.S. Тогда возникает вопрос: а как у ТС тогда такой файл возник?!
Добавлено через 2 минуты
Или у него все-таки это имя:
Lucida console дает просто квадратик на место этого символа:
Alikberov,
может это кусок какого-то url-овского пути пытаетесь не понять куда и зачем запихнуть? Делo в том, что команда color не поддерживает частичного изменения цвета текста и интернет кишит трюками по этому поводу. Довольно любопытный - вот этот:
Где создаётся файл с уникальным именем, идентичному выводимому тексту. А так как особенность команды findstr в том, что имена файлов она подкрашивает, то её и используют для вывода цветных строчек.
Читайте также: