Detaillierte Erläuterung des Unterschieds zwischen #{} und $ {} in mybatis

Ich habe in letzter Zeit MyBatis verwendet. Ich habe Ibatis schon einmal benutzt. Insgesamt ist es ähnlich, aber ich habe immer noch viele Probleme gestoßen. Ich werde es wieder aufnehmen.

Lassen Sie mich zunächst den Unterschied zwischen #{} und $ {} in mybatis wie folgt vorstellen:

1. # Behandeln Sie alle eingehenden Daten als Zeichenfolge und fügen Sie den automatisch eingehenden Daten doppelte Zitate hinzu. Zum Beispiel: Bestellung von #user_id #, wenn der in 111 übergabe Wert 111 ist, ist der Wert beim Parsen in SQL durch "111" bestellt. Wenn der in ID IS -ID übergebene Wert an SQL analysiert wird, ist sie von "ID" bestellt.

2. Zeigt $ die übergebenen Daten direkt an und generiert sie in SQL. Zum Beispiel: Bestellung von $ user_id $, wenn der in SQL übergebene Wert 111 beträgt, ist der Wert von user_id. Wenn der in IS is ID übergebene Wert an SQL analysiert wird, ist die Bestellung durch ID.

3. Die # Methode kann die SQL -Injektion stark verhindern.

4. Die $ -Methode kann die SQL -Injektion nicht verhindern.

5. Die $ -Methode wird im Allgemeinen verwendet, um Datenbankobjekte zu übergeben, z. B. in Tabellennamen.

6. Im Allgemeinen, wenn Sie #verwenden können, verwenden Sie nicht $.

Bei Verwendung von Auftrag nach dynamischen Parametern beim Sortieren von MyBatis müssen Sie darauf achten, $ anstelle von # zu verwenden

Saitenersatz

Die Verwendung der #{} -Format -Syntax führt standardmäßig zu MyBatis, um eine vorverarbeitete Anweisung Eigenschaft zu erstellen und einen sicheren Wert damit als Hintergrund festzulegen (z. B.?). Dies ist sicher und schnell, und manchmal möchten Sie nur eine Zeichenfolge einfügen, die nicht direkt in die SQL -Anweisung ändert. Zum Beispiel können Sie wie Order by es so verwenden:
Bestellung von $ {columnName}

Hier wird MyBatis keine Zeichenfolgen ändern oder entkommen.

Wichtig: Es ist nicht sicher, die Inhaltsausgabe vom Benutzer zu akzeptieren und eine unveränderte Zeichenfolge in der Anweisung zu geben. Dies kann zu potenziellen SQL -Injektionsangriffen führen, sodass Sie den Benutzern nicht erlauben sollten, diese Felder zu betreten oder normalerweise selbst zu entkommen und selbst zu überprüfen.

Beschreibung von mybatis selbst:

 String Substitutionby -Standard -Standard -Verwenden der #{} -Syntax führt dazu, dass MyBatis vorbereitete Eigenschaften erzeugt und die Werte sicher gegen die vorbereiteten Parameter festlegen (z. B.?). Dies ist zwar sicherer, schneller und fast immer bevorzugt, aber manchmal möchten Sie einfach nur eine Zeichenfolge, die in der SQL -Anweisung nicht modifiziert wurde, direkt injizieren. Zum Beispiel können Sie für die Bestellung von so etwas wie folgt verwenden: Bestellung von $ {columnName} Hier modifiziert oder entkommen MyBatis die String nicht. Wenn es nicht sicher ist, Eingaben von einem Benutzer zu akzeptieren und sie auf diese Weise für eine nicht modifizierte Erklärung zu versorgen. Dies führt zu potenziellen SQL -Injektionsangriffen und Sie sollten daher entweder Benutzereingaben in diesen Feldern ablehnen oder immer Ihre eigenen Flucht und Überprüfungen durchführen.

Aus dem obigen können wir sehen:

1. Verwenden Sie die #{} -Format -Syntax, um die Vorbereitungsanweisung in MyBatis zu verwenden, um Werte sicher festzulegen, und führen Sie SQL ähnlich wie folgt aus:

 PrepedStatement ps = conn.preparestatement (SQL); ps.Setint (1, id);

Der Vorteil davon ist: sicherer, schneller und ist normalerweise die bevorzugte Praxis.

2. Aber manchmal möchten Sie nur eine unveränderte Zeichenfolge direkt in die SQL -Anweisung einfügen. Zum Beispiel können Sie wie Order by es so verwenden:

 Bestellung von $ {columnName}

Zu diesem Zeitpunkt wird MyBatis der Zeichenfolge nicht ändern oder entkommen.

Diese Methode ähnelt:

 Anweisung ST = Conn.CreateStatement (); Ergebnisset RS = St.ExecuteQuery (SQL);

Die Nachteile dieser Methode sind:

Es ist unsicher, die Inhaltsausgabe vom Benutzer zu akzeptieren und in der Anweisung auf diese Weise unveränderte Zeichenfolgen bereitzustellen, was zu potenziellen SQL -Injektionsangriffen führt. Daher darf der Benutzer diese Felder nicht betreten oder entkommen und selbst überprüfen.