расширить на deceze это, я хотел бы привести несколько примеров и объяснить некоторые другие функции mod_rewrite.

все приведенные ниже примеры предполагают, что вы уже включили RewriteEngine On в своем .

Пример Переписать

давайте возьмем этот пример:

RewriteRule ^blog/([0-9]+)/([A-Za-z0-9-\+]+)/?$ /blog/index.php?id=&title= [NC,L,QSA]

правило разбито на 4 раздела:

1. RewriteRule - начинает переписывать правило
2. ^blog/([0-9]+)/([A-Za-z0-9-\+]+)/?$ - это называется шаблоном, однако я просто буду называть его левой стороной правила-то, что вы хотите переписать из
3. blog/index.php?id=&title= - называется подстановка, или правая сторона правила перезаписи-что вы хотите переписать в
4. [NC,L,QSA] флаги для Правила перезаписи, разделенные запятой, которое я объясню позже

вышеупомянутая переписка позволит вам связать что-то вроде /blog/1/foo/ и он действительно загрузится /blog/index.php?id=1&title=foo.

левая сторона правила

• ^ указывает начало имени страницы-таким образом, он будет переписывать example.com/blog/... а не example.com/foo/blog/...
• каждый набор (…) скобки представляют собой регулярное выражение, которое мы можем захватить как переменную в правой части правила. В этом примере:
  • первый набор скобок -([0-9]+) - соответствует строке длиной не менее 1 символа и только с числовыми значениями (т. е. 0-9). На это можно ссылаться с помощью в правой части правила
  • второй набор скобок соответствует строке длиной не менее 1 символа, содержащей только буквенно-цифровые символы (A-Z, a-z или 0-9) или - или + (Примечание + экранируется с обратной косой чертой, так как без экранирования это будет выполняться как regex символ повторения). На это можно ссылаться с помощью в правой руке сторона правила
• ? означает, что предыдущий символ является необязательным, поэтому в этом случае оба /blog/1/foo/ и /blog/1/foo переписал бы на то же место
• $ указывает, что это конец строки, которую мы хотим сопоставить

флаги

эти параметры добавляются в квадратные скобки в конце правила перезаписи для указания определенных условий. Опять же, есть много разных флагов, которые вы может читать в документация, но я пройду через некоторые из наиболее распространенных флагов:

NC

флаг no case означает, что правило перезаписи нечувствительно к регистру, поэтому для примера выше это будет означать, что оба /blog/1/foo/ и /BLOG/1/foo/ (или любое изменение этого) будет сопоставлено.

L

последний флаг указывает, что это последнее правило, которое должно быть обработано. Это означает, что если и только если это правило выполняется, никаких дополнительных правил будет оцениваться в текущем запуске обработки перезаписи. Если правило не совпадает, все остальные правила будут опробованы в обычном порядке. Если вы не установите L флаг, все следующие правила будут применены к переписан URL после этого.

END

С Apache 2.4 вы также можете использовать [END] флаг. Правило соответствия с ним будет полностью завершить дальнейшую обработку псевдонима / перезаписи. (А [L] флаг может часто вызывать второй раунд, например, при перезаписи в или из подкаталогов.)

QSA

флаг добавления строки запроса позволяет передавать дополнительные переменные в указанный URL-адрес, который будет добавлен к исходным параметрам get. Для нашего примера это означает, что что-то вроде /blog/1/foo/?comments=15 загрузите /blog/index.php?id=1&title=foo&comments=15

R

этот флаг не тот, который я использовал в примере выше, но я подумал, что стоит упомянуть. Это позволяет указать перенаправление http с помощью возможность включения кода состояния (например,R=301). Например, если вы хотите сделать 301 перенаправление на /myblog/ to / blog/, вы просто напишете правило примерно так:

RewriteRule ^/myblog/(*.)$ /blog/ [R=301,QSA,L]

Условия Переопределения

условия переопределения сделайте перезаписи еще более мощными, позволяя вам указывать перезаписи для более конкретных ситуаций. Есть много условий, о которых вы можете прочитать в документация, но я коснусь нескольких общих примеры и объясните их:

# if the host doesn't start with www. then add it and redirect
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

это очень распространенная практика, которая будет добавлять ваш домен с www. (если его еще нет) и выполните перенаправление 301. Например, загрузка http://example.com/blog/ это перенаправит вас на http://www.example.com/blog/

