私は最近MyBatisを使用しています。私は以前にイバティスを使用したことがあります。全体的に、それは似ていますが、私はまだ多くの問題に遭遇しました。もう一度録音します。
次のように、最初に＃{}と$ {}の違いを紹介します。
1。＃すべての着信データを文字列として扱い、自動化するデータに二重引用符を追加します。たとえば、＃user_id＃で注文、渡された値が111の場合、sqlにパージするときの値は「111」で注文します。渡された値がIDである場合、SQLに解析された値は「ID」によって順序です。
2。$渡されたデータを直接表示し、SQLで生成します。たとえば、$ user_id $で注文します。渡された値が111の場合、sqlに解析されたときの値はuser_idによって順序です。渡された値がIDである場合、SQLに解析された値はIDで順序です。
3.＃メソッドは、SQL注入を大幅に防ぐことができます。
4. $メソッドはSQL注入を防ぐことはできません。
5。$メソッドは、一般に、テーブル名を渡すなど、データベースオブジェクトを渡すために使用されます。
6.一般的に、＃を使用できる場合は、$を使用しないでください。
MyBatisをソートするときに動的パラメーターで注文を使用する場合、＃の代わりに$を使用することに注意を払う必要があります。
文字列置換
デフォルトでは、＃{}形式の構文を使用すると、MyBatisが前処理されたステートメントプロパティを作成し、背景（？など）として安全な値を設定します。これは安全で迅速であり、SQLステートメントに直接変更されない文字列を挿入するだけです。たとえば、注文のように、次のように使用できます。
$ {columnName}で注文
ここで、MyBatisは文字列を変更または脱出しません。
重要：ユーザーからのコンテンツ出力を受け入れて、ステートメントの変更されていない文字列に提供することは安全ではありません。これにより、潜在的なSQLインジェクション攻撃につながる可能性があるため、ユーザーがこれらのフィールドに入ることを許可したり、通常はエスケープして自分でチェックすることを許可しないでください。
MyBatis自体の説明：
string substitutionby default、＃{}構文を使用すると、mybatisが準備されたステートメントプロパティを生成し、prepedStatementパラメーター（例：）に対して値を安全に設定します。これはより安全で、より速く、ほとんど常に好まれていますが、SQLステートメントに変更されていない文字列を直接注入したい場合があります。たとえば、注文の場合、次のようなものを使用する場合があります：$ {columnName} by $ {columnName}ここで、MyBatisは文字列を変更または逃がしません。これにより、潜在的なSQLインジェクション攻撃につながるため、これらのフィールドでのユーザー入力を許可するか、常に独自のエスケープとチェックを実行する必要があります。上記から見ることができます：
1。＃{}形式の構文を使用して、MyBatisで準備ステートメントを使用して値を安全に設定し、次のようにSQLを実行します。
preatedStatement ps = conn.preparestatement（sql）; ps.setint（1、id）;
これの利点は、より安全で、より速く、通常は好ましい実践です。
2。しかし、変更されていない文字列をSQLステートメントに直接挿入するだけです。たとえば、注文のように、次のように使用できます。
$ {columnName}で注文現時点では、MyBatisは文字列を変更または脱出しません。
この方法は次のとおりです。
ステートメントst = conn.createStatement（）; resultset rs = st.executequery（sql）;
この方法の欠点は次のとおりです。
ユーザーからのコンテンツの出力を受け入れ、この方法でステートメントで変更されていない文字列を提供することは安全ではありません。その結果、潜在的なSQLインジェクション攻撃が行われるため、ユーザーはこれらのフィールドに入ることは許可されていません。