2013/01/18

Ubuntu12.04でMozc。aptで入れれるようになってた・・・!


なんか、Mozcがaptで入れれるようになってた!

ヤバイ。早速入れた。aptの呪文を唱える。

apt-get install ibus-mozc

50.3 MB。数分で完了。今、このエントリはMozcで書いてるけど・・・うん、日本語変換すごいいい!

実はLinux版ATOKであるATOKXやX3は買ってて、たまに入れるけど再度インストールしなおすことも結構多くて、結局は基本的にAnthy使ってた。

いまは開発用途や普段使いにはUbuntuが使い慣れているし必要十分なのだけど、正直、日本語変換だけはキツかった。Mozcならいける!

・・・またGoogle先生依存が拡大したな。。でもMozcこれ( ・∀・)イイ!!顔文字とか辞書で変換出てくるよwww

中華系androidの中華フォントでは、表示できない日本の文字がある点に注意!



安価に手に入る、いわゆる「中華pad」など、中国系のandroid端末は、フォントが中国のだったりする。

で、気温botのツイートをandroid端末で見てて、「〜」が欠けていることに気づいた。おそらくコレ、中華系フォントに「〜」っていう文字が無いために生じてる問題だ。

たぶん日本でも、安価に手に入る中華androidを使っている人は結構いると思う。そういう人もおそらくこのフォントの問題に直面してるのではなかろうか。僕自身使ってるやつが中華のだったので気づくことが出来たのだけど。フォントを日本のにするにはroot化が必要で、結構たいへん。一部機種の場合は簡単にフォントを変更できる場合もあるようだが、いまさっきそういうソフトを試してみたところ駄目だった。簡単にフォントが変えられると問題が色々生じることも分かるのだけど、それゆえに出来ればgoogle先生にOS公式とかででも良いので対応してほしい感じ。

なので、日本で中華padを使ってる人も割と居るハズなので、中華系フォントで表示できない文字は使わないノウハウ・・・みたいなのが必要かもしれない。Twitterクライアント側とかで、使用する文字をチェックして、機種依存文字やフォントで表示不能な今回のみたいな文字に対しては、「表示できない可能性がありますがよろしいですか?」みたいなアラートが出せれば、特に公式Twitterのツイート担当者にとっては、親切な機能かもしれない。

それにしても、今日、文字コード系のセキュリティ部分を読んでたので、文字コード系のエントリを書いてたタイミングなので、なんだか奇遇。

初めて文字化けに直面して以来15年は経つのかな

ネットにつないでホームページを見るようになってスグに、メールやホームページが文字化けする現象に直面することで、「文字コード」は認識するようになった。

以来、Perlでスクリプトを改造したり簡単なのは書けるようになり、その際にも文字化けの問題はついてまわった。jcode.plなんてのがあったり、歴史的な時代を経てきているなぁと思う。

・・・で、今の今まで、英語圏とかでは「ASCII」が主流なんだと思ってたんだけど。どうやら7bitアスキーを拡張してフランス語やドイツ語などの文字を加えた8bitのISO-8859-1(Latin-1)というのが主流らしい。Google先生など、最近の流れはUTF-8とかのunicodeなのかと思っていたけど、このあたりはどうなのだろう。日本でも、WindowsのSJISじゃなくてEUC-JPでやるべきだよね、なんて感じだったのはもう昔の話で、今はUTF-8にだいぶ移行してるのだろうか?

文字コード周りで、単純に表示がバグる、、、というのはつまり個人的にも最初に直面した問題で、しかしある意味軽微な問題であり、深刻なのは文字コードの違うデータを入力することによりWEBアプリにセキュリティ上の問題を引き起こす、、、という点なのだと知ったのは比較的最近の話・・・そう、JI-JOEさんのセキュリティ本で知った感じだったと思う。

Perlをいじり始めたのは2000年夏で、Perlを少し書けるようになったのは2001年初頭。PHPを書き始めたのは2003年夏頃。・・・以来、PHPで色々書いてきたけど、PHPとはかれこれもうすぐ10年になる。体系的に勉強したりみたいなのではなく場当たりで勉強してきたので、未だにオブジェクト指向とか色々な書き方には疎いし、セキュリティの勉強も甘かった。

