к примеру так:
файл .htaccess

<ifModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^([a-zA-Z0-9\-\_\.\/\\]{0,224})$ index.php?show_uri=$1 [L,QSA]

</ifModule>

а в скрипте разбиваеш переменную $_GET['show_uri'] на массив. А далее обрабатывай значения по их индексу.
т.е.

$show_uri_arr = explode("/", $_GET['show_uri']);

будет:
$show_uri_arr[0] = "user";
$show_uri_arr[1] = "George";

это простой пример. доработать сможешь ведь.

Вопрос не о .htaccess. Вопрос о более высоком уровне - обработке в самом движке. У нас одна цель .htaccess - передавать все запросы index.php и все.

понаехло тут урлрерайтщиков блин

Один из лучших - это django. Второй - sf.

Соль простая.
Существует 2 вида получения параметров из урла:
1. На основе регулярки. В django очень даже это дело понравилось - сразу задаются и имена параметров и модуль и действие.
При этом нет никаких ограничений - можете хоть иметь урл вроде:
/user-info-someuser.showcomment
При этом будем иметь модуль user, экшн info, параметр someuser и ещё один параметр showcomment. Про регулярки думаю не стоит рассказывать. Стоит вообще это дело посмотреть как работает
2. Автоматический.
Имеем урл:
/user/show/id/1

Каждый параметр разделен слешем.
Первый параметр - модуль. Второй - экшн. Третий - имя параметра. четвертый - его значение

Если Вы посмотрите на наш фреймворк, то заметите что приведенные выше вещи он уже делает. Правда, по регуляркам пока не реализован реврайтер. Мне важно увидеть именно реализацию, как следует описывать правила.

Конечно, если вы реализуете реврайтер для нашего проекта - это будет большой вклад в развитие нашего open source проекта. Однако и советы от опытного разработчика всегда являются для нас незаменимой помощью.

Спасибо за комментарий!

Спасибо. Опять не о том.

Адрес стандартен для ZendFramework и других MVC фреймворков: /model/action/params...

Вот нужно сделать реврайтер для нестандартных ситуаций. Например, есть задача сделать так: project_name/bugs/list рассматривать как bugs/list/project:project_name

Т.е. человек видит одно, а система понимает это как совершенно другие команды, выходящие за рамки стандартной MVC архитектуры.

Надеюсь, теперь я более понятно пояснил чего хочу.
Спасибо за предложения.

once more - регулярка

О, регулярка. Это хорошо. Дошли до сути.

Уточняю. Желаю определить стиль описания реврайтов, чтобы было удобно писать эти реврайты для больших сайтов. Ведь урлы могут пересекаться - а это уже плохо. Вот именно поэтому я и желаю выбрать лучший вариант из предлагаемых.

Пример плохого реврайта:
[a-z]+[0-9]{1,4} -> user/$1
[a-z0-9]+ -> article/$1

При определенной ситуации (например: user124) получаем коллизию - пересечение двух правил. Это очень плохо. Именно этого следует избежать.

Теперь слушаю Ваши предложения по решению этой задачи. просьба заранее просмотреть различные источники, чтобы сэкономить свое время и быстрее получить ответ на этот вопрос.

Спасибо.

на самом деле да, пример очень плохой.
Я бы всё таки не стал удалять совсем понятия модуля в урлах.
Таким образом, лучше сделать регулярки вроде
user\/[a-z]+[0-9]{1,4} -> user/$1
article\/[a-z0-9]+ -> article/$1

если быть более точным - паттерн применяется дважды:
1. Для сравнения паттерна с урлом и определение приложения, модуля, действи - пересечение полностью на совести разработчика
2. Обозначение параметров. Например:
article\/(?<alias>\w+)
Сделал preg_match_all - получим совпадения, а заодно и ключи.
В данном случае вытащим параметр alias, который потянется в контроллер

Если есть желание - можешь помочь в реализации этого модуля. Однако, придется изучить хотя бы 5 различных подходов, используемых в разных фреймворках. (это своего рода инвайт в прокт phpDays)

Пример из жизни. Создается сайт для ведения проектов.
На первом месте в УРЛ стоит название проекта. Далее уже идет имя контроллера и действия.

/[project_name]/code/view -> /code/view/project:project_name

При этом мы оставляем систему и код приложения "прозрачными", и пользователь видит удобные УРЛы для себя.

Последнюю версию кода класса Router смотрим здесь:
http://http://code.google.com/p/phpdays/so.../browse/trunk...
(хотя в данный момент он пуст)

http://http://site.ru/[controller]/[action]/[args]/[args]...

http://http://site.ru/users/napeHeK/news/

$controller = 'users';
$action = 'napeHeK';
$subaction = 'news';

$controller = new $controller();
$controller->$action($subaction);

class users
{
. . . function __call($username, $args)
. . . {
. . . . . . $subaction = $args[0];
. . . . . . echo $username;
. . . }
}

Общепринятый вид, не думаю что нужно прыгать выше головы. А регулярки не стоит использовать, слишком они медленные.

* Тут берётся только один параметр, для упрощения. Я обычно делаю отдельный класс для разбиения запроса и хранения кусков. А контроллер уже сам делает валидацию и берёт все что нужно

В .htaccess

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^(.*)$ index.php?$1 [L,QSA]

Думаю не стоит нагружать с лишними регулярками, нет смысла

Сравнить одну строку - слишком медленные?
echo быстрее print, да?

Какую строку вы сравниваете? Мы вроде говорили о разбивке запроса...

/[project_name]/code/view -> /code/view/project:project_name

explode (может быть и strpos) будет работать раз в 20 быстрей, чем preg_match

echo быстрее print, да? Да, вы думаете по другому? :)

Да, нужно внедрить будет простой рврайтинг. Как я вижу. некоторые фрейворки вообще не обрабатывают запросы. если реврайт не прописан (тот же Django). Вообще это с одной стороны правильно - я не ко всем контроллерам даю доступ. а только к тем, что я считаю нужным. Да и не ко всем методам. а только к тем. что я разрешил.

Нужно подумать как это внедрить. Штука действительно хорошая. Но сейчас все еще я применяю автоматическую маршрутизацию по принципу Zend Framework.

Спасибо за идеи. Будут свежие мысли - пишите, будем внедрять.

Алексей Светов
ужастнейший способ, имхо. код громостким выходит