Как поставить слэш в названии файла

Обновлено: 05.07.2024

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

Кто же прав? Есть какие-то стандарты, весомые аргументы и примеры, чтобы как говорится, "с цифрами в руках" доказать людям, что самое разумное в Windows ограничится в названии файла буквами латиницей, 0-9, не пытаться использовать ту же точку, после которой символы могут быть восприняты как расширение файла?

Цитата: в винде действуют только ограничения на длину имени в 256 символов Уже нет. Только в качестве рекомендаций.

Цитата: Причем нельзя именно анси их варианты, а вот, например, юникодовский ? можно быть не может.

Использовать можно, но в некоторых случаях нежелательно. Например, я никогда не буду на веб-сервере размещать файлы с кириллическими символами в имени. Даже пробелы стараюсь исключить, хотя с ними проблем не будет, просто не нравится, когда в адресной строке появляются %20.

Про не латиницу аналогично, проблемы могут возникнуть с неюникодовскими программами (которые вполне можно встретить).

Пробелы и точки можно было использовать ещё во времена DOS.
У разных ОС могут быть разные дозволения.
И кстати ж Винда сама сообщает какие символы нельзя:

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

Не рекомендовал бы использовать пробелы в именах. Возьмём linux, допустим пишем bash скрипт:
Код: declare -a res=($(find

-name name -execdir pwd ;)) Заполняем массив путями, в которых содержится name. Если в пути присутствует пробел, то путь будет разбит на две части и займет два элемента массива. Можно заставить работать команду правильно (в разных частях скрипта устанавливать необходимое значение IFS), но я просто не использую пробелы, так как в норме их не должно там быть.

Меня могут спросить: а при чём здесь Linux? Отвечаю: если не ошибаюсь, в win скриптах это тоже актуально (при запуске в командной строке .exe из Program Files приходится брать в кавычки). От спец символов тоже лучше отказаться (используются для шаблонов globbing).

Одного не понимаю: зачем нужно было вставлять пробел в "Program Files"?

Цитата: Заполняем массив путями, в которых содержится name. Если в пути присутствует пробел, то путь будет разбит на две части и займет два элемента массива. Пупец. Вы программу не правильно составили, Вам пробел виноват стал.
Цитата: при запуске в командной строке .exe из Program Files приходится брать в кавычки И в чем проблема? Для этого там кавычки и придуманы.
Цитата: зачем нужно было вставлять пробел в "Program Files"? Чтобы выглядело человечней. Нет, пусть лучше в шестнадцатеричной системе папки будем записывать - так программистам работать удобней.

Цитата: Я не считаю что пробелы в именах норма Но вообще-то это норма.

Я не знаю на каком Вы линуксе, в современных дистрах пробелы также обрабатываются. В том же ntfs/hpfs например. Используются такие же кавычки как и в винде.
Вот пример:
Цитата: ls "/home/user/Мои документы/"
ls '/home/user/Мои документы/'
ls /home/user/Мои документы/
ls "/home/user/Файл с "двойными кавычками" в названии"
ls '/home/user/Файл с "двойными кавычками" в названии'
ls /home/user/Файл с "двойными кавычками" в названии Цитата: В win может и норма, а в linux нет. Когда работал в линуксе также давал документам полноценные имена с пробелами и не испытывал от этого никаких проблем.

Когда работал в линуксе также давал документам полноценные имена с пробелами и не испытывал от этого никаких проблем. Разве я писал, что пробелы в путях линукс не может обрабатывать? У меня debian, не видел ни одного каталога или файла с пробелом, ни раз встречал рекомендации избегать пробелы в путях, согласен с этими рекомендациями. Понять это в полной мере можно после опыта написания shell скриптов (пути с пробелами можно обрабатывать, но не удобно). Если кто-то хочет создать себе лишние проблемы, то пусть использует пробелы. Мои_документы ничуть не хуже.

