Можно указать правила перенаправления URL-адресов в файле JSON.
Используйте следующий формат в файле JSON, чтобы указать правила перенаправления URL-адресов.
{ "redirectRules": [ { "type": "string", "comment": "this rule is applied first", "expression": "/index.htm", "location": "/home.html" }, { "type": "wildcard", "expression": "/items/*?page=*", "location": "/<$page$>?item=<$wildcard(1)$>", "code": 302 } ] }
Внешняя содержащая структура в файле JSON представляет собой массив. Этот массив содержит экземпляры правил.
Сначала оцениваются правила "string"
, а затем правила "wildcard"
, по порядку. После обнаружения соответствия одному из правил, оценка последующих правил отменяется и создается соответствующее перенаправление.
Каждое правило имеет следующие свойства:
Свойство "comment"
— дополнительная строка, которая не влияет на оценку правил. Оно содержит примечания или комментарии.
Свойство "expression"
— это обязательная строка, которая совпадает с входящим URL-адресом, связанным с сайтом. В правиле с подстановочными знаками символ звездочки (*
) соответствует нулевому или большему количеству символов.
Свойство "location"
— обязательная строка, указывающая местоположение или место назначения перенаправления. Перенаправление может быть задано полным или относительным URL-адресом.
Свойство "code"
— необязательное целое число, которое предоставляет код ответа HTTP, используемый при выдаче перенаправления. Данное значение должно быть одним из следующих целых чисел:
301: указывает на окончательное перемещение ресурса. Это значение используется по умолчанию, если свойство "code"
опущено.
302: указывает на временное перемещение ресурса.
Свойство "type" — это дополнительная строка, указывающая тип правила перенаправления. Данное значение должно быть одной из следующих строк:
"string"
указывает более быстрое правило, выражение которого точно соответствует всему введенному URL-адресу.
"wildcard"
указывает правило с подстановочными знаками, которое может соответствовать нескольким URL-адресам. Это значение по умолчанию, если данное свойство опущено.
Маркеры местоположения
Маркеры местоположения можно использовать для создания местоположения перенаправления. Каждый из следующих маркеров местоположения может помочь указать перенаправление:
<$urlPath$>
: часть пути соответствующего URL-адреса.
<$urlQueryString$>
: вся строка запроса URL-адреса из соответствующего URL-адреса.
<$urlQueryStringExcept(name1,name2)$>
: вся строка запроса URL из соответствующего URL-адреса минус именованные параметры.
<$wildcard(N)$>
: начинающийся с единицы индекс соответствующего подстановочного знака в соответствующем URL-адресе. (Это аналогично \1..\9
в регулярных выражениях.)
<$name$>
: значение параметра именованного параметра в строке запроса. Например, если на входе указана строка запроса msmith:?page=42
, можно использовать <$page$>
в заданном местоположении, чтобы поместить туда "42"
.
Ограничения
Приведенные ниже ограничения применяются ко всему файлу redirects.json
и к содержащимся в нем правилам.
Максимальный общий размер файла в Oracle Content Management составляет 250 КБ.
Максимальное число правил в файле rewords.json
: 1000.
Максимальная длина "expression"
для правила: 1000 символов.
Максимальная длина "location"
для правила: 2000 символов.
Максимальное число маркеров "*"
в выражении правила с подстановочными знаками: 10.
Пример соответствия строк
Правило:
{ "type": "string", "expression": "/old/page.jsp?id=material&type=glass", "location": "/new/<$id$>.htm" }
Следующий URL-адрес соответствует правилу:
/old/page.jsp?id=material&type=glass
В результате было бы создано следующее местоположение: /new/material.htm
Соответствует весь URL-адрес, включая строку запроса.
Несмотря на то, что в местоположении используется выражение <$id$>
, для этого примера оно не требуется, так как может соответствовать только одна возможная строка запроса. Местоположение может быть записано как /new/material.htm
.
Следующий URL-адрес не соответствует правилу:
/old/page.jsp
(Выражение правила содержит строку запроса, которая должна соответствовать.)
/old/page.jsp?id=material&type=glass&index=2
(Дополнительное выражение &index=2
в URL-адресе кандидата не полностью соответствует выражению правила.)
/old/page.jsp?type=glass&id=material
(Порядок параметров строки запроса должен соответствовать правилу "string".)
Пример соответствия при использовании подстановочных знаков
Правило:
{ "type": "wildcard", "expression": "/old/*/pages/*?id=*&item=sheet-*", "location": "/new/<$id$>/<$wildcard(4)$>.html" }
Следующие URL-адреса соответствуют правилу:
/old/phones/android/pages/info.asp?id=XT1045&item=sheet-specs
В результате было бы найдено следующее местоположение: /new/XT1045/specs.html
Часть пути URL-адреса соответствует, поэтому строка запроса также проверяется на соответствие условиям.
Параметры в данном примере соответствуют порядку параметров в выражении правила, но это не обязательно.
/old/phones/android/pages/info.asp?item=sheet-specs&id=XT1045
В результате было бы найдено следующее местоположение: /new/XT1045/specs.html
Часть пути URL-адреса соответствует выражению правила до знака вопроса (?
), поэтому параметры также проверяются на соответствие.
Несмотря на то, что параметры перечислены в выражении правила в другом порядке, они сопоставляются по отдельности.
/old/phones/android/pages/info.asp?id=XT1045&item=sheet-specs&unrelated=thing
В результате было бы найдено следующее местоположение: /new/XT1045/specs.html
Часть пути URL-адреса соответствует, поэтому строка запроса также проверяется на соответствие условиям.
URL-адрес кандидата имеет дополнительный параметр &unrelated=thing
, но поскольку именованные параметры запроса в выражении правила соответствуют, правило считается соответствующим.
Параметр unrelated
был бы доступен в местоположении как маркер, так как выражение <$unrelated$>
имело бы значение thing
, даже если оно не вносит вклад в соответствие правилу.
Следующие URL-адреса не соответствуют:
/old/pages/info.jsp
(Часть пути URL-адреса не соответствует части пути выражения правила.)
/old/phones/android/pages/info.asp
(Часть пути URL-адреса соответствует части пути выражения правила, а параметры запроса в выражении правила нет.)
/old/phones/android/pages/info.asp?id=cellular
(Часть пути URL-адреса соответствует части пути выражения правила, но не все параметры запроса в выражении правила соответствуют.)
Определение массива маркеров
Можно также создать массив определений маркеров в файле redirects.json
, что поможет при настройке перенаправлений, поддерживающих несколько неофициальных URL-адресов. Это позволяет перенаправлять адрес в соответствии с характеристиками входящего URL-адреса.
Используйте приведенный ниже формат в файле redirects.json
, чтобы определить маркеры для применения в URL-адресах правил перенаправления.
{ "tokenDefinitions": [ { "token": "sitePrefix", "type": "hostmatch", "expresion": "example.com" "value": "" }, { "token": "sitePrefix", "type": "hostmatch", "expresion": "*.com" "value": "/site/Starter-Site" }, { "token": "gotoRedirect", "type": "pathmatch", "expresion": "*oracle*" "value": "https://www.oracle.com" "flags": "caseinsensitive" }, ] }
Определения меток имеют указанные ниже свойства.
"token"
: имя маркера, который необходимо определить.
"type"
: один из указанных ниже вариантов.
"hostmatch"
для соответствия значению хоста входящего URL-адреса.
"pathmatch"
для соответствия значению пути входящего URL-адреса.
"querymatch"
для соответствия значению запроса входящего URL-адреса.
"expression"
: выражение, которое должно использоваться для сопоставления. Поддерживаются подстановочные знаки.
"value"
: значение, которое должно использоваться для маркера.
"flags"
: по умолчанию при сопоставлении выражений учитывается регистр, если только для значения flags
не задано значение caseinensitive
При вычислении значения маркера перечисление содержимого массива tokenDefinitions
будет выполняться в указанном порядке. Будет использоваться первое определение сопоставления. Если определения маркеров не соответствуют данному маркеру, вместо него будет использоваться пустая строка. По соображениям целесообразности и эффективности работы наиболее часто используемые маркеры должны располагаться в верхней части списка tokenDefinitions
.
К tokenDefinitions
применяются указанные ниже ограничения.
Можно создать до 250 определений маркеров.
Имя token
должно содержать менее 100 символов.
expression
может содержать до 10 подстановочных знаков.
expression
должно содержать менее 1000 символов.
value
должно содержать менее 1000 символов.
Пример
Например, возможно, у вас есть следующий файл redirects.json:
{ "redirectRules": [ { "type": "string", "expression": "/legacy-privacy-policy.html", "location": "<$pathPrefix$>/about/new-privacy-policy.html" }, ] "tokenDefinitions": [ { "token": "pathPrefix", "type": "hostmatch", "expression": "vanity.com" "value": "/fashion" }, ] }
В этом случае свойство location
правила имеет маркер <$pathPrefix$>
. Маркер pathPrefix
определяется в разделе tokenDefinitions
. Если входящий URL-адрес совпадает с "vanity.com", то для pathPrefix
будет задано значение /fashion
. Это будет использоваться в ответе location
, в результате чего мы получим /fashion/about/new-privacy-policy.html
.
Предположим, что первый URL-адрес персонализированного домена — http://example.com/legacy-privacy-policy.html
. Это будет соответствовать первому и единственному правилу перенаправления.
Объявленное значение location
для этого правила — <$pathPrefix$>/about/new-privacy-policy.html
. В этой ситуации необходимо оценить маркер <$pathPrefix$>
. Для этого содержимое массива tokenDefinitions
перечисляется, чтобы найти совпадение.
Учитывается первое определение маркера. Его token
является предпочтительным, поэтому он будет оцениваться в дальнейшем. Выражение vanity.com
не соответствует входящему URL-адресу example.com
, поэтому это определение не удовлетворяет требованиям, и перечисление продолжается.
На этом этапе определения маркеров больше не существуют, поэтому для значения маркера <$pathPrefix$>
используется пустая строка. Окончательное местоположение для этого перенаправления: /about/new-privacy-policy.html
.
Предположим, что второй URL-адрес персонализированного домена — http://vanity.com/legacy-privacy-policy.html
. Как и в случае с первым URL-адресом, объявленное значение location
для этого правила — <$pathPrefix$>/about/new-privacy-policy.html
. В этой ситуации необходимо оценить маркер <$pathPrefix$>
. Для этого содержимое массива tokenDefinitions
перечисляется, чтобы найти совпадение.
Учитывается первое определение маркера. Как и раньше, его token
является предпочтительным, поэтому он будет оцениваться в дальнейшем. Выражение vanity.com
соответствует входящему URL-адресу vanity.com
, поэтому это определение удовлетворяет требованиям, а значение /fashion
используется в качестве значения маркера.
Поскольку для маркера было найдено совпадение, перечисление содержимого массива определений маркеров прекращается и окончательное местоположение вычисляется как /fashion/about/new-privacy-policy.html
.
Тестирование перенаправлений сайта
При редактировании сайта можно повторно протестировать его перенаправления, открыв панель Настройки и нажав Перенаправления. Введите URL-адрес для тестирования и нажмите Тест.