‘文字化け’ タグのついている投稿

epubcheckの日本語文字化け対策

2013/10/28

 以前、このブログで発表して現在配布中の「EPUB3トータルデータチェッカー」なのですが、どうも日本語のパス名が化けて表示されるようで少々気になっていました。エラーメッセージ自体は英語ですのでそこまでの問題ではないのですが、JEPAがepubcheckの日本語化バージョンを発表したなどというニュースもありましたし、これが標準になってくるとエラーメッセージそのものが文字化けして読めないというような事態になってきます。これでは少々寝覚めが悪いのも確かですのでちょっと調べてみました。

.bash_profileを書き換えてみたけれど・・・

 「java mac 文字化け」などで検索すると、事例がそれこそ星の数ほど引っかかるのですが、要はjavaの内部処理コードのデフォルトがShift_JISなため、そのままでUTF-8環境に書き出すと日本語部分が文字化けしてしまうということのようです。「ターミナルの文字コードをShift_JISに設定すれば化けない」なんて情報もあったのですが、そこは諸般の事情で変えたくないので却下です。で、このあたりこのあたりの情報をもとにまずは.bash_profileに設定を追記してみました。

 まずはターミナルを立ち上げて以下のコマンドを入力し、.bash_profileを編集できるようにします。

cd ~
vi .bash_profile

viが立ち上がったら、iキーを入力して挿入モードにし、以下のコマンドを入力します。

alias javac=’javac -J-Dfile.encoding=UTF-8′
alias java=’java -Dfile.encoding=UTF-8′

.bash_profileを編集 コマンドを入力し終えたらESCキーを押して「:wq」を入力してファイルを閉じます。viとか普段使わないのでこことかでコマンド調べながらの作業です。

 これでターミナルを再起動し、

-java -jar epubcheckのパス epubファイルのパス

 などと打ち込めば、例えパスに日本語が含まれていても正しくチェック結果が表示されるはずです。

ターミナル出力結果が文字化けせずに表示された 実際試してみると、確かに正しく表示されました。

 ただ、この方法だと(まあbashの設定を変えただけなので当たり前なんですが)ログ出力したテキストファイルにまでは効力が及ばないようで、相変わらずログテキスト内では文字が化けてしまっています。

「export _JAVA_OPTIONS=-Dfile.encoding=UTF-8;」を追記して文字化け解消

ログファイルが文字化けせずに出力された そこで、ここの情報をもとに、「-java -jar epubcheckのパス epubファイルのパス」の前に「export _JAVA_OPTIONS=-Dfile.encoding=UTF-8;」を追記してみました。
 つまりjavaを実行する前に出力文字コードをUTF-8にするオプションを連続実行するようにしてみたわけです。

 はい、ちゃんと日本語になってくれました。

改訂済の「EPUB3トータルデータチェッカー 1.2.1」こちらからダウンロードしていただけます。

 なお、今回はJEPAの日本語化バージョンの元バージョンが「3.0」(英語最新版は3.0.1)であることから、内包するepubcheckのパッケージを差し替えることは見送りました。従いまして、エラーメッセージ自体は従来通り欧文で表示されます。将来的に日本語化バージョンがバージョンアップした場合には、適宜差し替えを考えております。

 epubcheckのエラーメッセージの内容につきましてはここが参考になります。
 なお、こちらのTIPSやアプリケーションを利用された結果生じた損害につきまして私は一切の責任は負いかねますので、あくまで自己責任にてご利用ください。

(2013.10.29)

EPUB3ビューアのIVS・サロゲートペア対応状況in2013年4月

