プレイスホルダ2種と既存の改修

＃＃＃今回は割合と「実務メイン」で失礼をさせていただければと思います。
早速ですが、前回ちらりと出しました「プレースホルダ」について少し細かい話をさせていただければ、と思います。

用語を少し厳密におさらいしておきましょう。
まず「正式なデータが入るまでの臨時のスペースを適切な表記で仮に表現した」SQLを準備しておきます。このように準備されたSQLを「準備された文(プリペアドステートメント)」と呼称します。
また「正式なデータが入るまでの臨時のスペースを適切な表記で仮に表現したもの」を、プレースホルダと呼称します。
ちなみに「プレースホルダ」という呼称自体は、SQLのこの話の他に、「HTML5(placeholder属性)」「PowerPoint」などにも出てくる用語です。確かに「とりあえずの、仮の目印」は便利ですからね。

上述のようなケースにおいて「準備された文」と「バインドされた値」は別々に通信されます。
この「別々に通信される」ことは、SQL-Injection対策としてとても有効になります。
「別々に通信されることが原理的にSQL-Injection対策になる」理由を細かく書くとかなり長くなってしまうのですが、端的には「”SQLのパース処理時”の”本来の意図と異なるパース結果”を誘発することによって悪意あるSQLを発行させるSQL-Injection」に対して「そもそも”準備された文”に”別途通信された値をバインドする”という手間をかけるので、”パース処理の誤謬を誘発させる”ことが原理的に出来ない」ために安全である、という事になります。

この続きは以下をご覧ください
リンク