# if it cant find the image, try find the image on another domain
RewriteCond %{REQUEST_URI} \.(jpg|jpeg|gif|png)$ [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*)$ http://www.example.com/ [L]

это немного реже, но является хорошим примером правила, которое не выполняется, если имя каталога или файла, который существует на сервере.

• %{REQUEST_URI} \.(jpg|jpeg|gif|png)$ [NC] будет выполняться только в перепишите файлы с расширением jpg, jpeg, gif или png (без учета регистра).
• %{REQUEST_FILENAME} !-f проверит, существует ли файл на текущем сервере, и только выполнит перезапись, если это не
• %{REQUEST_FILENAME} !-d проверит, существует ли файл на текущем сервере, и только выполнит перезапись, если это не
• перезапись попытается загрузить тот же файл в другой домен

ссылки

переполнение стека имеет много другие большие ресурсы, чтобы начать работу:

• Serverfault: все, что вы хотели знать о mod_rewrite
  ^{(имейте в виду, чтобы удалить косую черту в ^/ pattern префиксы для .htaccess использование.)}
• делать и не в скрытые возможности mod_rewrite.
• посмотреть через наши самый популярный мод-рерайт вопросы и ответы.
• Apache перенаправления и перераспределения руководство.
• Языкапочти конечной .htaccess, что руководство
• и mod-переписать тег wiki ссылки.

и новичок дружественных regex обзоры даже:

• наши regex тег wiki для синтаксического компендиума.
• и короткий сводка регулярных выражений Apache.
• Else regexp.info для простых в понимании основ.

часто используемые заполнители

• .* соответствует чему угодно, даже пустой строке. Вы не хотите использовать этот шаблон везде, но часто в последнем резервном правиле.
• [^/]+ чаще используется для отрезки пути. Он матчи угодно, но не Слэш.
• \d+ соответствует только числовым строкам.
• \w+ соответствует буквенно-цифровых символов. Это в основном стенография для [A-Za-z0-9_].
• [\w\-]+ для сегментов пути в стиле"slug", используя буквы, цифры, тире - и _
• [\w\-.,]+ добавляет точки и запятые. Предпочитаю сбежать \- тире […] charclasses.
• \. обозначает a буквальный период. В противном случае . за пределами […] вместо любого символа.

каждый из этих заполнителей обычно заворачивают в (…) скобках, как группа захвата. И вся картина часто в ^………$ start + end маркеры. Цитирование "шаблонов" является необязательным.

RewriteRules

следующие примеры ориентированы на PHP и немного более инкрементальны, их легче адаптировать для подобных случаев. Это просто резюме, часто ссылающиеся на больше изменений или детального Q&As.

• статическое сопоставление
  /contact, /about

  сокращение нескольких имен страниц до внутренних файловых схем наиболее просто:

   RewriteRule ^contact$  templ/contact.html
   RewriteRule ^about$    about.php
  

• числовые идентификаторы
  /object/123

  введение ярлыков, таких как http://example.com/article/531 к существующим PHP скриптам также легко. Числовой заполнитель может просто быть перенесен на :

   RewriteRule ^article/(\d+)$    article-show.php?id=
   #                      └───────────────────────────┘
  

• заполнители в стиле Slug
  /article/with-some-title-slug

  вы можете легко расширить это правило, чтобы позволить /article/title-string заполнители:

   RewriteRule ^article/([\w-]+)$    article-show.php?title=
   #                       └────────────────────────────────┘
  

  обратите внимание, что скрипт должны иметь возможность (или быть адаптированным) сопоставить эти заголовки с идентификаторами базы данных. Только переписчики не могут создавать или угадывать информацию из тонкого воздух.

• слизни с числовыми префиксами
  /readable/123-plus-title

  поэтому вы часто будете видеть смешанные /article/529-title-slug пути, используемые на практике:

   RewriteRule ^article/(\d+)-([\w-]+)$    article.php?id=&title=
   #                      └───────────────────────────────┘
  

  теперь вы можете просто пропустить мимо title= в любом случае, потому что ваш скрипт обычно будет полагаться на идентификатор базы данных. The -title-slug стал произвольным украшением URL.