2013/04/15

 前回のエントリで予告させていただいたように、各EPUB3ビューアのUnicode IVSサロゲートペア文字※1対応の最新状況をチェックしてみました。外部からのEPUB3の取り込みをサポートしていないビューアもありますので完全とはいきませんが、ある程度の参考にはなるのではないかと思います。なお、チェックしたのはこのあたりを参考にしてサロゲートペア303文字、前回のmonokanoさん、NAOIさんの資料を参考にしたIVS文字127文字(Windows8でIVS対応した文字)です。IVS文字、サロゲートペア文字ともにこのテストの文字が全てではありませんので、あらかじめご了承ください。

 各ビューアの画面スクリーンショットを収めたPDF資料をダウンロードできるようにしておきましたので、適宜ご参照いただきながらお読みいただければと思います。また、テストに使用したepubデータも同じくダウンロードできるようにしましたので、お手持ちの端末等で自由にお試しください。
 IVS文字の表示にはビューアだけではなく、フォントの側の対応も必要となりますので、今回のテストでは各ビューア内で選択可能なフォントにそれぞれ切り替え、スクリーンショットを撮っています。添付資料内のフォント名表記は各ビューア内の表記に従いました。

 また、これはあらかじめお断りしておきたいのですが、IVSやサロゲートペアで表すような文字は、一部の学術系書籍および人名漢字以外ではほとんどニーズのないような文字が大半を占めます。従って、これらの文字の現時点での正確な表示をもって各ビューアの品質の絶対評価をしようとは思っておりません。ただ、前回のエントリで述べたように、Windows8のIVS対応によってテキスト内にIVS文字が混入する可能性を否定できなくなりましたので、「IVS文字を適切に無視して親字のみを表示する」実装は期待したく思っています。また、サロゲートペア文字に関しましては、「吉」(20BB7)※2のように、ATOK等の日本語入力システムで無意識に入力可能な文字も存在していますので、少なくともこういった比較的使用頻度の高い文字に関しましては、主要ビューアでの早い段階での表示対応を望みたいと思っています。

Adobe Digital Editions 2.0

IVS文字対応 サロゲートペア文字対応
◎:異体字字形まで表示 ◎:正しく字形を表示

 Adobeの汎用EPUBビューア、Adobe Digital Editions 2.0です。
 Mac版でサロゲートペア文字の「U+29FCE」(29FCE)が表示出来ていないこと、Windows版でIVS文字の「煕」(242EE E0101)が化けていることを除けば、かなり理想的な対応状況です。「煕」はサロゲートペア文字+IVS異体字の組み合わせですので、化けている理由はそのあたりかもしれません。IVS文字で異体字が表示されず、親字が表示されているものもありますが(6FF9 E0101など)、Unicode IVSで本来求められる「最低限親字を表示し、IVS文字を適切に無視する」という実装になっており、高く評価できます。化けている文字はおそらくフォント側に字形が収録されていないものと思われますので、ビューア側の実装としてはまず合格と言って良いように思います。

iBooks3.1

IVS文字対応 サロゲートペア文字対応
○:親字の字形を表示(iOS6) ◎:正しく字形を表示(iOS6)

 iPad、iPhoneなどのiOS端末で使用できるAppleのEPUB/PDFビューア、iBooksです。
 iOS6.1.3ではおおむねIVS文字は親字が表示されてIVS文字は無視され、サロゲートペア文字は縦横ともにきちんと表示されるというかなり評価できる状態です。フォントに游ゴシック体を選択した場合のみ「丈」(2000B)などいくつかの文字が化けますが、これはフォントに字形が収録されていないためでしょう。
 ただiOS5.1.1の環境ですと、サロゲートペア文字が縦書き時にほとんど表示できず、かろうじて表示できている文字も化けているというような状態になりました。IVS文字も「□」で表示されてしまっています。かなりつらい状態ですが、古い環境ではあり、まあ致し方ないところかと思います。

Himawari Reader Ver3.3.0

IVS文字対応 サロゲートペア文字対応
△:IPAex明朝/ゴシックでは異体字字形を「□」で表示 ○:IPAex明朝/ゴシックでは正しく字形を表示

 Android環境で広く使われている汎用EPUBビューア、Himawari Readerです。
 作者の中野さんより、Himawari Readerは.TTFフォントは全て表示可能だが、公式にはライセンスに従ってIPAex明朝およびIPAexゴシックをオプションアプリ形式で配布している、とのコメントをいただきましたので、今回は「標準フォントセット」およびオプション配布の「IPAex明朝」、「IPAexゴシック」についてテストをしました。
 テスト結果はかなり面白いもので、「標準フォントセット」ではIVS文字がきちんと異体字字形で表示されるもののサロゲートペア文字は全く表示されず、「IPAex明朝」/「IPAexゴシック」ではIVS文字は「□」で表示されてしまうもののサロゲートペア文字はきちんと表示されました。

