Chrome和Edge中GET参数自动编码异常是否属于Bug？

问题场景 #

某遗留Web应用采用Shift_JIS作为页面字符编码，通过JavaScript设置GET参数时，特定多字节字符“ー”出现编码异常：

• 浏览器自动编码结果为%81[
• 符合Shift_JIS规范的正确编码应为%81%5B
• 旧版Tomcat允许该请求，新版Tomcat则因“违反RFC 7230和RFC 3986规范”报错

示例代码如下：

<!doctype html>
<html>
<head>
    <title>Shift_JIS_AutoUrlEncode_Bug?</title>
    <meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
    <script type="text/javascript">
    <!--
    function exec() {
        var url = location.href.split('?')[0];
        
        location.href = url + '?value=フー'
    }
    -->
    </script>
</head>
<body>
    <input type="button" value="Go Get Paramater Auto Encode!" onclick="exec();">
</body>
</html>

结论：这不是Chrome和Edge的Bug #

浏览器的行为是遵循URL编码规范与Shift_JIS字符集特性的正常结果，具体原因如下：

1. Shift_JIS字符集中，“ー”对应的字节是0x81和0x5B，其中0x5B恰好对应ASCII字符左方括号[。
2. 根据URL编码规范，ASCII范围内的可打印字符（包括[）允许直接出现在URL中，无需进行百分号编码。
3. 因此浏览器仅对非ASCII的0x81进行编码得到%81，而0x5B对应的[直接保留，最终形成%81[的结果。
4. 新旧版Tomcat的差异在于对URL规范的严格程度：旧版校验宽松允许混合编码，新版严格遵循RFC规范，要求所有非标准URL字符必须完整百分号编码，因此触发报错。

解决方案 #

不要依赖浏览器的自动编码逻辑，手动使用encodeURIComponent()对GET参数值进行编码，确保所有字节都被正确转换：

function exec() {
    var url = location.href.split('?')[0];
    var value = encodeURIComponent('フー');
    location.href = url + '?value=' + value;
}

encodeURIComponent()会将Shift_JIS的0x81和0x5B分别编码为%81和%5B，最终生成符合RFC规范的%81%5B，可被新版Tomcat正常处理。

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