Indesign CCのQRコード生成機能のダメっぷりは…

つい先日.idmlファイルを間違ってCoteditorにドロップした時に表示された化け化けの文字列の先頭がPKで始まるのを見て、「ああ、こいつらってインデザインの皮被ったzipファイルか…」って思いました…何度目かってつっこみは無しの方向でお願いします。
まあ、解凍した以外何もしてません、docxと似てるな…って思っちゃっただけなんです。ところで、docmって拡張子はdocxのお友達の認識でOKですか?これも詳しくは調べていませんが…
本題は全く関連しませんが、QRコード絡みです。この前からぼそっと呟いている事をまとめてみました。


8.3.2 数字モード 数字モードは、10進数集合(0〜9)のデータを通常、3文字を10bitで符号化する。8.3.3 英数字モード 英数字モードは、45文字「10個の数字(0〜9)、26個のアルファベット文字(A〜Z)及び9個の記号(スペース、$%*+−.,;)のデータを符号化する。通常2文字を11bitで符号化する。
8.3.4 8ビットバイトモード 8ビットバイトモードは、JISX0201に基づく8ビットのラテン文字・片仮名用8ビット符号に規定された文字を扱う。このモードにおいて、データは、1文字を8ビットで符号化する。
8.3.5 漢字モード 漢字モードは、JISX0208の附属書1で符号化を行う漢字集合(漢字のほかに仮名、英数字等を含む。)を扱う。各2バイトの文字値は、13ビット2進コード語に圧縮する。
8.3.6 混在モード QRコードは8.3.1〜8.3.5に規定する任意のモードの組合せによるデータ列を扱う事が出来る。
混在モードにおける入力データ文字列の最も効率的な表現方法の選択については、附属書Hによる。

以上はJISX0510よりの引用です。Adobe社の実装では「数字モード及び8ビットバイトモード」が実装されています。漢字モードはシフトJISを想定して設定されているために敬遠して、マルチバイト文字はUTF-8を8ビットバイトモード上で処理を行うようになっているようです。次に示すのは漢字モードの処理例です。

kanjimode.png
ご覧の様にJISX0208上の文字集合(こう書くとややこしいのですが要するにEUC、JIS、SJIS等の2バイト文字コードで利用される文字集合)にJISX0201の文字集合が混在する場合、8ビットバイトモードが利用される場合があります。規格書自体、日本語に関してはシフトJISを想定したものになっているのがお分かり頂けるでしょう。もちろん仕組み的には8ビットバイトモードは3バイトであろうが処理可能であり。最近のデコーダーでは何ら問題なくデコードが可能です。
しかしながら、コードリーダーを設計する際、規格書のお手本通りに実装すると日本語はシフトJISを利用する事になります。特に古い実装ではにAscii以外は2バイト(SJIS)で決め打ちなものも散見されます。3バイトで見なければならないものを2バイトで見てしまいますので当然文字化けが生じます。例えば、「あ」の場合、0xE3、0x81、0x82の3バイトですが、頭の2バイトの0xE381と認識して「縺」を拾ってしまうと言う事が起こります。
さて、このまともにデコード出来ないコードリーダーを不良だと言えますか?Adobe社にしてみれば、UTF-8でマルチバイトでも問題なくコード化出来てる。どこに問題があるんだ?ってとこなのでしょう。しかし、規格を読み解くとAdobe社の実装が日本の実勢を全く考慮していない事がありありと浮かびあがります。日本語の特徴である漢字モードを欠いた状態で日本語対応とするのはいかがなものでしょうか。
シフトJIS自体は緩やかに死滅に向かうでしょう。大勢に影響は無いと言うのは正しいのかも知れません。しかし、もやっとするものが残るのも確かです。自身の都合で「規格上に明記された実装すべきモードを外す」というのはアプリケーションメーカーとしてあるべき姿なのでしょうか…

…わたし自身シフトJIS実装するのに相当苦労してんだよw

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト /  変更 )

Google フォト

Google アカウントを使ってコメントしています。 ログアウト /  変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト /  変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト /  変更 )

%s と連携中