Kindle PaperWhite ファームウェア5.3.4

IVS文字対応 サロゲートペア文字対応
△:IVS文字を「□」で表示 ◎:ほぼ全ての字形を正しく表示

 Amazonの電子ペーパー端末、Kindle PaperWhiteです。
 なお、kindleに関しましては、epubファイルをkindlegen2.8にてmobiデータに変換し、テストしております。
 IVS文字は全て「□」で表示され、サロゲートペア文字は「艾」(26AFF)および「U+237FF」(237FF)以外はきちんと表示されています。この2文字につきましては、おそらくフォント側に字形がないために表示できていないものと思われます。

Kindle for Android 3.8.2

IVS文字対応 サロゲートペア文字対応
△:IVS文字を「□」で表示 ◎:ほぼ全ての字形を正しく表示

 KindleのAndroid版アプリ、Kindle for Androidです。
 Kindle PaperWhiteとほぼ同様の結果ですが、こちらは「艾」と「U+237FF」を正しく表示できています。おそらくフォントの違いによるものと思われます。

Kinoppy for Android Ver 1.4.2

IVS文字対応 サロゲートペア文字対応
◎:異体字字形まで表示 ◎:ほぼ全ての字形を正しく表示

 紀伊国屋書店の電子書籍ビューア、KinoppyのAndroid版アプリ、Kinoppy for Androidです。
 IVS文字が異体字字形で表示され、サロゲートペア文字も「丈」(2000B)が消えてしまう以外はきちんと表示出来ています。フォントを「IPAexゴシック」に切り替えた場合のみIVS文字の「齬」(2A61A)が化けるのですが、これはフォントに収録されている字形数の差によるものと思います。

Kinoppy for iOS Ver 1.4.2

IVS文字対応 サロゲートペア文字対応
◎:異体字字形まで表示 ◎:ほぼ全ての字形を正しく表示

 KinoppyのMac版アプリ、Kinoppy for iOSです。
 Android版アプリと同様にかなり理想に近い対応ですが、サロゲートペア文字の「丈」が消えてしまう以外に、縦書き時に「U+200A2」(200A2)や「U+200A4」(200A4)が横転表示されてしまいました。使用頻度の高い文字はほぼ無いのですが、該当する文字を使用する場合にはCSSで正立を指示する必要がありそうです。

Kinoppy for Windows Ver 1.4.2

IVS文字対応 サロゲートペア文字対応
◎:異体字字形まで表示 ◎:ほぼ全ての字形を正しく表示

 KinoppyのWindows版アプリです。
 iOS版とほぼ同じ状態です。レンダリングエンジンが同一であることが推測できます。

Kinoppy for Mac Ver 1.4.3

IVS文字対応 サロゲートペア文字対応
◎:異体字字形まで表示 ◎:全ての字形を正しく表示

 KinoppyのMac版アプリです。
 サロゲートペア文字の「丈」がきちんと表示され、さらに横転してしまっていた文字も正立しています。Mac版のみバージョンが1.4.3ですので、レンダリングエンジンのバージョンアップの結果、きちんと表示出来るようになったと見てよいかもしれません。だとすれば、近い将来iOS版やWindows版のKinoppyでも正常な表示が期待できそうです。

 紀伊國屋書店は今後、学術書・専門書に注力していくのではないかというイメージがありますし、そういった分野ではIVS/サロゲートペア文字の表示に関して実際にニーズがあるでしょう。Amazon等に対する差別化のポイントとしても有効なのではないかと思います。

Kobo Touch ファームウェア2.4.0

