Есть ли у файловых расширений какое-либо предназначение (для операционной системы)?

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

Это то, что я помню из своего образования. Пожалуйста, поправьте меня, если я ошибаюсь!

В последнее время немного поработал с системами Ubuntu: я вижу много файлов в системах, которые имеют расширения типа .sh , .txt , .o , .c

Теперь я интересно: эти расширения предназначены только для людей? Итак, чтобы понять, что это за файл?

Или они имеют какое-то назначение и для операционной системы?


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

Это то, что я помню из своего образования. Пожалуйста, поправьте меня, если я ошибаюсь!

  • правильно запомнил.

Эти расширения предназначены только для людей?

  • Да, с «но».

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

В Windows открывающее программное обеспечение прикреплено к расширениям.

Открыть текстовый файл с именем «file» в Windows сложнее, чем открыть тот же файл с именем «file.txt» (вам нужно будет переключить диалоговое окно открытия файла с *. txt в *. * каждый раз). То же самое касается текстовых файлов, разделенных TAB и точкой с запятой. То же самое касается импорта и экспорта электронной почты (расширение .mbox).

В частности, когда вы пишете программное обеспечение. Открыть файл с именем «software1», представляющий собой HTML-файл, и «software2», являющийся файлом JavaScript, становится сложнее по сравнению с «software.html» и «software.js».