実は、僕自身、実際これまで、WEBアプリへ不正なデータを流し込まれた経験がある。時期は2005〜6年頃だったろうか、あとになって気づいたのだけど、記録データのテキストファイルを開いてみたら、一部おかしな文字列が挿入されていて、その時は何故か分からなかったのだけど、後々、それはセキュリティ的な問題で受け付けていたデータからセキュリティを脅かされた記録だったっぽい・・・とだけは分かった。数百人分のメールアドレスなどの個人情報が絡むデータだったので、僕が気づいていないだけで、そのデータはその時悪用された可能性はゼロじゃなかったりする。ちなみに不正に挿入された文章はいわゆる2ちゃんねる用語の入った文章だったので余計に不気味だしやはりクラックだったのだなと今は確信してる。もし、これ関連で、メールなどで何かが起きていたとしたら申し訳ないし、そういうクラックをされていた事実もあるので、それ関連であれば犯人が他に実際居たのだということは認識してほしいし、スクリプトが未熟だった点をお詫びするしかない。

今後の話。セキュリティに関しては、入力値を受けとって何かをするWEBアプリをこれから作ろうって思ってるので、まず勉強しとこうと思っているのが今の状況。少しづつだし、頑張った先に結果があるのか、継続可能で幸せに繋がるのかは不明なのだけど、とりあえず頑張る。

開発・運用におけるログ記録方法

開発時のデバッグ等や、実運用時の問題発生時の確認等のために、ログが重要という話。

実際、場当たり的に必要が生じた時にテキストファイルに必要に応じて必要なフォーマットで記録して確認してたのが実情で、所謂運用というのの経験が浅いため、まだ自分なりの型がなくてどうすればいいのかなぁというのが現状。

で、log4phpというのがあるらしいのだが、設置・設定が面倒っぽくて、横道的な設定が既にやや複雑なのがパッと見うーんと感じてしまった。むしろ、PHPの関数にあるerror_logをうまく使えば対処できそうじゃないかな?とパッと見で妄想してる段階。error_logは使ったことない。

でも、ここ1年、実運用時も含めた開発期間のデバッグはログが結構重要だと実感しているので、どうやってログをとったものか・・・と思っているところ。

間もなく徳丸本も残すところ100ページ程度と終りが近づいてる。凄い勉強になったし、何度か読まないとなと思ってる。

農薬代替で「定期的な水浸し」システムってどうだろう?

なんか起きてしまってて、寝れなくてボンヤリ妄想を繰り広げてる。

で、思ったのだけど、紫外線とかで野菜などの害虫退治がデキないだろうか。

あるいは、害虫は虫だから、酸素が無い状況=植物なら二酸化炭素あればいい、
みたいな状況なら害虫は死滅してしまい植物には好環境、
1日何回か二酸化炭素濃度をバッチ処理で極めて高くするとかありそうな
コストが見合わなそうな、
でも他産業と組み合わせて何かありそうな。

気圧を極めて高くしたり、低くしたりすると、植物は大丈夫だけど害虫には無理な条件がありそうな気も。
コストはどうなのかわからないけど。

あ。水浸しならどうだろう?安価だしバッチシステムは構築できそう。
10分くらいなら植物とか完全水没してもたぶん大丈夫だよね?でも害虫は息ができなくて死ぬよね?
定期的に水没する装置にしておいて、機械的に水没を繰り返すようにすれば害虫駆除できそうな。

既に可能な奇策・・・巨額額面通貨の発射スイッチ

ロイターでのこのコラム、興味深い。

「コラム:アベノミクスに残る奇策は100兆円硬貨か=村田雅志氏」
http://jp.reuters.com/article/jp_column/idJPTYE90G06O20130117?feedType=RSS&feedName=jp_column&virtualBrandChannel=13487&utm_source=twitterfeed&utm_medium=twitter&sp=true

現行の法律の範囲内でも、政府レベルの判断で記念通貨という形でもって、一瞬で大量の通貨を発行して市場に流し込めるとは。。アメリカでも、日本でも、可能。

巨額な額面が記載された紙切れもしくは硬貨によるテロ行為だ。
それこそ言われている「通貨戦争」がここまで来ちゃった感。

本当に奇策だし、踏み切るかもしれなさげ。

しかし、核のスイッチみたく、一方が発射してしまったら、応戦しないとヤバい感じかもしれなさげなような、各国間の調整のために混乱が生じた際の収拾のために全世界がやらないといけないのかもしれなくなるかもな。

それがどんな結果をもたらすかは、やってみないと分からない感じで、怖すぎる。
通貨が安くなる状態を超えて、流通できない状態になったりするのだろうか。

