00:35:21
icon

どんな風に変換されてるか、図にしました。QR‐コードの「漢字モード」は Shift JIS を経由するので右のように若干崩れた形だけど、要するに JIS X 0208 の一つ一つの区を隙間なく詰めていった感じの符号化方式だ。JIS X 0208 は「94 区 94 点」の枠組みだけど、この操作は 96 点単位で捉えてよい。

二バイト文字で下位バイトに 256 通りの値を使い切るなら、上位バイトが三種類の値を消費する間にちょうど八区収まる事になる。これを第九区以降も繰り返すと、上位バイトが五ビットを使い切って 32 種類目の値(十進 31、すなわち 0x1F)を表す時、X 0208 の第 86 区の途中で限界に達する。(図中の「上位バイト 01」の「6 区」と同じ状況。)X 0208 の文字は第 84 区で弾切れだから、これで残らず符号化できる。

Attach image
00:49:46
icon

QR‐コードについて考えてる間に QR‐コードのスパム通報が来るのう。

01:34:49
icon

qrqrpardemo.nakanishi.dev/
nakanishi.dev/posts/rMQR%E3%81

こちらの QR‐コード生成器で生成したコードを iPhone に読ませてみると、和文の解読に失敗する事がある。「ああああ漢漢」が「縺ゅ≠縺ゅ≠貍「貍「」に化けるという事は…UTF‐8 を Shift JIS と見なしてますね。

この生成器が「漢字モード」を利用してない事が分かる。

Qr and rMQR Generator
Attach image
01:34:57
icon

UTF-8 で :
E38182 あ
E6BCA2 漢

Shift JIS で :
E381 縺
82E3 ゅ
8182 ≠
E6BC 貍
A2 「

02:00:54
icon

iPhone のカメラで認識した時に使われる QR‐コードっぽいアイコン(図の左)、よく見ると微妙にあり得ない形なのが気になる。こんな風にするくらいなら、apple.com を表す正しい QR‐コードでも生成して、その左上を切り抜いた方がマシぢゃないかな。視覚的な特徴を捉えたデフォルメとしては、コントロールセンターのボタンに使われるアイコンが綺麗だと思う(図の右)。iOS 15.8.3 はちょっと古いので、最新版がどうかは知らない。

Attach image
02:13:57
icon

情報通信用などの多くの文字符号化方式は、「バイト列の途中から読んでも分かるように」とか「途中のデータが缺損しても後続に影響しないように」といった考慮で符号空間に隙間を持つ事が多い。でも QR‐コードには「全てのビットを一度に完全に読む」という前提があるので(その為に誤り訂正も組み込んでるわけで)、元データの符号はできるだけ無駄なく稠密〔ちゅうみつ〕にしたいし、していいわけだ。

02:26:10
icon

UTF‐8 とかスカスカだし、ZIP したいよな…。かつて Unicode にも簡易な圧縮みたいな方式が定義されてて、それは廃止されたんだっけ。

12:52:40
icon

シャワー浴びた。おはよう。

15:27:40
icon

これは全部、iPhone のカメラで読める QR‐コード。但し、左上のまともな奴以外は向きを水平か垂直に揃えないと認識しない。位置検出パターンが正方形に近い事を期待して傾きに対処してるみたい。ほかの機器がどう読み取るかは未確認。

Instagram の生成する QR‐コードが位置検出パターンをカド丸にしてるようなので、それを参考にした実験です。

Attach image
17:11:14
icon

これも iPhone のカメラで読める QR‐コード。本質的にはあまり壊してないし、通用しやすいんぢゃないかな。傾けてやると位置検出パターンが左右対称になって綺麗かも。

Attach image
17:19:56
icon

ちなみに「mofu.kemo.no」より「MOFU.KEMO.NO」の方が符号化の効率がいいという性質を利用して、セル数(細かさ)を抑制してます。

21:10:12
icon

これは正方形よりも正六角形っぽい印象を与えるようにした QR‐コード。少なくとも iPhone は読める。通常のコードでも真正面でない位置からカメラを向けたら像が細長く変形するから、多くの読み取り装置は耐性を持ってるんぢゃないかな。

Attach image
23:02:43
icon

誤り訂正に頼ってデータ部を削り、六角形にしちゃった。これでも読めるなあ。真ん中にアイコンとかを置いて誤り訂正に任せるのはよく見掛ける。それと大体同じ。

Attach image