2 回答
TA贡献1909条经验 获得超7个赞
我建议对此保持谨慎。有两个问题:
第一个问题是,当字符串不匹配时,像您向我们展示的那样的正则表达式可能会遇到性能问题。特别是,在匹配失败之前,您会得到很多不必要的回溯。
(可以通过使用“不情愿”或“占有”量词而不是“贪婪”量词来避免回溯,但您需要了解自己在做什么。)
即便如此,除非字符串很短,否则使用Base64.Decoder::decode
方法尝试 base64 解码并捕获可能的异常可能比使用正则表达式进行验证更有效。并且您拥有解码数据的潜在好处。
(也许作为加速,您可以在尝试完整的 base64 解码之前检查前 4 个和最后 4 个字符。)
第二个问题是(理论上)一个字符串在语法上可能与 Base64 一样有效,但它是由另一个“进程”产生的。因此,当您解码字符串时,您可能会得到垃圾。因此,作为验证的一部分,解码字符串并检查里面的内容可能值得。
我知道我可以使用一些 try catch 方法。但这对java来说是昂贵的操作。
都是相对的。此外,由于(我认为)Java 8 中引入的一些优化,较新的 JVM 可以更有效地抛出和处理异常。
TA贡献1834条经验 获得超8个赞
任何给定字符串的 base64 渲染只是另一个由 64 个标记组成的字符串。是否可以对字符串进行正则表达式检查是否仅包含该给定字母表的标记?是的。这是否意味着这样的字符串确实是有意使用 base64 编码的结果?不。另外请注意,仅由 64 个标记组成的字母表这一事实并不意味着是其他字符串的合法 base64 编码。由于字符串长度和可能的填充以及处理方式的问题,字符串“a”本身可能不是任何东西的有效 base64 编码,即使它包含的字母表可能暗示除此以外。
“尝试从实际内容中检测”通常是一种非常糟糕(因为完全容易出错)的策略。尽可能避免。
添加回答
举报