筆まめがオンライン化（ＡＳＰ化？）、ただいまサービス名募集中だそうな

筆まめがオンライン化されたものがでましたね。

筆まめオンライン　ベータ版
http://app.fudemame.net/index.html

　現在、自分のうちのプリンタで印刷した結果を報告するモニターを募集しているようだ。
　実際の正式版では、作った年賀状を注文できるそうだ（いまはベータなのでできない）

　つーことは、ＡＳＰみたいなもんかな？？
　たしかに、年賀状ソフト、新年にしか使わないからＡＳＰでいいのかも（＾＾）
　そうなれば、デザインも毎年変えられるわけだし。

　そうそう、デザインのキラーコンテンツとして、「やわらか戦車」が入ってるぞ！
　って、わかる人にしかわからないが。。。

　なお、このサービスの名前の募集しているそうだ。
　いい名前が思いついた人は、
　ここ、ここ　http://app.fudemame.net/campaign/campaign.html
　。。。でも、賞品は、わかんないようだ（＾＾）

メイドさんロボットを、東京大学やトヨタなどが共同で開発ってこと？

ここのニュース
東大とトヨタ・松下など７社、ロボットの共同研究を開始
http://www.nikkei.co.jp/news/sangyo/20060804AT1D0406N04082006.html

これだけなら、たいした話ではない。
しかし、問題は開発するロボットの内容なのだ。
（以下、上記記事より引用、ウィリアムのいたずらが編集）


2009年ごろまでに部屋の後片づけロボット
　13年ごろまでにベッドメイキングロボット
　16年ごろまでにはお手伝いロボット


おおおお、完璧です！
お部屋片付けや、ベッドメイキング、お手伝いとくれば、間違いない！
これは、「メイドロボット」開発ですね。

もちろん、家に入ると、「おかえりなさいませ、ご主人さま」といって。。
ぜひぜひ、プログラムを書き換える機能をつけて欲しい（ＷｅｂＡＰＩでサーバープログラムを書き換えると、いろんな指示ができるでもＯＫ）

そしたら、いろんな動きとかがカスタマイズできる。
（って、どんな動きをさせる気だ　＾＾）

---

　このかたも似たような指摘をしていますね。で、そこをみると、１０億／年ってかいてあったけど、１０億で、１０年ってことは１００億、１体２０万円、でその半分の、１０万円を研究開発費としたら。。。
　１０万個売ればいいってことですか。。不可能な数字ではなさそうだけど、そうだとしたら、もっと、フィギア部分にこらないといけません。

　バンダイ、コナミ、タカラトミー、海洋堂の協力も必要です！
　イメージ図は、こんなかんじ？
（思いっきり違うといわれそうだ。。正直、そう思う　＾＾）

---

　でも、その（一番上に書いてある）記事に

自分で判断して部品を組み立てていく産業ロボット

ってあるんですけど。。ってことは、このメイドロボットが自分で、赤ちゃんロボットを組み立てるんでしょうか（＠＿＠！）おおお、まさに小子化対策、でも、ロボットの子供が増えることでも、小子化対策なんでしょうか？
。。。と思ったら、違うみたいね。「産業用」って、かいてあった。

このメイドロボットが、子供を作るのではないようだ。。

しかし、とはいえ、期待できる開発です。メイドロボット。。。

って、なんか、とんでもない勘違いしてる？？
ウィリアムのいたずら（＾＾；）

auのケータイメールに、検索サイト等のＵＲＬを貼り付けないほうが「安全」ってこと？

ここのニュース
auのW42CAとW42Hに強制再起動する不具合
http://k-tai.impress.co.jp/cda/article/news_toppage/30484.html
によると、メール作成中に%nおよび%S,%81nのように半角数字が入った場合などが
はいると、W42CAとW42Hで、強制再起動（ＢＲＥＷなあなたに。。あの真っ黒になったあと、ちょっと時間がたってもどるあれみたいよ・・）するそうだ。

　そんなの、どーいうケースで起こるのかというのを、スラッシュドットの記事
auのW42CAとW42Hが%nと%Sの文字列で強制再起動
http://slashdot.jp/mobile/06/08/04/068204.shtml
のコメントで推測している。
そのケースは、（以下斜体は上記スラドのコメントより引用）

「凄いナンパ成功率!100%S●Xできちゃいます！」


まあ、これは、そーいうメールを開かなければいいが、こっちはやばい！


Shift_JISで「ゴメn」と入力
　http://www.google.co.jp/search?ie=Shift_JIS&q=%83%53%83%81n


つまり、検索をかけたときなんかで、馬（946e）
など、SJISの文字コードで、XX6e(XXは81など数字２文字）で終わる文字を
ＵＲＬに含んでいる場合、たとえば、ワロスコリアで、「馬」を検索すると
http://warosukorea.seesaa.net/pages/user/search/?keyword=%94n
となるのだが、こういうのは、危ないってことになるのかな。。。

もちろん、「馬」で終わるのが危ないんだから、
競馬も、競走馬も、海馬もあぶないだろう。

。。。って、結構やばくない？
パソコンから、このサイトみてえ！と、ケータイにＵＲＬ知らないで送っちゃったら。。
ちなみに、もう一個のＳは、１６進で、53、これで終わる文字っていうと、全が入る

auのケータイメールに、検索サイト等のＵＲＬを貼り付けないほうが「安全」ってこと？

なお、ＹＡＨＯＯやＧｏｏは、検索文字、ＥＵＣっぽいので、これらでは、だいじょーぶ（＾＾）

---

なお、スラッシュドットの考察ではprintfがらみと考えているが、
ウィリアムのいたずらの推測では、そうではなく、エンコードされている場合の文字の取り扱いではないか？

１．文中に%なんとかという文字列があると、エンコードしてしまう
　　あるいは、エンコードされた文字列と判断してしまう。
２．このとき文字列を勘定してデコード結果の長さを返す関数は、
　　％なんとかの文字は、ＵＴＦでエンコーディングされていると、
　　思い込んでいる
　　→だから、ＵＴＦコード=%E3%81%94%E3%82%81nは、正常にうごいた。
３．ところがＳＪＩＳで送ってしまうと、ＳＪＩＳは２バイトで、バイト数が違う
　　→結果として、ＵＴＦのつもりで、３バイト分でカウントすると、文字数は
　　　少なく勘定してしまう。
４．ここで、デコード結果の文字数を返す関数は、上記の少なく勘定した
　　値を返し、これを元にmallocした。
５．ところが、その後、実際の変換ロジックは、ＳＪＩＳをちゃんと
　　変換しに行った。
　　→そうすると、少なく勘定してあるとことに、ちゃんとした長さの文字を
　　　いれようとするから。。。

　メモリがたらなくなり、メモリーバイオレーションを起こす。
　ＢＲＥＷで、メモリーバイオレーションがおきると。。。
　ね、黒バックになって、つじつまが合う。

---

　ただ、この場合、nとSだけなるっていうことはない。他の文字でもなる。。
　なので、そんなことはないか。。

　とはおもうけど、まさか、他の文字については、まだチェックしてませんとか、
　そんなことは。。。

　ないよね。だいじょーぶだよね（＾＾）

---

　ま、理由ははっきりしないものの、意外と、この%数字nっていうケース、
検索結果のＵＲＬなんかを送る場合では、多いかもしれない。。。

　けど、そんな検索結果のＵＲＬをケータイメールで（に）おくることなんて、
　ないか（＾＾）；