拡張機能がURLでしばしば隠されるのはなぜですか?


20

多くの場合、URL拡張機能は非表示になっています(例:)が.html.phpすべてのWebサイトがこれを行うわけではありません。

ウェブマスターが拡張機能を隠すのはなぜですか?セキュリティのためか、URLがよりきれいに見えるようにするためか、それとも他の目的のためですか?


回答:


29

URLから拡張子を削除する理由はいくつかあります。

  • URLをきれいにするには
  • URLを入力しやすくする
  • URLを覚えやすくするため
  • URLをよりSEOキーワードフレンドリーにするには
  • テクノロジーを変更できるようにする-サイトをあるテクノロジーから別のテクノロジーに移動したい場合は、URLに拡張子がないかどうかさえユーザーに知られずに行うのが最も簡単です

多くのサイトはコンテンツ管理システム(CMS)によって生成され、URLが次のようになることを覚えておいてください/index.php?page=this-is-the-widget-page。これは特にく、単なる拡張よりもはるかに厄介です。削除index.php?page=するように書き換えると、はるかに改善されます。

サーバーはドキュメントの種類をヘッダーとして送信するため、Web上で拡張機能は必要ありません。Webページはtext/html、として、image/pngまたはとして提供されimage/jpegます。これにより、ブラウザは拡張機能を使用せずにコンテンツをレンダリングする方法を認識し、URLにテキスト、HTML、PDF、または画像が含まれていることを把握できます(詳細については、Wikipediaの記事インターネットメディアタイプを参照してください)。

一部のウェブマスターは、このコンテンツタイプに一致する拡張子をURLで使用することを選択します。そのため、text/htmlドキュメントには.html拡張子があり、image/pngドキュメントには.png拡張子があります。これは、コンテンツタイプに関するメタデータが失われるファイルシステムにURLが保存されるときに役立ちます。ほとんどのファイルシステムでは、ファイルを開くプログラムは拡張子によって選択されます。そのため、ページがPHPによって提供されている場合でも、一部のWebマスターは.php拡張機能を削除し、一部のWebマスターはそれをに置き換え.htmlます。

また、URLが/拡張子持たない場合に、末尾のスラッシュ()で終わる方が良いかどうかという質問もあります。これは、スタックオーバーフローについて多くの議論があります。


11
一部のフレームワーク(MVCなど)では、URLがファイルを識別しないため、非表示にする拡張子はありません。
ヘンリックリパ

6

すべてのWebサーバーには、1つ以上の「デフォルトファイル」があります。これは、訪問者がスラッシュ/で終わるURL(フォルダーなど)にアクセスするたびに表示されるファイルです。

Webサーバー上のデフォルトのファイル名がindex.phpで、訪問者www.example.com/pagename/アクセスする場合、実際にアクセスしていwww.example.com/pagename/index.phpます。

末尾がない場合/、WebサーバーはおそらくURLを書き換えて削除するだけです。必要がないためです。実際、このサイトはそうしています。


2
質問が「どのように」ではなく「なぜ」であったかはわかりません。Patrikの答えは、方法に関しては絶対に正しいです。スティーブンは、しかし、「なぜ」と答えた
ブラント・ソロヴィ

4

これは、個人のWebサイトで目指している「クールな」URIスキームのタイプです。

(!あまりにも、おそらくより多くのウェブデザイナー/開発者)個人的に、私はそうすることを始めた理由は、記事を読んだ後だった「クールなURIは変わらない」 -この文書は、ワールド・ワイド・ウェブの建国の父、ティム・バーナーズによって書かれました-リー。

Tim Berners-Leeの有名な記事で、彼は基本的にStephen Ostermillerこの質問に対する優れた答えを持っているのと同じ理由を述べてい ます。

「拡張機能がURLに隠されている理由」という主な質問に対してより具体的な回答をするために、私は主な理由は次のとおりです。

1. URIを将来にわたって保証するには:

