PHPで配列を一括初期化する一番速い方法
SimpleBenchのサンプルを兼ねて、配列の一括初期化を行うパターンでどれが速いか計測してみました。 計測パターンwhileで初期化foreachで初期化forで初期化array_fillで初期化array_padで初期化 サンプルソースコード 結果 結果は、array_fillとarray_padが圧倒的に速いことが分かりました。ループして初期化するよりも組み込み関数で初期化した方がいいという事ですね。 ちなみに、array_fillとarray_padが僅差だったので何回か試してみると、手元の環境ではarray_fillの方が速い事が多かったです。
PHPで複数行の文字列を扱う方法
PHPで複数行の文字列を扱う方法を紹介します。 １．問題点 複数行にわたるテキストを変数に代入したり出力するときに、次のように1行ずつ連結せずに記述する場合があります。 $text = "aaa\n" . "bbb\n" . "ccc"; が、もう少し簡単に複数行を記述したいところです。 ２．クォーテーションの中で改行する 次のようにクォーテーションの中で改行すれば、そのまま改行として出力されます。 <?php $text = 'aaa bbb ccc'; var_dump($text); ?> 実行結果 string(11) "aaa bbb ccc" ダブルクォーテーションで括れば中の変数も展開します。 <?php $foo = 'bar'; $text = "aaa bbb $foo ccc"; var_dump($text); ?> 実行結果 string(15) "aaa bbb
さくらのレンタルサーバーで常時SSL/TLSを設定する | サイト公開時 | ドキュメント | a-blog cms developer
さくらのレンタルサーバーでは以下の特殊な事情により、SSL/TLSの常時化に一工夫必要になります。 モジュール版について phpをモジュール版で動かしている場合は、以下の対応は必要ございません。 CGI版をご利用の場合は、以下対応が必要になります。 仕様 httpsのアクセスであっても、%{SERVER_PORT} に 443ではなく80が設定される。 httpsのアクセスであっても、%{SERVER_HTTPS} は空。 $_ENV['HTTPS'] に httpsのアクセスの場合は"on"が設定されるが、リライトされたものは、空になってしまう。 httpsのアクセスの場合、%{HTTP:X-Sakura-Forwarded-For} に クライアントのIPアドレスが設定される。 a-blog cmsでの常時SSL/TLS対応 以上の仕様により、通常の方法では常時�SSL/TLSが対応で
さくらのレンタルサーバで常時SSL化するときに、http→httpsの転送でハマった話 - Qiita
前提 Slimframework 3を使っています。 さくらのレンタルサーバにアップロードしていました。 公開ディレクトリの場所を変更しています。（/home/アカウント/www/ → /home/アカウント/www/ディレクトリ名/www） 動いたコード フロントコントローラの一番上に、下記の処理を挿入しました。今回はSlimframework 3を使用していますが、CakePHPやWordPressなど、処理をフロントコントローラに集める他のフレームワークやCMSでも動きそうです。 後述のとおり、a-blog cmsの問題解決用の記事を参考にしています。 ただし、さくらのレンタルサーバでしか通用しません。 何より対応が無理矢理過ぎるのでいつ動かなくなるのかと不安です。。 if (isset($_SERVER['HTTP_X_SAKURA_FORWARDED_FOR'])) { $_SE
DIS例2 / PHPは配列型と辞書(HaspMap)型が区別不能な言語！ | PHPを使いもせずDISってる君達へ - Qiita
PHPはよくDISられることがあります。しかし、実際にはほとんどPHPを利用していない人が印象だけでDISってることが多いような気がします。 そこで、PHPがよくDISられている点について、実際どうなのかをPHP未体験者向けに解説していきたいと思います。PHPを触ったことない人でもわかりやすいようにシンプル目な仕様のRubyを例に説明していきたいと思います！( Ruby触ったことなくても、その他のOOP言語を触ったことあれば雰囲気は理解できるように書いています ) DIS例1 / PHPは配列操作がしづらい PHPの配列操作は扱いづらい等とDISる人たちがいます。実際のところどうでしょうか。 以下のような処理を配列への中間変数を用いず行うコードを例に考えてみます。 0. [2,4,6,8,10]という配列を用意して 1. ↑の配列から8以下の数だけを選択した配列を作る 2. ↑の配列から各
ニューヨークITブログ » HTMLのFormへ、戻るボタン(Back)で戻ると内容が消える問題
今回はテクニカルな話題、備忘録がわりで。 WebサイトでFormを使っているとき、次のページに進んでから戻るボタンを押すことがあります。このとき、ユーザーはさっき入力した内容が画面に残っていることを期待するでしょう。しかし、実際にはFormの中身がもとに戻っている(消えている)ことが多々あります。 これ、Googleで検索しても「サーバー側ではどうしようもない」と言っているBLOGや掲示板が多いですが、そんなことはありません。 手元のFireFox(最新)で試したところ、Formにさっきの内容が残るかどうかは、HTTPヘッダーでキャッシュを許しているかどうかに依存するようです。Ajaxで内容を書き換えた状態が破棄されるかどうかも同様。サーバーによって、HTTPヘッダーを吐き出すときにキャッシュOKにするかNGにするかが、サーバー既定値として設定されています。それを「確実にキャッシュOK」に
PHPのロケールに関するまとめ - hnwの日記
5/3 17:45追記：t_komuraさんに指摘いただいた関数と、さらに僕が調べ直したものを含め、「ロケール設定に従う関数一覧」に25個ほど追加しました。かなり見落としがありましたね…。 PHPのロケール*1まわりについて調査したので、これをまとめてみます。 この記事は「ロケールの影響を受ける関数 - Sarabande.jp」を掘り下げたものです。masakielasticさん、ナイスな記事をありがとうございます。 PHPの文字列型と文字エンコーディング 他のモダンなLL言語と異なり、PHPは文字列の文字エンコーディングに関して何も仮定せず、単なるバイト列として管理しています。つまり、文字エンコーディングの取り扱いは各関数の実装に委ねられています。 下記の通り、これはマニュアルにも記述があるのですが、実に残念なことです。 残念ながら、PHP の各関数が文字列のエンコーディングを判断する
libmysqlclientを使うプログラムはset namesをutf8であっても使ってはいけない | へぼい日記
mysql_enable_utf8 => 1 で DBIC::UTF8Columns 要らなくなるっぽいComments 上記の記事のブクマに set namesを直接実行しちゃうのはutf8であってもコンパイルオプションによっては問題起こるのでお勧めできない http://b.hatena.ne.jp/nihen/20090204#bookmark-11950629 ってことを書かせてもらったんだけど、この最後のset namesはutf8でも使っちゃダメという話を軽く説明します。 まずは、基本的なことはMySQL5開拓団 – 日本語処理の鉄則 / KLab株式会社を読んでください。mysqlの日本語処理についてのドキュメントとしては、私は今一番信頼できるドキュメントだと思っています。 さて、上記のページの< 図3：クライアント側文字コードの指定チャート>を、勝手ながらすべて引用させてい
文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2010年9月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPカンファレンス2010にて「文字コードに起因する脆弱性とその対策」というタイトルで喋らせていただきました。プレゼンテーション資料をPDF形式とslideshare.netで公開しています。 文字コードのセキュリティというと、ややこしいイメージが強くて、スピーカーの前夜祭でも「聴衆の半分は置いてきぼりになるかもね」みたいな話をしていたのですが、意外にも「分かりやすかった」等の好意的な反応をtwitter等でいただき、驚くと共に喜んでいます。土曜にPHPカンファレンスに来られるような方は意識が高いというの
おそらくはそれさえも平凡な日々: PHPの正規表現と文字列
PHPで正規表現を扱う上で、正規表現パターンの記述で迷ってしまっている人が多い気がする。 PHPが文字列を生成する その文字列を正規表現エンジンに渡す と言う2段階の手順があり、そこがやや複雑なので混乱を招く部分があるのだと思う。 混乱を防ぐためには、その手順をしっかり追って、正規表現リテラルとして指定している文字列をechoしたらPHPがどのように出力するかを考えてみると良い。 例えば以下のようなコードがあったとする。 preg_match('/\\d/','3d'); まず、preg_match()の第一引数になっている正規表現パターンをechoで出力するとどうなるかを考える。 echo '/\\d/'; #/\d/ なので、/\d/が正規表現エンジンに渡されると分かる。なので、上記のパターンはマッチする。 さらに混乱を招きやすくしているのが、PHPの文字列の仕様で、特にバックスラッシ
htmlspecialcharsは不正な文字エンコーディングをどこまでチェックするか
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2009年9月30日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、PHPのhtmlspecialchars関数の第三パラメータ（文字エンコーディング指定）により、どこまで文字エンコーディングの妥当性チェックをしているかを報告します。 2007年4月に、寺田氏(id:teracc)の素晴らしいエントリ「htmlspecialcharsと不正な文字の話」により、htmlspecialcharsは、第三パラメータの文字コードを実質的に無視しており、不正な文字エンコーディングが指定された場合、その文字はチェックされずにすり抜けてしまうという結果が報告されています。
出力時の文字エンコーディング変換、妥当性確認について - t_komuraの日記
大垣さんが以下のページで PHP について言及しておられますので、気になったことを書いておきたいと思います。 http://blog.ohgaki.net/rails-ruby-1-9 私は、現在、PHP で構築したサイト運用はしていませんので、出力時に文字エンコーディングを変換、妥当性確認する方法がどの程度有効で、どのような問題があるのかは十分把握していません。ある程度実施方法については書いておきますので、参考にされる方は、実用可能かどうかを十分検証してください。 出力時に文字エンコーディングを変換する方法 PHPで、似た様な動作にしたい場合（ブラウザ以外からの入力も怪しいなど）出力時に強制的に文字エンコーディング変換してしまえば良いです。例えば、 mbstring.internal_encoding = utf-8 mbstring.http_output = utf-8 と出力文字エ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHP: Noticeエラーを回避してarrayから値を取得するいくつかの例