在 community.wanikani.com 上，当在新标签页中打开或复制粘贴链接时，打开包含日语的完整 URL 主题链接的功能已失效。但在同一标签页内点击链接进行导航仍正常工作。
例如，在新标签页中打开 此链接 本应导航至
キノの旅 Home Thread (Intermediate Book Club) - Book Clubs - WaniKani Community
但实际却尝试导航至
キノの旅 Home Thread (Intermediate Book Club) - Book Clubs - WaniKani Community
导致无法加载。
如果 链接 恰好完全匹配，则能正常工作。当然，由于主题标题经常会被重命名，这种情况并不常见。
我也尝试在 try.discourse.org 上复现此问题，但在那里的安装版本中，即使主题标题中包含日文字符，URL 中也从未添加这些字符。我不确定原因是什么，但由于没有发生这种情况，我无法在那里演示该错误。
这两个链接都指向主题 34890。我在 Firefox 中打开都没问题。请问是什么问题？
叹气 看来这可能是又一个 Chrome 的 bug。我在 Firefox 和 Edge 中测试都正常。奇怪的是，在无痕模式下第一次打开时没问题，但第二次就失败了。清除网站缓存/Cookie 并重启电脑后，问题依旧。Chrome 提示的错误是“重定向次数过多”。
能否麻烦你在 Chrome 中检查一下，确认这是否是一个普遍问题，而不仅仅是我这边的问题？请注意，尝试多次打开页面，因为第一次似乎能正常加载。非常感谢您的帮助！
我可以在 Chrome 移动版上复现。
谢谢。我想我会向 Google 报告这个问题。
在我的安卓手机的 Chrome 浏览器上，第二个链接会无限重定向。
还在用 Chrome 吗？在向 Chrome 团队报告之前，我想先确认一下。我假设 Discourse 最近没有与此相关的变更？（无论如何，这很可能仍然是 Chrome 的问题，因为该问题仅出现在 Chrome 中，即使 Discourse 方面确实发生了某些变更。）
稍等一下，这可能是 Discourse 的问题，甚至可能是服务工作者（service worker）的 bug。
好的，感谢更新。
关于此事有任何更新吗？
这需要一些时间来解决，因为它已经分配好了，所以不会遗漏。
我不指望能找到任何解决方案或变通方法。我们只能等待修复。
您是否仍遇到此问题？看起来可能已修复，除非这次我操作方式有所不同。
哎呀，我收回刚才的话。今天这个问题又出现了。我完全不知道它之前是怎么被暂时修复的。
既然这可能需要一段时间，我暂时愿意接受一些变通方案。我在主题开头提到过，在 try 上（我也在 meta 上确认过）日文字符从未被添加到 URL 中，从而有效地绕过了这个问题。这是不是某个网站或分类的设置，我可以和我的网站管理员讨论一下？除了这个之外，还有其他变通方法的建议吗？
当我在浏览器中输入带有阿拉伯语标题的 URL 时，例如：
https://forums.coretabs.net/t/2456
我会陷入无限重定向（而且生成的链接不正确，我猜这与编码有关）
它应该重定向到：
https://forums.coretabs.net/t/ماذا-يجب-ان-نتعلم-في-javascript-؟/2456
因为 Twitter 和 Facebook 对阿拉伯语的支持不佳：
我已经深入研究了我们的代码库，看起来这个错误比较简单，但我还是想确认一下我的假设。
我们有一个名为 slug_generation_method 的站点设置，必须将其从默认的 ascii 值更改为 encoded 才能触发此错误。当您更改此站点设置时，我们会清除所有 slug 并重新生成它们。
我不理解的是，为什么当站点设置设置为“encoded”时，我们会生成如下 slug：
[3] pry(main)> SiteSetting.slug_generation_method
=> "encoded"
[4] pry(main)> Slug.for(t.slug)
=> "キノの旅-home-thread-intermediate-book-club"
而我原本以为“encoded”意味着类似以下内容：
[5] pry(main)> CGI.escape(Slug.for(t.slug))
=> "%E3%82%AD%E3%83%8E%E3%81%AE%E6%97%85-home-thread-intermediate-book-club"
这似乎来自
当主题 slug 不匹配时，来自表的原始 slug 会返回在 301 响应的 Location 头中，依我看来，我们应该在其中返回一个有效的 URL。
是的，我们应该清理一下编码后的 slug 生成方法，减少对浏览器内置机制的依赖。
所以你的意思是 URL 本身会显示编码后的版本？还是说重定向会在内部通过使用该编码版本来处理？无论如何，让这一切“自动生效”而不依赖浏览器的特性，那就太好了。
你好，
这个案例解决了吗？
因为我仍然遇到这个问题，正如我在 我发起的主题 中关于此事所发布的那样。
没有，正如 bug 分类下的开放主题所示 
@sam 我今天又看了一下这个问题，有两种解决方案：
当 slug 生成设置设为 encoded 时，在 slug 列中存储实际的 编码后 slug。执行一次迁移，清除当前所有使用编码 slug 的记录，以便它们能随时间正确重新生成。
保留当前的 UTF-8 slug，并在发送 301 重定向的 header 时动态修补它。
就我而言，方案 1“更正确”，并且会使向客户端传递原始 slug 变得更困难。不过，仅仅修补 slug 生成器是不够的，因为浏览器在收到 301 重定向时会获取到编码后的 URL，但在下一次请求时会对其进行解码，导致我们的 slug 比较失败并再次重定向。这意味着我还需要修补 topics 控制器中的 slug 比较方法，可能还有其他地方。
我应该继续沿着这条路走吗？