Html “构建”的最佳实践；“缩小你的结果范围”；产品过滤功能

我正在构建一个类似于和的“缩小结果范围”功能。将用户的筛选选择存储在可共享/书签的URL中的最佳做法是什么

显而易见的选择是将用户的所有选择保留在查询字符串中。然而，这两个例子都在做一些更神秘的事情：

百思买：

http://www.bestbuy.com/site/olstemplatemapper.jsp?id=pcat17080&type=page&qp=crootcategoryid%23%23-1%23%23-1~~Q70726F636573696E677496D653A3E313930302D30312D3031~~cabcat0500000%23%23%2311a~~cabcat0502000%23%230%23%23o~~nf518 | | 243630202D2024383939&list=y&nrp=15&sc=abComputerSP&sp=%2CurrentPrice+skuid&usc=abcat0500000

似乎他们正在为搜索分配一些唯一的值，并将其临时存储在自己的一侧。或者可能是因为他们相信默默无闻的安全性，所以将他们的db id包装在一堆垃圾中

保持这样的简单有什么固有的缺点吗？

www.mydomain.com？color=blue&type=laptop

因此，当我选择一个17英寸的屏幕大小作为过滤器时，它只需重新加载页面，并附加查询字符串：

www.mydomain.com？color=blue&type=laptop&screen size=17

另外，为了澄清，我可能会在URL中使用来自数据库的相应ID，以使验证和解析更容易/更快，但问题仍然是，在我的简单方法中是否存在我遗漏的一些问题

---

提前感谢！

我认为更具可读性的方式，即www.mydomain.com？color=blue&type=laptop&screen size=17是更好的方法。只需确保在url进入数据库之前，您正在清理url中的所有内容。

查询字符串的最大长度（255？），这可能是序列化的原因。

分面搜索领域的首批玩家之一是Endeca，他们仍然被许多人使用（PC连接、家得宝、沃尔玛…）。您可能想看看。 有一个。看看这个

---

我认为URL的组成并不重要，但我实际上认为以可读的形式呈现参数可能是危险的通过不允许无效的参数组合，可以避免生成空结果集。如果查询字符串是用户可编辑的，则它们可能会产生无效的组合，从而绕过引导搜索

实际长度是2048/个，但没错，这是一个很好的观点。有时，一半的战斗只是为了弄清楚谷歌的术语——感谢你提供的关于分面搜索的提示。我从没听说过这个词。