Цитата: Понять это в полной мере можно после опыта написания shell скриптов (пути с пробелами можно обрабатывать, но не удобно). Их и в винде обрабатывать не удобно . Потому что нет ни снипетов ни полноценной библиотеки скриптов. Каждый уважающий себя админ, должен всегда все писать с нуля на коленке и материть пробелы в путях файлов. А проблема высосана из пальца. То что в Дебиане нет пробелов тоже просто - они очень консервативны и раньше в путях не было пробелов, то и счас по старинке те же пути и соответственно пробелов нет. И вообще там есть даже стандарт на каталоги в корне точки монтирования, кто-то придерживается, кто-то нет.

Ничего не из пальца. Это как в C++ разрешить ; в именах, в трезвую голову это не придёт. Для подкрепления своей позиции процитирую документация Mingw:
Цитата: MinGW may have problems with paths containing spaces, and if not, usually other programs used with MinGW will experience problems with such paths. Thus, we strongly recommend that you do not install MinGW in any location with spaces in the path name reference. You should avoid installing into any directory or subdirectory having names like "Program Files" or "My Documents", etc.

Про MiniGW это проблемы MiniGW. Если мне разрешено создавать пробелы, я буду их создавать так как мне это удобно. Согласен. И чё за тема? Я хочу, что-бы всё было по моему, и не хочу обучаться. Финиш.

А в винде, если мешают пробелы, всегда можно воспользоватья короткими именами.

А так я согласен с Utkin - если кому-то мешают пробелы - это всецело его проблема. Меня вот бесят файловые системы которые различают строчные и прописные буквы.

Цитата: Плюс, данный подход с пробелами подталкивает к написанию ну очень длинных и неудобоваримых имён. Так Вы от них никуда не денетесь. принесут документ с винды и все, накрылась империя зла с короткими именами . Тут не огораживаться надо, а наоборот увеличивать возможности. А не принесут так почтой отправят и на поток поставят. Придет от партнера и/или учредителя. Тут как раз самое то - автоматизация почты, сортировка по папочкам/специалистам и прочая рутина - сам Торвальдс велел. А не судьба, потому что админ из чувства вредности и ностальгии помнит времена когда имена были английские без пробелов и не более 8 символов.

Всем спасибо за ответы!

Я была свидетелем того, как некоторые студенты с других факультетов называли свои презентушки и работы как Бог на душу положит - с пробелами, с использованием не латинских букв, а потом бегали как угорелые по университету и дергали людей с инфотехнологии - мол, у них экзамен/защита работы, а у них файл не открывается, потому как имя дано некорректно.

Цитата: , а у них файл не открывается, потому как имя дано некорректно. а.. Так это уже другой вопрос-то! Что и в чём не открывается?
Есть программы не умеющие работать (или криво работающие) с юникодом.
Например мой любимый Viewer не открывает фотографии, если в имени есть хитроюникодные символы. Но не потому что файл так нельзя называть, а программу сделали с багом.

Цитата: а у них файл не открывается, потому как имя дано некорректно. Это особенности программ уже. У меня из последних тупняков MySql Workbench не сохраняет в русской папке, сразу вылет (при этом сохраняемый файл, если существовал до этого, бесследно пропадает). По-русски имя можно, а папку куда сохраняется нельзя. Файловая система здесь не причем. Но короткие или там временные файлы я вообще называю 1.расширение Так быстрей и везде 100 процентов откроется.

Вот и шо Либо каждый раз переключай системную локаль и перезагружайсо, либо имей секас со всякими эмуляторами.

Надо просто объяснять всё полностью:В разных операционных системах могут быть разные требования к именам файлов; В современных операционных системах Windows в именах файлов запрещены следующие символы: / : * ? " < > | Некоторые буквосочетания являются зарезервированными, например проводник Windows не позволит вам назвать папку или файл латинскими буквосочетаниями "con" или "nul"; Некоторые программы могут не понимать слишком длинных имён папок/файлов; Некоторые программы могут не понимать кириллицу и/или символы юникода, не рекомендуется злоупотреблять ими; Некоторые слишком старые программы могут путаться, если в имени и/или в пути к файлу есть пробелы;

Цитата: Некоторые программы могут не понимать кириллицу и/или символы юникода, не рекомендуется злоупотреблять ими; А еще программы могут быть скомпилированы без поддержки юникода и другой локалью, и начнутся глюки.
А еще можно пытаться распаковать архив от архиватора без поддержки юникода/мультибайта (например, зип) созданный в другой локали и увидеть странные имена

