のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,914人
頁
昨日:no data人
頁
今日:人
頁
最近の注目
人気の最安値情報

    元スレ【PHP】下らねぇ質問はID出して書き込みやがれ 96

    php覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : - shutdown + 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

    101 = :

    >>98
    {} なんぞ使ってて速度を気にするような人なんておらんだろ？
    そもそも文字列内に変数を展開なんてしないし

    102 = :

    速度の違いが分かるほど複雑なスクリプト組んでるわけじゃないけど
    >>100の理由でシングルしか使ってないな。妄信的に

    105 = :

    >>102
    {}使ったほうがすっきりする場合は使ってる。

    106 = :

    88です
    >>91
    ありがとうございます。
    print '<a href="'.$_SERVER['PHP_SELF'].'"> 削除 </a>';
    は無事動きました。
    href="
    の部分のダブルクオテーションは文字という考え方ということですよね？
    なので、
    '<a href="'
    という、シングルクオテーションで囲まれている
    <a href="
    が文字と言う考え方であってますでしょうか？


    次に、変数を""というダブルクオテーションで囲むと、
    その囲まれてる変数は展開されるという認識の下、以下にしてみるとダメでした。
    print '<a href="'."$_SERVER['PHP_SELF']".'"> 削除 </a>';

    今回、a href=の後のクオートがもともとのHTMLの仕様では、
    ダブルクオテーションであり、そのあとに、変数を囲むダブルクオテーションが続くと
    何か問題が出てしまうのでしょうか？


    さらに、{}で変数を囲めるということでためしてみました。

    print '<a href="'{$_SERVER['PHP_SELF']}'"> 削除 </a>';
    も、
    print '<a href="'.{$_SERVER['PHP_SELF']}.'"> 削除 </a>';
    も動きませんでした。
    書き方がまちがっていますでしょうか？

    107 = :

    展開可能とはいえ文字列ん中に変数入れるとか普通気持ち悪くね？
    HTMLの中に書くって事でスタートしてるからこうなってるんだと思うよ
    つまりビュー層のハナシ
    zend のコーディング規約でもシングルクオートで変数は連結しろとかなかったっけ？
    他言語の使い手にも読みやすいって事まで考えてそうなってると思うんだけどな

    108 = :

    >>106
    <a href="
    が文字と言う考え方であってますでしょうか？

    あってる

    print '<a href="'."$_SERVER['PHP_SELF']".'"> 削除 </a>';
    では，"$_SERVER['PHP_SELF']" のパースができない(だったような

    print '<a href="' . "{$_SERVER['PHP_SELF']}" . '"> 削除 </a>';
    なら動くと思う。

    素直に
    print '<a href="' . $_SERVER['PHP_SELF'] . '"> 削除 </a>';
    でいいじゃんかよ

    ちゃんとエスケープもしろよ？歯も磨けよ？

    109 = :

    >>106
    > '<a href="'
    > という、シングルクオテーションで囲まれている
    > <a href="
    > が文字と言う考え方であってますでしょうか？

    あってる。

    > 次に、変数を""というダブルクオテーションで囲むと、
    > その囲まれてる変数は展開されるという認識の下、以下にしてみるとダメでした。
    > print '<a href="'."$_SERVER['PHP_SELF']".'"> 削除 </a>';

    print '<a href="'."{$_SERVER['PHP_SELF']}".'"> 削除 </a>';
    にしてみて。

    > print '<a href="'{$_SERVER['PHP_SELF']}'"> 削除 </a>';

    .が無いし、{}が不要。

    > print '<a href="'.{$_SERVER['PHP_SELF']}.'"> 削除 </a>';

    {}が不要。

    110 = :

    >>106
    $_SERVER['PHP_SELF']はセキュリティ上の問題があるのでHTMLとして出力する物には使わない
    $_SERVER['SCRIPT_NAME']またはbasename(__FILE__)で代用

    111 = :

    $_SERVER['PHP_SELF']や$_SERVER['SCRIPT_NAME']を使わなくても
    <a href=""> 削除 </a>
    でいけるやん

    112 = :

    みんなよくつきあうな。どうみても釣りじゃん。

    113 = :

    {}で囲むのはダブルクオテーション中のときだけでいいです

    //ダブルの場合
    echo "こんにちわ、{$name}さん。";

    //シングルの場合
    echo 'こんにちわ、' . $name . 'さん。';

    115 = :

    >>114
    そういうのはそのまま考えて分割して連結でよくね？
    マルチバイトとか絡んでくると面倒になるし

    118 = :

    >>117
    変換してんじゃないの？

    120 = :

    PHP でやってるとしたらそうじゃね？ auto は微妙だけど

    121 = :

    >>109
    >>110
    >>111
    >>113
    ありがとうございました。
    おかげさまで完全に理解できました！！

    122 = :

    >>121
    おめ。

    どうやって勉強してるかわからないけど、
    今の知識だとセキュリティ対策が十分にできないと思うから
    本とか読んで学んだほうがいいよ。

    123 = :

    >>89 >>108
    元の質問者とは別人ですが、便乗して質問させてください

    $_SERVER['PHP_SELF']より$_SERVER['SCRIPT_NAME']のほうが安全ということですが、
    $_SERVER['SCRIPT_NAME']を使ってもエスケープは必要なんでしょうか？

    124 = :

    >>123
    確かにそちらの方が安全だが、アンカーの先にはそれについて言及していない。
    誰にレスをしたんだ？

    127 = :

    >>124
    > 誰にレスをしたんだ？

    主に>>108の「ちゃんとエスケープもしろよ」へのレスです。

    >>125
    はい、$_SERVER['PHP_SELF']のほうをそのまま出力すると
    JavaScriptを仕込まれてしまう可能性があるということですよね？
    なので、エスケープする理由はわかります。

    お尋ねしたいのは、_SERVER['SCRIPT_NAME']でもエスケープする必要があるのかということです。
    SCRIPT_NAMEにはPHP_SELFのようなXSSの脆弱性はないと思ってたんですが、
    何か特殊な方法による攻撃の対象になることがあるんでしょうか？

    128 = :

    >>127
    http://www.php.net/manual/ja/reserved.variables.server.php
    'PHP_SELF'
    現在実行しているスクリプトのファイル名です。
    ドキュメントルートから取得されます。
    例えば、http://example.com/test.php/foo.bar というアドレス上にあるスクリプトでは
    $_SERVER['PHP_SELF'] は /test.php/foo.bar となります。

    'SCRIPT_FILENAME'
    現在実行されているスクリプトの絶対パス

    133 = :

    >>130
    はい。読み込み専用で開けばよいので
    パラメータは'rb'をつけています。

    134 = :

    >>133
    file_get_contentsやreadfileは試してみた？

    135 = :

    >>131
    requireやincludeは外部ファイルのスクリプトを読み込むもの。
    extension_dirなどの拡張モジュールは、
    Cなどの低級言語で書かれているのでPHPより高速で、当然にコンパイルされているので速い。

    137 = :

    >>133 >>136

    先ほど自己解決しました。
    おそらく・・なんですが。
    サーバ側のファイルとクライアントでダウンロードしたファイルを
    比較したところ、クライアント側には行頭に改行コードが入ってました。

    そのせいでファイルサイズも1バイト分差異がありました。

    対策としてサーバ側のスクリプトファイルの
    不要な改行コードを削除しました。

    <?
    --色々なロジック--
    ?>
    　←この辺りの不要な改行コードを削除。


    そうしたところ、こちらが意図するとおりにファイルを
    送ることが出来ました。

    どうもありがとうございました。

    138 = :

    137ですが、
    >>133ではなく、>>134でした。

    申し訳ありません。

    140 = :

    >>137
    XML吐く時に同じ事食らったよ
    以来終了タグ ?> は書かなくなった
    zend framework のコーディング規約でも書くなってなってる

    141 = :

    >>140
    バカよけのための規約で、結構前からあるにはある

    142 = :

    PHPをプログラミングするのにお薦めの最適な開発ツール(エディタ)って何になりますか？

    コード補完してくれて,定義済みのうユーザー定義関数もアシストしてくれるような定番があれば是非知りたいです
    MySQLのクエリも同時に書くのでそれも補完アシストしてくれたりしたら最高ですがそんなのってあるんでしょうか？

    開発効率が格段にあがるのでしたら有料でも全然かまいませんので お願いします
    ちなみに今は秀丸で書いてます

    145 = :

    プログラマならvimとかemacsみたいな自分でカスタムできるエディタを
    早いうちから使っといた方がいいよ

    秀丸でもマクロで多少のカスタムはできるんじゃなかったっけ
    使ったことないから知らないけど

    146 = :

    ちょっとした編集 gvim/vim
    デバッグまでする場合 netbeans

    148 = :

    >>135
    やっぱりそうでしたが、ありがとうございました。

    149 = :

    >>140 >>141

    たしかにzend frameworkには?>が書かれていないですね。
    規約だったとは・・・。

    ということは、皆さんの開発現場でも
    ?>は書かないようにされているのでしょうか？

    ?>を書かないことでのデメリットはないのでしょうか？
    もしデメリットがあればそれを認識した上で
    私も活用したいと考えておりますので
    教えていただけないでしょうか。

    150 = :

    >>149
    書いてはいけない理由はこのあたりを参考に
    http://d.hatena.ne.jp/fbis/20090716/1247714151
    http://d.hatena.ne.jp/Kiske/20100128/1264643384


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : - shutdown + 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド

    トップメニューへ / →のくす牧場書庫について