FNG09

yumano @yumano

今日はFNGオフライン FirefoxのSQL Lite Manager がわけわからんレベルで便利・・　http://bit.ly/7dGT2A

yumano @yumano

消した列のデータは先頭６バイトが000000で埋められているけど、データは残っている。

yumano @yumano

行の削除 PupSQL Lite →レコードの先頭フラグだけ書き換え、データは丸残り FireFoxプラグイン→データは00埋め、データ復活できない。

yumano @yumano

次のページを使う長いデータの場合、４バイト分データが消える

yumano @yumano

Firefoxのデータが見れるか、ポチポチしている最中。

yumano @yumano

mysqlはデータが一定のサイズのページ単位で保存。ページは末尾からデータがうまる。ページサイズを超えると次のページが作成される。

yumano @yumano

１レコードが連続したデータ。先頭部分がレコードそのものの情報。データの直前がレコードサイズ

yumano @yumano

レコードのサイズ表記は(x-13)/2、1レコード複数のカラムがある場合は順番に記載される

yumano @yumano

(0x0X-0x0d)/2で計算したできるように脳みそを取り替えた方が後々便利。

yumano @yumano

なんか、単純削除だとスラックのデータ残る。でも、更新した場合は、更新レコードのサイズがスラックに書き込める大きさならスラックが上書きされる。

yumano @yumano

って、削除時の細かい動作は、PupSQLiteの仕様な気がした。現にFirefoxプラグインと動作が違うし

yumano @yumano

PupSQLiteでファイルを保存時の注意点。保存イベントでは直前に編集していたデータの入力が完了していない。ちゃんと、入力→enter→保存 でないといけない。変な所ではまっていた orz

yumano @yumano

レコードに複数のカラムがある場合、「ほげほげ」1カラム目サイズ、2カラム目サイズ、１カラム目データ、２カラム目データとなる。

yumano @yumano

0xffを超える場合、データサイズはどう表現されるのか。(0xff-0x0d)/2=121 なので、122文字のデータを入力してみる

yumano @yumano

あれ？13 82 05 だ・・・ 82 05 が124文字のデータを表す

yumano @yumano

で、これが可変長整数なわけだ。10000010_00000101 =517 (517-13)/2 = 252 = 126byte なんか、数値が違う・・・

yumano @yumano

ふむ〜、計算がなんかあわない。バイトと文字数の換算を間違えているっぽ・・

yumano @yumano

(0x0X - 0xD) byte なんだね。そして、可変長だから1_00000101なの忘れてた。

yumano @yumano

1_00000101 だから、261 (261-13)/= 248byte 124文字 ぴったし。さて、ほげほげ部分を調べる作業に戻ろう

yumano @yumano

81 03 07 04 13 82 05 データ全長(3+124)文字 0B 06 03 11 19 データ全長(2+6) ほげの部分のサイズが増えた。データ全長が(63+63)文字でやってみよう。

yumano @yumano

あああ、浮動整数表記だから、63だと桁上がりしてしまうんだった・・・

yumano @yumano

30+31でデータを作り直したぉ

yumano @yumano

あれ、先頭部分が10バイトだ・・・ちゃんと、計算しないとだめだなぁ（T-T

yumano @yumano

ほげの部分のどこかが削除フラグだと思うんだけどなぁ・・・

yumano @yumano

うさみみ計算機とStirlingの比較作業は便利だった