あくまでも「ワタシが書いてきた」範囲内であって、data-uri にまつわる話を手取り足取る話ではない。
これまで一度も「キレイにまとめた形で」書いたことがなく乱雑に書いてきてるので、たまにワタシ自身が自分の書いたもの検索で困ることがあるのよね。
これまで書いてきたのは以下:
- iframe の src に data-uri を突っ込む例
- 『「ダウンロードさせる」以外の目的で data uri をリンク先として指定することまかりならん』
- Google Chrome の Open Frame プラグインの紹介
- data-uri を zip ダウンロードリンクに使う例
html というのはそもそもが「(論文などの)公開リンク集」のためのハイパーリンク目的で流行りだしたものなわけよ、つまりは「a href=」だの「iframe src=」てのは「独立した外部ファイルを指す」ために生み出されたものであって、実体を埋め込むためのものではないわけね。このことは、data-uri が誕生した今だって本質的には変わらなくて、主食はあくまでも「分割統治」のためのインフラ。ここだけは忘れないで欲しい。という前置きはしとく。
それでもなお data-uri が必要とされるのがまさにワタシのようなケースで、それを上で列挙したワタシがこれまで書いてきたものの中に書かれてる。一言で言えば「分割統治の方がメンテコストがかかる」というケースだね。特にワタシの場合はあなたが今みているこのページの編集。
たとえば何か資材をダウンロードさせたい場合に、「ログインして記事編集WEBアプリで編集」という操作と「サーバに ssh などで資材アップロード」という操作が(各々全く異なるユーザインターフェイスで)バラバラに行わなければならないとするならば、これは手間もかかるし、記事完成後の保守も大変。なので全部が「ログインして記事編集WEBアプリで編集」に一体化:
されていると嬉しい、てこと。特にワタシの場合は「皆が自分でプログラムを書くのに参考に出来るサンプル目的プログラム」なので、そもそも記事本体と完全に一体化してないととても都合が悪かったりもするのである。管理するワタシにとっても読み手にとっても、ね。
で、ワタシはこの data-uri を、Wordpress の記事編集画面の外で「PC でオフラインで」生成してるわけなんだけれど、それは Python スクリプトでやってる。これまであんまり整理してきてなかったんだけど、さっき少しだけ整理した。こんな:
1 #! py -3
2 # -*- coding: utf-8 -*-
3 import os
4 import sys
5 import io
6 import base64
7 import mimetypes
8
9
10 __MYNAME__, _ = os.path.splitext(
11 os.path.basename(sys.modules[__name__].__file__))
12
13
14 fn = sys.argv[1]
15 data = io.open(fn, "rb").read()
16 enc = base64.b64encode(data).decode()
17 bn, ext = os.path.splitext(os.path.basename(fn))
18 divid = bn.replace(".", "_")
19 if __MYNAME__.endswith("html2iframedatauri"):
20 print("""\
21 <iframe id="{fn}" width="100%" height="1000px"></iframe><br />
22 <script type="text/javascript">
23 var iframe = document.getElementById('{fn}');
24 iframe.src = 'data:text/html;base64,{enc}';
25 </script>\
26 """.format(enc=enc, fn=divid))
27 else:
28 if ext.lower() == ".7z": # mimetypeモジュールがまだ関知してない。残念。
29 mty = "application/x-7z-compressed"
30 else:
31 mty, _ = mimetypes.guess_type(fn)
32 print("""\
33 <a download="{fn}" href="data:{mty};base64,{enc}">{fn}</a>\
34 """.format(mty=mty, enc=enc, fn=fn))
たぶん python 3.x 用、かな? 2.7 は確認してない。もう少し頑張れば img src= とか色々出来るが、このスクリプトのインターフェイスね、考えるのがめんどいのは。まぁどこに使うのでもやり口は一緒だ。まぁワタシが必要とする事態になったら追記でもするわ。
「data-uri を zip ダウンロードリンクに使う例」という言葉どおりで、これまでは実は download については zip 以外試してきてなかった。まさに「Tabulator で csv 「的」データを入力にしたい、兼「声優世代表のおとも」(4) – 「データの正規化」のはなし」では zip を貼り付けているわけなんだけれど、そこでも書いた通り「zip よりもっと圧縮率が高いもの」を使いたかったんだよね。のでそれにそなえて、「data-uri を zip ダウンロードリンクに使う例」では「application/zip」を直値埋め込んでいたが、今貼り付けたスクリプトでは mimetypes で調べて埋め込んでる。
「「Tabulator で csv 「的」データを入力にしたい、兼「声優世代表のおとも」(4) – 「データの正規化」のはなし」」にあげた「ver 12」は、tar + bz2 圧縮にすると zip より遥かに小さくなることは既にわかってる。以前似た話を書いたので、興味がある方はどぞ。ともあれ、同じ「ver 12」の、レコード数激増(4750レコード) + tar + bz2 圧縮版:
mimetype は “application/x-tar” になる。bzip2 はどこ行ったんだ、とは思うが、皆で決めたことなのだからこれでいいんだろう。少なくとも Chrome にとっての問題はないようだね。
なお、その「~(4)」で問題にした「Wordpress のテーブルカラムサイズ制限にひっかかるかどうか」は、この tar + bz2 版はまだまだ余裕がある。たぶんあと最低でも 500 レコード増やしても載せられるのではないか? zip で貼り付けた 4315 レコードのは実は「制限にひっかかるギリギリ」。圧倒的な差ね、ほんと、zip なんかなくなれよ、再訪。(ちなみにアーカイブ内には入力の wppagenames.txt も出力の actor_basinf.html、actor_basinf_data.js も入れてる。)