810P 用に ubiqun の設定を行っているが，SoftBank 3G 携帯は，漢字コードが UTF-8 なので，ubiqun のバイト数カウントがうまくいかず，284bytes 送れるのに暫定的に 188bytes 毎に分割する設定にした，てのが前回までのあらすじ．
これだと，半角文字が含まれるメールだともったいないことになってしまうので，ubiqun を改造して，
・全角文字は 3bytes/1文字 でカウントする
・メールは 284bytes/1通 で分割する
を実装．
で，ubiqun_lib.pl に当てるパッチを作ったので，欲しい人はどうぞ．
バージョンは ubiqun_20030913 ベースで作ってます．
これ以外に，user_phone.dat の [PHONE1] セクションとかで
phone_type = jsky_longmail_free
mail_optimize_zenhan = no
mail_jcode_3g = yes
macro_header_from_2 = &MACRO_CUT($header{'FROM'}, 55)
macro_body_header_1 = $header{'X-UBIQUN-FILENAME'}
macro_byte_header = 100
macro_header_subject_2 = &MACRO_CUT($setting{'mail_split_now'} . '/' . $setting{'mail_split'} . ']' . $header{'SUBJECT'}, 40, $setting{'mail_jcode_subject'})に設定するのと，ubiqun_phonetype.dat の [JSKY_LONGMAIL_FREE] セクションに
mail_jcode_3g = noを追加すれば，うまくいくはず．(これつけないと config ファイルの仕組みがうまく働かなかった)
ポイントは，
・mail_jcode_3g = yes に設定することで全角文字を 3bytes でカウントする
・JIS コードの KI/KO を考慮する必要がないので mail_optimize_zenhan = no に設定する
・macro_byte_header = 100 に設定する事で，本文は 384 - 100 = 284bytes 固定
で，残りの macro_* 設定はお好みで．
810P 用に設定を行った ubiqun だが，どうも分割したメールが「続きを読む」になってしまう．調べてみると，メール全文が半角文字のときは確かに 284bytes だが，全角文字が入ると文字数が減る．ためしに全部全角文字を送ってみると… 188bytes!!!? (；´Д`)
ubiqun では JIS 漢字コードの KI/KO コードもカウントしてくれるので，全角・半角が混じっていてもこれまでも何の問題もなかった．そもそもソフトバンクの仕様はどうなってんのかねー? と思って探してみたら，見つけたのがここ．
ここを見ると本文は 284bytes 固定で，前回の推測が正しかったことがわかった．でもここにもはっきり書いてあるのに，全角メールが 188bytes しか受信できないのはどういうことよ ｵﾘｬ(ﾉ-_-)ﾉ ~┻━┻･..｡;･'
とふと目にとまったのが「対応文字コード」．ISO-2022-JP (いわゆる JIS コード) と，UTF-8…? UTF-8 では全角文字が 3bytes/1文字．もしやと思って計算してみる．
188 / 2 * 3 = 282 ≒ 284
漢字コードは UTF-8 かよ… 効率が悪い漢字コード採用するなんて，SB のシステム作ったやつはアホですか．
とりあえず暫定対策としては，mail_byte = 188 で「続きを読む」は回避できるが，188bytes なんて細切れ過ぎるよ… 3G 携帯に変えたの，失敗だったな（゜ーÅ）ほろり
SoftBank 携帯の 810P に対する ubiqun の設定を行った．
ubiqun とは，長いメールを受信無料サイズに分割・転送して全文をタダで読めるようにするメール転送ソフトのようなもので，これを自宅 Linux サーバに仕掛けて使っている．そもそも SoftBank の前身である J-PHONE を選んだのも，メール 384byte まで受信無料だったから(笑)
で，けっこう古いこのソフト，SoftBank 3G 用の設定があるはずもなく．user_phone.dat の [PHONE_1] セクションなんかで以下の設定をするとうまくようだ．
phone_type = jsky_longmail_free
# ubiqun_phonetype のオーバーライド
mail_byte = 284
macro_header_from_2 = &MACRO_CUT($header{'FROM'}, 55)
macro_body_header_1 = $header{'X-UBIQUN-FILENAME'}
macro_byte_header = 0
macro_header_subject_2 = &MACRO_CUT($setting{'mail_split_now'} . '/' . $setting{'mail_split'} . ']' . $header{'SUBJECT'}, 40, $setting{'mail_jcode_subject'})昔の J-PHONE 時代の端末だと，「From アドレス + Subject + 本文 + α」が 384bytes に分割しなければならなかったので，macro_byte_header で From や Subject のバイト数をカウントするための式を設定し，本文をその分少なく分割する．
3G 携帯では，調べた限り Subject とか関係なく，本文が 284bytes になるようにすればいいらしい．なので mail_byte = 284 と macro_byte_header = 0 さえ設定してれば，あとはお好みでいいはず．
5年間w 使い続けていた携帯 T-08 を，ついに機種変して 810P Get!!
T-08 も QVGA で，携帯では音声通話とメールしか見ないし，T-08 のままでも別になんら不満はなかったのだが，ホワイトプラン + 新スーパーボーナスで今の支払い +\200 x 24ヶ月で機種変できる というのを知って早速機種変しに行った．
だが実際はそんなに甘くなかった．
まず事務手数料で +\1,995
新スーパーボーナスの最初の 2ヶ月は割り引き対象外なので +\1580 x 2
まぁここまでは，Web ページ見れば載ってるのでいいとしよう．問題はここから．
なんか，W ホワイトプランとパケ放題とあといろいろオプションつけないと，頭金 \5,250 取るといいやがる．んなもん，どこにも載ってなかったやんけーーー (- -# むか
とりあえずそこらへん付けて 1ヶ月ではずしたほうが安かったので，その分の料金が \980 + \1000 くらい．はぁ．なんかこういうのって，買う直前までわからんからなんか納得いかんよなぁ．
あとショックだったのが，以前は +\150 の E メールサービスで事足りていたのだが，3G 携帯になってからは \315 の S! ベーシックパックに入らないとだめなのね… たかが \150 だけど基本料金が up するのはなんかやだなぁ．
久々の PSP データロガーネタ．
今のデータロガーには，LED によるデジタルメータとシフトアップインジケータ機能もついているんだけど，よく考えたら PSP にスピードも表示させてるし，もしかして LED ディスプレイいらねぇんじゃねえの? と思い始めた．
でも PSP のほうにシフトアップインジケータは実装されていなかった (構想はしていたけどズルズルと先送りに…) ので，これを期に実装してみた．
で，デモ動作を撮ってみたのが下の動画．(デモ動作は 0:46 あたりから．別の目的で作った動画なので，前半とかスル～でヨロ)
まあ見た目的には OK なんだけど，昼間でもシフトインジケータが点灯しているのに気づくほど輝度があるかどうか (真剣走りしてるときは PSP 注視する余裕ないので) と，データロガー本体からシリアル通信でデータを受け取ってる関係上タイムラグが発生するので，実際の Eg 回転数と表示とのズレがちょっと心配だな．
でも，もし LED を撤去する事ができたら，すっきりできていいかも．
MAPLUS の足跡を GoogleEarth に表示する方法は割りと挙がってるんだけど，轍 (GoogleMaps) に表示する方法は，カシミールとかで変換する方法以外挙がってなさげなので，タダでやる方法を試してみる．
轍自体には，すでに NMEA-0183 をリードする機能はついているのだが，測地系が WGS84 を想定しているので，MAPLUS の足跡 (Tokyo測地系) を WGS84 に変換するため，まず GpsLogCv で変換する．
gpslogcv -ITOKYO -INME -TNME -DW -SA -oR 入力ファイルとかで．
しかし，GpsLogCv が出力した NMEA は，なんかセンテンスが足りないらしく轍でリードしようとすると「フォーマット違うぞｺﾞﾙｱ」と怒られてしまう．
ここで登場するのが，GoogleEarth の時にも使用する gpsbabel．
gpsbabel で NMEA→NMEA に変換する(笑) ウチの場合はこれで轍にリードできた．
動作的には GoogleEarth に表示させたほうが断然速いんだけど，ツーリングの軌跡を仲間内で共有するときとかは，Web ブラウザで見れる GoogleMaps のほうがありがたいかも．
って書き終わってから気づいたけど，MAPLUS 公式サイトの足跡表示を使えばいいのか?(；´Д`)
Linux サーバを立ち上げている人なら誰でも直面する問題，セキュリティ．Linux ではやたらとログが残るので，どこからどんなアクセスがあったかが詳細にわかるので，気になりだすと仕方がない．
特に，中国・韓国あたりからのアタックがひどい．スパムメールの踏み台にしようとしてるのか，メールサーバーに何度もアクセスして失敗した跡がある．
あー，俺別に中国人・韓国人に友達いないし．そんなとこからのパケット無条件に捨ててくれていいよ．
と同じ境地の人がいるはずと思ってググって見たら，いたよ…↓
http://www.hakusan.tsg.ne.jp/tjkawa/lib/krfilter/index.jsp
これは iptables を利用して，中国・韓国・東南アジアからのパケットを無条件でポアするフィルタ．
3日ほどで 221件のアクセスが引っかかった↓
Chain KRFILTERED (2247 references)
pkts bytes target prot opt in out source destination
221 10768 DROP all -- * * 0.0.0.0/0 0.0.0.0/0変なアクセスログがすっきりヽ(´ー｀)ノ
自宅サーバーのアパッチで，クッキーを食わせる cgi を立ち上げていたところ，クライアント PC のブラウザ (IE) でどうやらクッキーが保存されていないことに気づいた．
他のサイトではクッキー OK なので，IE はシロだと判断して，Apache の設定を疑っていたのだが，最初のこの判断が間違っていておおハマリしてしまった．Apache の設定をいくらイジっても改善しない．
ここで，確か IE にはゾーンごとにセキュリティの設定が別々に設定できたよな? と思って一番ゆるい設定にしてみたら，クッキー食えました．犯人は IE かよ…orz
で，さらに詳しく調べてみると，サーバの URL は外から見ると http://naruto.sytes.net/ だが，ローカルでアクセスするときは，http://dds_svr/ とマシン名だけでアクセスしていた．で，IE は，URL にピリオドが何個ついているかもゾーン判定の材料にしているようで，後者でアクセスするとなぜかキツイ制限になってクッキーが拒否されていたようだ．
でも普通，ローカルアクセスのほうが制限がゆるくできると思うのだが…．
きっかけは，コメントスパムが大量に来るようになったこと．
大量のユーザに被害が出ていることから，犯人は単純なスクリプト攻撃を行っていると思われるが，こんな単純な攻撃にすら何の防衛手段もとらない Yahoo のアホアホさに嫌気がさした．
ほかにも不満点はたくさんあって，制限されまくった html タグとか，スタイルがまったくカスタマイズできないとか，アクセス解析ができない ( JavaScript も書けない ) とか，挙げれば切がない．最初の blog サイト選択の時点で間違ってたよ俺．
なので，blog サイトの乗換えを決定!
といっても，自宅サーバに立ち上げた blog サイトだが．
http://naruto.sytes.net/~yoshi/blog/diary.cgi
自宅サーバにした理由は，blog のデータがローカルに保存できるので，データの乗換えが容易なことと，フリーの blog cgi スクリプトを改造すればカスタマイズが無制限であること．
というわけで，Yahoo ブログの更新はこれにて停止．
Yahoo ブログのデータもスクリプトでコンバートして，新しい blog サイトに全部移動できてるみたい．