передачи параметров GET, которые выглядят как URI каталоги

Question

Я видел много URI, которые выглядят примерно так:

www.fakesite.net/stories/1234/man_invents_fire 

и мне было интересно, если/1234/man_invents_fire части URI, на самом деле каталоги или если они являются параметрами GET (или что-то еще). Я заметил, что много раз сегмент/man_invents_fire не нужен (может быть удален без каких-либо последствий), что заставило меня поверить, что/1234/является номером id для истории в таблице базы данных (или что-то подобное линии).

Если эти сегменты URI являются параметрами GET, есть ли простой способ достичь этого? Если это не так, что делается?

(также, я знаю, что CodeIgnitor предоставляет такую ​​функциональность, но мне было любопытно узнать, можно ли легко его реализовать без CodeIgnitor. Однако я, как правило, PHP, если это имеет отношение к ответу)

Благодаря

Answer 1

Проще всего сделать это маршрут всех в главный файл index.php и выяснить ваш маршрут оттуда, запустив $ штук = взорваться («/», $ _SERVER [ «REQUEST_URI»]);

После установки/включения mod_rewrite убедитесь, что разрешить переопределение не установлено в false в настройке apache (чтобы разрешить чтение .htaccess), а затем выбросьте это в файле .htaccess вашего docroot.

<ifModule mod_rewrite.c> 
    RewriteCond %{REQUEST_FILENAME} !-s #Make sure the file doesn't actually exist (needed for not re-routing things like /images/header.jpg) 
    RewriteRule . /index.php [L,QSA] #re-route everything into index.php 
</IfModule> 

Answer 2

Это называется перезаписи URL, Google для него, вы найдете много информации об этом.

Answer 3

Точно так же, как постоянные ссылки в WordPress, это делается обычно с помощью mod_rewrite от Apache (или его эквивалента, если не используется Apache); однако вы также можете использовать обработчик страницы ошибок 404 для достижения того же результата (но это обычно не рекомендуется).

Как правило, все запросы страниц перенаправляются на шлюз, который анализирует запрошенный URI, чтобы определить, соответствует ли он указанному шаблону (в вашем случае может быть /{category}/{article_id}/{article_title}). Оттуда шлюз обычно может использовать только article_id для получения соответствующего контента.

В зависимости от системы, category и article_title может обычно быть выброшены/игнорируется и, как правило, для значения SEO; однако в некоторых случаях category может быть использован для увеличения article_id (например, для определения таблицы БД для запроса и т. д.).

MVC, как и Zend, также использует аналогичную технику, чтобы определить, какой контроллер и способ в ней выполнить. Примерный формат для этого типа использования: /{module}/{controller}/{method}; однако, это очень настраиваемый.

Answer 4

Если вы используете Symfony, для этого вам понадобится routing feature.

Answer 5

Ну, вы вроде правы в предположении, что и main_invents_fire являются параметрами. Они не являются действительно параметрами GET в том смысле, что протокол HTTP описывает их, но они выполняют одну и ту же задачу, сохраняя при этом URL-адрес «дружественным». Этот метод называется URL rewriting, и в Интернете есть информация об этом в эти дни ..

Вот article about friendly URLs in PHP, но я уверен, что поиск по этой теме даст более полезные результаты.

Answer 6

Реализация этого в PHP обычно выполняется через файл .htaccess и с использованием apache's mod_rewrite module.

Answer 7

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

Зависит от того, какой язык вы используете для его декодирования. В этом случае кажется, что «рассказы» являются основным сценарием, а «1234» - это идентификатор, а «man_invent_fires» - это заголовок.

Если вы используете php, вы можете использовать переменную $ _SERVER ['PHP_SELF'] или $ _SERVER ['REQUEST_URI'] для ее декодирования.

Если вы планируете создать такой сайт, необходимо иметь в виду определенную безопасность. Посмотрите их в Google, но ключевой, который нужно искать, это инжекторы sql.

Answer 8

В какой-справочной информации в дополнение к ответам до меня, URL является только что - «Uniform Resource Locator». Хотя в прежние времена он часто использовался для сопоставления 1: 1 с файловой структурой/каталогом, все, что требуется в спецификации HTTP, это идентификация определенного ресурса. В основном это означает, что, учитывая определенную строку, он должен указывать определенный «ресурс» на сервере. На практике в среде HTTP это обычно реализуется с помощью механизма перезаписи, такого как mod_rewrite. Такие RFC, как этот: http://www.ietf.org/rfc/rfc1738.txt, дают хороший, хотя и абстрактный, обзор. Однако концепции только оживают после разработки и реализации некоторых неочевидных целей.