IVS文字対応 サロゲートペア文字対応
×:通常の文字まで表示されなくなる ×:通常の文字まで表示されなくなる

 楽天Koboの電子ペーパー端末、Kobo Touchです。
 こちらは組版の確かさには比較的信頼感のある端末だったのですが、IVS/サロゲートペア文字の表示に関しては、各行のIVS/サロゲートペア文字の後ろの文字列がごっそり消えてしまうという結果になりました。これはEPUB3コンテンツにこれらの文字が混入していた場合、完全に可読性が損なわれる「事故」になってしまうことを意味します。Kobo向けコンテンツの制作では、IVS/サロゲートペア文字がコンテンツ内に含まれていないかをきっちりチェックし、外字画像にするなどの対応を取る必要がありそうです。

楽天Kobo Android版 バージョン4.8

IVS文字対応 サロゲートペア文字対応
△:IVS文字を「□」で表示 ◎:全ての字形を正しく表示

 楽天KoboのAndroid版アプリ、楽天Kobo Android版です。
 こちらはIVS文字は「□」で化けて表示され、サロゲートペア文字は正常に表示されるという標準的な結果が出ています。IVS文字は化けてしまいますが、可読性を致命的に損なうわけではありませんので大きな問題にはならないでしょう。
 ただ、koboに限らず「購入した書籍をどの端末でも読むことができる」のが今の多くの電子書籍ストアの売りですので、「kobo touchではきちんと読めないコンテンツがある」時点でストアの魅力を多少なりともスポイルするのは間違いありません。早い段階でのKobo Touchのファームウェア修正を期待します。

Murasaki バージョン2.1

IVS文字対応 サロゲートペア文字対応
△:IVS文字を「□」で表示 △:縦書き時に内容を表示出来ず

 Macで比較的良く使われていると思われる汎用EPUBビューア、Murasakiです。
 こちらはIVS文字が「□」で化けて表示され、サロゲートペア文字を含む縦書きのファイルを表示しようとするとアプリがフリーズしてしまうという結果が出ました。おそらくwebkitのサロゲートペア文字対応の問題に引きずられているものと思うのですが、詳しいことはわかりません。個人的にMurasakiはEPUB制作時のチェック用として多用しているビューアですので、早い段階で修正されることを望みたいです。

Readium Version 0.9(Mac)

IVS文字対応 サロゲートペア文字対応
○:異体字字形まで表示(ただし横転) ×:全て文字化け

 ウェブブラウザ、Google Chrome内で使用できる汎用EPUBビューア、ReadiumをMac版Chrome内で動かした場合です。
 サロゲートペア文字が縦書き時にほとんど化けてしまい、表示できません。また、表示出来ている文字も本来のコード位置とは異なる字形が表示されてしまっています。
 IVS文字に関してはほぼ全ての文字が異体字字形で表示されているのですが、文字が全て横転して表示されてしまっています。また、「煕」(242EE E0101)のみが縦書き時に化けてしまい、横書き時にもIVS文字の部分が化けて表示されてしまっているのですが、これは前述したように「煕」がサロゲートペア文字+IVS文字の組み合わせなことに関係がありそうです。

Readium Version 0.9(Windows)

IVS文字対応 サロゲートペア文字対応
△:IVS文字を「□」で表示、横転 △:縦書き時に直前の文字が消える

 ウェブブラウザ、Google Chrome内で使用できる汎用EPUBビューア、ReadiumをWindows版Chrome内で動かした場合です。
 IVS文字は「□」に化けてしまう他、縦書き時に横転して表示されてしまっています。また、サロゲートペア文字は横書きではきちんと表示されるものの、縦書き時には直前の始めカギ括弧が消えてしまっています。

 Readiumは本来、校正用のビューアとして本命視されていただけに、現在のこの状態は残念です。Readiumプロジェクトは先日、非営利電子書籍規格ライセンス団体「Readiumファウンデーション」として法人化とのニュースがありましたので、今後IVS/サロゲートペア文字の表示を含めてレンダリングエンジンの改善を期待したく思っています。

