Rozszerzenie nazwy pliku - Filename extension

Rozszerzenie pliku , rozszerzenie pliku lub typ pliku jest identyfikator określony jako przyrostek do nazwy z pliku komputerowego . Rozszerzenie wskazuje na charakterystykę zawartości pliku lub jego przeznaczenie. Rozszerzenie plik jest zazwyczaj ograniczona z pliku z kropką (okres), ale w niektórych systemach jest to oddzielone odstępami.

Niektóre systemy plików implementują rozszerzenia plików jako cechę samego systemu plików i mogą ograniczać długość i format rozszerzenia, podczas gdy inne traktują rozszerzenia plików jako część nazwy pliku bez specjalnego rozróżnienia.

Stosowanie

Rozszerzenia nazw plików mogą być uważane za rodzaj metadanych . Są one powszechnie używane do sugerowania informacji o sposobie przechowywania danych w pliku. Dokładna definicja, podająca kryteria decydowania, która część nazwy pliku jest jego rozszerzeniem, należy do reguł konkretnego używanego systemu plików ; zwykle rozszerzenie jest podłańcuchem, który występuje po ostatnim wystąpieniu znaku kropki (na przykład: txt jest rozszerzeniem nazwy pliku readme.txti htmlrozszerzeniem mysite.index.html). W systemach plików niektórych systemów mainframe, takich jak CMS w VM , VMS , oraz systemów PC, takich jak CP/M i systemach pochodnych, takich jak MS-DOS , rozszerzenie jest oddzielną przestrzenią nazw od nazwy pliku. W systemach DOS i Windows firmy Microsoft rozszerzenia takie jak EXE, COMlub BATwskazują, że plik jest programem wykonywalnym . W OS/360 i następcach część nazwy zbioru danych następująca po ostatnim okresie jest traktowana jako rozszerzenie przez jakieś oprogramowanie, np. TSO EDIT, ale nie ma ona specjalnego znaczenia dla samego systemu operacyjnego; to samo dotyczy plików Unix w MVS.

Systemy plików dla systemów operacyjnych typu UNIX nie oddzielają metadanych rozszerzenia od reszty nazwy pliku. Znak kropki to po prostu kolejny znak w głównej nazwie pliku. Nazwa pliku może nie mieć rozszerzeń, jedno rozszerzenie lub więcej niż jedno rozszerzenie. Więcej niż jedno rozszerzenie zwykle reprezentuje przekształcenia zagnieżdżone, takie jak files.tar.gz( .tarwskazuje, że plik jest archiwum tar jednego lub więcej plików, a .gzwskazuje, że plik archiwum tar jest skompresowany za pomocą gzip ). Programy przekształcające lub tworzące pliki mogą dodać odpowiednie rozszerzenie do nazw wywnioskowanych z nazw plików wejściowych (chyba że podano jawnie nazwę pliku wyjściowego), ale programy czytające pliki zwykle ignorują te informacje; jest przeznaczony głównie dla użytkownika. Częściej, zwłaszcza w plikach binarnych, sam plik zawiera wewnętrzne metadane opisujące jego zawartość. Ten model zazwyczaj wymaga podania pełnej nazwy pliku w poleceniach, podczas gdy podejście do metadanych często pozwala na pominięcie rozszerzenia.

Systemy plików VFAT , NTFS i ReFS dla systemu Windows również nie oddzielają metadanych rozszerzeń od reszty nazwy pliku i zezwalają na wiele rozszerzeń.

Wraz z pojawieniem się graficznych interfejsów użytkownika pojawił się problem zarządzania plikami i zachowania interfejsu. Microsoft Windows umożliwiał skojarzenie wielu aplikacji z danym rozszerzeniem, a do wyboru wymaganej aplikacji dostępne były różne akcje, takie jak menu kontekstowe oferujące wybór między przeglądaniem, edycją lub drukowaniem pliku. Założenie nadal było takie, że każde rozszerzenie reprezentuje pojedynczy typ pliku; istniało jednoznaczne mapowanie między rozszerzeniem a ikoną.