その際は、通貨の価値が暴落してジャブジャブなことを知らない人に、ジャブジャブの通貨を得た人がものすごく不合理な取引を持ちかけたりもあるのだろう。「通貨価値暴落」は、現実にそうなったときどうなるかというと、緩やかに目に見えていくのだろう。

いずれにせよ、確実にインフレが待ってる。
たぶん相当ヤバいインフレ、もしくは通貨の流通不能な状況。

もう3〜4年くらい前から来るだろうなって思ってたけど、本当に現実味を帯びてきた感じがする。
近所の書店でも、以前はちらほらしかなかった通貨暴落系の書籍が、棚1スパン上から下までそれ系みたいなのを先日見たときは、もう来てしまってるなぁとしか思えなかった。

本当のホントに、こんな時代が来るとは、、、 生きていると色々なことが起きるものだ

人類は、陸・海・空、知らないことまだまだ多数

地中深くのこと、人類はまだよく分かっていない
地下を掘り生活空間を作ったり交通システムを作ったりしているし、
水はじめ各種の資源を掘りあげたりしてるけど、その影響も分かっていない

海、特に深海については分からないことばかり
海洋を動きまわる生物の生態は表層に生きている生物でもわかってないこともある

空・・・ 飛べるようになったのはまだ最近の話
飛べる虫や鳥を知ってるけど、例えば極めて高度の高いところはどうか
そして果てなき宇宙

僕はかなり解明が進んだ時代に生まれて、人類の先輩方が築き上げてきた叡智の恩恵を受けている
それでもなお、解明が進んでいない分野が多数あって、しかしこれから解明が進んでいくのだろう

人類って凄いし、これからも凄いことが出来るだろうに、時々戦争などで自らを破壊して。
直近、命を相当危機的なことにしてしまう戦争の危うい状況も、経済が危うい今 危ぶまれて。

僕の何か、その人類の積み上げに貢献できることが出来れば素敵なのだけど。

2013/01/17

NULLバイト攻撃/最初と最後の正規表現

これまでPHPでアプリを作ってて、多様なユーザの入力文字列に対する処理で、想定と違う結果になることが度々あった。

NULLバイトのことを知ってからまだ日が浅いけど、どういう関数を使えばいいのか(バイナリーセーフで?)とか、パターンマッチの方法とかがまだアヤフヤなところがある。

で、今、過去の不可解な挙動に対することも含め、合点がいったのが、正規表現でのデータの最初と最後をどう表現するか・・・という点。

正規表現の書籍を読んで、「^」が最初で「$」が最後、というような認識でいたのだけど、少し注意すべき点が。この「^」と「$」は改行までの意味であり、データ全体ではなかった。データ全体での最初と最後は「¥A」「¥z」だった。また、最後の行の行末の意味が「¥Z」となるようだ。・・・確かに^$に対する説明を改めて読むと「行頭」「行末」とある。でも処理対象データは複数行に渡る場合も渡らない場合もあり、、、そのあたりで、以前想定と違う挙動で対処できてなかったぽい。

・・・ということで、例えば1〜5文字の英数字を正規表現で表現すると

'/¥A[a-z0-9]{1,5}¥z/ui'
'/¥A[a-zA-Z0-9]{1,5}¥z/'

など、となる。

u修飾子はUTF-8エンコーディングを示し、i修飾子は大文字小文字を区別しないことを示す。
また、¥dや¥wは全角も含む点などに注意で、全角数字など含めたくない場合は明示的な[0-9]とした方が吉と。

WEBアプリのセキュリティ問題も勉強中な状態で、正規表現もまだアヤフヤ多数。奥の深いことではあるけど一歩づつ。

2013/01/16

PHPのstream wrapperやe修飾子など...怖


PHPのstream wrapper。そのdata:ストリームの危険性。

前からPHPのマニュアル他で稀に目に入ってくることはあったけど、WEBアプリのセキュリティに関わってくるとのことでビックリ。見てみたら確かに危ない系の機能が沢山。それを使って何が出来るのかイマイチぱっと見で理解できないのだけど、ヤバいことに繋がりそうな匂いはプンプンする。

とはいえ結局、得体のしれない入力値を不用意にスクリプトに流し込むことでセキュリティが脅かされるという点は変わらない部分なので、その軸をしっかり意識して丁寧に作らないといけないなと思う。

PHP:サポートするプロトコル/ラッパー
http://php.net/manual/ja/wrappers.php

===

また、preg_replace関数などで、「e修飾子」を使うと、文字列をevalで評価して実行デキてしまうというのも全く寝耳に水、結構気軽にpreg_replaceは使うので、うっかりセキュリティ上の欠陥を作る可能性大。

