Разработчик Ubuntu дает вам начало со многими учебниками и ресурсами.
Здесь нет 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.
Как упоминалось другими, в 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 (!)
Если у вас есть не-родные файлы с расширениями имен, не удаляйте расширения, если все будет в порядке!
Я хотел бы принять другой подход к этому из других ответов и бросить вызов понятию, что «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 ++На самом деле, некоторые технологии полагаются на расширения файлов, поэтому, если вы используете эти технологии в Ubuntu, вам также придется полагаться на расширения. Несколько примеров:
gcc использует расширения для различения файлов C C ++. Без расширения практически невозможно отличить их (представьте себе файл C ++ без классов). многие файлы (docx, jar, apk) - это просто структурированные ZIP-архивы. Хотя вы обычно можете вывести тип из содержимого, это может быть не всегда возможно (например, Java Manifest является необязательным в файлах jar).Не использовать расширения файлов в таких случаях можно только с помощью взломанных обходных решений и, вероятно, будет очень подверженным ошибкам.
Ваше первое предположение верно: расширения в Linux не имеют значения и полезны только для людей (и других не-Unix-подобных ОС, которые заботятся о расширениях). Тип файла определяется первыми 32 битами данных в файле, который известен как магический номер. Поэтому для сценариев оболочки требуется строка #! - чтобы сообщить операционной системе, какой интерпретатор должен вызывать. Без него сценарий оболочки представляет собой просто текстовый файл.
Что касается файловых менеджеров, они хотят знать расширения некоторых файлов, таких как .desktop файлы, которые в основном такие же, как и для быстрых клавиш Window, но с большим количеством возможностей. Но что касается ОС, то он должен знать, что находится в файле, а не то, что в его названии
Это слишком большое для ответа на комментарий.
Имейте в виду, что даже «расширение» имеет много разных значений.
То, о чем вы говорите, кажется, это 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, если установлено разрешение на выполнение. При этом они имеют смысл и по-прежнему используются на «компьютерном уровне» для многих вещей.