MW211 EXIT

devlog
PHP/改行の表示
2011年09月08日
「<br/>タグ」を「改行コード(\n)」に変換するには、「br2nl()」を使う
例)$data = nl2br($html);

「改行コード(\n)」を「<br/>タグ」に変換するには、「nl2br()」を使う
例)$html = nl2br($data);

(DB内などの)データとしては「改行コード(\n)」で管理し、
表示する時には「<br/>タグ」で出力するという感じ。

但し、「<input>タグ」で入力される場合、
ユーザは「<br/>タグ」なんか入力しない(改行で入力する)ので
使用頻度的には以下なのかもしれない。
  「br2nl()」<「nl2br()」

個人的には、「nl2br()」で変換なんかせずに、「<pre></pre>タグ」で囲っちゃって
そのまま出力してしまった方が使い勝手はいいような気がする。
若干、単細胞な感じだけどね。
ちなみに当blogも見た目重視で「<pre></pre>タグ」を採用しています。
なってたって固定フォントの字下げが生命線ですから。
分類:PHP
C言語/先頭0埋めの罠
2011年09月07日
C言語においてソース上に以下の表記をした場合、以下の値となる。

    「10」→「10」(10進数とみなされるため)
   「010」→「 8」( 8進数とみなされるため)
  「0x10」→「16」(16進数とみなされるため)

意外に見落としがちなのが、8進数の表記。
つい先頭位置合わせで以下のような記述をしてしまいがちだ。

   a = 0012;
   b = 0123;
   c = 1234;

この場合、aは12に、bは123には…当然ながらならない。
ちなみにこの先頭0埋めのことを「ゼロサプレス」…とは言わないから合わせて注意。
(っていうかこの文章を書いていて気づいた)
「ゼロサプレス」は「12→0012」ではなく、「0012→12」のことをさす。
「12→0012」のことは、「ゼロパディング」という。
分類:C/C++、注意
PostgreSQL/連番初期化
2011年09月06日
PostgreSQLのAutoNumber機能(bigserial型など)を、
「1」に初期化するSQL文は以下のとおり。
┌──────────────────────────────────────┐
│ALTER SEQUENCE AutoNumber用列名 RESTART WITH 1;                             │
└──────────────────────────────────────┘
なお、下記でも代用できる。
┌──────────────────────────────────────┐
│SELECT SETVAL ('AutoNumber用列名', 1, false);                               │
└──────────────────────────────────────┘
この場合、第一引数の「AutoNumber用列名」を「'」で囲うことに注意。
また、第三引数に「SELECT SETVAL」の「is_called」を抑制する
「false」指定を行わないと、一件目の挿入データが「2」から始まってしまうので
こちらも注意が必要である。

なお、「TRUNCATE TABLE」で表を初期化する場合には、
「RESTART IDENTITY」オプションを付加してあげれば、上記のことをやってくれる。
┌──────────────────────────────────────┐
│TRUNCATE TABLE 表 RESTART IDENTITY;                                         │
└──────────────────────────────────────┘
分類:PostgreSQL
$_GET、$_POST、$_SESSIONの違い
2011年09月05日
$_GET
・aタグのhref属性などのリンク先URLに簡単に埋め込める(→テキストリンク系)
・多数の明細中にある各リンクなどに向いている
・抽出や検索など公開性の高い処理に向いている
・ブラウザのURL入力欄から簡単に入力できる
・情報が表に出やすい
・情報を引き継ぎにくい(ただしパラメータ付きURLをそのまま引き継げる)
・ブックマークにパラメータも含めて記録させることができる

$_POST
・form内でsubmitする必要がある(→ボタン系)
・一画面中に一つの(決定)ボタンなどに向いている
・更新など公開性の低い処理に向いている
・情報を非常に引き継ぎにくい(hidden属性で伝言していかねばならない)

$_SESSION
・PHPプログラム内でしか設定できない
・ログイン情報など気密性の高い処理に向いている
・情報を引き継ぎやすい
・その反面、情報を適宜クリアする必要(ゴミの掃除)が発生する

          ┌─────┬─────┬─────┐
          │  $_GET   │  $_POST  │$_SESSION │
          ├─────┼─────┼─────┤
入力容易性│    ○    │    △    │    △    │
          ├─────┼─────┼─────┤
隠蔽性    │    △    │    ○    │    ○    │
          ├─────┼─────┼─────┤
情報持続性│    △    │    ×    │    ○    │
          └─────┴─────┴─────┘
分類:PHP
PHP/GETにGET
2011年09月04日
┌──────────────────────────────────────┐
│<form method="post" action="a.php?b=c">                      →「a.php?b=c」│
└──────────────────────────────────────┘
formのaction属性で指定するURLにGETパラメータを付加した場合
POSTの場合は、GETパラメータが引き継がれる。

しかし、GETの場合はクリアされてしまう。
┌──────────────────────────────────────┐
│<form method="get" action="a.php?b=c">                           →「a.php」│
└──────────────────────────────────────┘
(雪だるま式に)GET転がしができるかと思ったら、大間違い。
POSTではうまくいってもGETに変えたらハマってしまうってことがあるので要注意。

