FrameMakerのQRコードビルダーについて

ご無沙汰しています。こちらで書くのは久しぶりなのですがAdobeのユーザーフォーラムにブログを設けましたので今後はそちらの記事が多くなる予定です。自動化全般について取り扱うスタイルは今までと変わりありませんので定期的にチェックしてみて下さい。

https://forums.adobe.com/community/international_forums/japanese/automation/overview

ところで、昨年末から個人的にFrameMakerを仕入れて色々とテストしています。

これもExtendScriptをサポートするのですが、随分と毛色が違っていて思うように動かす事ができません。UI絡みなんてとても変です。というか、まともにScriptUIが使えないｗ

それは多分どうでもいいんです。今回はまたもやBUGを踏み抜いてしまったようなので、その顛末を残しておきます。

まずQRコードビルダーで「ああああ」と４文字のひらがなをエンコードしてみます。

これのバイナリは以下のようになっています。

40 ce 38 18 2e 38 18 2e 38 18 2e 38 18 20 ec 11

冒頭が4＝0100で始まることからこのコードは8bitバイトモードで記述されていることがわかります。また続くコード長が0xcですから12byteがコードの中身となります。これは続く（e3 81 82）×４が実態であり、続く0で終端して0xecと0x11は埋め草となっています。もちろんUTF-8ですから「ああああ」がUTF-8の文字コードで正しくコード化されているということになります。

さて、このQRコードビルダーですが、InDesignのQRコード生成機能とは異なりデコーダを内蔵しています。ですから、他で作ったQRコードを配置したものでもコードから文字列を取り出すことが出来ます。InDesignの場合は生成したEPSファイルのメタデータとして元の文字列を保持し、それを再編集に利用していましたからこの実装は更に一歩踏み込んだ物と言えそうです。が、このデコーダがおバカです。
先程のQRコードではひらがな４文字をコード化しました。これには理由があります。UTF-8の3バイト×4で12バイトのバイナリを生成するためです。

こちら、先程のQRコードを再編集かけたウインドウです。そう、ものの見事に化けています。
実際のバイト列は以下の様になっています。

41 2e 7b 8b ae 38 28 5e 28 9a 0e 7b 8b ae 38 28
5e 28 9a 00 ec 11 ec 11 ec 11 ec 11

バイトコードを見てみると8bitバイトモードでコード数が18byteとなります。

e7 b8 ba e3 82 85 e2 89 a0 e7 b8 ba e3 82 85 e2 89 a0

こちらがそうなんですが、これは「縺ゅ≠縺ゅ≠」をUTF-8の文字コードで並べたものです。では、何が起きているのでしょう。

• 縺　UTF-8（e7 b8 ba）／SJIS（e3 81）
• ゅ　UTF-8（e3 82 85）／SJIS（82 e3）
• ≠　UTF-8（e2 89 a0）／SJIS（81 82）

化けた文字列のコードを見てみると、デコーダがどういった処理をしているのか判明します。これはデコード時に読み取ったバイトデータをシフトJISとしてバイト列を読み込み処理しています。そして、それをUTF-8の文字コードで再度エンコード処理を行っているのです。
このQRコードビルダーと言う機能、QRコードを読み込んで再編集を行えるというちょっと気の利いた機能が仇となっています。基本的にどんなQRコードでも読み込んで処理するために読み込んだバイト列の文字コードを判別しなければなりません。その文字コード判定ルーチンがおバカなケースです。先程４文字でコード化する理由を書きました。これは文字化けを生じさせる為の調整です。奇数個の文字列ではバイト数が合わないために文字化けを生じません。例えば３この「あ」の場合バイト列は９バイトとなりSJISと見ると１バイト余るために誤判定は起きず正常にUTF-8として読み込みます。
さて、回避方法ですが再編集で文字化けを生じてしまうと元の文字列は破棄されてしまいます。ですから再編集を行う場合は別のリーダー等で文字列を抜き出して、それを利用して再度生成させる等の一手間をかける必要があります。
Adobe社はもうQRコードの実装を諦めたほうが良いｗ
どう実装してもバグが残されている(^-^;