PDF がダウンロードされず開くときのリンク確認

PDF の受信者に必要な操作を決める

イベントのプログラムをダウンロードというボタンで送ったのに、文書がタブで開く。別の人は読みたいだけなのにダウンロードされる。どちらも、それだけでリンク切れの証拠にはなりません。URL を変更する前に、閲覧、コピーの提供、または両方のどれが必要か決め、受信者の端末で実際に起きることを確かめましょう。

確認した質問には、HTML から外部 PDF をダウンロードしたい場合と、ブラウザー設定にかかわらず表示したい場合がありました。このガイドは公開プログラムを例にします。WikiURL は URL の応答と宛先を調べる助けになりますが、文書サーバーを設定したり、訪問者のビューアーを置き換えたりしません。内容、サーバーの指示、ブラウザーの解釈を区別するところから始めます。

応答ヘッダーが表示方法を示す

MDN は Content-Disposition がブラウザー内での表示か添付ファイルとしての処理かを示すと説明しています。RFC 6266 は inline と attachment を定義します。例は二つの代替応答であり、一緒に送るブロックではありません。Content-Type は PDF 型を表し、filename は名前を提案します。これらはファイルを配信するサーバーの応答ヘッダーです。ボタンの文字や URL に書いても設定されません。

Inline は表示の意図を、attachment はダウンロードとしての処理を要求します。ただし同じ見た目の動作を保証しません。MDN が述べるように、ブラウザー、設定、その他の条件が影響します。ダウンロードは自動保存されたり、後で開かれたりします。ホスティング担当者に最終ファイルの実際の応答を確認してもらいましょう。一つのプログラムのために全ファイルの設定を変える必要はありません。

Content-Type: application/pdf
Content-Disposition: inline; filename="programa.pdf"

Content-Type: application/pdf
Content-Disposition: attachment; filename="programa.pdf"

リンク名と内容を混同しない

例のアドレスは架空で動作しません。試験前に example.invalid を公開済みの実際のドメインに置き換えます。承認されたプログラムが届くことを確認し、案内ページ、非公開ログイン、エラーでないか見ます。.pdf で終わるパスは手掛かりであり内容の検証ではありません。URL の名前変更は HTML を PDF に変換せず、壊れたファイルも修復しません。

管理者ならブラウザーのネットワークツールでファイル要求を調べ、最終応答の Content-Type と Content-Disposition を確認します。管理者でなければ URL、観察した動作、希望結果を担当者へ渡します。正しいファイルを確認してもらい、Cookie や認証情報を含む画面は送らないでください。承認原稿を保持します。名前やヘッダーの変更は内容の新しい版や日程更新の証明にはなりません。

https://example.invalid/documentos/programa.pdf

Download 属性は万能な命令ではない

管理するページでは download を付けた HTML リンクを提供できます。MDN は動作範囲を同一オリジンの URL と対応する blob、data の場合に限定しています。他オリジンの URL では属性が無視され通常の移動になりますが、宛先サーバーは Content-Disposition でダウンロードを要求できます。属性の追加やボタンの文字変更だけで外部ファイルを直せるとは約束しないでください。

短縮リンクは経路に別の宛先を加えますが、他サーバーの PDF を自分のオリジンのファイルにはしません。QR はアドレスの表現であり、ブラウザーへダウンロード命令を組み込みません。外部ホスティングでは文書化された機能を使うか、所有者に適切な配布 URL を求めます。応答を制御できなければ、自動保存を約束するボタンより説明付き閲覧ページが役立つ場合があります。

WikiURL で公開経路を調べる

WikiURL の URL チェッカーに公開プログラムの URL を入力します。HTTP ステータスと、転送がある場合に検出された最終宛先を確認します。非公開アドレス、管理リンク、秘密は送信しません。ログインや別の資料に着くなら共有先を先に修正します。200 はその確認に対する応答を示すだけで、訪問者が PDF を端末へ保存した、または正しい内容を読んだ証拠ではありません。

次に送信予定と全く同じリンクをパソコンのブラウザーと携帯電話で開きます。タイトル、日付、読みやすさ、利用できる操作でコピーを保存できるか確認します。チェッカーは各読者のビューアーや設定を再現しません。技術的結果とブラウザーの体験が異なるなら両方と条件を記録します。一回の成功試験から全員の同じ体験を断定してはいけません。

期待する動作を明確にして試験を残す

閲覧向けには PDF でプログラムを見るという文言なら即時保存を約束しません。検証済みダウンロードを提供する場合は文書を明示し、分かれば容量も伝えます。ビューアーが開いたときに保存する短い案内を添えてもよいでしょう。一つのプログラムのために全体のブラウザー設定変更を求めたり、曖昧な複数ボタンの奥へ宛先を隠したりしません。

QR 作成や短縮リンク配布前に最終 URL、文書の版、試験端末を記録します。ホスティング変更やファイル差し替え後は応答が変わり得るため再試験します。目標は予定する相手が正しいプログラムを使え、閲覧や保存の正確な説明を得ることです。タブで開くこととダウンロードは違う動作で、リンクの案内もその違いを反映させましょう。