ファイルパスまたはURLで画像を参照するPDFは、隠れた依存関係を持ちます。 ドキュメントが作成したマシンを離れるとき、無状態のクラウド関数で実行されるとき、または何年もアーカイブされるとき、これらの参照は壊れやすく、ロゴやグラフが入るべき場所に空白のボックスが残る可能性があります。 画像を直接HTMLにbase64データURIとして埋め込むことでその依存性を取り除き、IronPDFはその結果を完全に自己完結したPDFにレンダリングします。

ビジネス問題

請求サービスがAzureまたはAWS Lambdaに移行するとき、ファイルシステムへのアクセスは限定的で一時的であり、ローカルで動作していた画像のパスは解決しなくなります。 レポートツールは、オリジナルのアセットサーバが変更された後でも正しく表示され続ける必要があるドキュメントを電子メールで送信します。 パイプラインは、実行時に生成されたイメージからディスクに保存されることなくドキュメントを組み立てます。 いずれの場合も、外部画像参照は責任です。

データURIとして画像を埋め込む

パターンは3ステップです: 画像のバイトを読み取り、それらをbase64に変換し、結果を対応するMIMEタイプの<img>タグに配置します。 レンダリングされたPDFはそのファイル内に画像を保持します。

using IronPdf;
using System;

byte[] imageBytes = System.IO.File.ReadAllBytes("logo.png");
string dataUri = "data:image/png;base64," + Convert.ToBase64String(imageBytes);
string html = $"<img src='{dataUri}'>";

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf(html);
pdf.SaveAs("self-contained.pdf");

using IronPdf;
using System;

byte[] imageBytes = System.IO.File.ReadAllBytes("logo.png");
string dataUri = "data:image/png;base64," + Convert.ToBase64String(imageBytes);
string html = $"<img src='{dataUri}'>";

var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf(html);
pdf.SaveAs("self-contained.pdf");

同じアプローチは実行時に生成された画像、例えば、メモリで生成されたグラフまたはバーコードに対しても、バイトを直接エンコードして一時ファイルを書き込むことなく使用できます。データURIが正しいタイプを宣言している限り、複数の形式がサポートされています: PNG、JPEG、GIF、SVG (image/svg+xml)、およびWebP。

計画すべきポイント

• Base64はサイズを追加します: エンコードは各画像のバイトサイズを約3分の1増加させ、HTMLとPDFの両方に含まれます。 画像が多いドキュメントでは、エンコード前に圧縮またはサイズ変更を行い、PDF圧縮をその後適用します。
• MIMEタイプを一致させる: プレフィックスは形式に一致する必要があります。例えばJPEGの場合はdata:image/jpeg;base64,であるべきで、それ以外では画像がレンダリングされません。
• ファイルシステムの依存なし: 画像が文書内を移動するため、レンダリングは到達可能なパスやアセットサーバに依存しないため、クラウドやコンテナデプロイメントで信頼性があります。
• 取得回数の減少: インライン画像はレンダリング中に余分なHTTPまたはファイルシステムの呼び出しを避け、多くの小さな画像が含まれるドキュメントのスループットに貢献します。

結果

画像をデータURIとして埋め込むことで、チームはノートパソコン上でもサーバーレス機能内でも同じようにレンダリングされ、メール送信やアーカイブ時にもすべての画像が保持されるPDFを生成します。 詳細な形式と例はDataURIsガイドで画像を埋め込むにあります。