Может кто-нибудь дать мне Регулярное выражение для идентификации закодированного URL?

Question

В настоящее время я пытаюсь определить, закодирован URL-адрес или нет. Вот несколько конкретных примеров:

1. http://www.linxology.com/browse.php?u=Oi8vZXNwbnN0YXIuY29tL21lZGlhLXBsYXllci8%3D&b=13
2. http://www.linxology.com/browse.php?u=Oi8vZXNwbnN0YXIuY29tL290aGVyX2ZpbGVzL2VzcG5zdGFyL25hdl9iZy1vZmYucG5n&b=13

Не могли бы вы дать мне регулярное выражение для этого? Существует ли самообучающийся генератор регулярных выражений, который может фильтровать идеальное регулярное выражение при увеличении количества входных данных?

Answer 1

Если вас интересуют URL-адреса в кодировке base64, вы можете это сделать.

Немного теории. Если L, R являются обычными языками, а T является обычным преобразователем, то LR (объединение), L & R (пересечение), L | R (объединение), TR(L) (изображение), TR^-1(L) (ядро) - все обычные языки. Каждый регулярный язык имеет регулярное выражение, которое его генерирует, и каждое регулярное выражение генерирует регулярный язык. URL-адреса могут быть описаны обычным языком (за исключением случаев, когда вам нужно подмножество тех, которых нет), почти каждая схема перехода (и base64) является обычным преобразователем. Поэтому теоретически это возможно.

На практике все становится довольно грязно.

Регулярное выражение для допустимых строк base64: ([A-Za-z0-9+/]{4})*(|[A-Za-z0-9+/]{2}(==|[A-Za-z0-9+/]=)

Если он встроен в параметр запроса URL-адреса, он, вероятно, будет закодирован в формате urlencoded. Давайте предположим, что только url будет закодирован (потому что другие символы тоже могут, но не обязаны).

Это приводит нас к чему-то вроде [?&][^?&#=;]+=([A-Za-z0-9+/]{4})*(|[A-Za-z0-9+/]{2}(%3D%3D|[A-Za-z0-9+/]%3D)

Другая возможность состоит в том, чтобы рассматривать только те URL-адреса в кодировке base64, которые имеют какое-либо свойство - в вашем случае все они начинаются с ": //", что очень удачно, потому что это точно соответствует 4 символам "Oi8v". В противном случае это было бы более сложным.

Получается [?&][^?&#=;]+=Oi8v([A-Za-z0-9+/]{4})*(|[A-Za-z0-9+/]{2}(%3D%3D|[A-Za-z0-9+/]%3D)

Как видите, все становится все более и более грязным. Поэтому я бы рекомендовал вам

1. разбить URL на его части (например, протокол, хост, строка запроса)
2. получить параметры из строки запроса и urldecode их
3. попробуйте base64 декодировать по значениям параметров
4. применить ваш критерий для "хороших закодированных URL"

Answer 2

Этот вопрос может быть сложнее, чем вы думаете. Например:

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

Теперь, это может быть простая кодировка типа "? Year = 2009" или сложная, как в ваших примерах.

Или

URL-адреса сайта могут использовать перезапись URL-адресов (как это делает этот сайт). Посмотрите на URL этого вопроса. Код 615958 закодирован и ... знаки вопроса не использовались!

На самом деле, вы можете сказать, что весь URL закодирован!

Возможно, вам нужно лучше определить, что вы подразумеваете под "закодированным".

Answer 3

Вы не можете надежно разобрать URL с помощью регулярных выражений. (Это уже ТАК мантра?)

Вот несколько конкретных примеров:

Непонятно, что означает «закодированный» - можете ли вы привести контрпримеры URL, которые вы считаете «не закодированными»?

Вы говорите о кодировке Base64 в параметре "u"? Хотя можно сказать, является ли строка допустимой строкой Base64, невозможно обнаружить Base64 и отличить ее от чего-либо еще; например, слово «сосиски» также является допустимым Base64 (оно декодируется как «\ xb1 \ xab \ xacj \ x07 \ xac»).

Answer 4

Ну, в зависимости от того, что находится в этом закодированном тексте, вам может даже не потребоваться регулярное выражение. Если в этом одном ключе «u» есть несколько параметров строки запроса, возможно, вы можете просто проверить длину текста в каждом значении строки запроса, а если оно превышает (скажем) 50, вы можете предположить, что оно, вероятно, закодировано. Я сомневаюсь, что любые некодированные одиночные параметры будут такими же длинными, поскольку они должны быть строковыми данными, и, следовательно, их, вероятно, необходимо будет закодировать!