がるの健忘録 このページをアンテナに追加 RSSフィード

2008-02-07

[][]多分よくないのは「腰掛けること」

元ネタふたつ。

ひとつめはここ。

http://itpro.nikkeibp.co.jp/article/OPINION/20080206/293139/

やっぱりPHPがイイ?

とりあえず気を引いた部分。

個人でも企業でも手軽に利用できる言語として,PHPプログラマが増えているわけだ。

うん「手軽に」ね。

基本的な文法などはC言語に似ているが,変数の決まりごとが緩いせいもあって,サクサクとプログラミングができた。まさにイイ言語だ。

「サクサクとプログラミングができた。」…うんこれだけなら「ステキだなぁ」と思うのだけど。

PHPで構築するアプリケーションはWebアプリケーションなので,作ったアプリケーションを日本中あるいは世界中から,Webブラウザを通して利用できる。しかし,不特定多数のだれからも使ってもらいやすいメリットと引き替えに,世界中の犯罪者から攻撃されてしまう恐れがあるというデメリットが生じることは仕方ない

「仕方がない」の一言の裏側にある事象の玉虫色さ加減とかその深度とかに興味があるなぁ。

ところが,ある米国の調査結果では,PHPで発見されたバグがほかの言語よりも多いというレポートがある。

この「バグ」って、言語のバグ? それともPHPでWebアプリケーションを構築した際にもりこんだセキュリティホールの類?

PHPは,プログラミングを始めたばかりの人でも,Webアプリケーションが構築・公開できる点は確かに「イイ!」。ところが,セキュリティホールの有無や,変わった仕様に頭を使わせる点は「イイ?」のだろうか。もちろん,これからもPHPユーザーは増えていくだろう。今後は,ユーザーがわずらわしいことを考えずにプログラミングできるようなバージョンアップを期待したい。

「ユーザーがわずらわしいことを考えずにプログラミングできるようなバージョンアップ」ってどんなものを想像してるんでしょ?

割と本気で不明。


総じて。「ITProという(少なくとも一般の人にとっては)それなりの技術サイト」で「日経ソフトウエアの名前を横につけた記者が」書く内容にしてはちょっといかがなものかなぁと。


もういっちょ。こっちは、コメントに対して返答してくださった ID:tek_koc さん。

大本は http://d.hatena.ne.jp/tek_koc/20080205/1202185452 の記事への私のコメントからかえしてくださいました。

利用者側からしたら、大切なデータなんてよほど信頼できるところ以外には(例え注意書きが無くても)入力すべきではないなと思ってます。世の中の初心者全てが注意書きをしても、悪い悪い大人はフィッシングとかでデータをちょうだいしちゃうので。

だから、入力しちゃった以上はわりと自己責任な感が強いよなぁと思わざるを得ないです。

概ねtrueだと思うです。ただ、その認識が「一般に広く知れ渡っているのか」というと非常に疑問ですが。

でもって更に僕個人は、セキュリティを万全にすることも含めて趣味のプログラムかな、と思ってます。遊びは本気でやった方が楽しいというか、趣味だから別にセキュリティいいよねーってのはどうなのよ、と。

ふむりなるほど。

自分がわりあい「趣味と仕事の境目があいまい」なのであまり深く考察していなかったのですが。「趣味だから別にセキュリティいいよねーってのはどうなのよ、と。」これは確かに腑に落ちる発言です。

多分…私が持っているのは、この文章を前にもう一度考え直すと。「公に出すのにセキュリティいいよねぇってのはどうよ?」なのだろうなぁと思います。

見る角度が違うだけで、多分考えていることは変わらないと思うですが。

端的に言うと、責任(能力)の有無なのかなーなんて頭がお花畑の僕は気軽に考えてしまいます。

初心者が警告文書くのに同意する上でそもそもデータ入力させる全てのサイトが警告すべきだと思いますし、入力する側は初心者だろうが企業だろうがあまり大事なことは書かない方がいいかなと。書いても良いけど、企業の場合なら責任とってくれるかもしれないだけで、流出しないわけでもないよ、と。

