--',200)これもSQLインジェクションです。SQLを動的に組み立てる危険性SQLを文字列から動的に組み立てる処理は危険を抱えてます。外部の信用ならないデータを取り込むプログラムの内部で、プログラム作成者の意図に従って生成したデータ(文字列)で構成するSQLはある程度信用できるSQLです。少なくとも意図的に妨害や損傷を与えるSQLを作る事はしない筈です。ファイルやデータベーステーブルやユーザの入力等、プログラムの外部から取り込む、予期しない内容を入力してくる可能性がある場合、これを信用できないデータ、もしくは汚染されたデータと呼びます。みんな良い人ならいいのですが、そうでない人もいるので、意図的に誤動作を誘発するようなデータ内容を送ってくる可能性があります。外部プログラムも、もしかしたら悪意を持った内容を送り込んでくるかもしれません。検証を行い、プログラムの仕様に合ったものなのかを確認します。仕様を外れていればエラーにしなくてはいけません。仕様に合うのに問題がおきる場合もあります。マルチステートメント指示のような文字がある場合はエスケープ処理を行い文字列中に含ませても問題がないよう対処しなければいけません。あれ?SQLを実行したいだけなんだけどな......入力値のせいでSQLが成り立たなくなるのはまずいですから、単にエスケープ処理で終わる訳ではなく、全部連結した結果SQLとして正しい体裁を為すように補正する場合もあります。......おかしいですよね。入力値そのものの検証ではなく、それを組み入れたSQLも検証しなくてはいけないなんて。入力値の検証にコストをかけて、かつSQLの構成確認にコストをかけて。サニタイズ?何それおいしいの?世の中には「サニタイズ」なる用語があります。この用語を使っている書籍やページが言うには「特殊文字はちゃんとサニタイズ(?)して無力化しておけば問題ないぜ」と。別にやってもいいんですけどね。苦労の割には本来の処理にあまり貢献できません。これは「サニタイズ」が小細工の部類であり、SQLを文字列の連結で組み立てていく際に起こる問題を全く解決できないからです。プレースホルダを使いましょうそもそも、入力値を含めて作成された文字列をSQLとして解析しようとするから問題が起きます。SQLが入力値の内容に左右されない様にしちゃえば良いわけです。そのやり方の一つにプレースホルダという仕掛けがあります。RDBに限らず、こういうやり方はいろいろなところに使われています。昨今のWebアプリのSQLインジェクションは、そういう機能を知らずに(教わらずに)きた技術者によって引き起こされていると思ってもいいのではないかと思います。教えられる技術者も居なくなってきているという話もあるのですが。以下に仮想的なコードを示します。fileObj.close();最初に、実行したいSQLとそのSQLでつかうパラメタを定義しコンパイルします。prepare処理と言われる前処理です。次にパラメタに値を割り当ててからSQLを実行します。SQLはコンパイルされているので、毎回prepare処理を行う必要はなく、パラメタに割り当てる値を更新すれば次のデータを処理(SQLを実行)できることになります。この、SQL中にある“@xxx”のようなパラメタのことをプレースホルダといいます。いい加減な説明なのであとでちゃんと調べたほうが良いですよ。SQLServerだと“@xxx”、Oracleだと“:xxx”かな。このときは名称ではなくn番目のパラメタ、として指定します。SQLはコンパイルされており、入力値によってSQLが改変されることはありません。入力値の特定文字のエスケープ処理も要りません。素直に値を設定すればよいのです。油断はするなよもしデータベースの内容をWebブラウザへ出力するなら、出力中に怪しげなコードが含まれていてもそれを無効化するような仕掛けを入れます。xxコンパイラ用ライブラリ<JavaScript>document.href="http://xxxxx";</JavaScript>だったりしたら、この内容をそのままブラウザに出力するとそのブラウザに別サイトへのアクセスを指示することができちゃうかもしれません。ここで‟サニタイズ”の出番です。文字列中の‟<”や‟>”をそれぞれ‟&lt;”や‟&gt;”のような実体参照表記に変更するなどの処理を実施します。場合、専用の関数やメソッドが用意されていて自分でサニタイズ処理を行うような関数やメソッドを作らなくてもいい事がほとんどです。いうか作らない方がいいです。間違いなく考慮漏れや抜けが発生しますから。