По сути, это происходит потому, что веб-сайт говорит браузеру сделать это. Иногда это происходит потому, что разработчик веб-сайта решает, что им нужно такое поведение, например, распространенное на сайтах для обмена файлами. В других случаях это потому, что это вариант по умолчанию для любого программного обеспечения, которое они используют (например, программное обеспечение для форумов или блогов). Иногда это происходит потому, что разработчик сайта понятия не имеет, что они делают.
Content-Disposition
Обычно это происходит потому, что сайт отправляет Content-Disposition
заголовок в ответе. В частности, он может отправить либо inline
или attachment
.
inline
является значением по умолчанию, если не указано иное, и означает, что браузер откроет файл в окне браузера, если сможет.
attachment
означает всегда загружать файл, никогда не пытаться открыть его в браузере.
Если вы откроете инструменты разработчика своего браузера, вы увидите, что эта конкретная ссылка отправляет следующие заголовки ответа:
Content-Disposition: attachment; filename="Schubert-Sonata-21-B-flat.pdf"
Content-Type: application/pdf
Это говорит браузеру всегда загружать ( attachment
) файл и назначать ему имя по умолчанию, Schubert-Sonata-21-B-flat.pdf
а не выводить его из URL. Кроме того, он сообщает браузеру (правильно), что это application/pdf
файл, но, поскольку это attachment
браузер, загрузка по умолчанию все равно будет выполняться.
Встроенные детали обработки
Если a Content-Disposition
встроено (или не указано), браузер попытается открыть файл во встроенной программе просмотра по умолчанию. Это работает только тогда, когда браузер знает, какой это тип файла, и браузер знает, как открыть этот тип.
Тип обнаружения
Тип файла может быть указан сервером с Content-Type
заголовком. Например, наиболее распространенные встроенные типы text/html
, application/javascript
и text/css
, составляя три основные части современного сайта. Вы также можете иметь более эзотерические типы, как application/pdf
.
Другая возможность заключается в том, как сервер указан Content-Type
в application/octet-stream
. Это наиболее общий тип, и он сообщает браузеру, что файл - это просто произвольные данные - в этот момент единственное, что может сделать браузер, - это загрузить его (теоретически - мы доберемся до этого).
Когда Content-Type
сервер не указывает a (а иногда даже когда он есть), браузер может выполнить то, что известно как сниффинг, чтобы попытаться угадать тип, читая файл и ища шаблоны.
Тип обработки
После получения файла с inline
неопределенным расположением браузер должен попытаться открыть его в браузере, если это возможно. Для этого он смотрит на тип файла и, если он распознает тип, он попытается открыть его. Большинство браузеров открывают любой text/
тип в простой программе просмотра текста, пытаются отобразить text/html
как веб-страницу, могут открываться application/json
в специальной программе просмотра с подсветкой синтаксиса и т. Д.
Тип application/octet-stream
был обработан специально. Так как это должен быть самый общий тип, обозначающий произвольный поток байтов, не должно быть никакого обработчика, который мог бы применяться ко всем файлам этого «типа». Например, в Firefox это проявляется в невозможности установить обработчик по умолчанию для application/octet-stream
.
Некоторые сайты также используют нестандартные типы. Я видел application/force-download
использованный - который заканчивается как загрузка, потому что браузер не распознает или не знает, что еще делать с типом, но не наслаждается специальной обработкой, которая application/octet-stream
делает.
Небольшой урок истории
Чтобы увидеть, как обрабатываются PDF-файлы, мы можем немного углубиться в историю веб-поиска. Видите ли, в прошлом браузеры не знали, что такое PDF. Поэтому они не могли открыть его. Но мы видели, как PDF-файлы открывались в браузерах задолго до того, как появились встроенные средства просмотра PDF, так как же это работало?
Раньше было возможно расширить функциональность браузера с гораздо большим контролем, чем то, что вы можете сделать с ограниченными расширениями / надстройками в наши дни. Они были наиболее широко известны как плагины . В Internet Explorer они были элементами управления ActiveX; в Mozilla Firefox и позже в Google Chrome они были плагинами NPAPI. Эти плагины были способны делать все, что могла любая другая программа, и могли дополнительно регистрировать себя как обработчик для определенного типа файла, который в противном случае мог бы быть не распознан браузером. (Между прочим, позже оказалось, что это огромный риск для безопасности, и поддержка этих мощных плагинов была постепенно прекращена ...)
Во времена плагинов вы должны были установить Adobe Acrobat Reader, который затем установил плагин ActiveX или NPAPI, который регистрировал бы application/pdf
тип MIME, и велел браузеру открывать эти типы встроенным с помощью плагина.
Конечно, после ряда проблем с безопасностью и производительностью, вызванных этими плагинами, крупные поставщики браузеров решили включить свои собственные средства просмотра PDF, одновременно прекратив поддержку большинства плагинов. Единственный, который мы все еще видим, - Adobe Shockwave Flash, который обрабатывает application/x-shockwave-flash
.
На самом деле для этого еще есть некоторые элементы управления, например, в Firefox Preview in Firefox
опция все еще существует:
В прошлом это позволяло выбирать между несколькими плагинами, которые зарегистрировали этот тип. Например, список зарегистрированных типов для Flash:
Эти дни были и до того, как большая поддержка СМИ пришла с HTML5. Это были не просто PDF-файлы - ваш браузер не знал бы, как работать с контейнером MP4 или видео H.264, не знал бы, как воспроизводить MP3-файлы и т. Д. И т. Д. или даже Windows Media Player, или на веб-сайтах будет встроен медиаплеер, встроенный во Flash.
Content-Type: application/octet-stream
но это гораздо реже в наши дни.