`download`属性：ブラウザの「お節介」を制御し、ユーザーに直接ファイルを届ける技術
Web開発の現場で、ふとこんな要求を受けることはありませんか？
「このPDF、ブラウザで開くんじゃなくて、クリックしたら直接ダウンロードさせたいんだよね」
ユーザー体験（UX）を突き詰めると、単なるリンク遷移では不十分なケースは多々あります。特に、ブラウザが標準で対応しているファイル形式（PDFや画像など）は、リンクをクリックすると即座にブラウザのビューワーで開かれてしまいます。
これを防ぎ、ブラウザに「表示するな、保存しろ」と指示を出す。そのための魔法の属性が、HTML5から導入された `download` 属性です。
なぜ `download` 属性が必要なのか？
通常、``タグは「リソースへの移動」を目的としています。しかし、現代のWebアプリケーションにおいて、動的に生成したデータや特定のファイルをローカルに保存させたいというニーズは非常に高い。
従来はサーバー側で `Content-Disposition: attachment` というHTTPヘッダーを叩き込むのが唯一無二の正攻法でした。しかし、フロントエンドだけで完結させたい場合や、サーバー設定をいじれない環境では、この `download` 属性が真価を発揮します。
ブラウザの裏側で起きていること
`download` 属性を指定すると、ブラウザは「遷移」というイベントを「ダウンロード」というタスクに切り替えます。
具体的には、ブラウザのネットワークスタックがリクエストを受け取った際、HTMLの宣言を優先し、MIMEタイプが何であれ、「保存先を指定するダイアログ」を優先的に表示させようとします。もし属性値にファイル名を指定していれば、ブラウザはその名前をデフォルトのファイル名として採用します。
ただし、ここで注意が必要なのが「同一オリジン制限」です。
現場で直面する「動かない」の正体
セキュリティ上の観点から、`download` 属性はリンク先が同一オリジンであることを強く推奨します。クロスオリジン（別ドメイン）のファイルに対して `download` を指定しても、多くのブラウザでは無視され、通常のリンク（遷移）として振る舞います。
もし、別ドメイン上のファイルを強制的にダウンロードさせたい場合は、一度 `fetch` APIでバイナリ（Blob）として取得し、メモリ上でURLを生成（`URL.createObjectURL`）してから、仮想的なリンク要素を生成してクリックさせるという「一手間」が必要になります。
実践：現場で使える「堅牢なダウンロード実装」
ただ `download` 属性を貼るだけでなく、モダンなアプリケーションで活用するためのベストプラクティスをコードに落とし込みました。
押さえておくべきブラウザ対応状況
`download` 属性は、現在主要なモダンブラウザ（Chrome, Edge, Firefox, Safari）でほぼ完全にサポートされています。IE11は……残念ながら非対応ですが、今の環境でIEを考慮する必要があるケースは稀でしょう。
ただし、Safari（特にiOS）では、古いバージョンで挙動が安定しないことがあります。また、`download` 属性に指定するファイル名に特殊文字が含まれていると、環境によっては文字化けやファイル名の不整合が起きる可能性があります。ファイル名はできるだけASCII範囲内に留めるか、英数字のみで構成するのがトラブルを避けるコツです。
最後に：シニアエンジニアからのアドバイス
`download` 属性は非常に便利ですが、「ユーザーに無断で巨大なファイルをダウンロードさせない」というUXの原則を忘れないでください。特にモバイル回線を使用しているユーザーにとって、勝手なダウンロードはコストとストレスになります。
「ダウンロードボタン」であることを明確にUIで示し、必要に応じてファイルサイズを注釈に添える。こうした細やかな配慮が、技術だけでなく「プロダクト」としての質を決定づけます。
小手先のテクニックで終わらせず、それがユーザーにとってどのような「体験」になるか。そこまで想像力を働かせるのが、一流のフロントエンドエンジニアです。ぜひ、現場で活用してみてください。
コメント