ファイル拡張子には目的がありますか（オペレーティングシステム用）？

Linuxは、ファイルヘッダーのコードを介してファイルのタイプを判別します。ファイルを開くために使用するソフトウェアを知るために、ファイル拡張子に依存しません。

それは私の教育から覚えていることです。私が間違っている場合に備えて修正してください！

最近のUbuntuシステムと少しの作業：私のような拡張子を持つシステム上のファイルの多くを参照してください.sh、.txt、.o、.c

今、私は不思議に思っています：これらの拡張機能は人間専用のものですか？それでは、どのようなファイルであるかを把握する必要がありますか？

または、オペレーティングシステムにも何らかの目的がありますか？

Linuxは、ファイルヘッダーのコードを介してファイルのタイプを判別します。ソフトウェアがファイルを開くために使用することを知るために、ファイル拡張子に依存しません。

それは私の教育から覚えていることです。私が間違っている場合に備えて修正してください！

• 正しく記憶された。

これらの拡張機能は人間のみを対象としていますか？

• はい、しかし。

拡張機能に依存している他のオペレーティングシステムとやり取りするときは、それらを使用するのが賢明です。

Windowsでは、開くソフトウェアは拡張機能に添付されます。

「file」という名前のテキストファイルを開くことは、「file.txt」という名前の同じファイルを開くよりもWindowsで難しくなります（ファイルを開くダイアログ*.txtを*.*毎回切り替える必要があります）。TABおよびセミコロンで区切られたテキストファイルについても同様です。電子メール（拡張子.mbox）のインポートおよびエクスポートについても同じことが言えます。

特に、ソフトウェアをコーディングする場合。HTMLファイルである「software1」およびJavaScriptファイルである「software2」という名前のファイルを開くことは、「software.html」および「software.js」に比べて難しくなります。

Linuxでファイル拡張子が重要な場所にシステムがある場合、それをバグと呼びます。ソフトウェアがファイル拡張子に依存している場合、それは悪用可能です。私たちは、使用通訳ディレクティブを『マジックナンバー（16進数23と21、のASCII値構成する「！＃『ファイルの最初の2バイト文字もできる』（ファイルが何であるかを識別するために、＃を』と」！ 「）シバンと呼ばれることも多い」）。

ファイル拡張子に関する最も有名な問題は、WindowsのLOVE-LETTER-FOR-YOU.TXT.vbsでした。これは、ファイルエクスプローラーにテキストファイルとして表示される視覚的な基本スクリプトです。

Ubuntuでは、Nautilusからファイルを起動すると、何をするのかという警告が表示されます。gEditを開くはずのソフトウェアを起動したいNautilusからスクリプトを実行することは明らかな問題であり、警告が表示されます。

コマンドラインで何かを実行すると、拡張機能が何であるかを視覚的に確認できます。.vbsで終わる場合、私は疑わしくなり始めます（.vbsがLinuxで実行可能であるということではありません。少なくとも努力なしではありません;））。

ここに100％の黒または白の答えはありません。

通常、 Linuxはファイル名（およびファイル拡張子、つまり通常最後のピリオドの後のファイル名の部分）に依存せず、代わりにそのコンテンツの最初の数バイトを調べ、既知のマジックナンバーのリストと比較することでファイルタイプを決定します。

たとえば、すべてのビットマップイメージファイル（通常は名前の拡張子を持つ.bmp）BMは、最初の2バイトの文字で始まる必要があります。Bash、Python、Perl、AWKなどのほとんどのスクリプト言語（基本的に#コメントで始まる行を処理するすべてのもの）のスクリプトには、#!/bin/bash最初の行のようなシバンが含まれる場合があります。この特別なコメントは、ファイルを開くアプリケーションをシステムに伝えます。

そのため、通常、オペレーティングシステムはファイルの種類を決定するためにファイルの名前ではなくファイルの内容に依存しますが、Linuxではファイル拡張子が必要ないということは真実の半分にすぎません。

もちろん、アプリケーションは必要に応じてファイルチェックを実装できます。これには、ファイル名と拡張子の検証が含まれます。例として、GnomeのEye（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は引き続き開くことができますが、「Untitled」として開き、保存するために再度名前を付ける必要があります（Libreofficeはデフォルトで拡張子を追加するため、 2つのファイル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.odswithに変更して、mv開こうとすると、次のようになります。

（修復は失敗します）

また、ファイルを正しく開くには元の拡張子を戻す必要があります（必要に応じて形式を変換できます）。

TL; DR：

名前の拡張子が付いた非ネイティブファイルがある場合は、すべてが正常であると仮定して拡張子を削除しないでください！

私はこれに対して他の答えとは異なるアプローチを取り、「Linux」または「Windows」がこれと関係があるという考えに挑戦したいと思います（私と一緒に耐えてください）。

ファイル拡張子の概念は、単に「名前の一部に基づいてファイルのタイプを識別するための規則」として表現できます。ファイルの種類を識別するためのその他の一般的な規則は、その内容を既知の署名のデータベースと比較し（「マジックナンバー」アプローチ）、追加の属性としてファイルシステムに保存します（元のMacOSで使用されたアプローチ） 。