Klasyczny Mac OS usuwane filename oparte metadanych rozszerzenia całości; zamiast tego używał odrębnego kodu typu pliku do identyfikacji formatu pliku. Dodatkowo, kod twórca został określony w celu określenia, która aplikacja zostanie uruchomiona, gdy plik jest ikona została podwójnym kliknięciu . macOS używa jednak sufiksów nazw plików, a także kodów typu i twórcy, w związku z tym, że pochodzi z systemu operacyjnego NeXTSTEP podobnego do UNIX .

Ulepszenia

Rozszerzenie nazwy pliku było pierwotnie używane do określenia ogólnego typu pliku. Konieczność skondensowania typu pliku do trzech znaków często prowadziła do skróconych rozszerzeń. Przykłady obejmują używanie .GFXdla plików graficznych, .TXTdla zwykłego tekstu i .MUSdla muzyki. Ponieważ jednak powstało wiele różnych programów, które obsługują te typy danych (i inne) na różne sposoby, rozszerzenia nazw plików zaczęły być ściśle powiązane z niektórymi produktami — nawet z określonymi wersjami produktów. Na przykład używane były wczesne pliki WordStar.WS lub , gdzie n było numerem wersji programu. Ponadto opracowano sprzeczne zastosowania niektórych rozszerzeń nazw plików. Jednym z przykładów jest , używany zarówno dla pakietów RPM Package Manager , jak i plików RealPlayer Media;. Inne to , współdzielone przez czcionki DESQview , księgi finansowe Quicken i obrazy QuickTime ; , udostępniane przez skrypty GrabIt i obrazy ROM Game Boy Advance ; , używany w SmallBasic i Scratch ; oraz , używany w Dynamix Three Space i DTS . .WSn.rpm.qif.gba.sb.dts

Niektóre inne systemy operacyjne, które używały rozszerzeń nazw plików, na ogół miały mniej ograniczeń dotyczących nazw plików. Wiele z nich zezwalało na pełną długość nazwy pliku wynoszącą 14 lub więcej znaków, a maksymalna długość nazwy do 255 nie była niczym niezwykłym. Systemy plików w systemach operacyjnych, takich jak Multics i UNIX, przechowują nazwę pliku jako pojedynczy ciąg, nie dzielony na nazwę podstawową i składniki rozszerzenia, co pozwala na „.” być po prostu kolejnym znakiem dozwolonym w nazwach plików. Takie systemy generalnie dopuszczają nazwy plików o zmiennej długości, dopuszczając więcej niż jedną kropkę, a zatem wiele sufiksów. Niektóre komponenty systemów Multics i UNIX oraz działające na nich aplikacje używały w niektórych przypadkach sufiksów do wskazywania typów plików, ale nie używały ich tak często — na przykład pliki wykonywalne i zwykłe pliki tekstowe nie miały sufiksów w swoich nazwach.

File system High Performance (HPFS), używany w programie Microsoft i IBM „s OS / 2 wspierany także długie nazwy plików i nie podzielić nazwę pliku w nazwie i rozszerzeniu. Kontynuowano konwencję używania przyrostków, mimo że system HPFS obsługiwał atrybuty rozszerzone dla plików, umożliwiając przechowywanie typu pliku w pliku jako atrybutu rozszerzonego.

Natywny system plików Microsoft Windows NT , NTFS , obsługiwał długie nazwy plików i nie dzielił nazwy pliku na nazwę i rozszerzenie, ale znowu utrzymano konwencję używania sufiksów do symulowania rozszerzeń, aby zapewnić zgodność z istniejącymi wersjami systemu Windows.

Kiedy po raz pierwszy nadeszła era Internetu , osoby korzystające z systemów Windows, które nadal były ograniczone do formatów nazw plików 8.3 , musiały tworzyć strony internetowe z nazwami kończącymi się na .HTM, podczas gdy osoby korzystające z komputerów Macintosh lub UNIX mogły używać zalecanego .htmlrozszerzenia nazwy pliku. Stało się to również problemem dla programistów eksperymentujących z językiem programowania Java , ponieważ wymaga on czteroliterowego sufiksu .javadla plików kodu źródłowego i pięcioliterowego sufiksu .classdla plików wyjściowych kodu obiektowego kompilatora Java .

