Appleのstable版として落とせるBonjour SDK Java 版の TXTRecord クラスのレコード長計算関連がバグってます。
症状としては、最大長255 bytes(これもおかしくて本当は200のはず)まで入れられるはずのTXTレコードに、127文字までしか入れられない。
原因は、レコード長を byte 型で扱っていること。
Java のbyte 型は、-128～127 の符号有り型なのだけど、どうやら符号無しの方法でコーディングされています。なので、128以上を入れてしまうと、長さがマイナス値を取り、byte配列各保持にマイナスの大きさの配列を確保しようとして落ちます。
運が良いことに、TXTRecordクラスはfinal じゃないので、サブクラスを作って、長さ保持変数をint にしたり、byte から長さを取るところを byte[num] & 0xFF にしたりして対応しました。
今は時間が無くて無理だし、まさかCVS版に残っているとも思えないけれど、もし残っているようならレポートしておこうかな。
1日必要カロリー & 適性摂取量 計算機
ダイエットシリーズ
その他
- - - - - - - - - - - -
毎回計算するのが面倒だったので、生活活動強度に応じた必要カロリー&適性摂取量の計算機を作ってみました。
数値は、生活強度別エネルギー所要量表（kcal/日）から取ってきました。
一時出典は「最新食品標準成分表五訂版」社）全国調理師養成施設協会」とのことです。
糖質(炭水化物)は必要カロリーの0.7掛け、タンパク質は体重×1.1 で計算、脂質は残り物として計算しています。
生活強度の目安としては、ずっと家にいる人は1、 研究者やSE等で2、立ち仕事が多ければ3、重労働は4、と言ったところです。
詳細については、香川大学の医学部 保健師の健康教室にもっと詳しくてわかりやすい一覧がありますのでそちらをご覧ください。
と思ったら、動かない･･･。う～～ん。Bloggerでjavascriptは何かと面倒だなぁ。
原因判明。onclick=""だったのが原因だった。javascriptで""使ってるから''じゃないとだめっすね。
追記: なんで18歳未満がないかというと、どうやら体重対タンパク質の計算値が1.1じゃないらしいのだけど、適正値が見あたらなかったためです。もしご存じでしたら教えてください。よろしくお願いします。
その他
- 1日必要カロリー & 適性摂取量 計算機
- [個人用][訂正版][考察] 糖質･脂肪の摂取目安 (非運動時)
- - - - - - - - - - - -
毎回計算するのが面倒だったので、生活活動強度に応じた必要カロリー&適性摂取量の計算機を作ってみました。
数値は、生活強度別エネルギー所要量表（kcal/日）から取ってきました。
一時出典は「最新食品標準成分表五訂版」社）全国調理師養成施設協会」とのことです。
糖質(炭水化物)は必要カロリーの0.7掛け、タンパク質は体重×1.1 で計算、脂質は残り物として計算しています。
生活強度の目安としては、ずっと家にいる人は1、 研究者やSE等で2、立ち仕事が多ければ3、重労働は4、と言ったところです。
詳細については、香川大学の医学部 保健師の健康教室にもっと詳しくてわかりやすい一覧がありますのでそちらをご覧ください。
原因判明。onclick=""だったのが原因だった。javascriptで""使ってるから''じゃないとだめっすね。
追記: なんで18歳未満がないかというと、どうやら体重対タンパク質の計算値が1.1じゃないらしいのだけど、適正値が見あたらなかったためです。もしご存じでしたら教えてください。よろしくお願いします。
Blogger で javascript (続) < > ってどう使うんだ?
onclickに仕込む場合、途中に<>があると投稿できないようです。
>なんかで代用がきくのかな？
以下はそのテスト。
結論 どうやらOKらしい。
>なんかで代用がきくのかな？
以下はそのテスト。
結論 どうやらOKらしい。
Blogger で javascript を投稿するには
Bloggerでjavascriptが投稿しづらい!!
今のところ見つけている方法は二つ。
一つは、onclick="func(); function func(){......." として、タグに埋め込むこと。
ただ、その場合は改行等しないで、見づらいコードをずらずらと書くことになる。
もっとも、Bloggerは普通のタグを使うにも、改行時に勝手に<br>を入れてくれるので綺麗に書けないのだけれど･･･。
他の方法としては、テンプレートにAdding javascript to Blogger postsで示されているコードを入れてしまう方法があるという。
ということで、以下はテスト。
# だったのだけれど、どうもダメっぽい･･･。
今のところ見つけている方法は二つ。
一つは、onclick="func(); function func(){......." として、タグに埋め込むこと。
ただ、その場合は改行等しないで、見づらいコードをずらずらと書くことになる。
もっとも、Bloggerは普通のタグを使うにも、改行時に勝手に<br>を入れてくれるので綺麗に書けないのだけれど･･･。
他の方法としては、テンプレートにAdding javascript to Blogger postsで示されているコードを入れてしまう方法があるという。
ということで、以下はテスト。
# だったのだけれど、どうもダメっぽい･･･。
[訂正] Java SunJCEのRSA暗号時のパディングはおかしくなかった
どうやらおかしくなかったらしい。
private key で暗号化した場合のパディングが、以下のようになるらしい。
01 FF{8} FF* 00 bytes(INPUT)
public key で暗号化した場合、普通にPKCS1 のパディングが使われていました。
ただ、頭の0x00が抜けていましたけれど。
これって飛ばしておいて良いのかな･･･。
ちなみに、Privateのときに使われていたのは、EMSA-PKCS1-v1_5-ENCODEっぽい?
こちらも頭の0x00が抜けていましたけれど。
巨大数値化した時点で、頭の0x00は無くなることから、これはこれで良さそうだ。
だとすると、注意しないといけないのは、復号プログラムを書くときに、先頭の0x00が無くても慌てないことなのか。
private key で暗号化した場合のパディングが、以下のようになるらしい。
01 FF{8} FF* 00 bytes(INPUT)
public key で暗号化した場合、普通にPKCS1 のパディングが使われていました。
ただ、頭の0x00が抜けていましたけれど。
これって飛ばしておいて良いのかな･･･。
ちなみに、Privateのときに使われていたのは、EMSA-PKCS1-v1_5-ENCODEっぽい?
こちらも頭の0x00が抜けていましたけれど。
巨大数値化した時点で、頭の0x00は無くなることから、これはこれで良さそうだ。
だとすると、注意しないといけないのは、復号プログラムを書くときに、先頭の0x00が無くても慌てないことなのか。
Java SunJCEのRSA暗号時のパディングがおかしい?
SunJCEのRSA暗号時のパディングがおかしい感じがする。
以下、Sun Java JDK 1.6.0_06での場合。
Cipher を "RSA/ECB/PKCS1Padding" で初期化。
暗号化するのは、"This is a pen.": as hex "54 68 69 73 20 69 73 20 61 20 70 65 6e 2e"。
cipher.doFinal(PLAIN_TEXT.getBytes())で暗号化して、
それを復号(BigIntegerで計算)した結果が以下の通り。
01 FF FF FF ・・・・・FF FF 00 54 68 69 73 20 69 73 20 61 20 70 65 6e 2e
う～ん、おかしい。前半部分はPKCS1 の paddingのはずなのですが、どうにもおかしい。
PKCS1 の padding であれば、以下のフォーマットのはず。
00 02 [^(00)]{8} [^(00)]* 00 54 68 69 73 20 69 73 20 61 20 70 65 6e 2e
SunJCEのパディングは・・・何だこれ? なんて言うパディングなんだろう・・・
って、その前にPKCS1Paddingを指定しているのに違うやり方してる時点でダメなんだけど。
以下、Sun Java JDK 1.6.0_06での場合。
Cipher を "RSA/ECB/PKCS1Padding" で初期化。
暗号化するのは、"This is a pen.": as hex "54 68 69 73 20 69 73 20 61 20 70 65 6e 2e"。
cipher.doFinal(PLAIN_TEXT.getBytes())で暗号化して、
それを復号(BigIntegerで計算)した結果が以下の通り。
01 FF FF FF ・・・・・FF FF 00 54 68 69 73 20 69 73 20 61 20 70 65 6e 2e
う～ん、おかしい。前半部分はPKCS1 の paddingのはずなのですが、どうにもおかしい。
PKCS1 の padding であれば、以下のフォーマットのはず。
00 02 [^(00)]{8} [^(00)]* 00 54 68 69 73 20 69 73 20 61 20 70 65 6e 2e
SunJCEのパディングは・・・何だこれ? なんて言うパディングなんだろう・・・
って、その前にPKCS1Paddingを指定しているのに違うやり方してる時点でダメなんだけど。
OpenSSL と RSA鍵 と Java、ついでに OpenSSHの鍵
OpenSSLでRSAの鍵ペアを生成して、Javaのアプリケーションで利用する場合のメモ。
OpenSSLでの鍵生成
出来たsample.keyには、private.key もpublic.key も一緒に入っている。
- - - - - -
public.key の抜き出し
- - - - - -
sample.key は the traditional SSLeay compatible format なので、Java の ライブラリが扱えるPKCS#8 foramt へ変換する。
- - - - - -
Javaのアプリケーションなどで自作したRSA鍵をOpenSSL で扱う場合は、"-----BEGIN PRIVATE KEY-----" 等がちゃんと合っているか注意。異なっていると読んでくれません。
- - - - - -
OpenSSH のid_rsa.pub は Java から読めないみたいだけれど、id_rsa は上記のsample.key と同じ形式なので、同様の手法で private.key, public.key を生成できる。
OpenSSLでの鍵生成
- openssl genrsa 1024 > sample.key (1024bitの場合)
出来たsample.keyには、private.key もpublic.key も一緒に入っている。
- - - - - -
public.key の抜き出し
- openssl rsa -in sample.key -pubout > public.key
- - - - - -
sample.key は the traditional SSLeay compatible format なので、Java の ライブラリが扱えるPKCS#8 foramt へ変換する。
- openssl pkcs8 -topk8 -in sample.key -out private.key [-nocrypte|(パスフレーズに空にする)]
- - - - - -
Javaのアプリケーションなどで自作したRSA鍵をOpenSSL で扱う場合は、"-----BEGIN PRIVATE KEY-----" 等がちゃんと合っているか注意。異なっていると読んでくれません。
- - - - - -
OpenSSH のid_rsa.pub は Java から読めないみたいだけれど、id_rsa は上記のsample.key と同じ形式なので、同様の手法で private.key, public.key を生成できる。