如果您的規則有效,它將依賴字符編碼(在.htaccess文件中使用的編碼和用於請求的URI的編碼)。如果兩者都相同,它應該可以工作。
現在大多數用戶代理使用ISO 8859-1或UTF-8編碼通過HTTP請求的URL。但UTF-8早晚會取代ISO 8859-1。
而當bobince注意到註釋時,Apache在解釋.htaccess文件時在內部使用單字節編碼ASCII。所以當你使用像UTF-8這樣的多字節編碼時,你可能會遇到問題。不過是編碼independed如下:
# for ISO 8859-1
RewriteRule ^([a-zA-Z0-9\xC4\xD6\xDC\xDF\xE4\xE9\xF6\xFC-]*)/?$ page.php?var=$1 [L]
# for UTF-8
RewriteRule ^(([a-zA-Z0-9-]|\xC3\x84|\xC3\x96|\xC3\x9C|\xC3\x9F|\xC3\xA4|\xC3\xA9|\xC3\xB6|\xC3\xBC)*)/?$ page.php?var=$1 [L]
但是爲了避免這樣的結構,你可以只排除斜線和斑點,後來與PHP驗證的值:
RewriteRule ^([^/.]*)/?$ page.php?var=$1 [L]
那麼爲什麼它只能在服務器發生。 .. 我的本地機器正在工作.... :( – coderex 2009-08-22 10:37:47
也許你正在使用不同的編碼,無論是文件還是URI。 – Gumbo 2009-08-22 10:46:15
+1,Apache處理字節,所以原來的規則只適用於ISO-8859-1提交,這是很少見的,因爲今天的URL是事實上的UTF-8。最好避免這一層的問題,允許任何老字符通過;在PHP腳本中做任何你需要的字符檢查,把這種邏輯放在Web服務器層中作爲重寫是沒有意義的。 – bobince 2009-08-22 11:52:04