PHPで配列に安全にアクセスしたいだけだが - think and error
2010.09.18追記 多次元配列に対応してみました。 phpにおいて配列とは、生成時にarray()とかいう妙なリテラル*1を書くことを強制されるためそれだけで既に書くにも読むにもだいぶ残念ではあるが、加えて連想配列との境がないために挙動が予想つかないarray_*系関数が、なおかつ速度も大抵遅いと聞いてがっかりせざるをえない代物であると分かり残念な昨今。 まあ分からなくもない。恐らくPHP言語設計者は抽象度の高い（連想）配列を目指したのだろう。例えばCだと配列最後null文字が入り、その実装(仕様だっけ?)に依存したコードが多い。というか普通だ。 それに対しPHPでは数値のインデックスでさえ配列順序とは無関係だ。何故そうしたか分からんが。でもメモリ消費多いし、array_*関数は遅いし、foreachのためだけに設計されたんじゃねーのかこの配列は、と疑いたくもなる。 まあいい。全部憶
php変態文法最速マスター - milieuの日記
適当なタイトルをつけてしまったが，最近code golfをやっていたので，その記録を付けていきたいと思います．code golfというのは，なにか問題が与えられてその答えを出力するプログラムをどれだけ短くかけるかという競技（？）です．たとえば「Hello, world!を出力せよ」みたいな感じです．使用できる言語は本家のほうはruby,perl,python,phpでshinhさんの運営しているほうは大体なんでもありそうです．私は仕事でphpを使っているのでphpで参戦しました．(phpしか使えないとも言う)で、いくつか問題を解いてみたけどphpはrubyとかperlに比べると長くなりがちのようです．理由としては・標準入力を受け取るのが面倒・変数が2byte・関数名が長い・などが考えられると思います．しかし得意な分野もあって、それは単純出力系（上のHello, world! 問題とか）と文
ファイルアップロード攻撃＠PHP技術 - KIAI＠PG
ファイルアップロード攻撃です。 ファイルをアップロードさせた後、アップロードしたファイルを踏んでのPHPコードやJavascriptを実行させる攻撃です。 この攻撃の脅威は、 アップロードしたいファイルにスクリプトを仕込んで置く 転送したファイルを”システムにとって適切なファイルである”と偽装することで、ファイルを保存させる 保存したファイルにアクセスしてコードを実行させる(内部情報を抜き出すなど) ができることです。 サイト内(DocumentRoot下)へアップロードファイルを管理している時に起こる可能性があります。 ファイルアップロード攻撃 攻撃側 攻撃を行って見ます。ここではアップロードされたファイルを/image配下に設置しています。ここはURL指定できる場所になっています。 if(!empty($_FILES['userfile']['tmp_name'])){ move_up
PHPの言語仕様がウンコな理由個人的トップ10 - kなんとかの日記
「PHPerの問題点はPHPしか知らずに的外れなことを言うことだ」と、Javaしか知らなくて的外れなことを言っている連中にすら言われちゃってるPHPerのみなさん、こんにちは。 PHPは「使える道具」であることは事実です。しかし同時に言語仕様がウンコなのも事実。 ここでは、個人的にウンコだと思っているPHPの仕様を挙げてみたよ！ htmlspecialchars() の名前が長すぎる これはほんとウンコ。おまえWebアプリのための言語やろが！なんでこの関数の名前がこんなに長いねん！こんだけ長かったらめんどくさがって echo $var としてまうやろが！WordPressのthemeでHTMLエスケープ忘れが多いのはおまえの名前が長すぎるせいだ！ そんなわけで、全PHPerはこんな関数を定義するといいと思うよ。 ## echo $var; よりも短く h($var); と書ける! func
PHPのなにが素晴らしいって - キングダムぶろぐ
いや違うね。 PHPが素晴らしいんじゃなくて、 他があまりにもイケてなさすぎるんだよね。 たとえばさー ちょっとしたWEBサービス立ち上げたくてレンタルサーバーかりたとしても パッと使えるのって、ふつうPerlとPHPくらいのもんでしょ。 だれもかれもがサーバー環境のセットアップの知識と余裕があるわけじゃないしね。 それで、PerlかPHPの選択になって結局みんながPHPを選ぶわけなんだけど なんでかって？ ・普通に使うとPHPの方が遙かに早い え、mod_perl使えばはやいよって？ バカなの？ PHPは何も考えなくても早いんだよ。 ・Perlはユニコード普通に使おうとするとハマる 難しいこと考えずに手軽に扱えるようにならない限り誰も使わないよね こんな簡単なことなのに やれ文法がなんだだとか思想がどうとか Perl は利用しているユーザー含め質が低すぎるからうんこ。 っておばあちゃんが
PHPにメッセージキューとそれを扱う糖衣構文を実装してみた (「PHPのすべらない話 #3」) - moriyoshiの日記
Goにできて、PHPにできないはずはない！というわけでやってしまいました。まあ、これにメッセージキューとメッセージスロットを足しただけなんですが。 <?php function sub($i, $ch) { for (;;) { $a = <- [$ch]; printf("%d:", $i); var_dump($a); } } $ch = thread_message_queue_create(); for ($i = 0; $i < 10; $i++) { thread_create('sub', $i, $ch); } $i = 0; for (;;) { [$ch] <- $i++; usleep(50000); } ?> 見て分かるように、 [$ch] <- $i++;こんな感じにメッセージの送信を、 $msg = <- [$ch];こんな感じにメッセージの受信を書くことができ
PHPで面接に受かるたった1つの方法 - いぬビーム
面接官「特技はマジッククォートとありますが？」 PHP 「はい。マジッククォートです」 面接官「マジッククォートとは何のことですか？」 PHP 「魔法です」 面接官「え、魔法？」 PHP 「はい。魔法です。リクエスト全部に大ダメージを与えます」 面接官「……で、そのマジッククォートは当社において働くうえで何のメリットがあるとお考えですか？」 PHP 「はい。ハッカーが襲って来ても守れます」 面接官「いや、当社にはエスケープを忘れるような輩はいません。それにサニタイズは犯罪ですよね」 PHP 「でも、インジェクションにも勝てますよ」 面接官「いや、勝つとかそういう問題じゃなくてですね……」 PHP 「入力全部にaddslashesを与えるんですよ」 面接官「ふざけないでください。それにaddslashesって何ですか。だいたい……」 PHP 「\を付与するんです。埋め込み先がHTMLでもお構
Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある - t_komuraの日記
以下のページに関連して、htmlspecialchars() を使用している場合でも XSS が可能かどうか少し調べてみました。 http://www.tokumaru.org/d/20090930.html その結果、いくつかのブラウザで文字エンコーディングに Shift_JIS を使用していた場合、XSS が可能なことを確認しました。 テストコードは以下の通りです。リンクにマウスポインタを乗せると埋め込んだ Javascript が実行されます。 <?php $_GET['a1'] = "\xf0"; // \xf0 - \xfc で可能 $_GET['a2'] = " href=dummy onmouseover=alert(document.title) dummy=dummy"; header( "Content-Type:text/html; charset=Shift_JIS
htmlspecialchars: 問題を解決するにはどうすればよいか案 - ものがたり(旧)
http://d.hatena.ne.jp/IwamotoTakashi/20091006/p1 http://www.tokumaru.org/d/20090930.html#p01 先にはてブでコメントしてから2つ目以降を読んだっていうのはまあ秘密だとして。わたしは日本の人がどんだけPHPに関わっているか把握していませんが、見ていてこんなことを思いました: この問題は多分今のアプローチだと解決しないでしょう。というのは、今回岩本さんが書いたパッチは「仕様変更」を要求するものなので、bugtrackerで議論するだけでは結論が出せない/出しにくいもので、メーリングリストなどでちゃんと多くの人が見ているところで議論すべき内容なのです。開発者はほぼ例外なく開発MLを見ているでしょうが、バグレポートMLは（もしあれば）大量に流れてくるので、自分がメンテナンスしていない無関係なものは見ないという
PHPの「えせプログラミング言語」の弊害 - moriyoshiの日記
先日のエントリーでも少し触れたが、PHPの最大の問題点は、それが持つ「一見その言語構造がよくあるプログラミング言語の形をとりながら、プログラミング言語の最も大切なところを外している『えせプログラミング言語』である」点にある。Webアプリケーションの開発で注意すべき部分とは何かを根底の部分でちゃんと理解せずにPHPアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「PHPでプログラミング言語を学ぶ」などもっての他だし、「JavaでもPHPと同じようなプログラミング言語を作ってWebアプリの開発を効率化しよう」などという発想もとても危険である。 PHPの発想の根底には、「HTMLテンプレート用言語とロジック記述用言語の統一により、開発コストを減らそう」という CGI 時代の安易な発明がある。PHPは、その前近代的な発想を通じて、テンプレートとロジックを同じファイル
出力時の文字エンコーディング変換、妥当性確認について - t_komuraの日記
大垣さんが以下のページで PHP について言及しておられますので、気になったことを書いておきたいと思います。 http://blog.ohgaki.net/rails-ruby-1-9 私は、現在、PHP で構築したサイト運用はしていませんので、出力時に文字エンコーディングを変換、妥当性確認する方法がどの程度有効で、どのような問題があるのかは十分把握していません。ある程度実施方法については書いておきますので、参考にされる方は、実用可能かどうかを十分検証してください。 出力時に文字エンコーディングを変換する方法 PHPで、似た様な動作にしたい場合（ブラウザ以外からの入力も怪しいなど）出力時に強制的に文字エンコーディング変換してしまえば良いです。例えば、 mbstring.internal_encoding = utf-8 mbstring.http_output = utf-8 と出力文字エ
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
シンプルなTwitter検索「findTwitter」を作りました＆ソース公開
AutoPagerize対応したシンプルなTwitter検索「findTwitter」を作りました。 Twitterのつぶやきを検索 機能はシンプルです。テキストボックスに検索したいキーワードを入力して、「検索する」ボタンをクリックするとキーワードに合致したつぶやきを表示します。 「shin1x1」で検索 検索パターンとしては以下のような組み合わせが可能です。 単語で検索。（ex. [CakePHP]） スペースで単語を連結してAND検索。（ex. [PHP カンファレンス]） 「OR」で単語を連結してOR検索。（ex. [shin1x1 OR msng]） 仕組み TwitterAPIを叩いているだけ 仕組みはごくごく単純でTwitterの検索APIを叩いてるだけです。 検索結果はAPIの挙動に依存しているので、検索漏れや古いつぶやきが検索対象にならないなど現象があります。 CakePH
PHPの比較の素晴らしさ加減は正常
if ("0x0A" == "10") { print '(´ε｀ )ﾁｭｯ'; } チュッ。されちゃいます。 文字列であっても整数と解釈できる文字列の場合は勝手に型変換しやがる今世紀最大の愚行を犯してしまうってのは有名な話だよね。 文字列であっても整数と解釈できる文字列の場合は自動的に整数に型変換してくれる超便利機能があるってのは有名な話だよね。 だけどなんでコレが一致するかわけがわからんかった。 0x0Aは10進数で10になるので一致する。と、言いたいところなんですがそう単純な話じゃないんだ。 以下の例を目ん玉見開いて見て欲しい。 var_dump(0x0A); var_dump("0x0A"); var_dump((int)"0x0A"); var_dump((float)"0x0A"); var_dump(intval("0x0A")); 実行結果 int(10) string(4
FrontPage
のように表示されているため、「display_errors」は無効となっているようです。 試しに先ほど設定確認用に作成した「php_test.php」の内容をわざと間違えた内容にし、「php_test2.php」とします。 <? php // わざとスペースを入れてみました phpinfo(); ?> このファイルを確認するため、ブラウザで http://localhost:8001/php_test2.php にアクセスしてみます。 すると「display_errors」が無効となっているため、エラーがあってもブラウザ画面には何も表示されず、修正時の手助けとなるエラーが表示されません。 MAMPのデフォルトで無効となっている理由としては、「display_errors」の設定を記述してあるphp.iniファイルにも記述してあるようですが、 ; Print out errors (as a
PHP 5.3の名前空間仕様が変更されました
(Last Updated On: 2018年8月13日)名前空間に関する議論は5年以上も行われていたのですが、今度こそ結論が出たようです。 何故このようなエントリを書くかというと、Software Design（技術評論社）の11月号にPHPの最新情報としてα版PHP 5.3を紹介しているからです。入稿後に仕様変更があったので最新号の記事ですが既に内容が古くなってしまいました。 # とは言ってもまだ新しい仕様のPHPは無いですが α版なので仕様や機能が大きく変更される事もありますが大きな変更がありました。見本誌が刷り上がった頃に名前空間の区切り文字が”::”だと静的にメソッドを呼び出す場合やクラス定数を呼び出す場合に困る場合がある、とPHP開発者のMLで議論になり始めました。 ML上、IRC上、オフラインの打ち合わせが行われ、数週間におよぶ議論の結果が昨日MLに投稿されました。名前空間の
はてなブログ | 無料ブログを作成しよう
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
PHP コード最適化 Best Practices 63+ - カタコト日記
みたいなタイトルの記事を Digg 経由で発見。チートシート代わりにと思い超訳。*1 A Software Architect PHP 最適化 ベストプラクティス！ 01. static にできるメソッドは static として宣言しよう。（4倍速い） 02. echo の方が print より速い。 03. echo '文','字'; （カンマ区切り）の方が、'文'.'字' （ドット連結）より速い。 04. ループの最大値は、ループ「内」ではなく「前」にセットしておこう。 05. 大きい配列のような変数は unset() してメモリを解放しよう。 06. マジックメソッド（例： __get, __set, __autoload）は使用を避けよう。 07. require_once はハイコストなのです。 08. include や require でファイルはフルパスで指定しよう。 09
「@」でエラー抑制すると PHP が遅くなるという噂について : a My RSS 管理人ブログ
PHP では @ を付けることでエラーを回避できるという便利な記述方法があり、ものぐさな私などは if (@$var["foo"]) $result = $var["foo"]; みたいなコードを書いてしまいます。 で、この処理が「遅い」という噂やツッコミを度々受けるので調べてみました。 「ほら、そんな気にするほどでも無いよ」という結果を期待していたのですが、、、なんじゃこりゃ。。。 劇遅じゃないですか、これ。 いやはや・・・ ちょっと列挙しますね。以下のようなコードを単純 for 文で 100万回実行したときの結果です。 error_reporting(0) で PHP4 if (@$a["hoge"]) $b = $a["hoge"]; ⇒ 約 2.4 秒 if ($a["hoge"]) $b = $a["hoge"]; ⇒ 約 1.3 秒 if (isset($a["hoge"]))
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.rcdtokyo.com/ucb/contents/i000815.php