横井 羽衣子
SQL Developer Support Engineer
みなさんごきげんよう。今日は、みんな大好きレポートの大敵「PDF の文字化け」についてです。
以前、弊社森が Reporting Services でエクスポートした PDF における文字化け問題について書いています。これは SQL Server Reporting Services 上のレポート、いわゆるサーバー レポート (*.rdl) についてのお話でしたが、この記事では、意外に気づかないローカル レポート (*.rdlc) について「Report Viewer コントロールは Version 10 ではフォント埋め込み対応してるけど、Version 9 では対応されていない」という件についてと、エクスポート時の文字化けの確認ポイントについて触れたいと思います。
ちなみに、Version 9 は、Visual Studio 2008 付属、Version 10 は Visual Studio 2010 に付属しています。
PDF で文字化けしてしまうときのフォントの扱われ方
まず、レポートをエクスポートするときの動きについておさらいしてみましょう。PDF にする際は、サーバーレポート、クライアント レポートともに、以下のような動きになります。
(1) レポートのエクスポート出力元は、そのマシン上の OS のフォント情報を使い、PDF ファイルをレンダリングします。その際、フォントが埋め込まれない場合、文字識別情報 (グリフ ID) を埋め込みます。
例 : エクスポート出力元は、フォントのグリフ ID 10000 を埋め込む
(2) PDF ファイルにはフォントではなく、フォントを識別する グリフ ID の情報が保持されています。
(3) PDF Viewer (Adobe Reader など) で上記の PDF をクライアントマシン上で表示しようとします。
(4) クライアントでは、PDF 内のグリフ ID に相当する文字をクライアント OS 内のフォント ファイルに一致するものがあるか試みます。
図 : グリフ ID 10000 に合致する文字はこの環境にない
(5) しかし、その環境に合致するグリフ ID がない場合、別の文字が割り当てられてしまいます。結果、合致するグリフ ID がなかった文字は、文字化けしてしまいます。
また、エクスポート出力元と出力先で、同じグリフ ID を保持する場合でも、そのグリフ ID が異なる情報を保持する場合、文字化けします。
PDF を開くマシン上 (クライアントとしましょう) で表示する際、このグリフ ID をクライアント環境のシステムにあるフォントの中から、グリフ ID が合致するもので表示しようとしますが、合致するものがない場合やエクスポート元と異なる情報を保持する場合、人間が読むうえではなんだかよくわからない文字が割り当てられてしまい、結果的に文字化けと言われる解読不明な状況に陥ってしまったりするのです。これが、PDF の出力時の文字化けの動作です。
エクスポートする時レンダリングをするのは「誰」だ？~ ReportViewer のバージョンに注目！
レポートをエクスポートする時、あまり意識しないことですが、問題が発生した時などには大きなポイントになるのが、エクスポートする時レンダリングをするのは「誰」だ？ってところです。実は、この「文字」の情報、どこから来るか、どう扱われるかは、レンダリングする役割の機能が何かによって着目ポイントが変わってくるのです。
大まかにいうと（本当に大まかですが）ファイル出力の処理（フォントの埋め込み方法含む）は、双方以下の相違点があります。
・サーバー レポート : "Reporting Services" がレンダリングを行う。
・ローカル レポート : "ReportViewer コントロール" がレンダリングを行う。
サーバー レポートであり、かつ、以下の条件を満たす場合は、フォント埋め込みがなされます。
(1) Reporting Services がインストールされている環境に、埋め込むためのフォントが用意されていること
(2) レポート中で使用しているフォントが、埋め込みを許可していること
(3) フォントが TrueType であること
(4) 文字列の文字の Font プロパティが ANSI ではなく、Unicode に設定されていること
(5) レポート中で、フォントの Hidden プロパティが True ではないこと
(6) SQL Server 2005 Service Pack 3 以降の Reporting Services であること
(7) レポートの中の文字に日本語が含まれること
ローカル レポートの場合、ReportViewer 9.0コントロールがレンダリングをする場合は、フォント埋め込みがされません。一方、ReportViewer 10を利用した場合は、ローカル レポートにおいても、フォント埋め込みが可能です。
では、これを踏まえて、次は確認ポイントのパターンをみていきましょう。
構成を踏まえた確認ポイントのパターン
文字化けに実際であった場合、最も重要なポイントは、レポートを出力するまでのシステムの構成要素です。それらによって、確認パターンが変わってきます。以下は、代表的な構成と、各構成パターンにおける確認ポイントです。
パターン1 : [Client] – [SSRS + RDL]
→ SSRS によって、PDF にフォントが埋め込まれます。
確認ポイント :
1．SQL Server はフォント埋め込みに対応したバージョンであるか。
> バージョンが対応していない場合、SSRS に埋め込みフォントに対応した修正モジュールを適用します。(SQL Server 2005 の場合、SP3 以降適用)
2. PDF 化の対象レポートはフォント埋め込みの条件を満たしているか。
パターン2 : [Client] – [SharePoint 統合(SSRS + SharePoint) + RDL]
確認ポイント :
1．SQL Server と SharePoint Server は統合されているか。
Ø 統合されている場合、統合のために利用されるモジュールのバージョンを確認し、モジュールの適用が必要となります。
Ø 統合されていない場合、その利用方法を確認し、利用方法に応じた修正モジュールの適用が必要となります。
(※) SQL Server 2005 の場合、SP3 以降適用
2. PDF 化の対象レポートはフォント埋め込みの条件を満たしているか。
パターン3 : [Client] – [Web App + RDLC]
確認ポイント :
1．ReportViewerControl はフォント埋め込みに対応したバージョンであるか。(VS2008 付属の Report Viewer Control Ver.9 は対応していません。)
2. PDF 化の対象レポートはフォント埋め込みの条件を満たしているか。
パターン4 : [Client] – [Web App + Reporting Services]
確認ポイント :
1．SQL Server はフォント埋め込みに対応したバージョンであるか。
> バージョンが対応していない場合、SSRS に埋め込みフォントに対応した修正モジュール（SQL Server 2005 の場合、SP3 以降）を適用します。
2 PDF 化の対象レポートはフォント埋め込みの条件を満たしているか。
> バージョンは対応しているが、フォントの埋め込みが為されない場合、レポートの構造を埋め込みフォントが為されるように変更します。
いかがでしたでしょうか。
レポートをエクスポートした PDF だけを見ていると、文字化けの原因はわかりません。エクスポートした結果の成果物 (PDF など) に至る過程に着目する必要があります。意外に見落としがちで、かつサーバーの管理と開発は別の管轄になることもあると思います。サーバー管理者の方とともに確認を進めていただくとよいこともあるとご参考になれば幸いです。
それではみなさん、ごきげんよう。