StringEscapeUtils.escapeSql von commons.lang migrieren

Ich habe angefangen Commons.lang 2 zu commons.lang3 zu migrieren.StringEscapeUtils.escapeSql von commons.lang migrieren

Nach https://commons.apache.org/proper/commons-lang/article3_0.html

StringEscapeUtils.escapeSql

Dies war eine irreführende Methode, nur die einfachsten möglichen SQL Bearbeitung von Fällen. > Da SQL nicht Langs Fokus ist, machte es keinen Sinn, diese Methode beizubehalten.

Verstehen Sie es, aber was wird empfohlen, statt es zu verwenden?

Klärung

Können Sie eine dritte Partei empfehlen, die einfach escapeSql zu StringEscapeUtils.escapeSql ähnlich durchführen?

Quelle

2015-08-19 Michael

Beschreiben Sie Ihren Anwendungsfall. Der einfachste wäre "Datenbankabfragen ausführen", und dafür müssen Sie normalerweise keine SQL-Anweisungen entziffern (Sie können und sollten Bindevariablen verwenden). – Thilo

Ergänzung hinzugefügt – Michael

Warum möchten Sie das tun? Es scheint eine schlechte Idee zu sein, also kann ich verstehen, warum die Methode entfernt wurde. – Thilo

From the Javadocs:

Derzeit stellt sich diese Methode nur einfache Anführungszeichen in verdoppelt Apostrophe („McHale Marine“ => „McHale" Marine“).

Dies war der Methodencode:

/** 
675   * <p>Escapes the characters in a <code>String</code> to be suitable to pass to 
676   * an SQL query.</p> 
677   * 
678   * <p>For example, 
679   * <pre>statement.executeQuery("SELECT * FROM MOVIES WHERE TITLE='" + 
680   * StringEscapeUtils.escapeSql("McHale's Navy") + 
681   * "'");</pre> 
682   * </p> 
683   * 
684   * <p>At present, this method only turns single-quotes into doubled single-quotes 
685   * (<code>"McHale's Navy"</code> => <code>"McHale''s Navy"</code>). It does not 
686   * handle the cases of percent (%) or underscore (_) for use in LIKE clauses.</p> 
687   * 
688   * see http://www.jguru.com/faq/view.jsp?EID=8881 
689   * @param str the string to escape, may be null 
690   * @return a new String, escaped for SQL, <code>null</code> if null string input 
691   */ 
692  public static String escapeSql(String str) { 
693   if (str == null) { 
694    return null; 
695   } 
696   return StringUtils.replace(str, "'", "''"); 
697  }

So könnte man leicht die Methode mit einem einfachen Anruf String#replace ersetzen.

Es gibt jedoch einen Grund, dass die Methode entfernt wurde. Es war wirklich unausgegoren und ich kann mir keinen guten Grund vorstellen, warum du es benutzen willst. Um beispielsweise JDBC-Abfragen auszuführen, können und sollten Sie Bind-Variablen verwenden, anstatt zu versuchen, String-Literale zu interpolieren und zu escapen.

Quelle

2015-08-19 13:30:41 Thilo

Tatsächlich gibt es einen Anwendungsfall: Entweder Teile der SQL-Anweisung, die nicht mit Bind-Variablen parametrisiert werden können. Z.B. Der Tabellenname selbst: http://stackoverflow.com/q/1208442/274677 –

@MarcusJuniusBrutus: Ich würde nicht auf die gleichen Escaping-Regeln zählen, die dort verwendet werden. Und wenn Sie Dinge wie Leerzeichen oder Anführungszeichen in Schema-Objektnamen verwenden, bitten Sie bereits um Probleme. – Thilo

Falls Sie eine JDBC-Verbindung verwenden, um eine Erklärung mit Parametern wie der Vorbereitung:

con.prepareStatement("INSERT INTO table1 VALUES (?,?)"); 
pstmt.setInt(1, 200); 
pstmt.setString(2, "Julie"); 
pstmt.executeUpdate();

Sie alle Elemente zu entkommen nicht brauchen, die Sie mit den Funktionen auf einer vorbereiteten Erklärung einzufügen. Diese werden automatisch maskiert.

Dies beantwortet wurde, bevor in: Java - escape string to prevent SQL injection

Quelle

2015-08-19 13:31:20

eine API von OWASP ESAPI genannt Es ist, dass einige dieser Funktionen zur Verfügung stellt, können Sie es heraus überprüfen können.

Quelle

2016-06-27 07:01:26 bub

StringEscapeUtils.escapeSql von commons.lang migrieren

Antwort

Verwandte Themen