「サニタイズ」しないでください SQLインジェクションを防ぐ手段としての入力-
ドメインが制限されているため、このケースは「安全」です base64_encode 関数。 ただし..
悪い習慣とbase64でエンコードされた値の保存（表示されたクエリが機能するように）には、いくつかのネガティブ 変更による影響 保存された情報：破棄 値の順序により、情報は簡単に検索できなくなります 、追加が必要です 「エンコード/デコード」ステップ、さらには消費 より多くのスペース-痛い！
したがって、base64でエンコードするデータには特定のケースがあるかもしれませんが、このアプローチはではありません。 SQLインジェクション を軽減する手段として最適です。 。
この問題は、テキストプロトコルを介してSQLにアクセスすることが原因です。 ここで、クエリコマンド/形状と値 混合されています。 正しいの使用 エスケープテクニック（例： mysql_real_escape_string ）SQLテキストが解析されるように情報がエスケープされるようにすることで、これを修正します。 意図したとおりですが、base64エンコードの手順とは異なり、は実行しません。 提供される情報を実際に変更してください！
この
「個々のプログラマー」がひどいクエリを書くのを防ぐための解決策は、防止することです。 アドホッククエリがコード内に散在しないようにする：データアクセス操作をデータアクセス層に収集します（ DAL） （おそらくORMと組み合わせて）関連するアクションのみを公開し、DAL内でSQLを適切に使用できるようにします。より単純なプロジェクトでは、DALは、衛生状態やその他の検証ロジックのビジネスルールを一元管理するのに適した場所でもあります。
より正確に：
-
サニタイズ ビジネスルールの値。これにより、ユーザー名が短すぎる、文字が制限されている、またはビジネス要件を満たしていないなどの「不正な情報」を防ぐことができます。
-
プレースホルダーを使用する SQLインジェクション を防ぐため 。これは厳密に SQLへのデータの転送に関連しており、SQL内の情報とは関係ありません。
MySQL5.6.1は