Reader(Android版)バージョン3.1.2

IVS文字対応 サロゲートペア文字対応
◎:異体字字形まで表示 ◎:正しく字形を表示

 SONYの電子書籍ストア、ReaderのAndroid版アプリです。
 IVS文字、サロゲートペア文字ともに、テストに使用した文字に関してはほぼ完全な対応でした。ReaderのレンダリングエンジンはベースがAdobeのRMSDKですので、異体字表示対応の優秀さはこれによる部分も大きそうなのですが、Adobe Digital Editions 2.0で文字化けしていた「U+29FCE」(29FCE)もきちんと表示出来ていますので、ある程度独自のカスタマイズがなされているように思われます。

 いかがだったでしょうか? 最初に書いたように、こうした異体字の表示については人名漢字と一部の学術書以外ではほとんどニーズはないように思いますが、各ビューアのレンダリング実装の進捗度が想像できて、個人的にはなかなか楽しい実験でした。

 前回のエントリで書いたように、Windows8が単体でIVS文字の入力に対応した以上は、今後電子書籍制作用の原稿にIVS文字が含まれている可能性をEPUB制作者も想定しなければなりません
 また、サロゲートペア領域の文字の中には、ATOK等で特に意識せずに入力可能な文字がすでに存在しています。

 これらの文字の混入によってコンテンツの可読性が完全に損なわれる「事故」を誘発してしまうことはなんとしても避ける必要があります。今後、制作サイドにはEPUB内のこうした特殊文字を検知し、排除するスキルが必要になるでしょう。また、ビューア開発サイドの方には、「例え特殊文字が含まれていたとしても事故にならない実装」を求めたく思っています。

※1 EPUB3内部で用いられているコードはUTF-8であるため、正確には「サロゲートペア」という用語は不正確で、正確には「追加漢字面(Supplementary Ideographic Plane; SIP)」と表記するのが正しいと思いますが、実際のEPUB3データのハンドリングとしてはビューアでEPUBを展開する際にUTF-16などに展開され、その際の処理で追加漢字面の文字化けが起きると推測されるため、ここではわかりやすさを重視して「サロゲートペア文字」と表記しています。
※2 JISX 0208及びJISX 0213では「吉」に包摂されているため独立した字形として収録されていないが、UnicodeのCJK統合漢字拡張Bには独立した字形が存在するため、実際には入力が可能。

 

資料のダウンロードはこちら


(2013.4.18)

ご指摘をいただき、技術的な用語を若干修正いたしました。また、Himawari Readerの中野さまより、「Himawari Reader自体は.TTFファイルなら何でもOKで、公式にはライセンスに従ってIPAフォントをオプションアプリ形式で配布している形になる」とのコメントをいただきましたので、表記を修正させていただきました。

(2013.4.18追記)

Android端末の機種によってもフォント表示結果が変わってくるとのご指摘をいただきましたので、機種名を追記しておきます。「Nexus7 Android OS 4.2.2」です。また、Mac環境は「Mac OS X 10.7 Lion」、Windows環境は「Windows7」にてテストしました。

(2013.4.19追記)

Windows8のUnicode IVS対応で出てきそうな影響

2013/04/04

 先日、大手町のマイクロソフトテクノロジーセンターで開催されたセミナー「Windows 8 で変わる文字 – 異体字と Unicode IVS~ 情報システムにおける日本語処理 ~」に参加してきました。また、その後JEPAで開催された「Plat14 Unicode IVS/IVD入門「Unicode IVS/IVD入門」刊行記念セミナー」にも参加させていただき、MicrosoftとしてのUnicode IVS普及への姿勢が少し見えてきた感はありますので、印刷/電子書籍の業界に実際に近々出てきそうな影響についてちょっと書いてみたいと思います。なお、Microsoftのセミナーに関しては「ちくちく日記」さんにレポートが上がっておりますので、そちらも合わせてご覧ください。「Unicode IVS/IVD入門」につきましては、「イジハピ!」さんのエントリが参考になります。

