如何支持GB18030字符集 解决含该字符虚拟机RDP连接报403问题

问题根因 #

连接名称含GB18030字符的虚拟机时触发403，核心诱因通常不是权限问题，是三层编码不兼容：

1. 服务网关/容器默认URI编码仅支持UTF-8，GB18030生僻字的字节序列被识别为非法请求内容直接拦截
2. RDP协议层默认使用UTF-16LE编码传输字符串，传入未做适配的GB18030/UTF-8字节流会触发协议校验失败
3. 前置WAF/负载均衡的规则误把GB18030特殊字节判定为攻击特征拦截

具体配置步骤 #

• 配置请求链路URI编码兼容GB18030
  不用全局替换原有UTF-8配置，按服务栈做兼容即可：
  • 若用Nginx做反向代理，在对应服务的location块中添加charset GB18030;，同时关闭proxy_set_header中对URI的强制UTF-8转义，避免GB18030字符被转成乱码
  • 若用Tomcat/Jetty等Java容器，在Connector配置中添加URIEncoding="GB18030" useBodyEncodingForURI="true"，让容器可正确解析GB18030编码的URI参数
  • 若为自研的Go/Python服务，在URI解析逻辑中加入编码探测：优先按UTF-8解码，解码失败自动fallback到GB18030解码，不要硬编码仅支持UTF-8
• RDP协议层编码适配
  不需要手动做UTF-8/UTF-16全量转码。RDP客户端SDK一般要求传入语言原生的Unicode字符串（Python3为str类型、Java为String类型），你只需要把解析得到的GB18030字符转成对应语言的原生字符串类型即可，SDK会自动完成到协议要求的UTF-16LE编码转换，自行手动拼接UTF-16字节流很容易因字节序、BOM头错误导致识别失败。
• 调整网关拦截规则
  排查前置WAF、API网关的拦截日志，确认是否存在GB18030字符字节匹配攻击特征的情况，将RDP连接请求的路径加入编码白名单，允许GB18030全字节范围通过。

替代实现方案 #

• 全链路编码归一：在服务入口层就把所有传入的GB18030字符统一转成UTF-8编码，后续业务链路全量使用UTF-8传递参数，仅在调用RDP SDK时做协议层的编码适配，减少多链路编码不一致的问题
• 改参数传输位置：不要把包含GB18030字符的虚拟机名称放在URI中传递，统一放到POST请求体中传输，请求体的编码可控性远高于URI，基本不会触发编码类的403拦截

注意：不要直接对GB18030字符做默认URL编码，大部分标准URL编码器默认按UTF-8规则转码，会把GB18030生僻字转成错误字节序列，反而加重乱码问题。

内容的提问来源于stack exchange，提问作者user14337934