Czy rozszerzenia plików mają jakiś cel (dla systemu operacyjnego)?

73

Linux określa typ pliku za pomocą kodu w nagłówku pliku. Nie zależy od rozszerzeń plików, aby wiedzieć, jakiego oprogramowania należy użyć do otwarcia pliku.

Tak pamiętam z mojej edukacji. Popraw mnie, jeśli się mylę!

Praca trochę z systemami Ubuntu ostatnio: Widzę wiele plików na systemach, które mają rozszerzenia takie jak .sh, .txt, .o,.c

Teraz zastanawiam się: czy te rozszerzenia są przeznaczone tylko dla ludzi? Żeby dowiedzieć się, jaki to plik?

A może mają też jakiś cel dla systemu operacyjnego?

files file-format mime-type

— mizech
źródło

5

Jeśli nie uzyskasz tutaj dobrej odpowiedzi, pamiętaj, że istnieje również unix.stackexchange.com

— mchid

Powiązane, prawie duplikat: askubuntu.com/questions/390015/…

— Zzzach ...

powiązane: unix.stackexchange.com/questions/207276/…

— chaos

5

W Windows tak, w Linux / Unix w większości nie. Głównym wyjątkiem są samoczynnym programów - gzip, bzip2, xz- i tak dalej. Programy te używają przyrostków do oddzielenia skompresowanej wersji pliku od nieskompresowanego, który zastępują. Programy kompresyjne często narzekają na niepoprawny sufiks, nawet jeśli plik faktycznie jest plikiem skompresowanym typu, który powinien obsługiwać.

— Baard Kopperud

6

Myślę, że część problemu z tym pytaniem polega na tym, że „system operacyjny” nie jest dobrze zdefiniowanym pojęciem. Co jest częścią systemu operacyjnego i na czym polega aplikacja? Niewiele części systemu operacyjnego (niezależnie od tego, o jakim systemie mówimy) dba o typ pliku - po prostu robią to, co im powiedziano. Tak więc rozróżnienia dotyczące tego , jak wiedzą, są nieistotne; nie robią ani jednego. Z drugiej strony aplikacje mogą równie dobrze wykonywać jedną lub obie rzeczy.

— IMSoP

39

Linux określa typ pliku za pomocą kodu w nagłówku pliku. To nie zależy od rozszerzeń plików, aby wiedzieć, że oprogramowanie ma służyć do otwierania pliku.

Tak pamiętam z mojej edukacji. Popraw mnie, jeśli się mylę!

poprawnie zapamiętane.

Czy te rozszerzenia są przeznaczone tylko dla ludzi?

Tak, z ale.

Gdy wchodzisz w interakcję z innymi systemami operacyjnymi, które zależą od tego, jakie rozszerzenia są, to mądrzejszym pomysłem jest ich użycie.

W systemie Windows oprogramowanie otwierające jest dołączone do rozszerzeń.

Otwierając plik tekstowy o nazwie „plik” jest trudniejsze niż w Windows otwierania tego samego pliku o nazwie „plik.txt” (trzeba będzie przełączyć otwarty dialog z pliku *.txt, aby *.*za każdym razem). To samo dotyczy plików tekstowych oddzielonych tabulatorami i średnikami. To samo dotyczy importowania i eksportowania wiadomości e-mail (rozszerzenie .mbox).

W szczególności podczas kodowania oprogramowania. Otwarcie pliku o nazwie „software1”, czyli pliku HTML i „software2”, czyli pliku JavaScript, staje się trudniejsze w porównaniu z „software.html” i „software.js”.

