Java的等效PHP的mysql_real_escape_string（） [英] Java equivalent for PHP's mysql_real_escape_string()

问题描述

是否存在类似于PHP的mysql_real_escape_string（）的Java？

Is there a Java equivalent to PHP's mysql_real_escape_string() ?

这是为了在将SQL注入尝试传递给Statement.execute（）之前将其转义。

This is to escape SQL injection attempts before passing them to Statement.execute().

我知道我可以使用PreparedStatement，但我们假设这些是一次性语句，所以准备它们将导致性能降低。我已经将代码更改为使用PreparedStatement但是考虑到现有代码的结构，escape（）函数会使代码更改更容易查看和维护;我更喜欢易于维护代码，除非有一个令人信服的理由来增加复杂性。此外，PreparedStatements由数据库以不同方式处理，因此这可能会使我们面临数据库中我们之前未遇到过的错误，需要在发布到生产之前进行更多测试。

I know I can use PreparedStatement instead, but let's assume these are one shot statements so preparing them will result in lower performance. I've already changed the code to use PreparedStatement but given the way the existing code was structured, an escape() function would make the code changes much simpler to review and maintain; I prefer easy to maintain code unless there is a compelling reason for the extra complexity. Also PreparedStatements are handled differently by the database, so this could expose us to bugs in the database that we haven't run into before, requiring more testing before releasing to production.

仅 Apache StringEscapeUtils escapeSQL（）转义单引号。

后记：
在我继承的环境中有很多细微之处，我在我的问题中故意避免。

Postscript: There are a lot of subtleties in the environment I inherited that I deliberately avoided in my question.

要考虑的两点：

1）准备好的声明不是灵丹妙药，也不能提供100％的SQL注入保护。某些数据库驱动程序使用不安全的字符串连接实例化参数化查询，而不是将查询预编译为二进制形式。此外，如果您的SQL依赖于存储过程，则需要确保存储过程本身不会以不安全的方式构建查询。

1) Prepared statements are not a panacea and do not provide 100% protection against SQL injection. Some database drivers instantiate parameterised queries using unsafe string concatenation, rather than pre-compiling the query to a binary form. Also, if your SQL relies on stored procedures, you need to ensure the stored procedures do not themselves build queries in unsafe ways.

2）大多数预准备语句实现将语句绑定到语句被实例化的数据库连接上。如果您正在使用数据库连接池，则需要注意

仅使用准备好的语句引用与其准备的连接。一些池化机制确实透明地实现了这一点。否则你也可以汇集预备语句或（最简单但更多开销）为每个查询创建一个新的预准备语句。

2) Most prepared statement implementation bind the statement to the database connection the statement was instantiated on. If you are using database connection pooling, you need to be careful to
use the prepared statement reference only with the connection it was prepared on. Some pooling mechanisms do implement this transparently. Otherwise you could pool the prepared statements as well or (simplest but more overhead) create a new prepared statement for every query.

推荐答案

据我所知，没有标准方法可以做到这一点。

As far as I know, there is no "standard" way to do it.

尽管你目前担心，我强烈建议使用准备好的陈述。性能影响可以忽略不计 - 我们也有类似的情况，每秒有几千个语句 - 其中大部分都是一次性的。

I strongly suggest using prepared statements despite your current concerns. The performance impact is going to be negligible - we have a similar situation with several thousand statements per second - most of them one-shots as well.

你获得的安全性应该是比你还没见过的性能问题要高得多。在我看来，这是一个明确的情况不要过早优化。

The security you gain should be weighed much higher than a performance problem you have not even seen yet. In my opinion this is a clear situation of "Don't optimize prematurely".

在任何情况下，如果你真的发现你遇到性能问题，请确保通过仔细分析然后寻找替代方案，准备好的陈述真的是原因。直到那时你应该省去试图逃避正确的麻烦。

In any case should you really find out later that you run into performance problems, make sure that the prepared statements are really the cause by profiling carefully and then look for alternatives. Till then you should save yourself the hassle of trying to get the escaping right.

这更为重要因为我推断你正在开发某种面向公众的网站 - 内部应用程序很少获得足够的流量来关注性能。

This is even more important as I infer you are developing some sort of public facing site - internal apps seldom get enough traffic to be concerned about performance anyway.

这篇关于Java的等效PHP的mysql_real_escape_string（）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！