Цитата: В современных операционных системах Windows в именах файлов запрещены следующие символы: / : * ? " < > | Их аски варианты, юникодовские прокатывают

Может просто надо пользоваться и писать нормальные проги? Чай не во времена доса живем.

Это и есть те некоторые/устаревшие программы о которых я написал.

Я пишу нормально всегда А XnView самая нормальная прога, просто с таким вот косяком (благо на практике почти не попадаются такие файлы), отписал им в поддержку.

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

Ограничение 255 символов. Нельзя использовать двоеточие (, знак вопроса(?), слэш, звездочку. На точки, запятые и пробелы в windows ограничений нет. С кириллицей проблемы могут возникнуть, если вдруг windows сломается.. Еще некоторые имена файлов зарезервированы системой, например prn. Кроме того имя файла и директории не могут совпадать. В других ОС кириллица может в вопросики превратиться и файлы станут недоступны.

А вот на днях, в попытке чиста позырить, установил Android Studio. И что б вы думали? Эта падла читает каталог C:UsersАдминистраторAppData как какую-то Latin-1 крякозябру! 2015 год! Последняя версия с официального сайта! Unicode везде и всюду!
Так что legacy еще ой как долго будет жить всем назло))
И не надо предлагать сразу называться приличным именем. В моей говносборке имя юзера зашито по дефолту))

Мне нужно создать файл с именем файла, например :>? , возможно ли это как-то? Windows это останавливает.

