最近、一部の仕事では、テキストの文字コードをUnicodeにしていこうかと考えている。DTP作業と密接に連携する必要のある仕事では、Unicodeをベースにすれば、扱える文字種が増え、なおかつ特殊な記号を別途DTPオペレーターに指示する必要がない。例えば、改行マークを入れたい場合、今までの（シフトJISベースの）ワークフローではテキストデータ中にオペレーターがわかるように指示を入れたり、打ち出した紙に指示を書き込んでおくといった手間がかかった。Unicodeが扱える環境なら、「?」（U+21B5）をそのままテキストデータに書き込んでおけばいい（カギ括弧内は改行マーク。フォント環境によっては画面上で見えないかも）。マークの書体に凝りたいといった場合にはやはり別途指示する必要はあるだろうが。 DTPソフトではInDesignのUnicode対応が進んでおり、Mac／Winが混在したワークフローでも何とかなりそうな気がする。 現在試行錯誤中なのだが、1つ気になったのは既存のテキストデータを利用する場合だ。シフトJIS形式で書かれたテキストデータをUnicode（のUTF-8形式）に変換する場合、OSやアプリケーションによって変換結果が異なることがあるようだ。例えば、丸数字（「?」など）。WindowsではJISコード（JIS X 0208）を独自に拡張して丸数字等を割り当てている。こうした文字を使ったシフトJISのテキストを、Windowsのメモ帳でUTF-8形式で保存すると、該当するUnicodeのコードに変換される。しかし、Mac OS Xのテキストエディットで元のシフトJISテキストを読み込み（Mac用フォントの該当コードは丸数字でないため表示されない）、UTF-8形式で保存してもWindowsのメモ帳とは同じ結果にならないのだ（文字化けしてしまう）。Mac OS X（というよりWindows以外のOS）では、Windows独自拡張文字に対応していないから、ある意味当然といえば当然なのかもしれないが……。機種依存文字を使った文書をUnicodeに変換する際には、注意する必要がありそうだ。
（補足） このbinWord/blogは、UTF-8形式になっている。上記の文章中、改行マークや丸数字を使っているが、これはUnicodeで定義されているもの。WindowsXP等のMSゴシック・MS明朝、Mac OS Xのヒラギノフォントであれば問題なく閲覧できるはず。
（追記） 変換の相違についてまとめたページを発見。 ・シフトJISからUnicodeへの変換テーブルの相違
コメント