今日は、JSKifuForWP (その後のResponsive-Kifu)のコードをいじる。
コメント出力も可能になった。
JSKifuForWP は読み込むことのできるデータ形式は、nkif 形式のみである(→その後、kif 形式も読めるように改変)。nkif というのは、私が勝手に名付けた名称で、その出自が某放送局のためこの名前となっている (笑)。
今日の作業でそのデータ構造はほぼ理解した。
nkif は一局面を例えば
p=1b191716101617191b0014000000000012001d1d1d1d1d1d1d1d1d0000000000
00000000000000000000000000000e000000000000000e000e0e0e0e0e0e
0e0003000000000005000c0a08070207080a0c26;
h1=;
h2=;
という形で表す。p は盤面の駒配置、h1 は先手の持ち駒、h2 は後手の持ち駒、である。
p はここでも調べていた。1一が 1b で香、2一が 19 で桂、‥‥というのはわかっていたのだが、これだと 81 * 2 = 162 文字で盤面の駒配置はすべて決定されるはずだが、実際には、164 文字ある。最後の 26 が余計だ。
今までこれがわからなかったのだが、わかってみればなんことはない、これは着手位置を表すマーカー画像の位置そのものだった。初手▲2六歩と飛車先を突いたので、こうなっている次第。余計な情報なので落としてもいいのかもしれない。
そこまでわかったので、テスト的にデータベースも作ってみた。とりあえず三局ほどデータを挿入。
この状態で
SELECT * FROM tbl_kifu where kifu like ‘%p=1b19171610161719‥(略)‥0a0c26;%’
を実行(SQL文はいつまでたっても慣れないっす)。
結果は、
問題の処理時間は、
これだと100局程度でも、同一局面をひろってくるのに数秒かかりそう。
んー、ちょっと遅いかな。
感想としては
・それっぽいシステムは組めそう
・が、「こなれた」システムをつくるのはそれなりのノウハウが必要
と思った。
やはり、データベースとか検索とかは苦手だ。




