Парсинг рефереров с яндекса

[lorien]

Парсинг рефереров с яндекса

Встала тут такая проблема. Если ввести запрос в форму яндекса и потом выбрать, к примеру, вторую страницу резальтатов, то реферер будет иметь такой вид в конце:

&qs=text%3Dtest%26stype%3Dwww

То есть яндекс вместо того, чтобы заменить знаки & на & заменяет его на %26. То же самое и с знаком равенства. Вопрос, как такую кривизну парсить? Просто отсекать до первого амперсанда или %26 нельзя, так как в запросе, если он введён в кавычках, может быть амперсанд). Я вижу выход только в том, чтобы добавить в регесп функциональность для кавычек... Может, есть более простые решения и я просто чего-то не понимаю?

Tags: яндекс, реферер, парсинг

 

[Andreika]

введи эти Tags(ну м.б. кроме парсинга) в поиск по форуму - должно помочь

 

[lorien]

OFFTOP:
1) Ввёл. Никаких откровений не нашёл. Ткни меня носом в запрос, в котором я найду то, что мне надо, а не в котором, я найду то, что мне надо, как тебе кажецца.
2) Почему на этом форуме до сих пор не сделан поиск с учётом морфологии?

 

[Andreika]

в поиск слово yandex и первая ссылка
(раскодирование ссылки с НЕпервой страницы Yandex. )

 

[SiMM]

> То есть яндекс вместо того, чтобы заменить знаки & на & заменяет его на %26.
Яндекс тут вообще не при чём.
[m]rawurldecode[/m]

 

[lorien]

Спасибо. Релевантная моему топику тема. Но мне не подходит, потому что я не испытываю проблем с декодированием поисковой фразы. Я испытываю проблемы с чётким определеним того, что надо декодировать. Более подробно я описал проблему в первом посте текущего топика.

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

-~{}~ 13.10.05 09:41:

Яндекс тут вообще не при чём.

Яндекс причастен, потому что амперсенд-детерминатор GET-параметров кодируется другими поисковыми системами в & а не в %26. А яндекс в одном случае делает &, в другом случае делает %26.

 

[basboy]

lorien
Тебе что, проблематично заменить %26 на амперсанд?

 

[Crazy]

Re: Парсинг рефереров с яндекса

Автор оригинала: lorien
То есть яндекс вместо того, чтобы заменить знаки & на & заменяет его на %26.

И что конкретно кривого ты в этом видишь? Строго по стандарту.

Или ты это парсить не умеешь? Ну тогда это твоя проблема, а не яндекса.

 

[lorien]

И что конкретно кривого ты в этом видишь? Строго по стандарту.

По какому стандарту. Скажи номер RFC или название другого регламентирующего официального документа.

RFC1738:

n addition, octets may be encoded by a character triplet consisting
   of the character "%" followed by the two hexadecimal digits (from
   "0123456789ABCDEF") which forming the hexadecimal value of the octet.
   (The characters "abcdef" may also be used in hexadecimal encodings.)

   Octets must be encoded if they have no corresponding graphic
   character within the US-ASCII coded character set, if the use of the
   corresponding character is unsafe, or if the corresponding character
   is reserved for some other interpretation within the particular URL
   scheme.

далее там же

 Reserved:

   Many URL schemes reserve certain characters for a special meaning:
   their appearance in the scheme-specific part of the URL has a
   designated semantics. If the character corresponding to an octet is
   reserved in a scheme, the octet must be encoded.  The characters ";",
   "/", "?", ":", "@", "=" and "&" are the characters which may be
   reserved for special meaning within a scheme. No other characters may
   be reserved within a scheme.

   Usually a URL has the same interpretation when an octet is
   represented by a character and when it encoded. However, this is not
   true for reserved characters: encoding a character reserved for a
   particular scheme may change the semantics of a URL.

   Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
   reserved characters used for their reserved purposes may be used
   unencoded within a URL.

   On the other hand, characters that are not required to be encoded
   (including alphanumerics) may be encoded within the scheme-specific
   part of a URL, as long as they are not being used for a reserved
   purpose.

 

[Andreika]

lorien
первый запрос
text=test&a=1
ссылка на второй запрос
qs=text%3Dtest%26a%3D1
а по твоему должна быть
qs=text%3Dtest&a%3D1 ?

в первом случае $_GET['qs']="text%3Dtest%26...."
во втором $_GET['qs']="text=test"

 

[lorien]

Всё, большое спасибо. Я понял. Я не обратил внимания, что закодированные амперсенды - это всё составляющая параметра qs. Я думал, что text - это самостоятельный параметр.

 

[Crazy]

Автор оригинала: lorien
RFC1738:
n addition, octets may be encoded by a character triplet consisting
of the character "%" followed by the two hexadecimal digits (from
"0123456789ABCDEF") which forming the hexadecimal value of the octet.

Ты не пробовал читать этот текст ДО цитирования? Это как раз и есть нужное место.