第73話で正しく読めた一文字を、イトはexport trayへ置いた。
あ
source fileの名前はlabel。拡張子はTXT。
中には、前話から守ってきた三つのbyteがある。
E3 81 82今度の注文は、透明な案内板へ重ねられるPNG画像だった。
受け取り口にはimage/pngとある。
奥では、同じ案内板を使う18台の表示機が同期を待っている。ここでbatchを流せば、受け取った一件がそのまま18台へ配られる。
イトはfile名の最後を選んだ。
file name extension TXT -> PNGrename keyを押しかけた瞬間、検査lampがamberに変わった。
file name says PNG
first bytes E3 81 82
expected PNG 89 50 4E 47 0D 0A 1A 0A「名前はPNG。でも、中身はPNGとして始まっていない」
変えるのは名札か、中身か
イトは手を止めた。
「PNGっていう拡張子を付ければ、PNGになるんじゃないの？」
ユイは、TXT拡張子のlabelをread-only trayへ戻した。
マコトは、その横へ三枚のcardを並べた。
拡張子は、file名の末尾に付く手がかり。
media typeは、受け渡す側が「これは何として扱うdataか」を伝える情報。
file formatは、実際のbyte列をどんな構造と規則で読み書きするか。
似た役割に見えても、同じものではない。
ユイ
名札を付け替えても、箱の中の並びまでは変わりません
マコト
media typeだけをimage/pngにしても、受け取るdecoderがPNGの構造を読めるとは限らない
イト
じゃあ、見える名前と渡す札だけ合わせてもだめなんだ
Picoはrename keyにもexporterにも触れない。
同期を待つ18台を照らし、選択をイトへ返した。
三つの送り方
A：拡張子をTXTからPNGへrenameする
file名は注文どおりに見える。
けれど三byteはE3 81 82のまま。PNGのbyte構造は生まれない。
B：media typeだけをimage/pngにする
受け渡し札は注文どおりになる。
しかしdecoderへ届く中身はplain textのまま。正しくない型情報を渡すことになる。
C：sourceを残し、画像exporterから新しいPNGを書き出す
TXT拡張子のlabelはread-onlyで保つ。
文字をpixelへ描く処理を通し、PNGの規則で組み立てた別fileを、PNG拡張子のlabelとして作る。まず一件だけdecodeしてから、18台のqueueを再開する。
イトはrename画面を閉じた。
media typeの入力欄からも手を離した。
「C。名前をごまかすんじゃなくて、元を残して、新しい中身を作る」
PNGは、名前より先にbyteで始まる
このlabで使うPNGの先頭には、決められた8byteのsignatureがある。
89 50 4E 47 0D 0A 1A 0Aその後ろに、画像の大きさやpixel dataなどを運ぶchunkが続く。
PNGという拡張子は、人やappが形式を予想する助けになる。
でもrenameだけでは、このsignatureもchunkも追加されない。
image/pngというmedia typeも、中身をPNGへ作り替える魔法ではない。HTTPならContent-Typeなど、dataを渡す経路からsuppliedされる情報だ。
file名、受け渡し情報、実際のbyte構造。
三つが食い違えば、受け取る側は誤ったdecoderを選んだり、読み取りを拒否したりする。
イトがsourceではなく、outputを作った
イトはTXT拡張子のlabelへ透明なlock coverを下ろした。
sourceの三byteは触らない。
代わりにcopyを画像exporterへ送り、自分の手でcyanのexport handleを回した。
exporterは、UTF-8で読めたあをfontへ渡した。
fontが文字の形を描き、その形を透明な背景のpixelへ置く。
そしてpixel dataをPNGのchunkへ包み、新しいfileとして書き出した。
source file label (TXT extension)
source bytes before E3 81 82
source bytes after E3 81 82
output file label (PNG extension)
declared media type image/png
output starts with 89 50 4E 47 0D 0A 1A 0A一件だけpreview decoderへ渡す。
拡張子はPNG。
受け渡し札はimage/png。
先頭はPNG signature。
decoderは後ろのchunkも読み終え、透明な案内板の上へあを表示した。
renameだけで作ったfileは0件。
source editも0件。
test outputは1件。
そこでイトは、自分で18台のqueueを再開した。
18台すべてに、透明背景の同じあが現れた。
signatureだけで合格にしない
先頭8byteが合っていることは、PNGを見分ける強い手がかりになる。
ただし、それだけでfile全体が正しいとは言い切れない。
途中のchunkが欠けていたり、長さや内容に問題があったりすれば、decoderは最後まで読めない。
だからこのlabでは、次の順で一件を確認した。
1. sourceを残す
2. 対応exporterで新しいoutputを作る
3. 拡張子とmedia typeを照合する
4. signatureと内部構造を検査する
5. decoderで一件だけ開くすべてのfile形式がPNGと同じsignatureを持つわけではない。
大切なのは、拡張子の見た目だけで変換できたと決めず、その形式を実際に作れるappで書き出し、受け取る側でも確かめることだ。
文字の曲線が、四角い光へ変わった
18台目の表示を見届けると、イトはexporterの拡大窓をのぞいた。
遠くからは、なめらかなあに見える。
近づくと、輪郭は小さな四角へほどけていた。
透明だった場所にも、文字がある場所にも、一つずつ位置がある。
文字の端では、濃い青と薄い青が隣り合っている。
イトは、lock coverの下に残した三byteと、outputに並ぶ四角い光を見比べた。
同じあを表していても、もう同じbyte列ではない。
今回は、変えないことではなく、元を残したまま目的に合う別のdataを作ることを選んだ。
「この小さな四角は、どこに何色を置くって、どうやって覚えているの？」
次回、ピコルート第75話。
画像dataは、pixelと色をどう並べる？