Chrome为何不解码location.hash并显示解码字符？是否为Bug及优化方案咨询

首先明确：你遇到的情况不属于Chrome的Bug，而是不同浏览器厂商对URL哈希（Hash）部分的编码显示规则不一样导致的。

为什么会出现这种差异？ #

URL的哈希部分（#之后的内容）虽然允许包含非ASCII字符，但不同浏览器的处理逻辑有区别：

• Chrome会对非ASCII的Unicode字符（比如希腊字母α）自动进行百分号编码（%CE%B1是α的UTF-8编码的百分号转义形式）后显示，这是遵循URL编码规范的一种实现；
• IE则选择直接显示原始的Unicode字符，处理方式更宽松。

两种实现都符合URL标准的基本要求，只是厂商的显示策略不同而已。

针对你的单页应用，如何让Chrome地址栏显示解码后的哈希？ #

如果你希望地址栏能美观显示原始的#αααααα，推荐用以下两种方案：

方案1：用HTML5 History API替代location.hash（推荐）

现代单页应用更推荐使用history.pushState()/history.replaceState()来管理路由状态，这种方式可以自定义地址栏显示的URL内容，包括非ASCII字符：

// 替换当前历史状态，设置解码后的哈希
history.replaceState({}, document.title, '#αααααα');

// 或者添加一条新的历史记录
history.pushState({}, document.title, '#αααααα');

同时，你需要监听popstate事件来处理浏览器的前进/后退操作，维持应用路由的一致性，逻辑和监听hashchange事件类似：

window.addEventListener('popstate', function(event) {
  // 这里处理路由变化逻辑，比如获取当前哈希并更新页面
  const currentHash = window.location.hash.slice(1);
  const decodedHash = decodeURIComponent(currentHash);
  // 你的应用逻辑...
});

这种方式下，Chrome地址栏会直接显示解码后的#αααααα，完美满足你的用户体验需求。

方案2：如果必须依赖location.hash

直接操作location.hash时，Chrome会自动编码非ASCII字符，无法直接修改这个内置行为，但可以结合History API来“覆盖”显示效果：

// 先设置哈希（会被Chrome自动编码）
location.hash = 'αααααα';
// 用replaceState替换地址栏显示为解码后的哈希
history.replaceState({}, document.title, '#' + decodeURIComponent(location.hash.slice(1)));

此时地址栏会显示#αααααα，而location.hash的实际值仍然是编码后的#%CE%B1%CE%B1%CE%B1%CE%B1%CE%B1%CE%B1，你在应用中可以通过decodeURIComponent(location.hash.slice(1))来获取原始字符内容。

注意事项 #

• History API需要浏览器支持HTML5，现代主流浏览器都兼容，如果你的应用需要兼容旧版IE（比如IE9及以下），可能需要做降级处理，回到location.hash的方式；
• 无论用哪种方案，处理哈希内容时都要注意编码解码的一致性，避免出现乱码或路由错误。

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