PDFファイルの特定のアドレスにアクセスすると、Chromeは内蔵のPDFビューアで開く代わりにPDFをダウンロードします。すると、ページが真っ白になります。
クロームの設定に問題はありません:Chromeの設定に問題はありません。他のPDFファイルのアドレスを試してみても、Chromeは期待通りに動作します(Chromeの内蔵PDFビューアを使用するように設定しています)。しかし、同じ問題のアドレスを試すたびに、クロームはPDFをダウンロードし、真っ白なページを表示します。
Windows 10とChromeを使用しています。 バージョンは63.0.3239.84(公式ビルド)(64ビット)です。
今回私が試した問題のURLはこちら(Googleの検索結果)です。
Content-Disposition
Content-Disposition
ヘッダを送信するためです。具体的には、inline
または attachment
のどちらかを送信します。
inlineは特に指定がない場合のデフォルトで、ブラウザが可能であればブラウザウィンドウ内でファイルを開くことを意味する。 attachment
は常にファイルをダウンロードすることを意味し、ブラウザ内でファイルを開こうとはしない。ブラウザの開発者ツールを開くと、そのリンクが次のようなレスポンスヘッダを送信していることがわかります:
Content-Disposition: attachment; filename="Schubert-Sonata-21-B-flat.pdf"
Content-Type: application/pdf
attachment
) し、URLから推測するのではなく、Schubert-Sonata-21-B-flat.pdf
というデフォルトのファイル名を与えるように指示します。加えて、それはブラウザに(正しく)application/pdf
ファイルであることを伝えますが、attachment
であるため、ブラウザはデフォルトでダウンロードします。Content-Disposition`がインライン(または未指定)の場合、ブラウザはデフォルトの埋め込みビューアでファイルを開こうとします。これは、ブラウザがファイルの種類を知っていて、その種類を開く方法を知っている場合にのみ動作します。
ファイルタイプはContent-Type
ヘッダーでサーバーから指定することができます。例えば、最も一般的なインラインタイプは text/html
、application/javascript
、text/css
であり、現代のウェブサイトの3つの主要な部分を構成しています。また、application/pdf
のような難解なタイプもあります。
もう一つの可能性は、サーバーが Content-Type
に application/octet-stream
を指定している場合である。これは最も一般的なタイプで、ブラウザにそのファイルが任意のデータであることを伝えます。
サーバによって Content-Type
が指定されていない場合(時には指定されていても)、ブラウザは sniffing と呼ばれる処理を行い、ファイルを読んでパターンを探すことでタイプを推測することができます。
またはunspecified dispositionのファイルを受信すると、ブラウザは可能であればブラウザ内で開こうとする必要があります。これを行うには、ファイルの種類を調べ、その種類を認識したら開こうとします。ほとんどのブラウザは
text/型のファイルを単純なテキストビューアで開き、
text/html型のファイルをウェブページとしてレンダリングしようとし、[
application/json型のファイルを特別な構文強調ビューアで開く](https://developer.mozilla.org/en-US/docs/Tools/JSON_viewer) かもしれません。 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では、「Firefoxでプレビュー」オプションがまだ存在しています:
オプションのスクリーンショット1。
過去には、これによってそのタイプを登録した複数のプラグインから選択することができた。例えば、Flashの登録されているタイプのリストです:
登録されている型のスクリーンショット2。
また、当時はHTML5で登場した多くのメディアサポートが登場する前でもありました。PDFだけでなく、MP4コンテナやH.264ビデオをどう扱えばいいのか、MP3ファイルをどう再生すればいいのかなど、ブラウザにはわからないことばかりでした。VLCやWindows Media Playerのようなメディアプレーヤーが提供するプラグインを見かけたり、ウェブサイトがFlashで作られたメディアプレーヤーを埋め込んだりする。
これは、HTTPのContent-Disposition
ヘッダーが、ファイルが添付ファイルであることを指定しているためです。これは、ファイルを直接開くのではなく、ダウンロードするようにブラウザに指示します。
この動作を上書きできるChromeアドオンがあります 次の画像はFirefox開発者ツールのものです: