SQL標準同様に、文字列リテラルはシングルクォートで囲み、識別子をクォートする場合は、ダブルクォートで囲むことになっています。識別子(テーブル名、列名等)しかし、マニュアルによると、SQLiteのクォーティングには例外があります。それを実例で紹介しましょぅ。a;1sqlite>続いて、以下を実行します。ところが文法違反に見えますよね。FROMの後には表の名前が続くはずです。列名だとするとそのような列は存在しないので、こちらもエラーになるはずです。SQLiteの場合、上記SQL文はエラーにならず、以下の結果となります。'a';a|1|1|1|aasqlite>これはどういうことでしょうか?その答えは、SQLiteのマニュアルにあります。引用すなわち、シングルクォートで囲まれたキーワードが、文字列リテラルが許可されていない箇所に置かれている場合、識別子として認識されます。ダブルクォートで囲まれたキーワードであるのに、該当する列名等がない場合、文字列リテラルとして認識されます。僕達の気持ちをここまでくんでくれるなんて!!というのはもちろん冗談で、こんなのは余計なお世話としか言いようがありません。開発者が間違った場合でもエラーにならず、見つけにくいバグの原因になりそうです。SQL風)や、バッククォートで囲む方式(MySQL風)もサポートしていますが、これらの場合は、自動的に文字列リテラルとして認識されることはないようです。これらを使えば...という意見もありそうですが、ISO標準にはない書き方なので、移植性がそこなわれますよね。すれば、勝手に文字列リテラルとして認識されることもないし、移植性も損なわれません。この問題に起因するセキュリティ上の問題はないか考えてみましたが、思いつきませんでした。思いついた方があれば、ぜひ教えてください。追記(20:35)この問題が原因で脆弱性となる例を考えましたので紹介します。ログイン処理で、「ログイン状態を保存」をトークンを用いて実装していたとします。SQL文は下記となります(SQLインジェクション対策はされていると想定)。一致するものがあれば、そのユーザで自動ログインするという想定です。つづりを以下のように間違えていたとします。指定するとログインできてしまうことになります。し・か・し・な・が・ら、この例では正常系がまともに動かないため、テストさえしていれば、この脆弱性が入ったままリリースされることはないでしょう...ということで、あまり現実的ではない...しかし、絶対にないとも言い切れない...脆弱性の例でした。