htaccess чистые URL-адреса $_GET пусты

У меня есть следующий URL-адрес:

http://www.domain.gr/add-event?state=3cb7a28b14112d3f3ecada3d6915ac5f&code=AQAZeWtJgz1ZYWvsorRPiMRetkNhnU3NrQ9KYzIRkogUpg6IPHCkFCAWMBUYGYtulfWnr5JHWs2GbrBUAp89pVLStyKs_rer2r14yLI6qdByoqEv1TtHGK4TPzdLFRTgXZEzPEUyk9ixYQfdmZid0dRdTfVXDPqniCKnu8RHQb1ErRDezsdI2CcYsTxofe_wwtZYVD3d4r9VtlANrGn_klP1#_=_

Мое правило RewriteRule отлично работает с такими URL-адресами, как http://www.doamin.gr/news/date/title-of-article установка 'новости' как $_GET['page'] и $_GET['request'] как '/date/title-of-article' Мой htaccess имеет следующий код по порядку предоставить чистые URL-адреса:

RewriteCond %{REQUEST_FILENAME} !-f
#RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^/]*)(.*)$ /index.php?page=$1&request=$2

С указанным выше URL-адресом $_GET устанавливается следующим образом:

$_GET['страница'] = 'добавить событие'; $_GET['запрос'] = ''; // пустой

Как мне изменить reqriteRule, чтобы получить оставшуюся часть URL-адреса в этом случае? (Не испортив мои чистые URL-адреса).


php .htaccess mod-rewrite clean-urls
person syd619    schedule 21.01.2013    source источник
comment
В длинном URL вверху я вижу 2 ключа state и code. Затем кажется, что их значения пытаются зафиксировать в правиле. Это правильно? Если это так, регулярное выражение должно группировать все после state= и все после code=, а оно этого не делает. Если нет, объясните подробнее, в чем проблема.   -  person Felipe Alameda A    schedule 22.01.2013
comment
ну, до сих пор у меня не было переменных для моих чистых URL-адресов, поэтому www.domain.gr/pagename/rest-url назначал $_GET['page'] = pagename и $_GET['request'] = /rest-url. Но в этом случае этого длинного URL-адреса $_GET['request'] возвращает пустое значение, которое я хотел бы вернуть, было бы всем после '?'   -  person syd619    schedule 22.01.2013
comment
Хорошо. Но в запросе 2 параметра: $1 and $2. На какой ключ следует назначать весь входящий запрос, page или request?   -  person Felipe Alameda A    schedule 22.01.2013
comment
$ _GET [ 'запрос'] должен иметь такое состояние = 3cb7a28b14112d3f3ecada3d6915ac5f и код = AQAZeWtJgz1ZYWvsorRPiMRetkNhnU3NrQ9KYzIRkogUpg6IPHCkFCAWMBUYGYtulfWnr5JHWs2GbrBUAp89pVLStyKs_rer2r14yLI6qdByoqEv1TtHGK4TPzdLFRTgXZEzPEUyk9ixYQfdmZid0dRdTfVXDPqniCKnu8RHQb1ErRDezsdI2CcYsTxofe_wwtZYVD3d4r9VtlANrGn_klP1 # _ = _   -  person syd619    schedule 22.01.2013
comment
Регулярное выражение в правиле предназначено для сопоставления других строковых структур и их разделения. Вам придется изменить его, чтобы делать то, что вам нужно, вместе со всем правилом. Но если вы это сделаете, другие URL-адреса не будут совпадать.   -  person Felipe Alameda A    schedule 22.01.2013
comment
Можно ли как-то заменить? с & в URL через htaccess?   -  person syd619    schedule 22.01.2013
comment
Да, но если вы это сделаете, это изменит все URL-адреса, и хуже всего то, что запросы перестанут быть запросами, поскольку их идентифицирует ?. Итак, это не очень хорошая идея.   -  person Felipe Alameda A    schedule 22.01.2013
comment
Я придумал другое решение. Я мог бы проверить и обработать $_SERVER['REQUEST_URI'] Я полагаю, это сработает... чтобы я мог извлечь нужную мне информацию, не связываясь с правилами htaccess   -  person syd619    schedule 22.01.2013
comment
Это практичное решение. Правила перезаписи не должны использоваться для решения проблемы, с которой вы столкнулись.   -  person Felipe Alameda A    schedule 22.01.2013

Ответы (1)


arrow_upward
-1
arrow_downward

Ваш первый подшаблон ([^/]*) является жадным шаблоном. Это означает, что выражение будет соответствовать максимально возможной подстроке входной строки (а поскольку выражение соответствует всему, кроме символа /, оно будет соответствовать всей строке — впоследствии второй подшаблон не будет соответствовать ничему).

Вы можете пометить подшаблон как нежадный или ленивый (например, ([^/]*?)), но тогда он будет соответствовать только символу /. Вы можете изменить шаблон, чтобы он соответствовал всему, вплоть до начала части запроса URL: ^([^/]*?)\?

person helmbert    schedule 21.01.2013