WindowsまたはLinuxシステム上のすべてのファイルには名前と内容の両方があるため、ファイルの種類を知りたいプロセスは、「拡張子」または「マジックナンバー」アプローチを適切に使用できます。ほとんどのファイルシステムにはこの属性の標準的な場所がないため、メタデータアプローチは一般に利用できません。

Windowsでは、ファイルを識別する主な手段としてファイル拡張子を使用する強い伝統があります。最も目に見えるのは、ファイルをダブルクリックして起動するアプリケーションを決定するときに、グラフィカルファイルブラウザー（Windows 3.1のファイルマネージャーと最新のWindowsのエクスプローラー）がそれを使用することです。Linux（より一般的にはUnixベースのシステム）では、コンテンツを検査するための伝統があります。最も顕著なのは、カーネルが直接実行されるファイルの先頭を見て、その実行方法を決定することです。スクリプトファイルは、使用するインタープリターを示すために、インタープリターへ#!のパスを続けて開始します。

これらの伝統は、各システム用に記述されたプログラムのUI設計に影響を与えますが、各アプローチには異なる状況で長所と短所があるため、多くの例外があります。内容を調べるのではなくファイル拡張子を使用する理由は次のとおりです。

• ファイルの内容を調べることは、ファイル名を調べることと比較してかなりコストがかかります。たとえば、「*。confという名前のすべてのファイルを検索する」は、「最初の行がこの署名に一致するすべてのファイルを検索する」よりもはるかに高速です
• ファイルの内容があいまいになることがあります。多くのファイル形式は実際には特別な方法で処理された単なるテキストファイルであり、他の多くは特別に構造化されたzipファイルであり、これらの正確な署名を定義するのは難しい場合があります
• ファイルは、複数のタイプとして真に有効な場合があります。HTMLファイルも有効なXMLである可能性があります。ZipファイルとGIFを連結すると、両方の形式で有効です。
• マジックナンバーの一致により、誤検出が生じる可能性があります。ヘッダーのないファイル形式は、「GIF89a」バイトで始まり、GIF画像と誤認されることがあります
• ファイルの名前を変更すると、そのファイルを「無効」とマークする便利な方法になります。たとえば、「foo.conf」を「foo.conf〜」に変更すると、ファイルを編集してすべてのディレクティブをコメントアウトするよりも簡単であり、自動ロードされたディレクトリから移動するよりも便利です。同様に、.phpファイルの名前を.txtに変更すると、ApacheはソースをPHPエンジンに渡すのではなく、プレーンテキストとして提供するようになります。

デフォルトでファイル名を使用するLinuxプログラムの例（ただし、他のモードがある場合があります）：

• gzipおよびgunzipは、「。gz」で終わるファイルを特別に処理します。
• gccは「.c」ファイルをCとして、「。cc」または「.C」をC ++として処理します

実際、一部のテクノロジーはファイル拡張子に依存しているため、Ubuntuでこれらのテクノロジーを使用する場合は、拡張子にも依存する必要があります。いくつかの例：

• gcc拡張機能を使用して、CとC ++ファイルを区別します。拡張機能がなければ、それらを区別することはほとんど不可能です（クラスのないC ++ファイルを想像してください）。
• 多くのファイルは（docx、jar、apk）だけで、特に構造化されたZIPアーカイブです。通常、コンテンツからタイプを推測できますが、常に可能とは限りません（たとえば、ファイルのJavaマニフェストはオプションjarです）。

このような場合にファイル拡張子を使用しないことは、ハッキングの回避策でのみ可能となり、非常にエラーが発生しやすくなります。

最初の仮定は正しい：Linuxの拡張機能は重要ではなく、人間（および拡張機能を気にする他の非Unix系OS）にのみ有用です。ファイルのタイプは、ファイル内の最初の32ビットのデータによって決定されます。これは、マジックナンバーとして知られています。 これが、シェルスクリプトに#!行が必要な理由です。それがなければ、シェルスクリプトは単なるテキストファイルです。

ファイルマネージャーに関する限り、ファイルなどの一部のファイルの拡張子を知りたいと思ってい.desktopます。これは、Windowsのショートカットバージョンと基本的に同じですが、より多くの機能を備えています。しかし、OSに関する限り、ファイルの名前ではなく、ファイルの内容を知る必要があります。

これはコメントの回答には大きすぎます。

意味が異なれば、「拡張」でさえ多くのことを忘れないでください。

あなたが話しているのは、後の3文字のようです。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、または拡張子を使用せず、コンテンツに関しては意味を持ちますが、。何らかの意味があります main.oとmainを無視するようにSCMをセットアップするでしょう。

ポイントはこれです：拡張機能は、ウィンドウのようには使用されません。名前の.txt部分を削除するため、カーネルは.txtファイルを実行しません。実行権限が設定されている場合は、.txtファイルを実行することも非常に幸せです。そうは言っても、それらには意味があり、いまだに多くの目的で「コンピューターレベル」で使用されています。