元のルールの仕組みは次のとおりです。 URLを起動します。
http://mydomain.com/npguar/en/index.php?maybe=a-query
は、専用のファイルシステムパスを取る:
npguar/en/index.php
は.htaccess
を取得するために使用された接頭辞を削除します。
en/index.php
マッチこれは正規表現に対して^([a-z]{2})/(.*)
。一致するので、処理が続行されます。
(en)/(index.php)
この試合は後方参照$1 = en
と$2 = index.php
を定義しています。このようなURLの一部に一致した正規表現でのサブパターンがありました。
対応するRewriteCond
を確認してください。最初の引数は$1
で、文字列はen
に展開されます。 2番目の引数は!
で、正規表現はその文字列と一致しないため、条件は真です。
条件が戻っRewriteRule
に行くと置換文字列$2?language=$1
を構築し、真であるので:
index.php?language=en
これは内部リダイレクトですので、一緒に戻ってのorignal URLのビットを置きます。ここにクエリがあり、[QSA]
フラグが指定されていないため、元のクエリ(maybe=a-query
)が置き換えられます。
http://mydomain.com/npguar/index.php?language=en
このURLは最初から処理するためにApacheに戻されます。書き換えルールが再度チェックされます([L]
フラグはこれを防ぎませんが、一致しないため、ページが提供されます)。
このルールの問題点は、RewriteCond
で$1
です。それは$2
でなければなりません。上記の例ではRewriteCond
はfalseになりますが、en/products.php
ではtrueになります。
RewriteCond
が意図したよりもはるかに緩慢なので、これはうまくいきます。
(en)/(1)(/product_specification.php)
ので$1 = en
、$2 = 1
、:正規表現は、このようなURL(第2 /
がどこに行くに注意を)壊すため
は
新しいルールは、動作しません。次に、$1
と^product_specification.php
を比較します。一致しません。条件はfalseです。
代わりに、新しいルールは次のようになります。
RewriteCond $3 ^product_specification\.php$
^^ ^
RewriteRule ^([a-z]{2})/([0-9]{1,2})/(.*) $3?language=$1&id=$2 [L]
^
(.../product_specification.phpfoo
が一致しないように、私も最後に$
を追加しました。)
同じルールが単純になります
RewriteRule ^([a-z]{2})/([0-9]{1,2})/(product_specification\.php)$ $3?language=$1&id=$2 [L]
ありがとうございます、実際には私のクエリで何が間違っていたのか説明できますか? – Shishant
申し訳ありませんが、より明確になっているはずです。回答が編集されました。 – aaz
ありがとう、大変ありがとうございます。 – Shishant