Ostatecznie system Windows 95 wprowadził obsługę długich nazw plików i usunął podział nazwy/rozszerzenia 8.3 w nazwach plików z systemu Windows innego niż NT, w rozszerzonej wersji powszechnie używanego systemu plików FAT o nazwie VFAT . VFAT po raz pierwszy pojawił się w Windows NT 3.5 i Windows 95 . Wewnętrzna implementacja długich nazw plików w VFAT jest w dużej mierze uważana za kłopot , ale usunęła ważne ograniczenie długości i pozwoliła plikom na mieszanie wielkich i małych liter na maszynach, które nie działały dobrze z Windows NT .

Problemy z nazwami poleceń

Użycie rozszerzenia nazwy pliku w nazwie polecenia pojawia się sporadycznie, zwykle jako efekt uboczny zaimplementowania polecenia jako skryptu, np. dla powłoki Bourne lub dla Pythona , a nazwa interpretera jest dodawana do nazwy polecenia, a praktyka powszechnie stosowana w systemach, które opierają się na powiązaniach między rozszerzeniem nazwy pliku a interpreterem, ale zdecydowanie przestarzała w systemach uniksopodobnych, takich jak Linux , Oracle Solaris , systemy oparte na BSD i macOS firmy Apple , gdzie interpreter jest zwykle określany jako nagłówek w scenariusz (" shebang ").

W systemach opartych na asocjacjach rozszerzenie nazwy pliku jest zazwyczaj mapowane do jednego, ogólnosystemowego wyboru interpretera dla tego rozszerzenia (takiego jak „.py” oznaczające użycie Pythona), a samo polecenie można uruchomić z wiersza poleceń, nawet jeśli rozszerzenie jest pomijane (zakładając, że dokonano odpowiedniej konfiguracji). Zmiana języka implementacji powoduje również zmianę rozszerzenia nazwy komendy, a system operacyjny udostępnia spójny interfejs API , umożliwiając użycie tej samej wersji komendy bez rozszerzeń w obu przypadkach. Ta metoda cierpi nieco z powodu zasadniczo globalnego charakteru mapowania skojarzeń, a także z powodu niepełnego unikania przez programistów rozszerzeń podczas wywoływania programów, a programiści nie mogą tego wymusić. Windows jest jedynym rozpowszechnionym pracodawcą tego mechanizmu.

W systemach z dyrektywami interpretera , włączając w to praktycznie wszystkie wersje Uniksa, rozszerzenia nazw poleceń nie mają specjalnego znaczenia i standardowo nie są używane, ponieważ podstawową metodą ustawiania interpreterów dla skryptów jest uruchamianie ich od jednej linii określającej interpreter do wykorzystanie (co może być postrzegane jako zdegenerowany widelec zasobów ). W tych środowiskach włączenie rozszerzenia w nazwie polecenia niepotrzebnie ujawnia szczegóły implementacji, które narażają wszystkie odniesienia do poleceń z innych programów na przyszłe ryzyko, jeśli implementacja ulegnie zmianie. Na przykład, byłoby całkowicie normalne, gdyby skrypt powłoki został ponownie zaimplementowany w Pythonie lub Ruby, a później w C lub C++, z których wszystkie zmieniłyby nazwę polecenia, gdyby użyto rozszerzeń. Bez rozszerzeń program zawsze ma taką samą nazwę bez rozszerzeń, ze zmienia się tylko dyrektywa interpretera i/lub liczba magiczna , a odniesienia do programu z innych programów pozostają ważne.

Problemy z bezpieczeństwem

