是否有与 PHP 的 mysql_real_escape_string() 等效的 Java？
这是为了在将 SQL 注入(inject)尝试传递给 Statement.execute() 之前对其进行转义。
我知道我可以使用 PreparedStatement 代替，但我们假设这些是一次性语句，因此准备它们将导致 lower performance .我已经将代码更改为使用 PreparedStatement，但鉴于现有代码的结构方式，escape() 函数将使代码更改更易于查看和维护；我更喜欢易于维护的代码，除非有令人信服的理由导致额外的复杂性。此外，数据库对 PreparedStatements 的处理方式也有所不同，因此这可能会使我们面临以前从未遇到过的数据库中的错误，需要在发布到生产环境之前进行更多测试。
Apache StringEscapeUtils escapeSQL()只转义单引号。
后记: 我继承的环境中有很多微妙之处是我在我的问题中刻意避免的。
需要考虑的两点:
1) 准备好的语句不是万能的，不能提供 100% 的 SQL 注入(inject)保护。一些数据库驱动程序使用不安全的字符串连接来实例化参数化查询，而不是将查询预编译为二进制形式。此外，如果您的 SQL 依赖于存储过程，则需要确保存储过程本身不会以不安全的方式构建查询。
2) 大多数准备好的语句实现将语句绑定(bind)到实例化该语句的数据库连接。如果使用数据库连接池，需要注意
仅将准备好的语句引用与准备它的连接一起使用。一些池化机制确实透明地实现了这一点。否则，您也可以合并准备好的语句，或者(最简单但开销更大)为每个查询创建一个新的准备好的语句。
最佳答案
据我所知，没有“标准”的方法。
尽管您目前存在顾虑，但我强烈建议您使用准备好的语句。对性能的影响可以忽略不计 - 我们也有类似的情况，每秒有数千条语句 - 其中大多数也是一次性的。
您获得的安全性应该比您尚未见过的性能问题更重要。在我看来，这是“不要过早优化”的明显情况。
无论如何，如果您稍后真的发现遇到性能问题，请通过仔分割析确保准备好的语句确实是原因，然后寻找替代方案。在此之前，您应该省去尝试正确逃脱的麻烦。
这更重要，因为我推断您正在开发某种面向公众的网站 - 内部应用程序很少获得足够的流量来关注性能。
关于PHP 的 mysql_real_escape_string() 的 Java 等价物，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1018292/