• единообразие с альтернативными списками
  /foo/… /bar/… /baz/…

  если у вас есть аналогичные правила для нескольких виртуальных путей страницы, то вы можете сопоставить и сжать их с | альтернативные списки. И снова просто переназначьте их на внутренние параметры GET:

   #                               ┌─────────────────────────┐
   RewriteRule ^(blog|post|user)/(\w+)$  disp.php?type=&id=
   #               └───────────────────────────────────┘
  

  вы можете разделить их на отдельные RewriteRules должен быть слишком сложным.

• отправка связанных URL-адресов в разные backends
  /date/SWITCH/backend

  более практичным использованием альтернативных списков является сопоставление путей запросов с различными сценариями. Например, чтобы предоставить единообразные URL-адреса для старого и нового веб-приложения на основе дат:

   #                   ┌─────────────────────────────┐
   #                   │                 ┌───────────┼───────────────┐
   RewriteRule ^blog/(2009|2010|2011)/([\d-]+)/?$ old/blog.php?date=
   RewriteRule ^blog/(\d+)/([\d-]+)/?$  modern/blog/index.php?start=
   #                          └──────────────────────────────────────┘
  

  это просто переназначает сообщения 2009-2011 на один скрипт, а все остальные годы неявно на другой обработчик. Примечание более конкретное правило на первом месте. Каждый скрипт может использовать разные GET парамы.

• другие разделители, чем просто / пути слеши
  /user-123-name

  вы чаще всего видите перезаписи для имитации виртуальной структуры каталогов. Но ты не обязан быть нетворческим. Вы также можете использовать - дефисы для сегментирования или структуры.

   RewriteRule ^user-(\d+)$    show.php?what=user&id=
   #                   └──────────────────────────────┘
   # This could use `(\w+)` alternatively for user names instead of ids.
  

  Для также общего /wiki:section:Page_Name схема:

   RewriteRule ^wiki:(\w+):(\w+)$  wiki.php?sect=&page= 
   #                   └─────┼────────────────────┘       │
   #                         └────────────────────────────┘
  

  иногда это подходит для чередования между /-разделители и : или . в том же правиле даже. Или опять два RewriteRules для сопоставления вариантов на разные сценарии.

• дополнительно трейлинг / полоснуть
  /dir = /dir/

  выбирая пути в стиле каталога, вы можете сделать его доступным С и без окончательного /

   RewriteRule ^blog/([\w-]+)/?$  blog/show.php?id=
   #                         ┗┛
  

  теперь это ручки как http://example.com/blog/123 и /blog/123/. И /?$ подход легко добавить на любой другой RewriteRule.

• гибкие сегменты для виртуальных путей
  .*/.*/.*/.*

  большинство правил вы столкнетесь карта ограниченный набор /…/ сегменты пути к ресурсам для отдельных параметров GET. Некоторые скрипты обрабатывать переменное количество параметров однако. Движок регулярных выражений Apache не разрешить опционирование произвольного числа из них. Но вы можете легко развернуть его в блок правил самостоятельно:

   Rewriterule ^(\w+)/?$                in.php?a=
   Rewriterule ^(\w+)/(\w+)/?$          in.php?a=&b=
   Rewriterule ^(\w+)/(\w+)/(\w+)/?$    in.php?a=&b=&c=
   #              └─────┴─────┴───────────────────┴────┴────┘
  

  Если вам нужно до пяти сегментов пути, скопируйте эту схему в пять правил. Вы можете, конечно, использовать более конкретный [^/]+ заполнитель каждого. Здесь порядок не так важен, как ни то, ни другое. Поэтому иметь наиболее часто используемые пути в первую очередь нормально.

  в качестве альтернативы вы можете использовать параметры массива PHPs через ?p[]=&p[]=&p[]=3 запрос строка здесь-Если ваш скрипт просто предпочитает их предварительно разделить. (Хотя чаще всего просто использовать правило catch-all и позволить скрипту самому расширять сегменты из REQUEST_URI.)

  Читайте также: как преобразовать сегменты пути URL в пары ключ-значение строки запроса?

• дополнительные сегменты
  prefix/opt?/.*

  общее изменение иметь опционные префиксы внутри правило. Обычно это имеет смысл, если у вас есть статические строки или более ограниченные заполнители:

    RewriteRule ^(\w+)(?:/([^/]+))?/(\w+)$  ?main=&opt=&suffix=
  

  теперь более сложный рисунок (?:/([^/])+)? там просто обертывает не захват (?:…) group, и делает его необязательным )?. Содержащиеся заполнитель ([^/]+) будет замена шаблона , но быть пустым, если нет среднего /…/ путь.