Jeśli w systemie Linux istnieje system, w którym rozszerzenia plików są ważne, nazwałbym to błędem. Gdy oprogramowanie zależy od rozszerzeń plików, można to wykorzystać. Używamy dyrektywy interpretera do identyfikacji pliku („pierwsze dwa bajty w pliku mogą być znakami„ #! ”, Które stanowią liczbę magiczną (szesnastkowa 23 i 21, wartości ASCII„ # ”i„! „) często określane jako shebang”).

Najbardziej znanym problemem z rozszerzeniami plików był LOVE-LETTER-FOR-YOU.TXT.vbs w systemie Windows. Jest to wizualny skrypt podstawowy wyświetlany w eksploratorze plików jako plik tekstowy.

W Ubuntu po uruchomieniu pliku z Nautilus pojawia się ostrzeżenie, co zamierza zrobić. Wykonywanie skryptu z Nautilus, w którym chce uruchomić oprogramowanie, w którym powinien otworzyć gEdit, jest oczywistym problemem i otrzymujemy ostrzeżenie o tym.

W wierszu poleceń podczas wykonywania czegoś możesz wizualnie zobaczyć, jakie jest rozszerzenie. Gdyby skończył się na .vbs, stałbym się podejrzliwy (nie to, że .vbs jest wykonywalny w Linuksie. Przynajmniej nie bez większego wysiłku;)).

— Rinzwind
źródło

31

Zupełnie nie rozumiem tego, co chciałeś powiedzieć w ostatnim zdaniu. Po pierwsze, problemem jest ukrywanie rozszerzenia, a nie posiadanie go. Po drugie, exploit działałby tak samo w Linuksie - nazywasz plik binarny readme.txti sprawiasz, że jest on wykonywalny. Jeśli użytkownik go wykonał, nie otwiera edytora, ale uruchamia kod. Pod tym względem sprawianie, by rozszerzenia miały znaczenie (ale nie ukrywanie ich) jest bezpieczniejsze i łatwiejsze do wyjaśnienia dla niezorientowanych użytkowników. Istnieją inne różnice (przede wszystkim brak wykonywania plików z bieżącego katalogu), ale nie mają one nic wspólnego z rozszerzeniami.

— techraf

4

@techraf Właściwie menedżer plików prawdopodobnie spróbuje otworzyć readme.txtplik za pomocą edytora tekstu. Właśnie próbowałem z delfinem w KDE, tworząc skrypt powłoki dodający uprawnienia do plików wykonywalnych, zapisując go jako .txti kliknięcie spowoduje otwarcie go w Kate. Jeśli zmienię nazwę na, .shto kliknięcie spowoduje uruchomienie.

— Bakuriu

9

linux: skoro make opiera się na regułach zależnych od rozszerzenia pliku, czyż to nie uczyniłoby (bez zamierzonej gry słów) rozszerzeń przeznaczonych dla więcej niż tylko ludzi?

— bolov 27.07.16

15

To jest monumentalnie zła odpowiedź. Niektóre części systemu Linux używają magicznych liczb do określania typów plików. Wykonywanie plików w wierszu poleceń. Ale inne ogromne części systemu używają rozszerzeń plików, aby wiedzieć, na co zwrócić uwagę, czy to dynamiczny linker (który chce plików .so), modprobe, kompilacja systemów, wtyczek, bibliotek dla Pythona, Ruby itp. Wiele plików nie mają magiczne liczby, filesą oparte na heurystyce, nie są określone.

— Alan Shutko

3

„Linux określa typ pliku za pomocą kodu w nagłówku pliku” „poprawny” WTF? Jaki „kod w nagłówku pliku”? Nie ma takiego kodu i nie ma takiego ogólnego „nagłówka pliku” w systemie Linux.

— leonbloy

68

Nie ma tutaj odpowiedzi w 100% czarno-białej.

Zazwyczaj Linux nie polega na nazwach plików (i rozszerzeniach plików, tj. Części nazwy pliku po normalnie ostatnim okresie), a zamiast tego określa typ pliku, sprawdzając kilka pierwszych bajtów jego zawartości i porównując go z listą znanych magicznych liczb .

