Имеются ли расширения файлов для какой-либо цели (для операционной системы)?

Разработчик Ubuntu дает вам начало со многими учебниками и ресурсами.

1
задан 27 July 2016 в 18:22

6 ответов

Здесь нет 100% черного или белого ответа.

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

Например, все файлы изображений Bitmap (обычно с расширением имени .bmp) должны начинаться с букв BM в первых двух байтах. Скрипты на большинстве языков сценариев, таких как Bash, Python, Perl, AWK и т. Д. (В основном все, что относится к строкам, начинающимся с # как комментарий), могут содержать shebang, как #!/bin/bash, как первая строка. Этот специальный комментарий указывает системе, с помощью которой приложение открывает файл.

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

Приложения могут, конечно, реализовать свои проверки файлов, но они хотят, включая проверку имени файла и расширения. Примером может служить Eye of Gnome (eog, стандартный просмотрщик изображений), который определяет формат изображения с помощью расширения файла и выдает ошибку, если он не соответствует содержимому. Будет ли это ошибка или функция может обсуждаться ...

Однако даже некоторые части операционной системы полагаются на расширения имен файлов, например. при разборе файлов вашего программного обеспечения в файле /etc/apt/sources.list.d/ - только файлы с расширением *.list получают разобранные все остальные игнорируются. Возможно, это не в основном используется для определения типа файла здесь, а для включения / отключения парсинга некоторых файлов, но это все еще расширение файла, которое влияет на то, как система обрабатывает файл.

И, конечно, пользователь-пользователь большая прибыль от расширений файлов, так как это делает тип файла очевидным, а также позволяет использовать несколько файлов с тем же базовым именем и разными расширениями, как site.html, site.php, site.js, site.css и т. д. Недостаток, конечно, это расширение файла и фактический тип / содержимое файла необязательно должны совпадать.

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

63
ответ дан 23 May 2018 в 07:45
  • 1
    Вы немного противоречите себе здесь: если стандартное средство просмотра изображений требует, чтобы имя файла заканчивалось .bmp, какая часть ОС вы говорите, зависит от содержимого файла, начиная с «BM»? AFAIK, единственные «магические числа, о которых заботится ядро, являются исполняемыми типами, включая специальный случай #!. Все остальное зависит от решения какого-либо приложения. – IMSoP 27 July 2016 в 21:20
  • 2
    @IMSoP Я не знаю точную реализацию eog, и я не знаю, почему они вообще интересуются именем файла. На мой взгляд, это ошибка. И, конечно, если файл назван " bmp " но его формат содержимого не соответствует, конечно же, будет ошибка. Конечно, каждое приложение решает, как проверять файлы, но в целом приложения Linux не должны полагаться на это имя. Кстати, вы можете использовать file commend для изучения типов файлов по их контенту. – Byte Commander 27 July 2016 в 22:12
  • 3
    Предложение, которое я оспариваю, следующее: «Linux ... определяет тип файла, изучая первые несколько байтов». Какое определение «Linux» вы используете в этом предложении? Существование утилиты file на самом деле ничего не доказывает; это полезный инструмент, который может существовать на любой ОС. Какая фундаментальная часть ОС делает запуск file более «правильным»? чем подталкивание имени файла? – IMSoP 28 July 2016 в 00:51
  • 4
    Обратите внимание, что файлы без расширения могут быть связаны с программой. – isanae 28 July 2016 в 05:09

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

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

Однако

Я хотел бы добавить слово с осторожностью.

Если у вас есть файлы в вашей системе из системы, которая использует ассоциацию имен файлов, файлы могут не иметь этих магических номеров или заголовков. Расширения имени файла используются для идентификации этих файлов приложениями, которые могут их прочитать, и при переименовании таких файлов могут возникнуть некоторые неожиданные эффекты. Например:

Если вы переименуете файл My Novel.doc в My-Novel, Libreoffice все равно сможет его открыть, но он будет открыт как «Без названия», и вам придется называть его еще раз, чтобы чтобы сохранить его (Libreoffice добавляет расширение по умолчанию, поэтому у вас будет два файла My-Novel и My-Novel.odt, что может раздражать)

Серьезно, если вы переименуете файл My Spreadsheet.xlsx в My-Spreadsheet, затем попытайтесь открыть его с помощью xdg-open My-Spreadsheet, вы получите это (потому что это фактически сжатый файл):

И если вы переименуете файл My Spreadsheet.xls к My-Spreadsheet, когда вы xdg-open My-Spreadsheet получаете сообщение об ошибке:

место открытия ошибки: приложение не зарегистрировано как обращение к этому файлу

(Хотя в обоих случаях он работает нормально если вы сделаете soffice My-Spreadsheet)

Если вы затем переименуете файл без продолжения в My-Spreadsheet.ods с помощью mv и попытаетесь его открыть, вы получите следующее:

[ ! d9]

(ремонт не работает)

И вам нужно будет снова установить исходное расширение, чтобы правильно открыть файл (тогда вы можете c (!)

TL; DR:

Если у вас есть не-родные файлы с расширениями имен, не удаляйте расширения, если все будет в порядке!

22
ответ дан 23 May 2018 в 07:45
  • 1
    В диспетчере архивов открывается документ MS Office нового типа (docx, xlsx, pptx и т. Д.) Без расширения файла, поскольку эти типы файлов представляют собой фактически обычные ZIP-файлы, содержащие все XML-документы и мультимедийные файлы, необходимые для определения содержимого документа. Формат файла ZIP-каталога с копией довольно распространен в настоящее время. – Byte Commander 27 July 2016 в 11:21
  • 2
    Уже много отличных ответов, но только один конкретный для libreoffice, который я заметил. Вы создаете файл с разделителями-запятыми (CSV) и сохраняете его как «test.csv», откроется окно с вопросом, какой тип разделителя вы используете (например, libreoffice Calc). Если вы переименуете этот файл в «test.cs», например, тогда откроется Writer Libreoffice. Итак, помимо примера ZIP, приведенного выше, похоже, что libreoffice использует расширение файла. – Ray 27 July 2016 в 11:31
  • 3
    Файловая система linux ничего не делает в отношении типов файлов. Все это зависит от программ, работающих поверх него. – Peter Green 27 July 2016 в 18:29
  • 4
    @PeterGreen Да, но тот факт, что программы присваивают ему значимость, означает, что это не «просто для людей». способом, например, классическим MacOS, было [имелось четырехбайтовый «тип файла»). и "приложение-создатель" поля, которые не были частью имени файла, поэтому ОС и приложения имели всю необходимую информацию, не глядя на расширения файлов] – Random832 27 July 2016 в 18:36
  • 5
    @PeterGreen Файловая система Windows ничего не делает и в отношении типов файлов. Графическая оболочка (проводник Windows) использует расширение файла, чтобы выбрать действие для двойного щелчка, но технически это просто программа, работающая поверх ОС, так же, как и Nautilus. Было бы вполне возможно написать файловый менеджер Linux с таким поведением или Windows, который изучил содержимое файла. – IMSoP 27 July 2016 в 20:19

Я хотел бы принять другой подход к этому из других ответов и бросить вызов понятию, что «Linux» или «Windows» имеют к этому какое-либо отношение (нести меня).

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

Поскольку каждый файл в системе Windows или Linux имеет как имя, так и содержимое, процессы, которые хотят знать тип файла, могут использовать либо «расширение», либо «магическое число», как они видят поместиться. Подход метаданных обычно недоступен, так как в большинстве файловых систем нет стандартного места для этого атрибута.

В Windows существует традиция использования расширения файла в качестве основного средства идентификации файла ; наиболее очевидно, что графический браузер файлов (File Manager в Windows 3.1 и Explorer в современных Windows) использует его, когда вы дважды щелкаете по файлу, чтобы определить, какое приложение запускаться. В Linux (и, в более общем плане, системах на базе Unix) существует более традиционная проверка содержимого; прежде всего, ядро ​​смотрит в начало файла, выполняемого непосредственно, чтобы определить, как его запустить; файлы сценариев могут указывать на использование интерпретатора, начиная с #!, за которым следует путь к интерпретатору.

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

рассмотрение содержимого файла довольно дорого по сравнению с рассмотрением имен файлов; поэтому, например, «найти все файлы с именем * .conf» будет намного быстрее, чем «найти все файлы, первая строка которых соответствует этой сигнатуре», содержимое файла может быть неоднозначным; многие форматы файлов на самом деле являются только текстовыми файлами, обработанными особым образом, многие другие являются специально структурированными zip-файлами, а определение точных подписи для них может быть сложным, так как файл действительно может быть действительным как несколько типов; HTML-файл также может быть действительным XML, zip-файл и объединенный вместе GIF-файл остаются действительными для обоих форматов. Сопряжение магического номера может привести к ложным срабатываниям; формат файла, который не имеет заголовка, может начинаться с байтов «GIF89a» и быть неверно идентифицированным как изображение GIF, переименовав файл, может быть удобным способом пометить его как «отключенный»; например изменение «foo.conf» на «foo.conf ~», чтобы указать, что резервная копия проще, чем редактирование файла, чтобы прокомментировать все его директивы и удобнее, чем перемещать его из автозагружаемого каталога; Аналогично, переименование файла .php на .txt будет сообщать Apache, чтобы он служил своим источником как обычный текст, а не передавал его в PHP-движок

Примеры программ Linux, которые по умолчанию используют имена файлов (но могут иметь другие режимы):

рассмотрение содержимого файла довольно дорого по сравнению с рассмотрением имен файлов; поэтому, например, «найти все файлы с именем * .conf» будет намного быстрее, чем «найти все файлы, первая строка которых соответствует этой сигнатуре». gcc будет обрабатывать файлы «.c» как C и «.cc» или «.C» как C ++
18
ответ дан 23 May 2018 в 07:45
  • 1
    У Windows также есть сильная традиция скрывать расширение, если оно «хорошо известно». и даже DOS допускает команду опускать .COM, .BAT и .EXE, автоматически ищет тех, кто определяет, какую фактическую программу выполнить. Такого рода традиции не существует. – Monty Harder 29 July 2016 в 00:59
  • 2
    Это должен быть принятый ответ. – Ave 31 July 2016 в 16:29
  • 3
    Это гораздо лучший ответ, но имеет одну фактическую ошибку ... сценарий нельзя сделать выполнимым, поместив #! в начале. Любой файл с его исполняемым битом (битами) может выполняться одним из нескольких способов. #!/bin/bash и аналогичные подписи просто указывают, какой интерпретатор использовать. Если такая подпись не указана, предполагается интерпретатор интерпретатора по умолчанию. Файл, содержащий только два слова «Hello World», но с установленным битом выполнения, попытается найти команду «Hello» при запуске. – DocSalvager 3 August 2016 в 00:33
  • 4
    @DocSalvager Хороший улов, это была неуклюжая формулировка, как и все. Я немного переформулировал это, чтобы пояснить, что shebang не делает исполняемым скриптом, он просто меняет , как выполняется. – IMSoP 3 August 2016 в 01:08

На самом деле, некоторые технологии полагаются на расширения файлов, поэтому, если вы используете эти технологии в Ubuntu, вам также придется полагаться на расширения. Несколько примеров:

gcc использует расширения для различения файлов C C ++. Без расширения практически невозможно отличить их (представьте себе файл C ++ без классов). многие файлы (docx, jar, apk) - это просто структурированные ZIP-архивы. Хотя вы обычно можете вывести тип из содержимого, это может быть не всегда возможно (например, Java Manifest является необязательным в файлах jar).

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

13
ответ дан 23 May 2018 в 07:45
  • 1
    Хорошо, что вы упомянули о программировании, но вы указали большую часть деталей. gcc является интерфейсом для файлов C, для файлов C ++ вам нужен либо интерфейс g++, либо интерфейс командной строки, чтобы указать язык. Более важна программа make, которая решает, использовать ли gcc или g++ для создания определенного файла - и make полностью зависит от шаблонов имен файлов (в основном расширений) для его соответствия правилу. – Ben Voigt 29 July 2016 в 21:50
  • 2
    @BenVoigt При компиляции файла с расширением .cc с gcc он действительно будет скомпилирован как C ++, и это описано в man gcc: «Для любого заданного входного файла суффикс имени файла определяет, какой тип компиляция выполнена: " а затем список расширений и способы их обработки. – hvd 30 July 2016 в 13:53
  • 3
    @hvd Тогда, возможно, это набор библиотек по умолчанию, который идет ужасно неправильно, если вы не используете правильный интерфейс. В любом случае make является ярким примером, потому что все, что он делает, основано на расширении файла. – Ben Voigt 30 July 2016 в 16:28
  • 4
    @BenVoigt make также является хорошим примером, но gcc полагается так же сильно на имена файлов. Вот пример, более понятный, чем .c vs .cc: для C, gcc использует суффиксы, чтобы определить, должен ли его первый шаг препроцессить (.c), скомпилировать (.i), собрать (.s), или ссылку (.o). Здесь я использую -E, -S и -c, чтобы сообщить gcc, где остановиться, но он использует имена файлов, чтобы знать, с чего начать. gcc something.cc не будет ссылаться на правые библиотеки для C ++, но он будет рассматривать файл как C ++, поэтому многие пользователи путаются сообщениями об ошибках, которые они получают при совершении этой ошибки. – Eliah Kagan 24 January 2017 в 17:56

Ваше первое предположение верно: расширения в Linux не имеют значения и полезны только для людей (и других не-Unix-подобных ОС, которые заботятся о расширениях). Тип файла определяется первыми 32 битами данных в файле, который известен как магический номер. Поэтому для сценариев оболочки требуется строка #! - чтобы сообщить операционной системе, какой интерпретатор должен вызывать. Без него сценарий оболочки представляет собой просто текстовый файл.

Что касается файловых менеджеров, они хотят знать расширения некоторых файлов, таких как .desktop файлы, которые в основном такие же, как и для быстрых клавиш Window, но с большим количеством возможностей. Но что касается ОС, то он должен знать, что находится в файле, а не то, что в его названии

6
ответ дан 23 May 2018 в 07:45
  • 1
    Это не совсем так. Существуют программы, которые ожидают определенного расширения. Наиболее часто используемый пример, вероятно, gunzip, который не будет распаковывать файл, если он не называется foo.gz. – terdon♦ 27 July 2016 в 12:27
  • 2
    Это реализация конкретного программного обеспечения. По большей части утилиты на unix-подобных системах не ожидают расширения. – Sergiy Kolodyazhnyy 27 July 2016 в 12:36
  • 3
    По большей части они этого не делают, нет. Однако ваше первое предложение утверждает, что они никогда не используются и имеют значение только для людей. Это не совсем так. gunzip - один из примеров, eog - другой. Кроме того, многие инструменты не будут автозаполнять имена без правильного расширения. Все, что я говорю, это то, что это немного сложнее, чем «расширения всегда неактуальны». – terdon♦ 27 July 2016 в 12:40
  • 4
    1 небольшая проблема: ОП спросил об операционной системе. «gunzip» и «eog» не являются операционной системой, но решили создать свои собственные ограничения (в случае gunzip) или метода (eog). «тим-тим» хоть. – Rinzwind 27 July 2016 в 20:49
  • 5
    @Serg Конечно, вы можете определить OS узко и получить тривиальный ответ на вопрос. Однако это не очень полезный ответ, потому что подавляющее большинство того, что пользователь делает с компьютером, связано с программным обеспечением, которое вы исключили. Обратите внимание, что вопрос контрастирует «только для людей». против «операционной системы»; Я не думаю, что они имели в виду «ядро». – IMSoP 29 July 2016 в 12:06

Это слишком большое для ответа на комментарий.

Имейте в виду, что даже «расширение» имеет много разных значений.

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

Linux имеет много файлов, таких как .conf или .list или .d или .c, которые имеют смысл, но на самом деле не являются расширениями в смысле 8.3. Например, Apache ищет /etc/apache2/sites-enabled/website.conf для своей директивы конфигурации. Хотя система использует MIME-типы и заголовки содержимого, а что не означает, что это текстовый файл, Apache (по умолчанию) все равно не будет загружать его, не заканчивая на .conf.

.c - это другое Великий. Да, это текстовый файл, но gcc зависит от main.c становится main.o и, наконец, main (после ссылки). Ни в коем случае система не использует расширение .c, .o или no, чтобы иметь какой-либо смысл в отношении контента, но материал после. имеет некоторое значение. Вероятно, вы бы настроили SCM игнорировать main.o и main.

Точка точки такова: расширения не используются так, как они есть в окнах. Ядро не будет выполнять файл .txt, потому что вы удалите часть .txt имени. Также очень приятно выполнить файл .txt, если установлено разрешение на выполнение. При этом они имеют смысл и по-прежнему используются на «компьютерном уровне» для многих вещей.

4
ответ дан 23 May 2018 в 07:45
  • 1
    Windows также не привязана к схеме именования x.3, у вас есть более длинные расширения там, как .doxc, .torrent, .part и т. Д. Просто многие форматы файлов и расширения уже были указаны обратно в то время, когда 8.3 именование все еще было чем-то, а более поздние форматы в основном просто адаптировали соглашение о использовании до трех букв. – Byte Commander 27 July 2016 в 13:07
  • 2
    Я не вижу, как «.conf», «.c» и т. Д. Являются «другим значением», от «значения 8.3». Концепция расширения файла может быть просто выражена как «соглашение для идентификации типа файла на основе части его имени». Даже DOS / Win3.1 не требовало правильного расширения (вы могли бы вызвать документ Word и «STUPIDN.AME» и открыть его с помощью Ctrl-O в WinWord). Просто некоторые системы (например, дважды щелкните по Windows, gzip, ваш Makefile и т. Д.) Могут быть написаны для использования этого соглашения, чтобы сделать предположения о правильном действии для каждого файла. – IMSoP 27 July 2016 в 19:42
  • 3
    @ByteCommander Это правда, но расширение все еще определяет используемое приложение. Я не уверен, как отредактировать ответ, чтобы отразить это. – coteyr 27 July 2016 в 23:16
  • 4
    @coteyr Опять же, все зависит от того, что мы подразумеваем под «OS». Диспетчер файлов обязательно найдет ключ реестра для «AME» и скажет мне, что «foo.txt» это текстовый файл. Но запуск dir в командной строке не скажет мне ничего подобного; это просто все равно. Выполнение файлов, безусловно, является исключением, на обеих ОС; если вопрос был ограничен, ответ будет заключаться в том, что DOS / Windows только заботятся об имени, а Unix / Linux только заботятся о разрешении на выполнение и о первых байтах файла. Кроме того, всегда существует какое-то приложение, выбирающее конвенцию. – IMSoP 28 July 2016 в 00:07
  • 5
    @coteyr Вы забыли * .scr (двоичный файл заставки) в Windows 3.1 и выше. Тем не менее, расширение файла даже в системах DOS / Windows даже для исполняемых файлов все еще просто удобство. Специфика очень сильно зависит от того, где вы рисуете линию «операционной системы», но вы всегда можете загружать двоичный код в память и входить в нее самостоятельно, выполняя работу, которую обычно запрашивает ОС. В MS-DOS, если вы просматриваете command.com, я уверен, что есть список, такой как EXE COM, который вы можете редактировать, так что он ищет другие расширения, если ни один не указан (не сказать, что это была бы хорошая идея, заметьте). – Michael Kjörling 30 July 2016 в 14:59

Другие вопросы по тегам:

Похожие вопросы: