sqlunicode解码sql语句，解码句说白了就是解码句把一串看起来像乱码的Unicode编码，还原成人话能看懂的解码句SQL。这事我上周刚干过一次，解码句客户发来一段日志，解码句里面全是解码句`%u0053%u0045%u004C%u0045%u0043%u0054`这种玩意儿，肉眼根本没法读。解码句

先别急着上工具。解码句你得知道这玩意儿怎么来的解码句。有些程序为了防止SQL注入，解码句会把用户输入的解码句关键字做Unicode编码，或者某些防火墙在记录攻击流量时，解码句也会把SQL语句转成这种格式。解码句还有更狠的解码句，直接给你整成`\u0053\u0045\u004C`，解码句连百分号都省了。不管哪种，解码原理都一样——Unicode码点转字符。

我见过最坑的一种情况，是编码套编码。日志里先是`%u0053`，你解码完发现是`S`，结果后面还有一层`%53%45%4C`，这是URL编码的ASCII。你得先做URL decode，再做Unicode decode，顺序反了直接乱套。有一次我图省事，直接拿Python的`urllib.parse.unquote`处理，结果把`%u`开头的全给漏了，那叫一个惨。

说回正题。解码SQL语句，核心就是把每个`%uXXXX`或者`\uXXXX`替换成对应的字符。XXXX是四位十六进制数，查表或者用编程语言的内置函数都行。比如`\u0048`就是`H`，`\u0049`是`I`，拼起来就是`HI`。SQL语句里常见的`SELECT`，编码后就是`\u0053\u0045\u004C\u0045\u0043\u0054`，你看，每个字母都对应一个四位码。

手动解太慢，我一般直接写个正则替换。Python里一行代码的事：re.sub(r'%u([0-9A-Fa-f]{ 4})', lambda m: chr(int(m.group(1), 16)), s)。要是遇到`\u`开头的，把正则改成`\\u([0-9A-Fa-f]{ 4})`就行。注意转义符，别被Python的字符串转义坑了，最好用raw string。

解码完你就知道攻击者在干嘛了。我之前处理过一个案例，解码后是`SELECT * FROM users WHERE id = 1 OR 1=1 --`。典型的万能密码注入，后面跟个注释符把原本的SQL尾巴给吞了。要是没解码，你根本看不出这串编码背后藏着什么猫腻，防火墙报个`SQL Injection`警告，你还得猜它到底注入了啥。

还有种情况，是编码里混着中文。比如`%u67E5%u8BE2`，解码出来是“查询”俩字。这种情况多见于某些国产中间件的日志，它对非ASCII字符做了Unicode转义。你要是不知道这层，看到一串`%u`开头的东西就头大，其实翻译过来就是一句简单的`查询用户信息`。

说实话，这活儿不难，但容易出错。最容易翻车的是大小写和零填充。`%u0053`和`%u53`——后者只有两位，严格来说不合法，但有些系统会漏掉前导零。你解码的时候得自己补上，不然`chr(0x53)`直接给你来个`S`，看着对，可万一遇到`%u5`这种，那就彻底没辙了，得回去翻原始日志看是不是被截断了。

另外，别迷信在线解码工具。有些网站会把`%u`和`%`混着处理，你输入一段混合编码，它给你解出个四不像。我吃过一次亏，拿在线工具解一段带`%3D`（等号）的字符串，结果它把等号也给Unicode解码了，输出直接变成乱码。所以，关键时候还是自己写脚本靠谱，哪怕就十行代码，至少你能控制每一步的规则。

最后提一句，解码只是第一步。解出来之后你得分析那条SQL到底想干嘛。是拖库还是删表？是绕过认证还是读取敏感文件？我见过有人解码完就扔一边，说“哦，是SELECT”，结果那条语句是`SELECT load_file('/etc/passwd')`——这能一样吗？解码是手段，看懂攻击意图才是目的。