htaccess重寫和重定向SEO友好的URL

Question

我知道這個問題過去可能重復或回答過，但是我已經閱讀了apache.org網站，並且看到了許多其他類似的答案，並且由於我是.htaccess和阿帕奇。

為簡單起見，我們假設我網站的網址為： https://www.example.com : https://www.example.com

主頁是index.php ，有一個帶有3個select / dropdowns元素的提交表單，它們的名稱分別為： sp ， ar和in 。 sp是強制性的（用戶必須輸入一個值）， ar和in是可選的。

當我提交表單時，將執行文件results.php 。 當所有3個下拉列表均具有值時，提交的URL的形式為：

1) https://www.example.com/results.php?sp=textvalue1&ar=textvalue2&in=textvalue3

此外，根據ar和in是否具有（或沒有）值，URL的其他可能形式為：

2) https://www.example.com/results.php?sp=textvalue1&ar=&in= 
3) https://www.example.com/results.php?sp=textvalue1&ar=textvalue2&in= 
4) https://www.example.com/results.php?sp=textvalue1&ar=&in=textvalue3 

我想將這些“難看的” URL轉換為SEO友好的URL。

對於案例1（所有3個下拉列表都有值），我想提交表單並在瀏覽器的URL字段中查看：

(case 1) https://www.example.com/textvalue1/textvalue2/textvalue3

並獲得相同的結果（重要）！

同樣，我希望其他SEO友好的網址為：

(case 2) https://www.example.com/textvalue1
(case 3) https://www.example.com/textvalue1/textvalue2
(case 4) https://www.example.com/textvalue1/textvalue3

我的猜測是，我必須做兩件事：首先，將丑陋的URL轉換為SEO友好的URL，其次，將新的SEO友好URL視為舊的丑陋的URL。

到目前為止，我已經在案例2的.htaccess文件中嘗試了以下命令，但沒有任何反應：

Options +FollowSymlinks -Indexes -MultiViews
RewriteEngine On
RewriteCond %{THE_REQUEST} \s/results\.php\?sp=([a-zA-Z]+)\s [NC]
RewriteRule ^ /%1? [R=302,L]
RewriteRule ^/([[a-zA-Z]]+)$ /results.php?sp=$1 [L]

Answer 1

正如該問題的注釋中已經討論的那樣，我看到了有關重寫邏輯的問題。 您要求針對所有三個請求參數都存在的情況顯示一種更簡化的方法。 這是一個建議，也可以處理僅指定兩個參數的情況。 您甚至不需要這些條件，匹配模式足以滿足以下邏輯要求：

RewriteEngine on

RewriteCond %{REQUEST} !-f
RewriteCond %{REQUEST} !-d
RewriteRule ^/?([^/]+)/([^/]+)/([^/]+)$ /results.php?sp=$1&ar=$2&in=$3 [END]
RewriteRule ^/?([^/]+)/([^/]+)$ /results.php?sp=$1&ar=$2 [END]

RewriteCond ${QUERY_STRING} ^sp=(.+)&ar=(.+)&in=(.+)$  
RewriteRule ^/results\.php$ /%1/%2/%3 [R=301,END]
RewriteCond ${QUERY_STRING} ^sp=(.+)&ar=(.+)$  
RewriteRule ^/results\.php$ /%1/%2 [R=301,END]

該規則集將在http服務器主機配置和動態配置文件（“ .htaccess”樣式文件）中同樣起作用。 這里的一般說明：您應該始終喜歡將此類規則放置在http服務器主機配置中，而不是使用動態配置文件（“ .htaccess”）。 這些動態配置文件增加了復雜性，通常是導致意外行為，難以調試的原因，並且確實降低了http服務器的速度。 僅當您無法訪問真正的http服務器主機配置（閱讀：真正便宜的服務提供商）或堅持編寫自己的規則的應用程序（這顯然是安全的噩夢）時，才提供它們作為最后的選擇。

如果您使用上述規則集遇到“內部服務器錯誤”（http狀態500），則很可能是您運行了非常舊版本的apache http服務器。 在這種情況下，將END標志替換為L標志。 在這種情況下，您將在http服務器錯誤日志文件中的不受支持的END標志上找到特定的提示。

再說一遍： 如果您可以命名一個邏輯來決定使用哪個請求參數來分配第二條規則捕獲的第二條值（如果應用了第二條規則）， 那么就有可能實現這樣的條件並處理您最初提到的所有三種情況。 但是，如果不指定這種邏輯，就無法實現某些功能。