メモ - PDF の文字列型は BOM 付きの UTF-16BE

2009/06/23

普通にメモです。PDF の文字列の扱いはどんなもんだったけな,ということで,PDF-1.3 向けの仕様を読み直しているんですけど,どうも BOM 付きの UTF-16BE だったらしい。

For text strings encoded in Unicode, the first two bytes must be 254 followed by 255, representing the Unicode byte order marker, U+FEFF. (This sequence conflicts with the PDFDocEncoding character sequence thorn ydieresis, which is unlikely to be a meaningful beginning of a word or phrase.) The remainder of the string consists of Unicode character codes, according to the UTF-16 encoding specified in the Unicode standard, version 2.0. Commonly used Unicode values are represented as 2 bytes per character, with the high-order byte appearing first in the string.

PDF-1.7 の仕様書では UTF-16BE と書いてあるんだけれども,PDF-1.3 にそんな記述があった記憶がなかったもんで(単純に UTF-16 と書いてあると思ってた)下位互換性が気になったのでした。どっちにしても,なんだか,Windows の環境では一番厄介だな。これって普通はどうやって管理するんだろう。内部形式は UTF-16LE で持っておいて,出力するときだけ BOM 付けてひっくり返すのかな。ま,そうするんだろうな,きっと。

で,一方で,

At the most fundamental level, a PDF file is a sequence of 8-bit bytes. These bytes can be grouped into tokens according to the syntax rules described below. One or more tokens are then assembled to form higher-level syntactic entities, principally objects, which are the basic data values from which a PDF document is constructed.

(snip)

The data values of certain types of object—strings and streams—can be but need not be written entirely in ASCII.

ここら辺が PDF の面倒くさいとこなんだよな……と。基本は ASCII だけど,文字列は UTF-16。PDF の場合,キャラクターセットの問題だけじゃなく,微妙にバイナリデータが入ったり(ストリームをエンコードするとバイナリになる),ファイルアクセスが前提になってるところがあったりして,実装に難儀しそうなところが盛りたくさんだったりします。

巷の OSS のライブラリを見ていると,素直にファイルアクセスしているモノが多いんですけれど,これは多分 CreateFileMapping() なり(Windows の場合),mmap(2) なり(POSIX の場合)を使うのが一番しっくりくる仕組みなんじゃないかと思ったりもします。速度的にどうなるかは分からないけれども,実装は確実に楽になる。

ともかくも,PDF の文字列型は UTF-16BE(BOM) で,他は ASCII なんだけれども,たまにバイナリ。基本はファイルオフセットを主としたアクセスになる,と。ふーむ……。知ったら知ったで萎えるな,こりゃ。

Site Navigation
SNS Accounts (@aian)

普段はここら辺に住んでいます.