回避策としては「<input type="hidden"~」に切り換える。
┌──────────────────────────────────────┐
│<form method="get" action="a.php">                           →「a.php?b=c」│
│<input type="hidden" name="b" value="c">                                    │
└──────────────────────────────────────┘
分類:PHP、注意
PHP/submitボタンのタイトルをGETパラメータから除外する方法
2011年09月03日
formでGET送信(<form method="get")する場合、
以下のようにsubmitボタンのタイトルが長かったりすると、
┌──────────────────────────────────────┐
│<input type="submit" name="submit" value="とっても長いボタン名"/>           │
└──────────────────────────────────────┘

URL上に以下のように、その長いタイトルがエンコードされ埋め込まれてしまい
邪魔だと思ったことはありませんか?
┌──────────────────────────────────────┐
│….php?…&submit=%E3%81%A8%E3%81%A3%E3%81%A6%E3%82%82%E9%95%B7%E3%81%84%E3…│
└──────────────────────────────────────┘

解決方法はname属性をなくすことです。
┌──────────────────────────────────────┐
│<input type="submit" value="とっても長いボタン名"/>                         │
└──────────────────────────────────────┘

URL上から「submit=」自体がなくなります。

っていうか、元々が(他からコピペしてきたため)
name属性の意味を考えてない単純ミスなんですけどね。
分類:PHP
PostgreSQL/timestamp型を文字列として参照
2011年09月02日
timestamp型の項目を「YYYY-MM-DD HH:II:SS」(例:2011-09-02 12:34:56)の形式で
文字列として参照する場合は、「TO_CHAR()」を使う。
┌──────────────────────────────────────┐
│SELECT TO_CHAR("列",'YYYY-MM-DD HH24:MI:SS') AS "列",                       │
│    FROM "表";                                                              │
└──────────────────────────────────────┘
分類:PostgreSQL
Smarty/連想配列に値がない場合の処理分岐
2011年08月31日
Smartyに指定された連想配列(ここでは$data)に値がない場合に
全体を非表示とする例は以下の通り。
┌──────────────────────────────────────┐
│{if ($data|@count) > 0}                                                     │
│見出表示用タグ                                                              │
│{foreach from=$data key=k item=i}                                           │
│明細表示用タグ                                                              │
│{/foreach}                                                                  │
│{/if}                                                                       │
└──────────────────────────────────────┘

以下もOK。
┌──────────────────────────────────────┐
│{if $data}                                                                  │
│見出表示用タグ                                                              │
│{foreach from=$data key=k item=i}                                           │
│明細表示用タグ                                                              │
│{/foreach}                                                                  │
│{/if}                                                                       │
└──────────────────────────────────────┘
分類:Smarty
SQL/呉越同舟?
2011年08月30日
1対nの関係にある親子テーブルを結合して、子IDで親子両方の名称を取得する場合に
以下のようなSQL文となる(各IDは主キーとする)。
┌──────────────────────────────────────┐
│SELECT 親.名称,                                                             │
│       子.名称                                                              │
│    FROM 親,                                                                │
│         子                                                                 │
│    WHERE 親.親ID = 子.親ID                                                 │
│      AND 子.子ID = {子ID};                                                 │
└──────────────────────────────────────┘
一方、m対nの関係にある場合は上記SQL文では、複数のレコードが該当してしまう。
しかし、子IDに加えて親IDもわかっている場合には、
以下のようなSQL文で一意にレコードを取得できる。
┌──────────────────────────────────────┐
│SELECT 親.名称,                                                             │
│       子.名称                                                              │
│    FROM 親,                                                                │
│         子                                                                 │
│    WHERE 親.親ID = {親ID}                                                  │
│      AND 子.子ID = {子ID};                                                 │
└──────────────────────────────────────┘
全然別の一意情報を結合しただけだが、
1件×1件の直積は1件という単純な法則は結構使えるかも。
分類:SQL
内部結合と外部結合が複合する場合の罠
2011年08月29日
┌──────────────────────────────────────┐
│SELECT *                                                                    │
│    FROM 表1,                                                               │
│         表2                                                                │
│    WHERE 表1.ID = 表2.ID;                                                  │
└──────────────────────────────────────┘
内部結合している表1と表2のうち、表1の方に表3を左外部結合したい場合
やってしまいがちなミス。
┌──────────────────────────────────────┐
│SELECT *                                                                    │
│    FROM 表1,                                                               │
│         表2                                                                │
│    LEFT JOIN 表3 ON 表1.ID = 表3.ID                                        │
│    WHERE 表1.ID = 表2.ID;                                                  │
└──────────────────────────────────────┘
以下が正しい。
表1と表2の結合結果に表3を結合するのではなく、
表1と表3の結合結果に表2を結合するのが正しい。
┌──────────────────────────────────────┐
│SELECT *                                                                    │
│    FROM 表1 LEFT JOIN 表3 ON 表1.ID = 表3.ID,                              │
│         表2                                                                │
│    WHERE 表1.ID = 表2.ID;                                                  │
└──────────────────────────────────────┘
表2に外部結合する場合は、前述でも順番的に問題ないので、
本来の仕様を勘違いしたままとなりやすい。
┌──────────────────────────────────────┐
│SELECT *                                                                    │
│    FROM 表1,                                                               │
│         表2                                                                │
│    LEFT JOIN 表3 ON 表2.ID = 表3.ID                                        │
│    WHERE 表1.ID = 表2.ID;                                                  │
└──────────────────────────────────────┘
分類:SQL
前へ 1 … 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 次へ