Unicode IVSは「テキストの規格拡張」

 まず、そもそもUnicode IVSとはどういうものかということなのですが、これはごくざっくり言うと「テキストの規格拡張」です。Unicodeは世界中の文字をひとつの文字集合規格で表現できるようにして国による文字コードの違いによる「文字化け」トラブルを解消し、コード変換のコストをほぼゼロに近づけることを目指す壮大なプロジェクトですが、Unicode IVSはこれをさらに拡張し、主に日本で人名漢字や地名等で用いられている漢字の「異体字」を表記できるようにしようというものです。これらの文字はこれまではInDesignなどの印刷用組版アプリや官公庁の戸籍運用システムなどの閉じた環境内でのみ使用可能でしたが、Unicode IVSはこれを将来的にWebや電子書籍の世界でも使用可能にするために作られた規格です。

 技術的には、ひとつの文字を表すのに「親字+異体字指定文字」というデータ構造を取っており、ビューア側のフォントがIVSに対応していないなどの理由で正しく目的の異体字を表示出来なかった場合には、「異体字指定文字を無視して親字の字形を表示する」というソフトウェア実装が期待されています。これにより、「少なくとも親字は表示される」ようにし、完全な文字化けによって可読性が大きく損なわれることを防ぐわけです。

 ただし、なにしろIVSは「テキストの規格拡張」ですので、過去に作られた厖大なあらゆるテキストを扱うソフトウェアに影響が及ぶと考えられ、文字化けや運用エラーなどの事故を引き起こす可能性を否定できません。
 特にWindowsやMac OS、Microsoft Office等の日本語入力で一般ユーザーがIVS文字を無自覚に入力できるようになった場合、入力者の母数が大きいため影響がどれだけ広範囲に及ぶかちょっと見当もつきません。DTPや電子書籍ももちろんこの問題と無縁ではありませんので、上記のセミナーにとても興味があったわけです。

Windows8のIVS対応はJIS90字形との互換範囲に留まる

 上記2つのセミナーに出席したことでMicrosoftのWindows8でのIVS対応の方針がおぼろげに見えてきたのですが、どうやら目的としては「JIS90字形とJIS2004字形の同時表示」にあるようです。Vista以降Windows搭載フォントでの字形の基準が変わり、JIS90字形で一般的だった字形が出せなくなりました※1

 このためMicrosoftにJIS90字形対応について多数の要望が寄せられ、現状でこのニーズに応える技術がIVSしか見あたらないため、IVSを採用した、という流れのようです。従って、Windows8搭載フォント内でのIVS対応は127(122+5※2)文字に留まり、さらに現状Windows 8でIVS文字を入力するためにはMS-IMEの設定が必要になるとのことですので、少なくとも今のところは、DTP等への影響はそこまで大きくはなさそうです。これに関してはちょっと安心しました。

今後はIVS入りドキュメントが入稿されてくる可能性がある

 さて、そうは言っても条件付きとは言え「Windows 8単体でIVS文字が入力可能になった」ことは確かですので、対策は必要です。

 これまで組版ソフト内でか扱えなかった人名用漢字などを、一般ユーザーが設定が必要とはいえ入力できるようになるわけですから、中には好んで使う人もいると見なければなりません。つまり、完全に閉じた環境でDTP制作をしている会社ならともかく、外部からデータを受け取る可能性が少しでもある印刷・制作会社は全て、今後はIVSが混じったデータが入稿されてくる可能性があると見て対処する必要がありそうです。

 そして、IVSのやっかいな点は繰り返しますが「テキストの規格拡張」だということで、つまりWord内のIVS入りテキストをそのままコピー&ペーストでInDesignやIllustratorに持って行けてしまいますし、OS自体がIVSの字形表示に対応していなくても(何せテキストなので)、データのハンドリング自体はできてしまいます。Windows XPのメモ帳で保存したデータにIVSの異体字指定文字が混じってくる可能性もあるのです。PerlやRubyなどのテキスト処理プログラムも例外ではありません。そうなると、WordやExcelのドキュメントのみをチェックすればいいという話でもなく、「全ての形式のデータをテキストに落としてチェックする」くらいの対策が必要になるでしょう。

