JS 中的 URL 编码以实现有意义的 URL 和 Rails 页面缓存

发布于 2024-09-03 16:19:36 字数 1096 浏览 4 评论 0原文

我正在运行一个 Rails 应用程序,目前该应用程序的流量很大,因此我开始使用页面缓存来提高性能。到目前为止,一切都很顺利。但是当我尝试缓存搜索结果时,我遇到了一个奇怪的问题。

我的方法:

  • 使用有意义的 URL 进行搜索和分页(/search?query=term&page=3 变为 /search/term/3)
  • 使用 Javascript 提交表单 - 如果 JS 被禁用,则会回退到旧的形式(它也适用于我的路线,但没有缓存)

我的代码:

// Javascript
function set_search_action() {
  window.location = '/search/' + escape(document.getElementById('query').value);
  return false;
}

// HTML
<form action="/search" id="search_form" method="get" onSubmit="return set_search_action();">
  <input id="query" name="query" title="Search" type="text" />
  <input class="submit" name="commit" type="submit" value="Search" />
</form>

问题

一切都适用于像“term”这样的单个单词。但是,当我搜索“term1 term2”时,表单将提交到 /search/term1 term2//search/term1 term2/1 。应该提交到 /search/term1+term2 我认为这就是 JS 转义函数应该做的事情。

到目前为止,它也适用于开发模式下的空间。但我猜想在启用缓存的生产模式下这将成为一个问题(URL 不应包含任何空格)。

关于我做错了什么有什么想法吗?谢谢!

I'm running a Rails Application which gets a lot of traffic at the moment so I started using Page Caching to increase the performance. So far everything works like a charm. But when I tried to also cache search results I run into a strange problem.

My Approach:

  • Use meaningful URLs for searching and pagination (/search?query=term&page=3 becomes /search/term/3)
  • Use Javascript to submit the form - if JS is disabled it falls back to the old form (which also works with my routes, but without caching)

My Code:

// Javascript
function set_search_action() {
  window.location = '/search/' + escape(document.getElementById('query').value);
  return false;
}

// HTML
<form action="/search" id="search_form" method="get" onSubmit="return set_search_action();">
  <input id="query" name="query" title="Search" type="text" />
  <input class="submit" name="commit" type="submit" value="Search" />
</form>

The Problem

Everything works for single words like "term". But when I search for "term1 term2" the form is submitted to /search/term1 term2/ or /search/term1 term2/1 . It should be submitted to /search/term1+term2 That's what the JS escape function should do I think.

So far it works also with spaces in development mode. But I guess it will become a problem in production mode with caching enabled (URLs shouldn't contain any whitespaces).

Any ideas on what I did wrong? Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

零時差 2024-09-10 16:19:37

应提交至 /search/term1+term2

不。加号仅代表 application/x-www-form-urlencoded 内容中的空格,例如当 URL 的查询字符串部分用于提交表单时。在 URL 的路径部分中,+ 只是表示加号;空格应编码为 %20

我认为这就是 JS 转义函数应该做的事情。

是的,确实如此,这就是问题所在。 escape将空格编码为+,仅适用于表单提交;在路径中使用时,您会得到一个意外且不需要的加号。它还将非 ASCII 字符转换为特定于 escape 函数的任意格式,而 URL 解码器无法读取该格式。

正如 Tomalak 所说,escape()/unescape() 几乎总是错误的,通常不应该使用。 encodeURIComponent() 通常是您真正想要的,并且将为空格生成 %20,这是安全的,因为它在路径部分或查询字符串中同样有效。

It should be submitted to /search/term1+term2

Nope. Plus symbols only represent spaces in application/x-www-form-urlencoded content, such as when the query-string part of the URL is used to submit a form. In the path-part of a URL, + simply means plus; space should be encoded to %20 instead.

That's what the JS escape function should do I think.

Yes it does, and that's the problem. escape encodes spaces to +, which is only suitable for form submissions; used in a path, you will get an unexpected and unwanted plus sign. It also mangles non-ASCII characters into an arbitrary format specific to the escape function that no URL-decoder will be able to read.

As Tomalak said, escape()/unescape() is almost always the wrong thing, and in general should not be used. encodeURIComponent() is usually what you really want, and will produce %20 for spaces, which is safe as it is equally valid in the path part or the query string.

情仇皆在手 2024-09-10 16:19:37

切勿使用escape()!它已经损坏,并且对于您所做的事情强烈不推荐。请改用encodeURIComponent()

要使用 + 而不是 %20,请附加 .replace(/%20/g, "+")

Never use escape()! It's broken and highly dis-recommended for what you do. Use encodeURIComponent() instead.

To have + instead of %20, append a .replace(/%20/g, "+").

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文