リッチテキスト関連の文字化けについてのとりあえずのまとめ

  • 数回にわたって書いてきたMac OS Xのリッチテキスト関連の文字化けについて、よくわからない点も残っているが、とりあえずまとめてみようと思う。
  • 今のところ把握している問題は3つある。1つ目は、Mac OS X 10.5 Leopardのシステム・ルーチンが生成するリッチテキストの問題。2つ目は、InDesignにおけるリッチテキストの解釈の問題。3つ目は、InDesignが書き出すリッチテキストの問題である。


  • なお、図におけるクリップボードは「リッチテキスト形式に変換されたデータ」を意味するので、「書類をリッチテキスト形式で保存して閉じてから再度開いた場合」も、エンコーディングの変化は同じ。
  • 下図は、Mac OS X 10.5 Leopard上のリッチテキスト・モードのJedit Xで、テキストをコピー＆ペーストした場合のエンコーディングの変化を表したもの。リッチテキストに変換された時点で、右ブロックが全滅。この動作はテキストエディットでも共通なので、これらのアプリケーションが共用しているシステム・ルーチンの問題だと思われる。


  • 下図のU+2212の文字化けは、InDesignがリッチテキストを解釈するケース（クリップボードの全情報をペーストする設定となっている場合のエディタからのリッチテキストのコピー＆ペースト、リッチテキスト書類の配置など）で発生する。また、わたしの環境では、ヒラギノは化け、小塚書体やリュウミンは化けない。おそらくInDesignが不吉な例外処理を行っているものと思われるが、意味は不明。


  • 下図は、Leopard上のJedit XからInDesignにテキストをコピー＆ペーストした場合の文字化け。左ブロックでU+2225がU+2016に化けているのは、おそらくInDesignの仕様。Adobe-Japan1フォントでは、U+2225に対応するCID=15489を表示するためにはAdobe-Japan1-5のサポートが必要となるため、（そうでないフォントでも表示できるように）CP932 to Unicodeのテーブルに手を加えてあるのだろう。この仕様により、右ブロックのU+2016は、2回化けて結果的に元にもどっている。右ブロックにおける黄色地→グレー地の文字化けは、すでにクリップボード上で発生しているものなので、InDesignの責任ではない。


  • 下図は、InDesignからJedit Xにテキストをコピー＆ペーストした場合の文字化け。上述のカスタマイズされた変換テーブルを用いているためにU+2225が変換されず生き残っている以外は、左ブロックが全滅。