• записать остаток
  /prefix/123-capture/…/*/…whatever…

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

   RewriteRule ^(specific)/prefix/(\d+)(/.*)?$  speci.php?id=&otherparams=
  

  этот optionalized любой /…/…/… конечные отрезки пути. Что, конечно же, требует скрипта обработки, чтобы разделить их, и variabl-ify извлеченных параметров сам (что и есть Web - "MVC" рамки делают).

• завершающий файл "extensions"
  /old/path.HTML

  URLs на самом деле не имеют расширений файлов. Вот о чем вся эта ссылка (= URL-адреса-это виртуальные локаторы, не обязательно прямой образ файловой системы). Однако, если у вас было сопоставление файлов 1:1 раньше, вы can ремесло более простые правила:

   RewriteRule  ^styles/([\w\.\-]+)\.css$  sass-cache.php?old_fn_base=
   RewriteRule  ^images/([\w\.\-]+)\.gif$  png-converter.php?load_from=
  

  другие распространенные приложения переназначение устаревших .html пути к новой .php обработчики или просто псевдонимы имен каталогов только для отдельных (фактических/реальных) файлов.

• пинг-понг (перенаправляет и переписывает в унисон)
  /ugly.html ←→ /pretty

  поэтому в какой-то момент вы переписываете свои HTML-страницы, чтобы нести только красивые ссылки, как очерченный deceze. Тем временем вы все равно будете получать запросы на старый пути, иногда даже от книжные закладки. As решение, вы можете пинг-понг браузеры для отображения/установить новые URL.

  этот общий трюк включает в себя отправку 30x / Location редирект всякий раз, когда входящий URL следует устаревшей/уродливой схеме именования. Браузеры будут тогда rerequest новый / довольно URL, который впоследствии переписывается (только внутри) в исходное или новое место.

   # redirect browser for old/ugly incoming paths
   RewriteRule ^old/teams\.html$ /teams [R=301,QSA,END]
  
   # internally remap already-pretty incoming request
   RewriteRule ^teams$ teams.php        [QSA,END]
  

  обратите внимание, как этот пример просто использует [END] вместо [L] безопасно чередоваться. Для более старых версий Apache 2.2 вы можете использовать другие обходные пути, а также переназначение например, параметры строки запроса: перенаправить уродливый довольно URL, переназначить обратно на уродливый путь, без бесконечных циклов

• помещения ␣ в структуре
  /this+that+

  это не этого достаточно в адресных строках браузера, но вы можете использовать пробелы в url. Для перезаписи шаблонов используйте обратную косую черту-escaped \␣ пробелы. Иначе просто "-процитируйте весь шаблон или замену:

   RewriteRule  "^this [\w ]+/(.*)$"  "index.php?id="  [L]
  

  клиенты сериализуют URL-адреса с помощью + или %20 для пространства. Однако в RewriteRules они интерпретируются буквальными символами для всех относительных сегментов пути.

частые повторы:

• поймать-все для центральный диспетчер!--190--> / фронт-контроллер скрипт

   RewriteCond %{REQUEST_URI} !-f
   RewriteCond %{REQUEST_URI} !-d
   RewriteRule ^.*$     index.php   [L]
  

  который часто используется фреймворками PHP или скриптами WebCMS / portal. Фактическое разделение пути затем обрабатывается в PHP с помощью $_SERVER["REQUEST_URI"]. Таким образом, концептуально это в значительной степени противоположно обработке URL "per mod_rewrite". (Просто используйте FallBackResource вместо.)

• удалить www. от имени хоста

  обратите внимание, что это не копирует строку запроса вместе, так далее.

   #                               ┌──────────┐
   RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]  │ 
   RewriteRule ^(.*)$ http://%1/ [R=301,L]  │
   #             ↓           └───┼────────────┘
   #             └───────────────┘
  

  Читайте также:
  · переписывание URL для разных протоколов .реврайт
  · Generic htaccess перенаправить www на не-www
  · .htaccess - как заставить " www.- в общем смысле?

  обратите внимание, что комбо RewriteCond/RewriteRule могут быть более сложными, с совпадениями (%1 и ) взаимодействие в обоих направлениях даже:

  
  ^{руководство Apache-mod_rewrite введение, Copyright 2015 The Apache Software Foundation, AL-2.0}

• перейти к HTTPS://

   RewriteCond %{SERVER_PORT} 80
   RewriteRule ^(.*)$ https://example.com/ [R,L]
  

  см. также:https://wiki.apache.org/httpd/RewriteHTTPToHTTPS

• "удаление" расширения PHP

   RewriteCond %{REQUEST_FILENAME}.php -f
   RewriteRule ^(.+)$  .php  [L]  # or [END]
  

  Читайте также: удаление .РНР расширение с mod_rewrite

• сглаживание старые .html пути к .PHP скрипты

  см.: http://httpd.apache.org/docs/2.4/rewrite/remapping.html#backward-compatibility

• переписать с URL-адреса типа "/ page "на скрипт типа" / index.php / страница"

  посмотреть mod_rewrite, php и то .htaccess файл

• редирект поддомен в папку

  посмотреть как я могу заставить htaccess работать (поддомены)?

преобладает .htaccess подводные камни

Теперь возьмите это с зерном соли. Не каждый совет можно обобщить на все контексты. Это всего лишь простое резюме известных и нескольких неочевидных камней преткновения:

• включить mod_rewrite и .htaccess

  на самом деле использовать RewriteRules в файлах конфигурации для каждого каталога необходимо:

  • проверить, что ваш сервер имеет AllowOverride All включено. В противном случае ваш per-directory .htaccess директивы будут игнорироваться, а Перезаписывающие не будут работать.

  • очевидно есть mod_rewrite включено в своем модули.

  • добавить каждый список правил с RewriteEngine On по-прежнему. В то время как mod_rewrite неявно активен в <VirtualHost> и <Directory> разделы, каталог.htaccess файлы нуждаются в индивидуальном вызове.

• ведущий слеш ^/ не соответствует

  вы не должны начинать свой .htaccess шаблоны RewriteRule с ^/ обычно:

   RewriteRule ^/article/\d+$  …
                ↑
  

  это часто встречается в старых учебниках. И это было правильно для древнего Apache 1.X версий. В настоящее время пути запросов удобно полностью вы не хочу что обычно в свой .htaccess файлы.

  • во-первых, mod_rewrite не отключается случайным образом. (Если бы это было так, у вас были бы большие проблемы).
  • если бы он действительно был отключен, ваши перезаписи все равно не работали бы.
  • он предназначен для предотвращения HTTP 500 ошибки. То, что он обычно выполняет, - это изящество пользователи с HTTP ошибки. (Не столько более удобный, если вы думаете об этом.)
  • практически он просто подавляет более полезные записи журнала или уведомления сервера. Ты был бы не знаю о том, почему ваши переписчики никогда не работают.

  что кажется заманчивым как обобщенная защита, часто оказывается препятствием в практиковать.

• не используйте RewriteBase если не нужны

  многие примеры копирования + вставки содержат . Это неявно перестраивает относительные ссылки на то, чем они были раньше.

вы могли бы в качестве альтернативы ремесло дальнейшие переписчики для rebind .css или .png пути к их исходному положению. Но это и ненужно, или вызывает дополнительные перенаправления и препятствует кэшированию.

Читайте также: CSS, JS и изображения не отображаются с довольно url

 RewriteCond %{SERVER_NAME} localhost
 RewriteRule ^secret  admin/tools.php
 RewriteRule ^hidden  sqladmin.cgi

 RewriteCond %{QUERY_STRING} \b(?:param)=([^&]+)(?:&|$)
 RewriteRule ^add/(.+)$  add/%1/  # ←──﹪₁──┘

инструменты

существуют различные онлайн-инструменты для создания перезаписей для большинства GET-parameterish URL-адреса:

• http://www.generateit.net/mod-rewrite/index.php
• http://www.ipdistance.com/mod_rewrite.php
• http://webtools.live2support.com/misc_rewrite.php

в основном просто выход [^/]+ общие заполнители, но, вероятно, достаточно для тривиальных сайтов.

альтернативы и mod_rewrite

многие базовые виртуальные схемы url может быть достигнуто без использования RewriteRules. Apache позволяет вызывать PHP-скрипты без