｛QUERY_STRING｝和参数的重写问题

Question

我搜索了一下，但没有找到我面临的htaccess重写问题的解决方案：

我正在尝试重定向此URL:

example.com/search.php?clearSearch=true&searchPhrase=keyword

到此URL:

example.com/topic/pages/search.php?search=keyword

我只想将"关键字"(单词和数字(转移到新的URL。

我测试了很多变化，但什么都没发生：

没有关键字的正常301重定向运行

redirectMatch 301 ^/search.php https://www.example.com/topic/pages/search.php?search=

但这个不运行：

RewriteEngine On
RewriteCond   %{REQUEST_URI}    ^/index.php$
RewriteCond   %{QUERY_STRING}   ^search.php?clearSearch=true&searchPhrase=([0-9]*)$
RewriteRule   ^(.*)$ https://www.example.com/topic/pages/search.php?search=%1   [R=302,L]

我的重写配置出了什么问题？

Answer 1

你的想法太复杂了。请考虑这种方法：

RewriteEngine On
RewriteCond   %{QUERY_STRING} (?:^|&)searchPhrase=(.*)(?:&|$)
RewriteRule   ^/?index.php$ /topic/pages/search.php?search=%1   [R=302,QSD,L]

最好从302临时重定向开始，然后在确定所有设置都正确后，再将其更改为301永久重定向。这可以防止在尝试时出现缓存问题。。。

此实现将在http服务器主机配置或分布式配置文件(".htaccess"文件(中同样工作。显然，重写模块需要加载在http服务器内部，并在http主机中启用。如果您使用分布式配置文件，则需要注意它的解释在主机配置中是否已启用，并且它位于主机的DOCUMENT_ROOT文件夹中。

还有一句话：你应该总是更喜欢在http服务器主机配置中放置这样的规则，而不是使用分布式配置文件(".htaccess"(。这些分布式配置文件增加了复杂性，通常是导致意外行为的原因，很难调试，而且它们确实会减慢http服务器的速度。它们只是在您无法访问真正的http服务器主机配置(读作：非常便宜的服务提供商(或应用程序坚持编写自己的规则(这显然是一场安全噩梦(的情况下提供的最后一个选项。