結局DTPでの影響/対処法は?

異体字指定文字のみをInDesign内で選択できてしまう

異体字指定文字のみをInDesign内で選択できてしまう

 さて、では結局DTPで現状Unicode IVS入りのドキュメント入稿にどう対処すべきかということなのですが、以前JEPAセミナーで発表させていただいたようにInDesignはCS4以降でUnicode IVSに対応はしていますが、親字とIVSの異体字指定文字をアプリ内で別々に選択できてしまう少々怖い仕様なこと、Illustrator等は現状でIVSに対応していないことを考えると、まだDTPで安心して運用できる状況とは言い難いため、現状ではテキスト内でIVSが使われている箇所を特定し、字形パレット等から入力できるGSUBの異体字に置き換えてやることになるかと思います。IVSはテキストですので、(特に127文字程度であれば)Indesignタグテキスト等を経由させて同一字形のGSUB異体字に変換してからInDesignに取り込むこともそう難しくはなさそうです。ただし、再校等で追加入稿されてきたデータや、Illustrator等での対応に気をつける必要はあります。

IVS表示に対応していないツールでは化ける

IVS表示に対応していないツールでは化ける

 IVSの有無をチェックする方法ですが、IVSは親字のコードの後に「U+E0100〜U+E01EF」の異体字指定文字が並んでいる構成になっていますので、単純にIVSが含まれている文字を知りたいだけなら、この範囲の文字が含まれているかどうかを各種ツールでチェックすれば良いでしょう。また、現状IVSの表示に対応していないツールでは、異体字指定文字が化けて表示されますので、最悪これを目視でチェックすれば良いことになります。

 MicrosoftがWindows8内で使用可能としたIVS文字に関しましては、以前もお世話になったmonokanoさんNAOIさん制作の資料をご提供いただけましたので、こちらからダウンロードしてご参照ください(InDesignドキュメントです)

 おそらく、IVSがテキスト内に含まれているかどうかをチェックするツールの作成自体はそう難しくありません。ただ、なにしろ「WordやExcelのドキュメントを開いてコピー&ペースト」という完全に一般定着している作業の流れを変えることになりますので、必ずチェックすることを末端まで徹底させることは相当大変そうな話ではあります。

電子書籍ではどうなるの?

 次に電子書籍でのIVS対応状況ですが、まずXMDFやドットブックでは文字コードの基本がShift_JISですので、Unicodeの発展フィーチャであるIVSはそもそも使用できません。字形を再現するには外字画像にする必要があるでしょう。

 EPUB3では、「まだしばらくは使わない方が無難」といったところかと思います。少し前に見てみた記憶では、紀伊国屋書店のアプリ「kinoppy」のiOS版でIVS字形の再現まで確認できた他は、ほとんど対応しているアプリはなく、それどころかIVS文字が化けて表示されたり、IVS文字以降のテキストがごっそり表示されなかったりといったようなビューアの実装が見受けられました。

 ただ、正直まだ黎明期のEPUB3ではビューアアプリのアップデート間隔がかなり短いため、私もまだ最新ビューアの実装は追いきれていません。各電子書籍ビューアの最新IVS対応状況につきましては、いずれ調査の上、別エントリでご報告したいと考えております。

※1 JIS2004とJIS90の文字の形の対照表(Adobe)
※2 メイリオのみIVS対応のものが5文字あるようです

     

monokanoさん/NAOIさんにご提供いただいた資料はこちらからもダウンロードできます

(2013.4.04)

monokanoさんにご指摘いただいた部分を修正いたしました。「IVSシーケンス」を「異体字指定文字」に修正したのが主な修正点です。

(2013.4.04追記)

プロフィール
Jun Tajima

こちらにて、電子書籍&Web制作を担当しています。
このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。少しでも早い段階で快適な電子書籍閲覧・制作環境が整うことを願って、現場からの声を発信していこうと目論んでおります。

当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。また、本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。