わはは…お仕事している身としては痛い部分も多々(苦笑

ただ。企業の場合、責任能力のほかに「責任回避能力」とか「詭弁能力」っていう逆側のスキルもあったりするのですがB-p

おそらく現状において「入力する側は初心者だろうが企業だろうがあまり大事なことは書かない方がいいかなと」が一番正しいのではないかと。


ただ…これをクライアントに話をして、まぁ首を縦に振ることはないだろうなぁと(苦笑

ID:tek_koc さんは、私の「「趣味で作ったから危ないかもよ〜」ってちゃんとサイトに告知してあげないと」という発言に対して

それとは別に、なるべく書くべきだとも思います。これは作る側。

というか、初心者だけじゃなく自称上級者の人だって警告すべきだと思うんですよ、ネット初心者のためにも。

とおっしゃってますが(追記。この発言はおいら的には普通に腑に落ちます)。

別のタイミングで、リアルで同じ話を「技術系の会社やっているひと&技術者さん」にしたら、苦笑いしながら「書けるわけないじゃないですか」と言ってましたし。

おそらく。大抵の企業&「サラリーマンとしての*1技術者'sは「脆弱なのはわかってるけど言わなきゃわからないし被害くらうの俺らじゃねぇしいいじゃん」というあたりが本音なのでしょう。残念なことに。


まぁ結局…「自己防衛しようね」で終わっちゃう話ではあるのですが…そこで終わると色々と技術者的に「どうなのよそれわ」とか思ってしまうので。

とりあえず私的には、やっぱり「公開するならそれなりに。お仕事するならそれなりに」といい続けてみたいかなぁと。

*1:或いは向上心のない、学ばない

2008-02-05

[][]やっぱり変だよ orz

んと。偶然

http://php.benscom.com/manual/ja/function.get-defined-vars.php

なる関数見つけまして。

get_defined_vars

(PHP 4 >= 4.0.4, PHP 5)

get_defined_vars ― 全ての定義済の変数配列で返す

説明

array get_defined_vars ( void )

この関数は、環境変数サーバ変数、get_defined_vars() がコールされたスコープ内でユーザが定義した変数を含む、全ての の定義済の変数のリストを有する多次元の配列を返します。

わりと何も考えず、とりあえず動かしてみたですよWeb経由コンソール経由双方で。

$s = date('Y/m/d H:i:s');
var_dump(get_defined_vars());

結果。………いいから環境あるヤツやってみ腰ぬかすから。


コンソール環境の場合の例。

$ php t.php > a
$ ls -la
24095 Feb  5 nn:nn a

Webの場合。ファイルで保存すると…22091バイト。


………ねぇねぇたかがあんなプログラム変数領域表示で「24kってどゆこと?」


["GLOBALS"]["GLOBALS"]["_ENV"]

["GLOBALS"]["GLOBALS"]["HTTP_ENV_VARS"]

["GLOBALS"]["_ENV"]

["GLOBALS"]["HTTP_ENV_VARS"]

["_ENV"]

["HTTP_ENV_VARS"]

とかあって、多分明らかに同じデータだし。


["GLOBALS"]["GLOBALS"]["_SERVER"]

["GLOBALS"]["GLOBALS"]["HTTP_SERVER_VARS"]

["GLOBALS"]["_SERVER"]

["GLOBALS"]["HTTP_SERVER_VARS"]

["_SERVER"]

["HTTP_SERVER_VARS"]

も多分以下略。


でもねでもね

いちばんはぢめのひょおぢがね

array(15) {

["GLOBALS"]=>

&array(15) {

["GLOBALS"]=>

&array(15) {

["GLOBALS"]=>

*RECURSION*

["_ENV"]=>

ってなってたの

だから きっと「全部メモリ上で展開されている-検閲削除-なプログラミング言語」だなんてことはおもわないの

でもね…でもね…


やっぱこの言語変だよ仕様おかしいよ発想狂ってるよ orz


あんまりにも今更にすぎるんだけど。

「まぁかかわっちゃったしPHPしばらく気合入れてホゲるか」思ってやってきたけど…そろそろ乗り換え時なのかしらん orz

# 結局技術検証なのに愚痴だよちくしょぉ orz

[][][]邪悪だ…

多重継承。危険で、でもとても甘美な響き。

多分いまだ議論尽きせぬところかとは思いますが、それは「可能であればこそ」。「多重継承が出来ない」のなら、そも議論の俎上に上がることすらありません。

例えばPHPとかね。


え?

そんなあなたに耳寄りな危険情報。

http://php.benscom.com/manual/ja/ref.objaggregation.php

オブジェクトの集約/合成関数

-中略-

オブジェクト指向プログラミングでは、簡単なクラス (または インスタンス) を組み合わせてより複雑なクラスを作成するということが 一般に行われます。これは、複雑なオブジェクトオブジェクト階層を 構築するための柔軟な方法であり、多重継承と同等のことを動的に行う 機能を有します。 クラス(またはオブジェクト)を合成するには、合成される要素の間の 関係により関連(Association)と 集約(Aggregation)の 2 種類の方法があります。

関連は、独立に構築され、外部から 可視の部分を合成したものです。クラスまたはオブジェクトを 関連づける場合、各クラスは関連するクラスへのリファレンスを保持します。 複数のクラスを静的に関連づける場合は、クラスは他のクラスの インスタンスへのリファレンスを含みます。

-中略-

コンストラクタ (または他のメソッド) にリファレンスを渡すことにより 実行時に複数のインスタンスを関連づけることも可能です。 これにより、複数のオブジェクト間の関連を動的に変更することが 可能です。

-中略-

一方、集約では、合成されたパーツのカプセル化 (隠蔽) が行われます。(静的な) 内部クラス (PHP はまだ内部クラスを サポートしていません) を使用することにより、クラスを集約することが できます。この場合、このクラスを含むクラスを通じる場合以外、集約された クラスの定義にはアクセスできません。複数のインスタンスの集約 (オブジェクト集約) は、あるオブジェクトの内部にサブオブジェクトを 動的に作成することを意味し、この過程でこのオブジェクトプロパティと メソッドを拡張します。

オブジェクトの集約は、(例えば、分子は原子を集約したものであるといった) 包含関係を表す際の自然な方法であり、サブクラスを複数の親クラス およびそのインターフェイスに永続的にバインドすることなく、 多重継承と等価な機能を得るために使用できます。 実際、オブジェクトの集約はより柔軟に使用することができ、集約される オブジェクト継承するメソッドまたはプロパティを選択することが できます。

んと…設計間違えるとクリティカルにNGなことになるのは容易に予想がつきます。

そも

警告

この拡張モジュールは、 実験的 なものです。この拡張モジュールの動作・関数名・その他ドキュメントに書かれている事項は、予告なく、将来的な PHP のリリースにおいて変更される可能性があります。このモジュール自己責任で使用してください。

ってあたりから考えてもふつ〜「使うな」です。


でも…ちょっと*1心惹かれてしまうのはなぜ?(笑

# PHP使うのやめるんぢゃねぇのかよヲイ

*1:どころではなく

2007-12-28

[][]使ってはいけない

mb_convert_encodingにて。第三引数であるfrom encodeは、省略もしちゃいけなければautoも禁止でございます。

半角カタカナを使う時に。

…状況設定しだいでは。えらいことになります orz


以下加筆。

っつか調査終了。

とりあえず前提条件として、文字コードについて軽く。

半角カタカナに絞った文字コードは以下のとおり。


sjis

0xA1-0xDF


euc

0x8EA1-0x8EDF*1


utf-8

EFBDA1-EFBDBF と EFBE80-EFBE9F*2


さて。とりあえず問題を「半角カタカナのみの文字列の場合」に絞ってみます。

平たく答えを返すと「自動判別ができない」のがほぼ現状です。

面倒なので端的に書くと。文字コードマッピングが重なりまくってるために「どっちかである」と確定することができない状態になってしまいます。具体的には、0xa1 0xa1という「EUCの文字」が存在し、「0x8ea1」という「Shift-jisの文字」が存在します。UTF-8の領域も一緒。くもの巣は自分で書いてちょ。

ああ念のため。たとえば「0xb1 0xb1 0xb1」なら「奇数なんだから多分shift jis半角カナじゃね?」というほどにインテリジェントな機能は、とりあえず現状確認しているPHP5.2.5までの範囲ではないようです。で、それでもEUC変換すると「最後の1バイトなんかへんだから切り捨てちゃえ」と切り取られ、文字列が常に偶数文字化するという不思議な現象がおまけでついてきます orz


とりあえず色々と思うところはあるのですが(ってかいわゆるguessルーチンであるmb_detect_encodingをもうちょっと仕様的にどうにかして欲しいのですが具体的にはちゃんと確立を配列で返してくれるとか)。

ひとつには「Accept-Charset(通常はformエレメントのaccept-charsetアトリビュート値)を設定してもらう」ってのがあるのですが、特に携帯においてサポートされているかは限りなく疑問です(未調査)。

ふたつには「どこまでいっても誤検出の可能性」が付きまといます。


で…まぁ解法ってほどのものでもないんですが。

まず「mb系の自動検出でautoは禁物」これはmust。

ひとつは「postなりgetなりの値を一通りjoin(PHPだとimplodeですな)つなげてから推測」。文字数が多いほうが正解にたどり着きやすいので。

次点が、いわゆるヒンティング情報をhiddenなりで持たせる。便利ではあるのですが「忘れた瞬間にNG」なのが微妙。

で、このあたりを踏まえてとりあえずひとつの例を。GETのケースとかその他かなりアバウトにはしょってるので、空気だけ感じ取りつつmakeしなおしてください(一応MWには実装予定です)。

// 入力はshift-jisの可能性が高いだろうから優先順位もそっちにあわせる
mb_detect_order('sjis-win,eucjp-win,SJIS,EUC-JP,JIS,UTF-8,ASCII');

// チェック
if (false !== empty($_POST('hinting'))) {
  // ヒンティング文字列があればそれを基準にする
  $input_encode = mb_detect_encoding($_POST('hinting'));
} else {
  // なければ全体をマリっと使う
  $input_encode = mb_detect_encoding(implode('', $_POST));
}

…まぁ多言語でもいえるはずのTipsなのですが。この辺ってつい意識からはずしちゃいがちだし実際はずしてたので、めも。

# …でもさぁこーゆーところちゃんとフォローしてこその「初心者のための言語」ちゃうん?

*1:一部サイトで0x8E21-0x8E5F、とかなってますが、上述が多分正解だと思います

*2:なんで間がすっ飛んでるのか微妙なぞですがこうなってます

2007-12-18

[][][]うわぁ諸刃…

あえて周りから。

<?php
rename_function('strlen', 'new_strlen');
override_function('strlen', '$string', 'return override_strlen($string);');

function override_strlen($string){
        return new_strlen($string); 
}

rename_function

(PECL apd:0.2-1.0.1)

rename_function ― グローバルの関数テーブルで関数名を変更する

override_function

(PECL apd:0.2-1.0.1)

override_function ― 組み込みの関数を上書きする

一応、擁護。

これらの関数の哲学は

Advanced PHP Debugger (APD)

導入

APD は進化した PHP デバッガです。PHP コードのプロファイリングや デバッグの機能を提供すること、また完全なスタックトレースを出力する 機能を提供することを目的として作成されています。

ここに集約されます。

哲学を「正しく理解して」用いるんなら、多分色々と便利です。

でも…もし「できると適切の間にある深い溝」を理解しない人がつかうと…すごいことがおきます。


…一瞬、直接override_functionだけ見たときは「…狂った?」とか思いましたともさ(誰とか何とかってのはあえて語らず)。

プロの包丁は毎日砥ぐものですが、よく砥いだ包丁って凶悪な凶器になるんですよねぇ。

2007-12-06

[][][]半角カタカナのメモ

んと…もうひとつ再現条件が不明なのですが。

再現する環境だと100%の確立で、とりあえず「文字列の最後が半角カタカナの文字列をmb_convert_encodingすると変な文字化けを起こす」です。


…ソースあたらにゃいかんかなぁと思うのですが…その結果改修とかいう話になるとそれはそれで寒いし…

なんていうか………相変わらず痛い言語だ orz