Domyślne zachowanie Eksploratora plików , przeglądarki plików dostarczanej z systemem Microsoft Windows , polega na tym, że rozszerzenia nazw plików nie są wyświetlane. Szkodliwi użytkownicy próbowali rozprzestrzeniać wirusy komputerowe i robaki komputerowe , używając nazw plików utworzonych w stylu LOVE-LETTER-FOR-YOU.TXT.vbs. Mamy nadzieję, że pojawi się on jako LOVE-LETTER-FOR-YOU.TXT, nieszkodliwy plik tekstowy, bez powiadamiania użytkownika o tym, że jest to szkodliwy program komputerowy, w tym przypadku napisany w VBScript . Domyślnym zachowaniem ReactOS jest wyświetlanie rozszerzeń nazw plików w ReactOS Explorer .

Późniejsze wersje systemu Windows (począwszy od Windows XP Service Pack 2 i Windows Server 2003 ) zawierały konfigurowalne listy rozszerzeń nazw plików, które powinny być uważane za „niebezpieczne” w niektórych „strefach” działania, na przykład po pobraniu z sieci lub otrzymanych w formie e- załącznik do poczty. Nowoczesne systemy oprogramowania antywirusowego pomagają również bronić użytkowników przed takimi próbami ataków tam, gdzie to możliwe.

Niektóre wirusy wykorzystać podobieństwa między „ Comdomeny najwyższego poziomu i „.COM” rozszerzenia pliku wysyłając złośliwy wykonywalnych załączników poleceń pod nazwami plików powierzchownie podobny do URL ( na przykład «myparty.yahoo.com» ).

Zdarzały się przypadki złośliwego oprogramowania stworzonego w celu wykorzystania luk w niektórych aplikacjach systemu Windows, które mogły spowodować przepełnienie bufora stosu podczas otwierania pliku o zbyt długim, nieobsługiwanym rozszerzeniu nazwy pliku.

Rozszerzenie nazwy pliku to tylko znacznik, a zawartość pliku nie musi mu odpowiadać. Może to służyć do ukrywania złośliwej zawartości. Podczas próby zidentyfikowania pliku ze względów bezpieczeństwa uważa się za niebezpieczne poleganie na samym rozszerzeniu i preferowana jest właściwa analiza zawartości pliku. Na przykład w systemach pochodnych UNIX często zdarza się, że można znaleźć pliki bez żadnych rozszerzeń, ponieważ polecenia takie jak plik (polecenie) są przeznaczone do użycia zamiast nich i będą czytać nagłówek pliku w celu określenia jego zawartości.

Alternatywy

W wielu protokołach internetowych , takich jak HTTP i MIME e-mail , typ strumienia bitów jest określany jako typ nośnika lub typ MIME strumienia, a nie jako rozszerzenie nazwy pliku. Jest to podane w wierszu tekstu poprzedzającym strumień, na przykład Content-type: text/plain .

Nie ma standardowego mapowania między rozszerzeniami nazw plików a typami nośników, co powoduje możliwe niezgodności w interpretacji między autorami, serwerami sieciowymi i oprogramowaniem klienckim podczas przesyłania plików przez Internet. Na przykład autor treści może określić rozszerzenie svgz dla skompresowanego pliku Scalable Vector Graphics , ale serwer sieciowy, który nie rozpoznaje tego rozszerzenia, może nie wysłać prawidłowego typu zawartości application/svg+xml i wymaganego nagłówka kompresji, pozostawiając przeglądarki internetowe nie jest w stanie poprawnie zinterpretować i wyświetlić obrazu.

BeOS , którego system plików BFS obsługuje atrybuty rozszerzone, oznaczyłby plik swoim typem nośnika jako atrybut rozszerzony. Środowiska graficzne KDE i GNOME kojarzą typ nośnika z plikiem, analizując zarówno przyrostek nazwy pliku, jak i zawartość pliku, w sposób heurystyczny , na wzór polecenia pliku . Wybierają aplikację do uruchomienia po otwarciu pliku na podstawie tego typu nośnika, zmniejszając zależność od rozszerzeń nazw plików. System macOS używa zarówno rozszerzeń nazw plików, jak i typów multimediów, a także kodów typów plików , aby wybrać identyfikator typu Uniform Type Identifier, za pomocą którego można wewnętrznie zidentyfikować typ pliku.

Zobacz też

Bibliografia

Zewnętrzne linki