===

ゼロ除算の問題、「数学としてあり得ない」ということは割と最近(汗)知ったのだけど、計算機の処理上で問題を起こす場合もあるらしく、そこまでの危機意識が無かったのでセキュリティ・あるいは予想をしない解や結果を生むという認識で注意すべきなのだな。。。

この問題に関しては、色々と考えてしまう話で、みんなもコメントしたくなる話でもあって。(だからTwitterとかでこの話を以前も見かけたんだと思う)。やはり、完璧に定義されている数学の中にあっても、加減乗除の上で0が発生しその0が問題を解答不能らしき状況にしてしまう点は、予め間違いが起きることによって物事が生まれたのに違いない的な妄想広がりになっていく訳で。

しかし・・・・ x/0=x/0 ← もしかしてこの式だけは等号で成り立つ?
それと・・・・ 無限大=ゼロ ← もしかしてこれも言える、のか?
くわえ・・・・ ゼロ除算は最初に解く、という条件をつける・・・とか・・・



Wikipedia中のグラフ y=1/x は、真ん中で下から上につながって一本の線になっているのではないか?
http://ja.wikipedia.org/wiki/ゼロ除算

・・・と思ったら、よく見ればバースカラ2世という方が「n0 = ∞」と、そういう感じの定義をしたようで、しかしパラドックスがあるようだ・・・
・・・でも「有限の数をゼロで割ると(ゼロ除算)無限大になる」という考え方をしたとのことのようだ・・・「無限大=ゼロ」という定義ではないようだな・・・
とにかく、人類の歴史に凄い貢献を残した超偉大な人なのは間違いない・・・

とりあえず、やっぱゼロ除算よくわからない。・・・数学難しい・・・!

===

そしてPHPと件の本。そんな機能が!?っていう部分でホント勉強になる。ひとつひとつ頑張ろう。

期せずしてandroid開発者登録完了



昨夜、カード会社の支払情報を見ててびっくり。GooglePlayの支払いが1/9に発生してた。確かにGoogleアカウントをいじってて開発関連にもアクセスした。でも何かをどうかしたのかよく分からないのに決済が発生してた怖すぎる。

Twitterでも書いてた通り、自分的には昨年6月には開発者登録しておいたつもりで、円安反転してくるだろうな〜 そろそろこの円高水準で$支払うべきだろうな〜と思って支払いをしたハズのつもりだったのに。

その後、進まない改革・財政破綻が見え隠れで危険っぽい円安方向に為替が振れていき、金融政策も「円を刷るよ〜」になって一気に円安が90円近くまで進んだこのタイミングで、意図せずandroid開発者登録が完了してしまい、支払いが発生してたとか悔しすぎる。さすがに90円くらいまで一気に最近来てるから、しばらくこのへんをウロウロするか、多少円高方向に一時的な反転もあるのかもな感じのタイミングかと思われ・・・・。

・・・Twitterに、自分の為替に関する意見とか書いておいて、気分的には救われて良かった。結果論だけど予想通りだったし、為替変動分で損した気分なのも実害としては250円程度と比較的少額だし。

そして結局androidの開発者登録は期せずして済んだことになるので、制作して販売とかちゃんとやり遂げたい。PHP/WEB系との連携とかで色々おもしろいものは作れる・・・ハズ。

2013/01/15

WEBのセキュリティ対策



徳丸本、少しづつ読んできて、やっと半分を過ぎたあたり。

WEBアプリのセキュリティ対策で、色々自信が無かったのだけど、網羅的に解説されている内容を読み進める中で、なんとか頑張れそうな気がし始めてる。

でも奥の深い話なので、何度も読み返し、色々な知識にアンテナを張って勉強し続けて行かなければならない部分。
関連する知識で知らなかったことも出てくるので、ホント勉強になる。

unixシェルの複数コマンド記法

; コマンドを続けて実行
& バックグラウンドとフォアグラウンドで実行
&& 最初のコマンドが成功したら次のコマンドも実行
|| 最初のコマンドが失敗したら次のコマンドを実行
' ' バッククオートで囲った文字列をコマンドとして実行
| 最初のコマンドの出力を次のコマンドの入力として実行(パイプ)

色々あるなぁ..。;しか普段使ってない。&は見たことあるし稀に使うこともあったな。
|もたまにある。>とかみたく稀に使うこともある。

他は知らなかった..。

Amazon