Почему некоторые URL-адреса сайтов не включают расширение файла?
Я просматривал интернет и заметил, что YouTube, например, содержит URL-адрес, подобный этому, чтобы обозначить страницу видео:http://www.youtube.com/watch?v=gwS1tGLB0vc.
мой сайт использует такой URL для страницы темы:http://www.example.com/page.php?topic_id=6f3246d0sdf42c2jb67abba60ce33d5cc.
разница в том, если вы еще не заметили, что на youtube нет расширения файла для своей страницы просмотра, поэтому мне интересно,почему некоторые сайты не используют расширения файлов и какое использование он служит?
13 ответов
расширения файлов не используются из-за идеи, что URIs (и, следовательно, URL-адреса) должны быть независимы от реализации - если вы хотите получить доступ к адресам Джорджа У. Буша, вы должны иметь возможность перейти к http://www.whitehouse.gov/presidents/georgewbush/addresses (например). Используют ли серверы Белого дома PHP, Python или Perl, не имеет значения для конечного пользователя, поэтому они не должны его видеть. Конечному пользователю все равно, как была создана страница, потому что все веб языки выводят один и тот же HTML, CSS и тому подобное, и они просто просматривают страницу в своем веб-браузере.
большинство веб-фреймворков создают эту функциональность по умолчанию именно по этой причине, и это может быть выполнено независимо от перезаписи URL в большинстве веб-серверов. Этот идеал кодифицирован в руководстве по стилю W3C, которое, несомненно, является большим сторонником этой идеи, столь широко принятой. Это изложено в их руководстве, "крутые Ури не меняются", который должен проясните вещи, если вы все еще не совсем понимаете, почему здесь. Этот документ является предварительным заявлением по этому вопросу и стандартом де-факто для рамок.
стоит отметить, что обычно файлы, которые в конечном итоге загрузить (и иногда файлы данных, используемые в AJAX) по-прежнему будут иметь свои расширения файлов неповрежденными -http://example.com/song.mp3 или http://example.com/whitepaper.pdf - потому что они предназначены для сохранения в компьютер конечного пользователя, где расширения файлов имеют значение. Расширения не включены для страниц, которые просто отображается - большинство страниц.
то, что вы видите, является примером маршрутизации URL. Вместо того, чтобы указывать на определенный файл (например, page.php), сервер использует таблицу маршрутизации или конфигурацию, которая направляет запрос обработчику, который фактически отображает html (или что-либо еще в зависимости от возвращаемого типа mime). Если вы заметили, StackOverflow использует тот же механизм.
наличие или отсутствие расширения не имеет значения. Браузер действует на тип MIME, возвращаемый сервером, а не на любое расширение, используемое в URL-адресе.
когда вы спросите " почему?- вы спрашиваете о технической причине или о причине дизайна? Некоторые люди уже ответили на технические вопросы, поэтому я просто прокомментирую дизайн.
в основном это сводится к тому, что url-адрес является конечной точкой. Это место, куда должны попасть пользователи/службы. Расширение в большинстве случаев не имеет значения. Если пользователь просматривает веб-страницы и переходит кhttp://site.com/users он ожидает список пользователей. Ему все равно, что там не написано .html или .РНР. И как дизайнер, использующий эти расширения, на самом деле не имеет смысла. Вы хотите, чтобы ваше приложение имело смысл, и эти расширения на самом деле не обеспечивают понимания, что нужно пользователю.
раз, когда вы хотели бы использовать их, если бы вы создавали службу, которую будут использовать другие приложения. Затем вы можете использовать расширение для обозначения того, какие данные можно ожидать получить обратно (.формат JSON. ,XML, и т. д). Есть люди, работающие над рекомендациями по дизайну и спецификациями для этого материала, но это все рано
в основном эти расширения используются, потому что так работали веб-серверы/клиенты по умолчанию. Когда веб-разработка созрела, мы начали относиться к URL-адресам более профессионально и попытались заставить их иметь смысл для людей, читающих/использующих их.
хотя расширения не имеют значения для браузера, который просто использует заголовки, переданные ему, чтобы определить, что отображать и как его отображать, скорее всего, они do вопрос на сервере. Например, в вашем поле может быть установлен интерпретатор php и ruby, но на вашем веб-сервере есть файлы конфигурации для сопоставления расширений файлов с типами MIME. Например, из php5 Apache.conf:
AddType application/x-httpd-php .php .phtml .php3
что говорит Apache, что файлы заканчиваются .РНР. ,phtml, который и .php3 должен быть распознан как PHP-файлы.
однако, поскольку расширения ничего не значат для клиента, URL-адреса часто выглядят "лучше" без них. Для этого используются такие технологии, как Apache mod_rewrite может использоваться для" перезаписи " URL-адресов клиентской земли, чтобы иметь значение на сервере.
например, вы можете настроить mod_rewrite правила для перезаписи URL-адреса, как http://yourblog.com/article/the-article-you-wrote (который выглядит лучше и проще вводить и запоминать) до http://yourblog.com/articles.php?title=the-article-you-wrote, что Apache может используйте, чтобы правильно направить запрос на ваш PHP-скрипт.
ключ является заголовком HTTP-ответа
HTTP 200 OK
Content-Type: video/flv
Content-Length: 102345
DATA-DATA-DATA-DATA-DATA-DATA-....
Читайте также:
Content-Disposition: attachment; filename=genome.jpeg;
modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
больше деталей:http://en.wikipedia.org/wiki/MIME
ну, расширения файлов не имеют никакой пользы в интернете. Браузеру все равно, что это за расширение файла. Вы можете использовать файл CSS как .Ави. Так почему бы просто не оставить его? Это позволяет сократить URL-адреса.
кроме того," переписывание " url-адреса позволяет использовать более читаемые URL-адреса. Вы можете не понять /categories.php?id=455 а вы /455-some-category.
Если вы хотите сделать это самостоятельно и используете Apache, посмотрите на mod_rewrite.
url, должен правильно считаться частью пользовательского интерфейса. Таким образом, он должен быть разработан для передачи информации о том, где пользователь находится на сайте, и о структуре сайта.
url, например:
mysite.com/sport/soccer/brazil_wins_worldcup
много говорит пользователю о структуре сайта, и где он в настоящее время находится. В отличие от этого:
mysite.com/article.php?cateogry=12&articleid=371
бесполезно, вместо этого он раскрывает нерелевантную реализацию-детали, такие как, какой язык используется для создания сайта, и какой идентификатор этой статьи (вероятно, хранится в базе данных под этим идентификатором)
в дополнение к этому эстетическому аргументу (не подвергайте пользователя неуместным деталям реализации) это также помогает сделать сайт будущим доказательством. Потому что, если вы никогда не открывали свой язык выбора для начала, вы можете позже перейти на Ruby или Python, без каждой ссылки в мире, которая указывает на вас, теперь 404.
дизайн URL-адресов, чтобы иметь смысл для пользователей,и чтобы быть будущее.
есть много возможных ответов на этот. Это то, как настроены ваши серверы веб-приложений, что приводит к тому, что ваш веб-браузер интерпретирует. Могут быть ситуации, когда вы используете перезапись URL или маршрутизацию, и, как говорили другие, какие обработчики вы предоставляете для запрошенных URL или расширений.
У меня может быть URL-адрес типа"http://cory.com/this/really/doesnt/exist" и действительно ли он указывает на "http://cory.com/this.does.exist.123" Если бы я захотел.
нормальным поведением веб-сервера является отображение запрошенного пути URI в файл где-то в корневом каталоге документа. Так что http://example.com/foo/bar просто накладывается на /path/do/document/root/foo/bar. Кроме того, веб-сервер должен уметь обрабатывать файл. Это часто делается с помощью расширения имени файла. Итак, файлы с расширением имени файла .php обрабатываются интерпретатором PHP.
теперь помимо этого нормального поведения, большинство веб-серверов имеют функции, которые позволяют изменить оба отображения (т. е. переписывания URL-адресов) и способ обработки файла без расширения имени файла.
в случае веб-сервера Apache, первый может быть сделано с и mod_rewrite:
RewriteEngine on
RewriteRule ^/watch$ /watch.php
и последнее можно сделать с mod_mime:
<File watch>
ForceType application/x-httpd-php
</File>
(ОК, на самом деле это не mod_mime функция, а базовый характеристика.)
правило: расширения файлов не должны включаться в URIs
в Интернете, точка (.) символ обычно используется для разделения имени файла и части расширения URI. API REST не должен включать искусственные расширения файлов в URIs, чтобы указать формат тела сущности сообщения. Вместо этого они должны полагаться на тип носителя, передаваемый через заголовок Content-Type, чтобы определить, как чтобы обработать содержимое тела.
(1)http://api.college.restapi.org/students/3248234/transcripts/2005/fall.json (2)http://api.college.restapi.org/students/3248234/transcripts/2005/fall
(1)расширения файлов не должны использоваться для указания предпочтения формата. (2)клиентам REST API следует рекомендовать использовать выбор формата HTTP механизм, заголовок запроса Accept. ссылки: дизайн REST api rulebook
ниже того, что я использую в моем .htaccess, чтобы url-адрес все еще работал правильно без расширения HTML или PHP.
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.html -f
означает, что если файл с указанным именем в браузере не соответствует каталогу (- d) или файлам(-f) на вашем веб-сервере, то перепишите правило ниже
RewriteRule ^(.*)$ .html
Я не уверен, как работает ниже, но я думаю, что после его перезаписи с html, и если он все еще не соответствует ему, то перепишите с php
RewriteCond %{REQUEST_FILENAME}\.php -f
RewriteRule ^(.*)$ .php
если это все еще не соответствующий ему будет показывать 404 страницы.
вы также можете перенаправить 404 с кодом ниже .реврайт
ErrorDocument 404 /404.html
важно то, что код работает для моего сайта.
тем не нужно расширение файла.
"www.youtube.com/watch" это каталог YouTube. Таким образом, это может быть в основном написано как "www.youtube.com/watch/" с окончанием косой черты вперед.