Xに標準搭載されている「ヒラギノ」フォントはJIS2004に対応しています。含む2万字以上の漢字を利用できる環境は既に整っているといえます。Reportsでは,PDF定義済みのエンコーディング(CMap)を利用していたため1文字=2バイトの文字コードしか使用できませんでしたが,1.4版ではフォント内蔵のエンコーディングテーブルを参照することによりこの制限がなくなりました。これにより,フォントが持つ拡張漢字をフルに活用することが可能になりました。サロゲートペアとは2バイト(16ビット=65,536通り)で世界中のすべての文字を表現しようというのがUnicodeの初期の構想でしたが,この構想は早々に破綻し,現在では21ビットに拡張されています。TIP,...)と呼びます。UnicodeをUTF-16でエンコーディング(符号化)する場合,BMPは従来どおり1文字を2バイトで表現しますが,追加面を表現するためには2文字分の4バイトが必要になり,これをサロゲートペアと呼びます。Reportsではエンコーディング方式としてUTF-8を採用しています。BMP領域の文字は1文字を1〜3バイトの可変長でバイト列で表現しますが,追加面の文字をUTF-8でエンコーディングする場合は4バイトが必要になります。※UTF-8は可変長バイト列として表現されるので「サロゲートペア」と呼ぶのは相応しくないかもしれませんが,ここでは追加面に含まれる文字を便宜上サロゲートペアと呼んでいます。Reportsで利用することができます。Reportsが解釈できる文字参照を利用することができます。エスケープシーケンスによる指定プログラミング言語によっては,Unicodeコードポイントを表現するためのエスケープシーケンスが用意されています。C#では,“\uhhhh”または“\Uhhhhhhhh”で16ビットまたは32ビットのUnicode文字が指定できます。Javaでは,“\uhhhh”がありますが,16ビットUnicode文字しか指定できません。ゲートペアを表現するためには2文字に分解して記述する必要があります。PHPでは特にUnicode用のエスケープシーケンスは用意されていないようですので,“\xhh”などを利用してUTF-8バイト列を埋め込むしかありません。Reportsでパラメータをファイルを介して渡す際に利用するJSONでは,規格として用意されているのは16ビット形式の“\uhhhh”のみです。Reportsでは,JSONの規格からは外れますが“\Uhhhhhhhh”形式の32ビットUnicode文字も受け付けられるように独自改造を行なっています。文字参照による指定1.4版で追加した文字参照によりUncodeコードポイントを指定することもできます。“&#dddd;”または“&#xhhhhhh;”という書式により,10進数または16進数による指定を行うことができます。HTML4.0で定義されている文字実体参照も利用できます。文字参照はフィールド単位で有効・無効を切り替えます。デフォルトでは無効になっているので,利用する場合は明示的に有効にする必要があります。異体字セレクタとはUnicodeの漢字統合の原則により,復数の自体のバリエーションを持つ文字であってもひとつのコードポイントに統合されるのが基本です。多くの字体が存在することで有名な渡邊の「邊」で,実際にコードポイントが割り当てられてるのは,邉(U+9089),邊(U+908A)の2文字だけです。人名・地名などを扱うためには字体のバリエーションを実際に区別する必要がありますが,漢字統合の原則によりむやみに増やすことができません。そこで,漢字統合の原則を守りつつ字体を区別する方法として考えだされたのが異体字セレクタと呼ばれる特殊な文字コードです。日本語の場合,U+E0100〜U+E01EFの範囲のコードを異体字セレクタとして使用します。基本となる正体字の文字コードに続けて異体字セレクタを配置することで,何番目の異体字かを表現します。以下に,IPAmj明朝フォントを使って邊の異体字を列挙した例を示します。Reports独自形式のJSONで記述しています。