たとえば、次のようなURIを使用するのは良いアイデアのように聞こえるかもしれません。 http://www.example.com/page.pl ここ.plで、Perlスクリプトのファイル拡張です。しかし前夜のでしかし、thesedaysは、ほとんどのWeb開発者は、バックエンド・スクリプトのためのASP.NETやPHPを使用して、今日http://www.example.com/page.php 良いアイデアのような音が、最終的にはPHPやASP / ASP.netは、昔ながらになります。そのため、拡張機能を完全に削除することをお勧めします。

2.可読性と記憶性:

覚えやすいことは言うまでもなく、「クール」なURIを紙の上(紙、広告、名刺など)で口頭で渡すのがはるかに簡単です。

3.「ハッキング可能性」 *

最近のユーザーの大部分はおそらくすべての検索エンジンを通過すると思いますが、アドレスバーにアクセスしてを入力しwww.google.com、次にGoogleを使用して文字どおりに入力する人を見たことがありますwww.ebay.com。しかし、マルチメディアに基づいたWebサイトがある場合、URI http://www.example.com/videoは、音楽セクションがURI http://www.example.com/audioなどの下にあることを示唆していると思います。(私はまだアドレスバーを使用してWebサイトにアクセスします。私はその種のことについてかなり「昔ながら」です!)

*(ああ!「ハッカビリティ」–その言葉は存在しますか?!それはそうです今ます!):-)

4. **美学: それらをきれいに見せるために!(私のOCDを非難!)

ただし、SEO関連のさまざまなWebサイトを読んで、多くのWebメーザーが実際にファイル拡張子を動的URIに追加していることに気付きました。

実際のURIは次のとおりです。 http://www.example.com/article

ただし、Webマスターは書き換えを実行して、URIを次のように静的に「見える」ようにします。 http://www.example.com/article.html

この背後にあるロジックは、基本的に、検索エンジンが静的ページに高いランキングを割り当てることです(明らかに、変更される可能性は低い)。(私はSEOの専門家ではありませんが、個人的にはこの考えに賛同していません。GoogleとBingのアルゴリズムの背後にあるような考え方で、偽のファイル拡張子以上のものが必要になると思います。 SERPポールポジションにあなたの方法を詐欺!)

URIの命名の詳細については、次の記事を読むことをお勧めします。

ティムバーナーズリー:

W3C QAのヒント:

ブライアン・ケリー(UK Web Focus / UKOLN-バース大学):

お役に立てれば!


2

上記のすべての答えに完全に同意します。拡張機能がURLに表示されない理由の1つを追加するだけで、セキュリティが確保されます。簡単に言えば、URLで拡張子を公開しない場合、アプリケーションが構築された技術を理解することはほとんど困難です。したがって、PHPで作成された拡張機能が隠されていない場合、ハッカーは潜在的にPHPの脆弱性を把握し、悪意のあるアクティビティを実行する可能性があります。


私はあなたのコメントに同意しますが、セキュリティ対策としてバックエンドテクノロジーを難読化するためにURIを使用することは役に立たないと思います。一見すると、使用されている特定のテクノロジー隠れています。残念ながら、これを「だます」人はエンドユーザーだけです。ASP / PHP /などは言うまでもなく、URLが何であるかがわからないものもあります(ほとんどではありません)。より良いフレーズの欠如のために、あなたは一種のです「聖歌隊に説教。」
ヨルダンクラーク

1

ページの拡張機能を非表示にするかどうかに関係なく、ユーザーはあなたがどのテクノロジーを使用したかを知ることができます。cURLを使用することで、ヘッダー情報を取得してテクノロジーを取得することは不可能ではありません。

curl -I -L rembatvideo.ga

次に、テクノロジー、キャッシュ要求、接続などのようなものが表示されます。


0

「Stephen Ostermiller」が説明するとおり完全に同意しますが、URLの拡張子を隠すための秘trickに言及したいと思います。そのためには、.htaccess書き換えルールを使用する必要があります。これを支援するスクリプトを次に示します。

外部.phpリクエストを拡張子のないURLにリダイレクトする

RewriteCond %{THE_REQUEST} ^(.+)\.php([#?][^\ ]*)?\ HTTP/
RewriteRule ^(.+)\.php$ http://example.com/folder/$1 [R=301,L]
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.