Dosya uzantılarının herhangi bir amacı var mı (işletim sistemi için)?

Linux, dosya başlığındaki bir kod aracılığıyla bir dosyanın türünü belirler. Hangi yazılımın dosyayı açmak için kullanılacağını bilmek için dosya uzantılarına bağlı değildir.

Eğitimimden hatırladığım şey bu. Lütfen hatalı olduğumda beni düzelt!

Son zamanlarda Ubuntu sistemleriyle biraz Çalışma: Ben gibi uzantılara sahip sistemlerde dosyaların bir sürü görmek .sh, .txt, .o,.c

Şimdi merak ediyorum: Bu eklentiler sadece insanlar içindir? Yani ne tür bir dosya olduğu hakkında bir fikir edinmeli?

Yoksa işletim sistemi için de bir amaçları var mı?

Linux, dosya başlığındaki bir kod aracılığıyla bir dosyanın türünü belirler. Dosya ile bilmek dosya uzantılarına bağlı değildir, dosyayı açmak için kullanmaktır.

Eğitimimden hatırladığım şey bu. Lütfen hatalı olduğumda beni düzelt!

• doğru hatırladım.

Bu eklentiler sadece insanlar içindir?

• Evet, bir ama.

Uzantılara bağlı olan diğer işletim sistemleriyle etkileşime girdiğinizde, bunların ne olduğu daha akıllıca olur.

Windows'ta açılış yazılımı uzantılara eklenir.

"Dosya" "file.txt" adlı aynı dosyayı açarak daha Windows zordur adlı bir metin dosyası açılıyor (eğer dosya açık iletişim geçmek gerekir *.txtiçin *.*her zaman). Aynı şey TAB ve noktalı virgülle ayrılmış metin dosyaları için de geçerlidir. Aynı şey, e-postaların içe ve dışa aktarılması için de geçerlidir (.mbox eklentisi).

Özellikle yazılımı kodladığınızda. Bir HTML dosyası olan "software1" ve bir JavaScript dosyası olan "software2" adlı bir dosyayı açmak, "software.html" ve "software.js" ile karşılaştırıldığında daha zor hale gelir.

Linux'ta dosya uzantılarının önemli olduğu bir sistem varsa, bunu bir hata olarak adlandırırdım. Yazılım dosya uzantılarına bağlı olduğunda, bu istismar edilebilir. Bir dosyanın ne olduğunu belirlemek için bir tercüman yönergesi kullanıyoruz ("bir dosyadaki ilk iki bayt" #! "Karakterleri olabilir, bu da sihirli bir sayı oluşturur (onaltılık 23 ve 21," # "ve" ASCII değerleri! " ") sık sık shebang olarak anılır,").

Dosya uzantılarıyla ilgili en ünlü sorun Windows'ta LOVE-LETTER-FOR-YOU.TXT.vbs idi . Bu, dosya gezgininde bir metin dosyası olarak gösterilen görsel bir temel komut dosyasıdır.

Ubuntu'da, Nautilus'tan bir dosya başlattığınızda ne yapacağınız konusunda bir uyarı alırsınız. GEdit'i açması gereken bazı yazılımları başlatmak istediği Nautilus'tan bir betik çalıştırmak bir sorun olduğu açıktır ve bu konuda bir uyarı alıyoruz.