У каждого ограниченного символа есть другое значение или использование, поэтому, если имя файла или папки действительно содержит их, это может привести к возникновению Bad Things ™. Не возражаете, если я спрошу, почему вы пытаетесь это сделать? @ DMA57361, когда я делал это несколько лет назад, я проверял некоторые вещи. Если я правильно помню, результаты были забавными, но я не помню ничего особенно плохого . Самое большее, я просто не мог получить к ним доступ. (Хотя я полагаю, что это может вызвать проблемы, если, например, у вас есть файлы с именами a , b и вы a>b type a>b @moorecast, когда я делал это несколько лет назад, я создавал файлы / каталоги с фиктивными именами, а затем использовал редактор дисков, чтобы вручную устанавливать имена в записях каталога. Конечно, это было на томе FAT32, так что это было очень легко. Это было бы немного сложнее на томе NTFS. Mind if I ask why you are trying to do this? Может быть, реализовать (плохую) защиту от копирования ? «Мне нужно создать файл с именем файла, например:>?» - Сомневаюсь, что тебе нужно это сделать.

К сожалению, вы не можете использовать зарезервированные символы при создании папок или файлов, поскольку они являются частью системных функций.

То, что я рекомендую вам сделать, это просмотреть Character Map приложение - вы можете запустить и набрать charmap .

отсюда вы можете найти альтернативные символы, которые выглядят одинаково, например:

(скопируйте и вставьте их, вы увидите, что они разные)

Вместо косой черты / - вы можете использовать символ деления ∕

Вместо двоеточия : - вы можете использовать модификатор буквы двоеточия ꞉

@Arjan - только через командную строку .. даже тогда вы можете использовать клавишу табуляции для автозаполнения. Я использовал этот трюк для определенных ситуаций, например, когда мне нужно поставить вопрос в имени файла ( почему Microsoft оставил вопросительный знак зарезервированным? ఠ_ఠ) К сожалению, мне пришлось прекратить использовать любые символы не ASCII, потому что они вызывают проблемы с такими вещами, как программы дефрагментации, которые по какой-то причине кажутся неспособными перемещать файлы с символами Unicode в именах. ಠ Если подумать, этот ответ на самом деле тоже не отвечает на вопрос. Есть ответы ниже , что делать , так что это тоже должно быть просто комментарий.

Вы можете загрузиться с диска Linux (например, Knoppix ) и смонтировать раздел NTFS.

Linux имеет гораздо меньше ограничений на имена файлов, и позволит вам создавать такие имена (я пробовал).

Некоторые операционные системы запрещают отображение определенных символов в именах файлов: (Ресурс из Википедии )

\ backslash Также используется как разделитель компонентов имени пути в MS-DOS, OS / 2 и Windows (нет разницы между косой чертой и обратной косой чертой); разрешено в Unix имени файла

? знак вопроса, используемый в качестве подстановочного знака в Unix, Windows и AmigaOS; отмечает один символ Разрешено в Unix имена файлов

* звездочка используется в качестве подстановочного знака в Unix, MS-DOS, RT-11, VMS и Windows. Отмечает любую последовательность символов (Unix, Windows, более поздние версии MS-DOS) или любую последовательность символов в базовом имени или расширении (таким образом, « . » В ранних версиях MS-DOS означает «все файлы». Допускается в именах файлов Unix ,

: двоеточие используется для определения точки монтирования / диска в Windows; используется для определения виртуального устройства или физического устройства, такого как накопитель на AmigaOS, RT-11 и VMS; используется в качестве разделителя пути в классической Mac OS. Удваивается после имени в VMS, указывает имя узла DECnet (эквивалентно имени хоста NetBIOS (сеть Windows), которому предшествует "\".)

| вертикальная черта обозначает программную конвейеризацию в Unix и Windows; разрешено в именах файлов Unix

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

<меньше, чем используется для перенаправления ввода, разрешено в именах файлов Unix

> больше, чем используется для перенаправления вывода, разрешено в именах файлов Unix

, период разрешен, но последнее вхождение будет интерпретироваться как разделитель расширений в VMS, MS-DOS и Windows. В других ОС, обычно рассматриваемых как часть имени файла, допускается более одной полной остановки.

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

Кде о тебе заботится, да.

unicode же.
Мало тебе шкворца сняли, ой мало.

И правда, начертания различаются. А что это за символ такой?

действительно создаёт и открывает потом, по крайней мере на reiserfs

при отображении в заголовке начертания отличаются, но вводится как обычный слэш, а уж что отображается при показе пути не знаю

я ожидал, что в таком случае он подкаталоги должен создавать

grem ★★★★★ ( 02.08.18 14:40:10 )
Последнее исправление: grem 02.08.18 14:40:30 (всего исправлений: 1)

Вот да, я тоже такое ожидал.

Отличная фича, уже лет 5 по меньшей мере пользуюсь — не приходится ручками слеши копипастить.

Сомнительное решение, как по мне

уже лет 5 по меньшей мере пользуюсь — не приходится ручками слеши копипастить.

Зачем? Мне правда интересно, какие могут быть полезные сценарии применения у slash'ев или backslash'ев в названии файлов.

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

какой-нибудь секурити юзкейс можно придумать, в том и/или другом направлении

Понимаю, что вопрос глупый, но .
В ini файле сохраняю путь к файлу: "C:\1\1.txt", затем
считываю значение
CString m_strmyFile=AfxGetApp()->GetProfileString(strRazd,"NameFile");
После чего мне надо этот файл скопировать в другую
папку, но Win API функция CopyFile( ) (как и все остальные) работает если имя файла
использует двойной слэш, т. е. в моем случае - "С:\\1\\1.txt".
Когда я попытался в свою CString m_strmyFile с помощью Replace, Left,
Right и др. функций вставить "\\", то была выдана ошибка:
"error C2001: newline in constant".
Подскажите пожалуйста, как принято поступать в случаях
если путь задан в виде "C:\1\1.txt", а нужен в виде "С:\\1\\1.txt".

Хм. А мне кажется когда ты из любого файла считываешь какойнить путь его прога понимает также тоесть должно быть все ок.
Но если ладно не получается как говорится чем мудорней программа тем она идеальней я бы считал строку в переменную char потом стал помассивно искать \ если до этого символа \ еще не дошло то покачто все буквы копируются в другую переменную char b rfrnjrj z dcnhtnbk \ или \\ то сразу вставлять в тот вторичный char \\ вот и все.

Читайте руководства и справочники по языкам - это есть рулез. То, что ты прочитал из INI файла - никак преобразовывать уже не надо. Это правило (с двойными слешами, являющимися одной из escape-последовательностью) используется только тогда, когда ты указываешь имя файла в исходном тексте программы.

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