Na przykład wszystkie pliki obrazów bitmapowych (zwykle z rozszerzeniem nazwy .bmp) muszą zaczynać się literami BMw pierwszych dwóch bajtach. Skrypty w większości języków skryptowych, takich jak Bash, Python, Perl, AWK itp. (W zasadzie wszystko, co traktuje wiersze zaczynające się #od komentarza) mogą zawierać shebang jak #!/bin/bashpierwszy wiersz. Ten specjalny komentarz informuje system, w której aplikacji należy otworzyć plik.

Tak więc zwykle system operacyjny opiera się na zawartości pliku, a nie jego nazwie, aby określić typ pliku, ale stwierdzenie, że rozszerzenia plików nigdy nie są potrzebne w systemie Linux, to tylko połowa prawdy.

Aplikacje mogą oczywiście zaimplementować sprawdzanie plików w dowolny sposób, co obejmuje weryfikację nazwy i rozszerzenia pliku. Przykładem jest Eye of Gnome ( eogstandardowa przeglądarka zdjęć), która określa format obrazu na podstawie rozszerzenia pliku i zgłasza błąd, jeśli nie pasuje do zawartości. To, czy jest to błąd, czy funkcja, można omówić ...

Jednak nawet niektóre części systemu operacyjnego polegają na rozszerzeniach nazw plików, np. Podczas analizowania plików źródłowych oprogramowania w plikach /etc/apt/sources.list.d/- *.listparsowane są tylko pliki z rozszerzeniem, wszystkie inne są ignorowane. Może nie jest używany głównie do określania typu pliku, ale raczej do włączania / wyłączania analizy niektórych plików, ale nadal jest to rozszerzenie pliku, które wpływa na sposób, w jaki system traktuje plik.

I oczywiście ludzkie zyski użytkowników najbardziej z rozszerzeniami jak sprawia, że typ pliku oczywistej i pozwala również wiele plików o tej samej nazwie bazowej i różnych rozszerzeń, takich jak site.html, site.php, site.js, site.cssitd. Wadą jest to, oczywiście, że rozszerzenie pliku i rzeczywista typ pliku / treść niekoniecznie muszą być zgodne.

Dodatkowo jest potrzebny do współdziałania między platformami, ponieważ np. Windows nie będzie wiedział, co zrobić z readmeplikiem, ale tylko readme.txt.

— Bajt Dowódca
źródło

Lekko się tu zaprzeczasz: jeśli standardowa przeglądarka obrazów wymaga nazwy pliku kończącej się na .bmp, to o którą część systemu mówisz, że zależy od zawartości pliku rozpoczynającej się na „BM”? AFAIK, jedynymi „magicznymi liczbami, na których zależy jądro, są typy wykonywalne, w tym szczególny przypadek #!. Wszystko inne zależy od decyzji jakiejś aplikacji.

— IMSoP

@IMSoP Nie znam dokładnej implementacji eogi nie wiem, dlaczego w ogóle dbają o nazwę pliku. To moim zdaniem błąd. Oczywiście, jeśli plik ma nazwę „bmp”, ale jego format zawartości nie pasuje, oczywiście wystąpi również błąd. Oczywiście każda aplikacja decyduje o sposobie weryfikacji plików, ale ogólnie aplikacje Linuksa nie powinny polegać na nazwie. Przy okazji możesz użyć programu filecommend do zbadania typów plików według ich zawartości.

— Bajt Dowódca

1

Zdanie, które podważam, brzmi następująco: „Linux ... określa typ pliku, sprawdzając kilka pierwszych bajtów”. Jakiej definicji „Linux” używasz w tym zdaniu? Istnienie filenarzędzia tak naprawdę niczego nie dowodzi; to przydatne narzędzie, które może istnieć w dowolnym systemie operacyjnym. Jaka podstawowa część systemu operacyjnego sprawia, że uruchamianie filejest bardziej „poprawne” niż globowanie nazwy pliku?

— IMSoP

Pamiętaj, że pliki bez rozszerzenia można powiązać z programem.

— isanae

24

Jak wspomnieli inni, w Linuksie stosowana jest metoda dyrektywy interpretera (przechowywanie niektórych metadanych w pliku jako nagłówka lub liczby magicznej, aby można było powiedzieć właściwemu interpreterowi, aby ją przeczytał), a nie metoda powiązania rozszerzenia plików używana przez system Windows.

Oznacza to, że możesz utworzyć plik o dowolnej nazwie, którą lubisz ... z kilkoma wyjątkami

jednak

Chciałbym dodać słowo ostrzeżenia.

Jeśli masz w systemie jakieś pliki z systemu, który używa powiązania nazw plików, pliki mogą nie mieć tych magicznych liczb lub nagłówków. Rozszerzenia nazw plików służą do identyfikowania tych plików przez aplikacje, które potrafią je odczytać, a zmiana nazw takich plików może spowodować nieoczekiwane efekty. Na przykład:

Jeśli zmienisz nazwę pliku My Novel.docna My-Novel, Libreoffice nadal będzie mógł go otworzyć, ale otworzy się on jako „Bez tytułu” i będziesz musiał go nazwać ponownie, aby go zapisać (Libreoffice domyślnie dodaje rozszerzenie, więc będziesz miał dwa pliki My-Noveli My-Novel.odt, co może być denerwujące)

Mówiąc poważniej, jeśli zmienisz nazwę pliku My Spreadsheet.xlsx na My-Spreadsheet, a następnie spróbuj go otworzyć xdg-open My-Spreadsheet, otrzymasz to (ponieważ w rzeczywistości jest to skompresowany plik):

A jeśli zmienisz nazwę pliku My Spreadsheet.xlsna My-Spreadsheet, gdy xdg-open My-Spreadsheetpojawi się komunikat o błędzie

błąd podczas otwierania lokalizacji: Żadna aplikacja nie jest zarejestrowana jako obsługująca ten plik

(Chociaż w obu tych przypadkach działa, jeśli tak zrobisz soffice My-Spreadsheet)

Jeśli następnie zmień nazwę pliku bez rozszerzeń do My-Spreadsheet.odsz mvi spróbuj otworzyć go dostaniesz to:

(naprawa nie powiedzie się)

Będziesz musiał ponownie założyć oryginalne rozszerzenie, aby poprawnie otworzyć plik (możesz następnie przekonwertować format, jeśli chcesz)

TL; DR:

Jeśli masz pliki nienatywne z rozszerzeniami nazw, nie usuwaj rozszerzeń, zakładając, że wszystko będzie w porządku!

— Zanna
źródło

4

Nowy dokument MS Office (docx, xlsx, pptx itp.) Bez rozszerzenia pliku otwiera się w menedżerze archiwów, ponieważ te typy plików są w rzeczywistości zwykłymi plikami skompresowanymi ZIP, które zawierają wszystkie dokumenty XML i pliki multimedialne niezbędne do zdefiniowania zawartości dokumentu. Format pliku skompresowanego katalogu ZIP jest obecnie dość powszechny.

— Bajt Dowódca

1

Już wiele świetnych odpowiedzi, ale tylko jedna bardziej specyficzna dla libreoffice, którą zauważyłem. Tworzysz plik z wartościami rozdzielanymi przecinkami (CSV) i zapisujesz go jako „test.csv”, otworzy się okno z pytaniem, jakiego typu separatora używasz (np. Libreoffice Calc). Jeśli na przykład zmienisz nazwę tego pliku na „test.cs”, wówczas program Libreoffice Writer otworzy go. Poza powyższym przykładem ZIP wydaje się, że libreoffice korzysta z rozszerzenia pliku.

— Ray

3

System plików linux nie robi nic w odniesieniu do typów plików. To wszystko zależy od programów działających na nim.

— Peter Green,

@PeterGreen Tak, ale fakt, że programy przypisują mu znaczenie, oznacza, że nie jest tak „tylko dla ludzi”, np. Klasyczne MacOS miał to [były czterobajtowe pola „typu pliku” i „aplikacja twórcy”, które nie były t część nazwy pliku, więc system operacyjny i aplikacje miały wszystkie potrzebne informacje bez patrzenia na rozszerzenia plików]

— Random832

3

@PeterGreen System plików Windows również nie robi nic w odniesieniu do typów plików. Powłoka graficzna (Eksplorator Windows) używa rozszerzenia pliku, aby wybrać akcję podwójnego kliknięcia, ale technicznie jest to po prostu program działający na systemie operacyjnym, tak jak Nautilus. Z takim zachowaniem można byłoby napisać menedżera plików systemu Linux lub Windowsa, który sprawdzałby zawartość pliku.

— IMSoP

20

Chciałbym podejść do tego inaczej niż w przypadku innych odpowiedzi i zakwestionować pogląd, że „Linux” lub „Windows” mają z tym coś wspólnego (proszę o wyrozumiałość).

Pojęcie rozszerzenia pliku można po prostu wyrazić jako „konwencję identyfikującą typ pliku na podstawie części jego nazwy”. Inne typowe konwencje określania typu pliku to porównywanie jego zawartości z bazą danych znanych sygnatur (podejście „magicznej liczby”) i przechowywanie go jako dodatkowego atrybutu w systemie plików (podejście stosowane w oryginalnym systemie MacOS) .

Ponieważ każdy plik w systemie Windows lub Linux ma zarówno nazwę, jak i treść, procesy, które chcą poznać typ pliku, mogą użyć „rozszerzenia” lub „magicznej liczby”, jeśli uznają to za stosowne. Metoda metadanych nie jest ogólnie dostępna, ponieważ w większości systemów plików nie ma standardowego miejsca dla tego atrybutu.

W systemie Windows istnieje silna tradycja używania rozszerzenia pliku jako podstawowego sposobu identyfikowania pliku; najbardziej widoczna jest graficzna przeglądarka plików (Menedżer plików w systemie Windows 3.1 i Eksplorator w nowoczesnym systemie Windows), która korzysta z niego po dwukrotnym kliknięciu pliku w celu ustalenia, którą aplikację uruchomić. W systemie Linux (i bardziej ogólnie w systemach opartych na Uniksie) istnieje więcej tradycji sprawdzania zawartości; przede wszystkim jądro patrzy na początek pliku wykonywanego bezpośrednio, aby ustalić, jak go uruchomić; pliki skryptów mogą wskazywać interpretera do użycia, zaczynając #!od ścieżki, po której następuje ścieżka do interpretera.

Te tradycje wpływają na projektowanie interfejsu użytkownika programów napisanych dla każdego systemu, ale istnieje wiele wyjątków, ponieważ każde podejście ma zalety i wady w różnych sytuacjach. Powody, dla których warto używać rozszerzeń plików zamiast sprawdzać zawartość, obejmują:

sprawdzanie zawartości pliku jest dość kosztowne w porównaniu do sprawdzania nazw plików; na przykład „znajdź wszystkie pliki o nazwie * .conf” będzie znacznie szybsze niż „znajdź wszystkie pliki, których pierwszy wiersz pasuje do tego podpisu”
zawartość pliku może być niejednoznaczna; wiele formatów plików to tak naprawdę tylko pliki tekstowe traktowane w specjalny sposób, wiele innych to specjalnie skonstruowane pliki zip, a zdefiniowanie ich dokładnych podpisów może być trudne
plik może być rzeczywiście ważny jako więcej niż jeden typ; plik HTML może być również prawidłowym plikiem XML, plik zip i GIF połączone razem pozostają ważne dla obu formatów
dopasowanie magicznej liczby może prowadzić do fałszywych trafień; format pliku, który nie ma nagłówka, może zaczynać się od bajtów „GIF89a” i być błędnie identyfikowany jako obraz GIF
zmiana nazwy pliku może być wygodnym sposobem oznaczenia go jako „wyłączony”; np. zmiana „foo.conf” na „foo.conf ~” w celu wskazania, że tworzenie kopii zapasowej jest łatwiejsze niż edytowanie pliku w celu skomentowania wszystkich jego dyrektyw i wygodniejsze niż przeniesienie go z automatycznie ładowanego katalogu; podobnie zmiana nazwy pliku .php na .txt spowoduje, że Apache będzie podawał swoje źródło jako zwykły tekst, zamiast przekazywać go do silnika PHP

Przykłady programów systemu Linux, które domyślnie używają nazw plików (ale mogą mieć inne tryby):

gzip i gunzip mają specjalną obsługę każdego pliku z rozszerzeniem „.gz”
gcc będzie obsługiwał pliki „.c” jako C, a „.cc” lub „.C” jako C ++

— IMSoP
źródło

System Windows ma również silną tradycję ukrywania rozszerzenia, jeśli jest ono „dobrze znane”, a nawet DOS zezwalał na pominięcie polecenia .COM, .BAT i .EXE, automatycznie wyszukując je w celu ustalenia, który program ma zostać uruchomiony. * Nix nie ma takiej tradycji.

— Monty Harder

Jest to o wiele lepsza odpowiedź, ale zawiera jeden błąd rzeczowy ... skryptu nie można wykonać przez umieszczenie #!na początku. Dowolny plik z ustawionymi bitami (bitami) można wykonać na kilka sposobów. #!/bin/bashi podobne podpisy określają tylko, którego tłumacza należy użyć. Jeśli taki podpis nie zostanie dostarczony, zakłada się domyślny interpreter powłoki. Plik zawierający tylko dwa słowa „Hello World”, ale z ustawionym bitem wykonania, spróbuje znaleźć polecenie „Hello” po uruchomieniu.

— DocSalvager,

1

@DocSalvager Dobry haczyk, to było nieporadne sformułowanie w jak największym stopniu. Przeredagowałem go trochę, aby wyjaśnić, że shebang nie powoduje, że skrypt jest wykonywalny, a jedynie zmienia sposób jego wykonania.

— IMSoP,

15

Faktycznie, niektóre technologie nie polegać na rozszerzeń plików, więc jeśli korzystanie z tych technologii w Ubuntu, musisz polegać na zbyt rozszerzeń. Kilka przykładów:

gccużywa rozszerzeń do rozróżnienia między plikami C i C ++. Bez rozszerzenia ich odróżnienie jest prawie niemożliwe (wyobraź sobie plik C ++ bez klas).
wiele plików ( docx, jar, apk) są właśnie szczególnie strukturę archiwów ZIP. Chociaż zazwyczaj można wywnioskować typ z treści, nie zawsze jest to możliwe (np. Java Manifest jest opcjonalny w jarplikach).

Nieużywanie rozszerzeń plików w takich przypadkach będzie możliwe tylko przy hakujących obejściach i może być bardzo podatne na błędy.

— Dmitrij Grigoriew
źródło

Dobrze, że wspomniałeś o programowaniu, ale większość szczegółów była błędna. gccjest front-endem dla plików C, dla plików C ++ potrzebujesz g++frontonu lub przełącznika wiersza poleceń, aby określić język. Ważniejszy jest makeprogram, który decyduje, czy użyć gcclub g++zbudować konkretny plik - i makejest całkowicie zależny od wzorców nazw plików (głównie rozszerzeń) w zakresie dopasowania reguł.

— Ben Voigt

@BenVoigt Podczas kompilacji pliku z .ccrozszerzeniem gcctak naprawdę zostanie skompilowany jako C ++, a dokumentuje to man gcc: „Dla każdego pliku wejściowego przyrostek nazwy pliku określa rodzaj kompilacji:”, po której następuje lista rozszerzenia i sposób ich traktowania.

— hvd

1

@hvd Może to jest domyślny zestaw bibliotek, który idzie strasznie źle, jeśli nie używasz właściwej nakładki. W każdym razie marka jest najlepszym przykładem, ponieważ wszystko, co robi, opiera się na rozszerzeniu pliku.

— Ben Voigt

1

@BenVoigt makejest również dobrym przykładem, ale gccrównie mocno opiera się na nazwach plików. Oto przykład jaśniejszy niż .cvs .cc: W przypadku C gccużywa przyrostków, aby stwierdzić, czy jego pierwszym krokiem jest wstępne przetworzenie ( .c), kompilacja ( .i), asemblacja ( .s) lub link ( .o). Tutaj używam -E, -Si -cpowiedzieć, gccgdzie się zatrzymać , ale używa nazw plików, aby wiedzieć, gdzie zacząć . gcc something.ccnie będzie łączył się z odpowiednimi bibliotekami dla C ++, ale będzie traktował plik jako C ++, dlatego wielu użytkowników jest zdezorientowanych komunikatami o błędach, które otrzymują podczas popełnienia tego błędu.

— Eliah Kagan

7

Twoje pierwsze założenie jest poprawne: rozszerzenia w Linuksie nie mają znaczenia i są przydatne tylko dla ludzi (i innych nie-uniksowych systemów operacyjnych, które dbają o rozszerzenia). Typ pliku jest określany przez pierwsze 32 bity danych w pliku, co jest znane jako liczba magiczna. Dlatego skrypty powłoki potrzebują #!linii - aby powiedzieć systemowi operacyjnemu, który interpreter ma wywołać. Bez tego skrypt powłoki jest tylko plikiem tekstowym.

Jeśli chodzi o menedżerów plików, chcą znać rozszerzenia niektórych plików, takich jak .desktoppliki, które zasadniczo są takie same jak wersja skrótów Windows, ale mają więcej możliwości. Ale jeśli chodzi o system operacyjny, musi wiedzieć, co jest w pliku, a nie co w jego nazwie

— Sergiy Kolodyazhnyy
źródło

3

To nie do końca prawda. Istnieją programy, które oczekują określonego rozszerzenia. Najczęściej stosowanym przykładem jest prawdopodobnie taki, gunzipktóry nie rozpakuje pliku, jeśli nie zostanie wywołany foo.gz.

— terdon

To implementacja określonego oprogramowania. W przeważającej części narzędzia w systemach uniksowych nie oczekują rozszerzenia.

— Sergiy Kolodyazhnyy

7

W większości nie, nie. Jednak twoje pierwsze zdanie mówi, że nigdy nie są używane i mają znaczenie tylko dla ludzi. To nie do końca prawda. gunzipjest jednym przykładem, eogjest innym. Ponadto wiele narzędzi nie będzie automatycznie uzupełniać nazw bez odpowiedniego rozszerzenia. Mówię tylko, że jest to trochę bardziej skomplikowane niż „rozszerzenia są zawsze nieistotne”.

— terdon

1

1 mały problem: OP zapytał o system operacyjny. „gunzip” i „eog” nie są systemem operacyjnym, ale postanowili stworzyć własne ograniczenia (w przypadku gunzip) lub metody (eog). „typy mimów”.

— Rinzwind

1

@Erg Pewnie, możesz zdefiniować system operacyjny wąsko i uzyskać trywialną odpowiedź na pytanie. Nie jest to jednak szczególnie pomocna odpowiedź, ponieważ ogromna większość tego, co użytkownik robi z komputerem, dotyczy oprogramowania, które wykluczyłeś. Zauważ, że pytanie kontrastowało „tylko dla ludzi” z „systemem operacyjnym”; Nie sądzę, żeby mieli na myśli „jądro”.

— IMSoP,

6

To jest zbyt duże, by odpowiedzieć na komentarz.

Pamiętaj, że nawet „rozszerzenie” ma wiele różnych znaczeń.

To, o czym mówisz, wydaje się być 3 literami po. DOS sprawił, że format 8.3 stał się bardzo popularny, a Windows używa części .3 do dziś.

Linux ma wiele plików, takich jak .conf lub .list lub .d lub .c, które mają znaczenie, ale tak naprawdę nie są rozszerzeniami w sensie 8.3. Na przykład Apache patrzy na /etc/apache2/sites-enabled/website.conf w poszukiwaniu swojej dyrektywy konfiguracyjnej. Podczas gdy system używa typów MIME i nagłówków treści oraz tego, czego nie należy określać, jest to plik tekstowy, Apache (domyślnie) nadal nie będzie go ładować bez końcówki .conf.

.c jest kolejnym świetnym. Tak, jest to plik tekstowy, ale gcc zależy od tego, czy main.c stanie się main.o, a na końcu main (po połączeniu). W żadnym momencie system nie używa rozszerzeń .c, .o ani żadnego rozszerzenia, aby mieć jakiekolwiek znaczenie w zakresie treści, ale rzeczy po. ma jakieś znaczenie. Prawdopodobnie skonfigurowałbyś swój SCM tak, aby ignorował main.o i main.

Chodzi o to, że rozszerzenia nie są używane tak, jak są w systemie Windows. Jądro nie uruchomi pliku .txt, ponieważ usuniesz część nazwy .txt. Bardzo przyjemnie jest również wykonać plik .txt, jeśli ustawione jest uprawnienie do wykonywania. Biorąc to pod uwagę, mają one znaczenie i nadal są używane na „poziomie komputera” do wielu rzeczy.

— Coteyr
źródło

1

Windows nie jest również zobowiązany do x.3nazewnictwa więcej, masz już rozszerzenia również tam jak .doxc, .torrent, .part, itd. To jest po prostu, że wiele formatów plików i rozszerzenia zostały już określone z powrotem w czasie, gdy 8,3 nazewnictwo było jeszcze coś, a później formaty najczęściej po prostu dostosowały konwencję użycia do 3 liter.

— Bajt Dowódca

Nie rozumiem, w jaki sposób „.conf”, „.c” itp. Mają „inne znaczenie” od „sensu 8.3”. Pojęcie rozszerzenia pliku można po prostu wyrazić jako „konwencję identyfikującą typ pliku na podstawie części jego nazwy”. Nawet DOS / Win3.1 nie wymagało poprawnego rozszerzenia (możesz nazwać dokument programu Word „STUPIDN.AME” i otworzyć go za pomocą Ctrl-O w WinWord). Tyle, że niektóre systemy (np. Dwukrotne kliknięcie w systemie Windows, gzipplik Makefile itp.) Mogą zostać napisane w celu użycia tej konwencji w celu przyjęcia założeń dotyczących prawidłowego działania dla każdego pliku.

— IMSoP,

@ByteCommander To prawda, ale rozszerzenie nadal określa używaną aplikację. Nie jestem pewien, jak edytować odpowiedź, aby to odzwierciedlić.

— coteyr

1

@coteyr Znowu wszystko zależy od tego, co rozumiemy przez „system operacyjny”. File Manager z pewnością przyjrzeć się klucza rejestru dla „AME” i powie mi, że „foo.txt” jest plikiem tekstowym. Ale uruchamianie dirw wierszu polecenia nie powie mi nic takiego; to po prostu nie obchodzi. Wykonywanie plików jest z pewnością wyjątkiem w obu systemach operacyjnych; gdyby pytanie było ograniczone do nich, odpowiedź brzmiałaby, że DOS / Windows dba tylko o nazwę, a Unix / Linux dba tylko o uprawnienia do wykonywania i pierwsze bajty pliku. Poza tym zawsze jest jakaś aplikacja wybierająca konwencję do naśladowania.

— IMSoP

1

@coteyr Zapomniałeś * .scr (binarny wygaszacz ekranu) w Windows 3.1 i nowszych. To powiedziawszy, rozszerzenie pliku nawet w systemach DOS / Windows, nawet dla plików wykonywalnych, jest nadal tylko wygodą. Specyfika zależy w dużej mierze od tego, gdzie narysujesz linię „systemu operacyjnego”, ale zawsze możesz załadować plik binarny do pamięci i wskoczyć do niego sam, wykonując pracę, o którą zwykle prosi system operacyjny. W MS-DOS, jeśli spojrzysz na command.com, jestem prawie pewien, że istnieje lista taka jak EXE COM, którą możesz edytować, tak aby szukała innych rozszerzeń, jeśli nie zostanie określona (nie mówiąc, że to byłby dobry pomysł, uważam).

— CVn