Вероятно, это то, что вы ищете:
RewriteEngine on
# externally redirect profile/index.php?id=1 to /profile/1
RewriteCond %{QUERY_STRING} (?:^|&)id=(\d+)(?:&|$)
RewriteRule ^/?player/?$ /player/%1 [R=301,END]
# internally rewrite /profile/1 to profile/index.php?id=1
RewriteRule ^/?player/(\d+)/?$ /player/id=$1 [QSA,END]
Затем вы можете, как обычно, получить фактическое число c id из суперглобальных переменных php, поэтому $_GET['id'] в данном случае.
Предполагается, что запрос к /player/ каким-то образом сопоставлен с обрабатывающим сценарием php в вашей настройке. Ваш вопрос указывает на то, что это так, поэтому я не стал подробно останавливаться на этом.
В зависимости от вашего фактического логина приложения c (ссылки, которые оно отправляет или генерирует), вам не нужно первое перенаправление. Но вам обязательно нужно переписать входящие запросы так, чтобы php мог их обработать. Ваше приложение logi c определенно должно использовать только ссылки в форме /player/1, это первое перенаправление предназначено только для старых ссылок, которые были где-то отмечены, или если части вашего приложения logi c еще не были исправлены для использования новой ссылки шаблон.
Рекомендуется начать с временного перенаправления 302 и изменить его на постоянное перенаправление 301 позже, когда вы убедитесь, что все настроено правильно. Это предотвращает проблемы с кешированием при проверке ...
В случае, если вы получаете внутреннюю ошибку сервера (статус http 500), используя приведенное выше правило, то есть вероятность, что вы используете очень старую версию apache http сервер. В этом случае вы увидите явный намек на неподдерживаемый флаг [END] в файле журнала ошибок вашего http-сервера. Вы можете попробовать обновить или использовать более старый флаг [L], он, вероятно, будет работать так же в этой ситуации, хотя это немного зависит от вашей настройки.
Эта реализация будет работать аналогично на хосте http-серверов конфигурации или внутри распределенного файла конфигурации (файл ".htaccess"). Очевидно, что модуль перезаписи должен быть загружен внутри http-сервера и включен на http-хосте. Если вы используете распределенный файл конфигурации, вам необходимо позаботиться о том, чтобы его интерпретация была включена в конфигурации хоста и чтобы он находился в папке DOCUMENT_ ROOT хоста.
И общее замечание: вы всегда следует размещать такие правила в конфигурации хоста http-серверов вместо использования файлов распределенной конфигурации («.htaccess»). Эти распределенные файлы конфигурации добавляют сложности, часто являются причиной неожиданного поведения, их трудно отлаживать, и они действительно замедляют работу http-сервера. Они предоставляются только в качестве последнего варианта для ситуаций, когда у вас нет доступа к реальной конфигурации хоста http-серверов (читайте: действительно дешевые поставщики услуг) или для приложений, настаивающих на написании своих собственных правил (что является очевидным кошмаром безопасности).