Bir şeyi çalıştırdığınızda komut satırında, uzantının ne olduğunu görsel olarak görebilirsiniz. Eğer .vbs ile biterse şüphelenmeye başlardım (ki .vbs Linux'ta çalıştırılabilir değil. En azından biraz daha çaba sarf etmeden;).

Burada% 100 siyah veya beyaz cevap yok.

Genellikle Linux, dosya adlarına (ve dosya uzantılarına, yani normalde son dönemden sonraki dosya adının bir kısmına) dayanmaz ve bunun yerine, içeriğinin ilk birkaç baytını inceleyerek ve bunu bilinen sihirli sayılar listesiyle karşılaştırarak dosya türünü belirler. .

Örneğin, tüm Bitmap görüntü dosyaları (genellikle ad uzantısına sahip .bmp) BMilk iki bayttaki harflerle başlamalıdır . Bash, Python, Perl, AWK, vb. Gibi çoğu betik dilindeki komut dosyaları (temelde #yorum olarak başlayan satırları işleyen her şey ), #!/bin/bashilk satır gibi bir shebang içerebilir . Bu özel yorum sisteme dosyayı hangi uygulamayı açacağını söyler.

Bu nedenle, işletim sistemi normal olarak dosya içeriğine dayanır ve dosya türünü belirleme adına değil, dosya uzantılarının Linux'ta hiçbir zaman gerekli olmadığını belirten gerçeğin sadece yarısıdır.

Uygulamalar elbette, dosya adının ve uzantının doğrulanmasını da içeren dosya denetimlerini istedikleri gibi uygulayabilir. Bunun bir örneği, eogdosya biçimine göre görüntü biçimini belirleyen ve içerikle eşleşmiyorsa bir hata veren Gnome'nin Gözü'dür ( standart resim görüntüleyici). Bunun bir hata mı yoksa bir özellik mi olduğu tartışılabilir ...

Ancak, işletim sisteminin bazı bölümleri bile dosya adı uzantılarına dayanır; örneğin, yazılım kaynak dosyalarınızı ayrıştırırken /etc/apt/sources.list.d/yalnızca *.listuzantıya sahip dosyalar diğerlerinin yok sayılmasını sağlar. Belki de esas olarak buradaki dosya türünü belirlemek için kullanılmıyor, bunun yerine bazı dosyaların ayrıştırılmasını etkinleştirmek / devre dışı bırakmak, ancak hala sistemin bir dosyayı nasıl tedavi ettiğini etkileyen bir dosya uzantısı.

Ve tabii insan kullanıcı kar bariz bir dosya türünü yapar ve aynı zamanda aynı temel adla birden fazla dosya ve benzeri farklı uzantılar verir gibi dosya uzantıları en site.html, site.php, site.js, site.cssdezavantaj tabii vb dosya uzantısı ve gerçek dosya türünün / içeriğinin mutlaka eşleşmesi gerekmez.

Ek olarak, platformlar arası birlikte çalışabilirlik için gereklidir, çünkü Windows bir readmedosyayla ne yapacağını bilmeyecek , ancak yalnızca bir readme.txt.

Diğerleri tarafından belirtildiği gibi, Linux'ta tercüman direktif yöntemi (bazı meta verileri bir dosyada başlık veya sihir numarası olarak saklamak, böylece doğru tercümanın Windows tarafından kullanılan dosya adı uzantısı birleştirme yöntemi yerine okunması söylenebilir) kullanılır.

Bu, birkaç istisna dışında istediğiniz herhangi bir ada sahip bir dosya oluşturabileceğiniz anlamına gelir.

ancak

Dikkatli bir kelime eklemek istiyorum.

Sisteminizde dosya adı ilişkilendirmesini kullanan bir sistemden bazı dosyalarınız varsa, dosyalarda bu sihirli sayılar veya başlıklar olmayabilir. Dosya adı uzantıları, bu dosyaları okuyabilen uygulamalar tarafından tanımlamak için kullanılır ve bu dosyaları yeniden adlandırırsanız beklenmeyen efektlerle karşılaşabilirsiniz. Örneğin:

Bir dosyayı yeniden adlandırırsanız My Novel.dociçin My-Novel, LibreOffice yine açmak mümkün olacak, ancak 'İsimsiz' olarak açılır ve LibreOffice varsayılan olarak bir uzantı ekler (kaydetmek için tekrar isim vermek zorunda olacak, bu yüzden daha sonra olurdu iki dosya My-Novelve My-Novel.odtrahatsız edici olabilir)

Daha da ciddiyim, eğer bir dosyayı My Spreadsheet.xlsx'i My Spreadsheet olarak değiştirirseniz, onu açmaya çalışın xdg-open My-Spreadsheet(bunu gerçekte sıkıştırılmış bir dosya olduğu için) alacaksınız:

Ve bir dosyayı yeniden adlandırmak eğer My Spreadsheet.xlsiçin My-Spreadsheetne zaman, xdg-open My-Spreadsheetsen belirten bir hata olsun

açılış yeri hatası: Bu dosyanın kullanımı için hiçbir uygulama kayıtlı değil

(Her iki durumda da, yaparsanız tamam işe yarıyorsa da soffice My-Spreadsheet)

Eğer daha sonra extensionless dosyasını yeniden adlandırırsanız My-Spreadsheet.odsile mvve bu alacak açmaya:

(onarım başarısız)

Ve dosyayı doğru bir şekilde açmak için orijinal uzantıyı tekrar açmanız gerekir (dilerseniz formatı dönüştürebilirsiniz).

TL; DR:

Ad uzantısına sahip yerel olmayan dosyalarınız varsa, her şeyin yoluna gireceğini varsayarak uzantıları kaldırmayın!

Buna diğer cevaplardan farklı bir yaklaşım getirmek ve "Linux" veya "Windows" un bununla ilgisi olduğu fikrine meydan okumak istiyorum (benimle birlikte).

Bir dosya uzantısı kavramı basitçe "adının bir bölümünü temel alan bir dosyanın türünü tanımlamaya yönelik bir sözleşme" olarak ifade edilebilir. Bir dosyanın türünü tanımlamak için kullanılan diğer genel kurallar, içeriğini bilinen imza veritabanına ("sihirli sayı" yaklaşımı) karşı karşılaştırmak ve onu dosya sistemine (orijinal MacOS'ta kullanılan yaklaşım) fazladan bir öznitelik olarak depolamaktır. .

Bir Windows veya Linux sistemindeki her dosyanın hem adı hem de içeriği olduğundan, dosya türünü bilmek isteyen işlemler, uygun gördükleri gibi "uzantı" veya "sihirli sayı" yaklaşımlarını kullanabilir. Çoğu dosya sisteminde bu özellik için standart bir yer olmadığından meta veri yaklaşımı genel olarak kullanılamaz.

Windows'ta, dosya uzantısını bir dosyayı tanımlamanın birincil aracı olarak kullanma geleneği vardır; en belirgin şekilde, grafiksel dosya tarayıcısı (Windows 3.1'deki Dosya Yöneticisi ve modern Windows'daki Gezgin), hangi uygulamanın başlatılacağını belirlemek için bir dosyayı çift tıkladığınızda kullanır. Linux'ta (ve daha genel olarak Unix tabanlı sistemlerde), içeriği denetlemek için daha fazla gelenek var; en önemlisi, çekirdek, nasıl çalıştırılacağını belirlemek için doğrudan yürütülen bir dosyanın başlangıcına bakar; komut dosyaları, tercümanın #!yolunu izleyerek başlayarak kullanacağınız bir tercümanı belirtebilir .

Bu gelenekler, her bir sistem için yazılan programların UI tasarımını etkiler, ancak birçok istisna vardır, çünkü her yaklaşımın farklı durumlarda artıları ve eksileri vardır. İçeriği incelemek yerine dosya uzantılarını kullanma nedenleri:

• dosya içeriğinin incelenmesi, dosya adlarının incelenmesi ile karşılaştırıldığında oldukça maliyetlidir; bu nedenle, "* .conf adlı tüm dosyaları bul", "ilk satırı bu imzayla eşleşen tüm dosyaları bul" dan çok daha hızlı olacaktır.
• dosya içerikleri belirsiz olabilir; Birçok dosya formatı aslında sadece özel bir şekilde işlenen metin dosyalarıdır, diğerleri ise özel olarak yapılandırılmış zip dosyalarıdır ve bunlar için doğru imzalar tanımlamak zordur.
• bir dosya gerçekten birden fazla tür olarak geçerli olabilir; Bir HTML dosyası da geçerli XML olabilir, bir zip dosyası ve bir araya getirilmiş bir GIF her iki format için de geçerli kalır
• sihirli sayı eşleştirmesi yanlış pozitiflere yol açabilir; başlığı olmayan bir dosya formatı, "GIF89a" baytlarıyla başlayabilir ve GIF resmi olarak yanlış tanımlanabilir
• bir dosyayı yeniden adlandırmak "devre dışı" olarak işaretlemek için uygun bir yol olabilir; örneğin, bir yedeği belirtmek için "foo.conf" ifadesini "foo.conf ~" olarak değiştirmek, dosyayı tüm yönergelerini yorumlayacak şekilde düzenlemekten daha kolay ve otomatik olarak yüklenen bir dizinden çıkarmaktan daha kolaydır; Benzer şekilde, bir .php dosyasını .txt olarak yeniden adlandırmak Apache'ye kaynağını PHP motoruna iletmek yerine düz metin olarak sunmasını söyleyecektir.

Varsayılan olarak dosya adlarını kullanan Linux programlarına örnekler (ancak başka modları olabilir):

• gzip ve gunzip, ".gz" ile biten herhangi bir dosyanın özel işlemesine sahiptir.
• gcc, ".c" dosyalarını C, ve ".cc" veya ".C" yi C ++ olarak işleyecektir.

Aslında, bazı teknolojiler do dosya uzantılarına güvenmek, bu nedenle Ubuntu bu teknolojileri kullanan, sen de uzantıları güvenmek gerekir. Birkaç örnek:

• gccC + C ++ dosyalarını ayırt etmek için uzantıları kullanır. Uzantı olmadan onları ayırt etmek neredeyse imkansız (sınıfsız bir C ++ dosyası hayal edin).
• Birçok dosyaları ( docx, jar, apk) sadece özellikle ZIP arşivleri yapılandırılmıştır. Genellikle içerikten türünü tahmin mümkün olmakla birlikte, bu her zaman mümkün olmayabilir (örneğin Java Manifest olan isteğe bağlı yer jardosyaları).

Bu gibi durumlarda dosya uzantılarını kullanmamak, yalnızca geçici olmayan çözümlerle mümkün olabilir ve çok hataya açık olması muhtemeldir.

İlk varsayımınız doğrudur: Linux'taki uzantılar önemli değildir ve sadece insanlar (ve uzantıları önemseyen Unix benzeri olmayan işletim sistemleri için faydalıdır). Bir dosyanın türü, sihirli sayı olarak bilinen dosyadaki ilk 32 bit veri tarafından belirlenir. Bu nedenle kabuk komut dosyalarının #!satırlara ihtiyacı vardır - işletim sistemine hangi tercümanın çağırılacağını söylemek için. Onsuz, kabuk betiği sadece metin dosyasıdır.

Dosya yöneticileri gittikçe, .desktoptemelde, Windows'un kısayol sürümüyle aynı olan ancak daha fazla özellik içeren dosyalar gibi bazı dosyaların uzantılarını bilmek istiyorlar . Ancak işletim sistemi söz konusu olduğunda, dosyada ne olduğunu değil, dosyada ne olduğunu bilmesi gerekir.

Bu bir yorum cevabı için çok büyük.

Eğer farklı anlamlar varsa "uzatma" bile çok şey olduğunu unutmayın.

Senin bahsettiğin şey, ondan sonraki 3 harf gibi görünüyor. DOS 8.3 biçimini gerçekten popüler yaptı ve Windows bu güne .3 bölümünü kullandı.

Linux, .conf veya .list veya .d veya .c gibi birçok anlamı olan, ancak 8.3 anlamında gerçekten bir uzantısı olmayan dosyalara sahiptir. Örneğin Apache, yapılandırma yönergesi için /etc/apache2/sites-enabled/website.conf adresine bakar. Sistem MIME Türleri ve içerik üstbilgileri kullanırken ve ne bir metin dosyası olarak belirlenmemesi gerektiğine rağmen, Apache (varsayılan olarak) hala .conf ile bitmeden yüklenmeyecektir.

.c başka büyük olanıdır. Evet, bu bir metin dosyası, ancak gcc main.o ve nihayetinde main (hale geldikten sonra) main.o olmaya bağlı. Sistem hiçbir zaman .c, .o kullanır veya hiçbir uzantıyı içerik kadar anlamsız olmak için kullanır, ancak ondan sonraki şeyler. bir anlamı var. SCM'nizi main.o ve main'i görmezden gelecek şekilde ayarlamış olabilirsiniz.

Olması gereken nokta şudur: Uzantılar, pencerelerde olduğu gibi kullanılmaz. Çekirdek bir .txt dosyası yürütmez çünkü adın .txt bölümünü kaldırırsınız. Yürütme izni ayarlanmışsa bir .txt dosyası çalıştırmak da çok mutludur. Olduğu söyleniyor, bir anlamı var ve hala birçok şey için "bilgisayar düzeyinde" kullanılıyor.