Если в Linux есть система, в которой важны расширения файлов, я бы назвал это ошибкой. Когда программное обеспечение зависит от расширений файлов, это можно использовать. Мы используем директиву интерпретатора, чтобы идентифицировать файл («первые два байта в файле могут быть символами« #! », Которые составляют магическое число (шестнадцатеричные 23 и 21, значения ASCII« # »и»! «) часто называют shebang,»).

Самой известной проблемой с расширениями файлов была LOVE-LETTER-FOR-YOU.TXT.vbs в Windows. Это визуальный базовый сценарий, отображаемый в файловом проводнике в виде текстового файла.

В Ubuntu, когда вы запускаете файл из Nautilus, вы получаете предупреждение о том, что он собирается делать. Выполнение сценария из Nautilus, где он хочет запустить какое-то программное обеспечение, где предполагается открыть gEdit, является очевидной проблемой, и мы получаем предупреждение об этом.

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


74

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

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

Например, все файлы растровых изображений (обычно с расширением имени .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 .

Поделиться
Улучшите это ответ
ответ дан techraf
3,1161010 золотых знаков2222 серебряных знака3636 бронзовых знаков значки
ответил 27 июля ’16 в 07:22
  • Здесь вы немного противоречите себе: если для стандартной программы просмотра изображений требуется имя файла, оканчивающееся на .bmp, какая часть ОС, по вашему мнению, полагается на содержимое файла, начинающееся с «BM»? AFAIK, единственные «магические числа, о которых заботится ядро», — это исполняемые типы, включая особый случай #! . Все остальное зависит от решения какого-то приложения. — IMSoP 27 июля ’16 в 18: 20
  • @IMSoP Я не ‘не знаю точную реализацию eog , и я не знаю, почему они вообще заботятся об имени файла. На мой взгляд, это ошибка. И, конечно, если файл называется » bmp «, но его формат содержимого не совпадает, конечно же, будет ошибка. Конечно, каждое приложение решает, как проверять файлы, но в целом приложения Linux не должны полагаться на имя. Кстати, вы можете использовать file рекомендуем проверять типы файлов по их содержанию. — Byte Commander ♦ 27 июля 2016, 19:12
  • 2
    Предложение, которое я усложняю, звучит так: «Linux … определяет тип файла, исследуя первые несколько байтов» . Что определенно цию «Linux» вы используете в этом предложении? Существование утилиты file на самом деле ничего не доказывает; это полезный инструмент, который может существовать в любой ОС. Какая фундаментальная часть ОС делает запуск file более «правильным», чем использование подстановки имени файла? — IMSoP, 27 июля 2016 г., 21:51
  • Обратите внимание, что файлы без расширения могут быть связаны с программой. — isanae 28 июл. ’16 в 2:09
добавить комментарий |

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

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

Например, все файлы растровых изображений (обычно с расширением имени .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 .


24

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

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

Однако

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

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

Если вы переименуете файл в Мой роман. 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 и попробуйте открыть его, вы получите следующее:

(не удалось восстановить)

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

TL; DR:

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

Поделиться
Улучшить этот ответ
отредактировано 29 июля ’16 в 06:28
ответил 27 июля ’16 в 8:06
  • 4
    Новый-s Документ tyle MS Office (docx, xlsx, pptx и т. д.) без расширения файла открывается в диспетчере архивов, потому что эти типы файлов на самом деле являются обычными сжатыми файлами ZIP, которые содержат все документы XML и мультимедийные файлы, необходимые для определения содержимого документа. Кстати, в настоящее время формат файла ZIP-сжатого каталога довольно распространен. — Byte Commander ♦ 27 июля 2016, 20:21
  • 1
    Уже много замечательных ответов, но еще один, специфичный для libreoffice, который я заметил. Вы создаете файл значений, разделенных запятыми (CSV), и сохраняете его как «test.csv», откроется окно с вопросом, какой тип разделителя вы используете (например, libreoffice Calc). Если вы переименуете этот файл, например, в «test.cs», то его откроет писатель libreoffice. Итак, помимо приведенного выше примера ZIP, кажется, что libreoffice действительно использует расширение файла. — Рэй 27 июля ’16 в 8:31
  • 3
    Файловая система linux ничего не делает с типами файлов. Это все зависит от программ, работающих поверх него. — Питер Грин, 27 июля 2016 г., 15:29
  • 1
    @PeterGreen Да, но тот факт, что программы присваивают ему значение, означает, что это не «только для людей», как, например, в классической MacOS [были четырехбайтовые «тип файла» и « Создатель приложения », которые не были частью имени файла, поэтому ОС и приложения имели всю необходимую информацию, не обращая внимания на расширения файлов] — Random832, 27 июля 2016 г., 15:36
  • 5
    @PeterGreen Файловая система Windows ничего не делает с типами файлов или. Графическая оболочка (проводник Windows) использует расширение файла для выбора действия для двойного щелчка, но технически это просто программа, работающая поверх ОС, как и Nautilus. Было бы совершенно возможно написать файловый менеджер Linux с таким поведением или Windows, который проверял бы содержимое файла. — IMSoP, 27 июля 2016, 17:19
добавить комментарий |

Как упоминалось другими, в 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- Электронная таблица )

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

(восстановление не удается)

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

TL; DR:

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


24

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

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

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

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

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

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

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

  • gzip и gunzip имеют специальную обработку любого файла, заканчивающегося на «.gz».
  • gcc будет обрабатывать файлы «.c» как C, а «.cc» или » .C «как C ++
Поделиться
Улучшите этот ответ
отредактировано 02 августа 2016 в 22:07
ответил 27 июля ’16 в 17:13
  • В Windows также существует сильная традиция скрывать расширение, если оно «хорошо известно», и даже DOS позволяла команде опускать .COM, .BAT, a nd .EXE, автоматически ищущий их, чтобы определить, какую программу нужно выполнить. В * nix такой традиции нет. — Монти Хардер, 28 июля 2016, 21:59
  • Это гораздо лучший ответ, но с одной фактической ошибкой … скрипт нельзя сделать исполняемым, поместив #! в начало. Любой файл с установленным исполняемым битом (битами) может быть выполнен одним из нескольких способов. #!/bin/bash и подобные подписи просто указывают, какой интерпретатор использовать. Если такая подпись не указана, используется интерпретатор оболочки по умолчанию. Файл, содержащий только два слова «Hello World», но с установленным битом выполнения, при запуске попытается найти команду «Hello».. — DocSalvager 02 августа 2016, 21:33
  • 2
    @DocSalvager Хорошая уловка, это вообще неуклюжие формулировки. Я немного изменил его формулировку, чтобы прояснить, что shebang не делает исполняемый файл скрипта, он просто меняет то, как он выполняется. — IMSoP 02 авг., 16:08
добавить комментарий |

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

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

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

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

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

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

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

  • gzip и gunzip имеют специальную обработку для любых файлов с окончанием «.gz»
  • gcc будет обрабатывать файлы «.c» как C, а «.cc» или » .C «как C ++

16

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

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

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

Поделиться
Улучшить этот ответ
ответил 27 июля ’16 в 15:52
  • Хорошо, что вы упомянули программирование, но вы неправильно поняли большую часть деталей. gcc — это интерфейс для файлов C, для файлов C ++ вам понадобится интерфейс g ++ или переключатель командной строки, чтобы указать язык. Более важна программа make , которая решает, использовать ли gcc или g ++ для создания конкретного файла — и make полностью зависит от шаблонов имен файлов (в основном расширений) для соответствия правилам. — Бен Фойгт, 29 июля 2016, 18:50
  • @BenVoigt При компиляции файла с расширением .cc с gcc он действительно будет скомпилирован как C ++, и это задокументировано в man gcc : «Для любого заданного входного файла суффикс имени файла определяет, какой тип компиляции выполняется:», за которым следует список расширений и то, как они обрабатываются. — hvd 30 июля ’16 в 10:53
  • 1
    @hvd Тогда, возможно, это набор библиотек по умолчанию, который ужасно ошибается, если вы не используете правильный интерфейс. В любом случае make является ярким примером, потому что все, что он делает, основано на расширении файла. — Бен Фойгт, 30 июля 2016 г., 13:28
  • 2
    @BenVoigt make — тоже хороший пример, но gcc так же сильно зависит от имен файлов. Вот пример более понятный, чем .c против .cc : для C gcc использует суффиксы, чтобы указать, был ли его первый шаг предназначена для предварительной обработки ( .c ), компиляции ( .i ), сборки ( .s ) или связывания ( .o ). Здесь я использую -E , -S и -c , чтобы сообщить gcc где остановиться , но он использует имена файлов, чтобы знать, где начать . gcc something.cc не будет ссылаться на нужные библиотеки для C ++, но он будет рассматривать файл как C ++, поэтому многих пользователей смущает сообщения об ошибках, которые они получают при совершении этой ошибки. — Элиа Каган 24 янв. ’17 в 13:56
добавить комментарий |

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

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

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


6

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

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

Поделиться
Улучшить этот ответ
ответил 27 июля ’16 в 7:02
  • 4
    Это не совсем так. Есть программы, которые ожидают определенного расширения. Наиболее часто используемый пример — это, вероятно, gunzip , который не будет распаковывать файл, если он не называется foo.gz . — terdon 27 июля ’16 в 9:27
  • 8
    По большей части нет, нет. Ваше первое предложение, однако, утверждает, что они никогда не используются и имеют значение только для людей. Это не совсем так. gunzip — один пример, eog — другой. Кроме того, многие инструменты не будут выполнять автозаполнение имен без правильного расширения. Все, что я говорю, это то, что это немного сложнее, чем «расширения всегда неактуальны». — terdon 27 июля ’16 в 09:40
  • 1
    1 небольшая проблема: OP спросил об операционной системе. ‘gunzip’ и ‘eog’ не являются операционной системой, но решили создать свои собственные ограничения (в случае gunzip) или метод (eog). хотя «пантомимы». — Rinzwind, 27 июля 2016, 17:49
  • 2
    @Serg Конечно, вы можете узко определить ОС и получить тривиальный ответ на вопрос. Однако это не особенно полезный ответ, потому что подавляющее большинство того, что пользователь делает с компьютером, связано с программным обеспечением, которое вы исключили.. Обратите внимание, что вопрос противопоставляется «только для людей» и «операционной системе»; Я не думаю, что они имели в виду «ядро». — IMSoP, 29 июля 2016 г., 9:06
  • 2
    @Serg » Ясно, что операционная система не очень спорно тема я>» Э-э, цитации. Canonical называет Ubuntu «операционной системой». Вы говорите, что операционная система «состоит из ядра и нескольких базовых служб», но не указываете, какие «базовые службы», по вашему мнению, это. Мне было бы особенно интересно узнать, какие части systemd вы считаете компонентами операционной системы, а какие нет. В этом ответе неявно используется расплывчатое понятие «операционная система», а не то, что большинство людей имеет в виду под этим термином, особенно в кругах * nix. — Элиа Каган, 25 янв., 17:07
| показать 7 дополнительных комментариев

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

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


5

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

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

То, о чем вы говорите, похоже, состоит из трех букв после. DOS сделала формат 8.3 очень популярным, и в Windows до сих пор используется часть .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 или никакое расширение, чтобы иметь какое-либо значение в отношении содержимого, но вещи после. имеет какое-то значение. Вы, вероятно, настроили бы свой SCM, чтобы игнорировать main.o и main.

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

Поделиться
Улучшите это ответ
Создан 27 июл. в 12: 152016-07-27 12:15
  • 2
    Windows также больше не привязана к схеме именования x.3 , у вас есть более длинные расширения, такие как .doxc , .torrent , .part и т. д. Просто многие форматы файлов и расширения уже были определены еще в те времена, когда именование 8.3 все еще использовалось, а более поздние форматы в основном просто адаптировали условность использования до 3 букв. — Byte Commander ♦ 27 июля 2016, 10:07
  • 1
    Я не понимаю, как «.conf», «.c» и т. д. имеют «другое значение», чем «смысл 8.3». Концепция расширения файла может быть просто выражена как «соглашение об определении типа файла на основе части его имени». Даже DOS/Win3.1 не требовал правильного расширения (вы можете назвать документ Word «STUPIDN.AME» и открыть его с помощью Ctrl-O в WinWord). Просто некоторые системы (например, двойной щелчок по Windows, gzip , ваш Makefile и т. Д.) Могут быть написаны так, чтобы использовать это соглашение, чтобы делать предположения о правильных действиях, которые нужно предпринять для каждого файла. — IMSoP, 27 июля 2016 г., 16:42
  • @ByteCommander Это правда, но расширение по-прежнему определяет используемое приложение. Я не уверен, как отредактировать ответ, чтобы отразить это. — coteyr 27 июля ’16, в 20:16
  • 2
    @coteyr Опять же, все зависит от того, что мы подразумеваем под «ОС». Диспетчер файлов обязательно найдет раздел реестра для «AME» и сообщит мне, что «foo.txt» — это текстовый файл. Но запуск dir в командной строке ничего мне не скажет; ему просто все равно. Выполнение файлов, безусловно, является исключением в обеих операционных системах; если бы вопрос был ограничен ими, ответ был бы таков, что DOS/Windows только заботится об имени, а Unix/Linux только заботится о разрешении на выполнение и первые байты файла. Помимо этого, всегда есть какое-то приложение, выбирающее соглашение, которому следует следовать. — IMSoP, 27 июля 2016 г., 21:07
  • 2
    @coteyr Вы забыли *. scr (двоичный файл заставки) в Windows 3.1 и выше. Тем не менее, расширение файла даже в системах DOS/Windows даже для исполняемых файлов по-прежнему просто для удобства. Специфика во многом зависит от того, где вы проводите черту «операционная система», но вы всегда можете загрузить двоичный файл в память и перейти к нему самостоятельно, выполняя работу, которую обычно требует от ОС. В MS-DOS, если вы просмотрите command.com, я почти уверен, что есть список наподобие EXE COM, который вы можете редактировать, чтобы он искал другие расширения, если ни одно не указано (не говоря уже о том, что это было бы хорошей идеей, заметьте). — пользователь 30 июля ’16 в 11:59
| показать 1 дополнительный комментарий

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

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

То, о чем вы говорите, похоже, состоит из трех букв после. DOS сделала формат 8.3 очень популярным, и в Windows до сих пор используется часть .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 или никакое расширение, чтобы иметь какое-либо значение в отношении содержимого, но вещи после. имеет какое-то значение. Вы, вероятно, настроили бы свой SCM так, чтобы игнорировать main.o и main.

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

Оцените статью
Botgadget.ru
Добавить комментарий