Взлом urlopen Urllib на некоторых сайтах (например, StackApps API): возвращает результаты мусора - PullRequest
10 голосов
/ 12 июня 2010

Я использую функцию urllib2 urlopen, чтобы попытаться получить результат JSON из API StackOverflow.

Код, который я использую:

>>> import urllib2
>>> conn = urllib2.urlopen("http://api.stackoverflow.com/0.8/users/")
>>> conn.readline()

Результат, который я получаю:

'\x1f\x8b\x08\x00\x00\x00\x00\x00\x04\x00\xed\xbd\x07`\x1cI\x96%&/m\xca{\x7fJ\...

Я довольно новичок в urllib, но это не похоже на результат, который я должен получить. Я пробовал это в других местах, и я получаю то, что ожидаю (так же, как посещение адреса с помощью браузера дает мне: объект JSON).

Использование urlopen на других сайтах (например, "http://google.com") работает нормально и дает мне реальный HTML. Я также пытался использовать urllib, и это дает тот же результат.

Я застрял, даже не зная, где искать решение этой проблемы. Есть идеи?

1 Ответ

10 голосов
/ 12 июня 2010

Это почти похоже на то, что вы будете кормить, чтобы мариновать. Возможно, что-то в строке User-Agent или заголовке Accepts, которое отправляет urllib2, заставляет StackOverflow отправлять что-то отличное от JSON.

Один контрольный сигнал - посмотреть на conn.headers.headers, чтобы увидеть, что говорит заголовок Content-Type.

И этот вопрос, Результат формата нечетной строки из вызова API , может иметь ваш ответ. По сути, вам, возможно, придется прогнать свой результат через декомпрессор gzip.

Двойная проверка с этим кодом:

>>> req = urllib2.Request("http://api.stackoverflow.com/0.8/users/",
                          headers={'Accept-Encoding': 'gzip, identity'})
>>> conn = urllib2.urlopen(req)
>>> val = conn.read()
>>> conn.close()
>>> val[0:25]
'\x1f\x8b\x08\x00\x00\x00\x00\x00\x04\x00\xed\xbd\x07`\x1cI\x96%&/m\xca{\x7fJ'

Да, вы определенно получаете обратно закодированные данные в формате gzip.

Поскольку вы, кажется, получаете разные результаты на разных машинах с одной и той же версией Python, и в целом похоже, что API urllib2 потребует от вас сделать что-то особенное для запроса данных в кодировке gzip, я предполагаю, что у вас прокси там где-то.

Я видел презентацию EFF на CodeCon в 2009 году. Они проводили комплексное тестирование подключения, чтобы обнаружить грязные трюки ISP различных типов. Одна из вещей, которые они обнаружили во время этого тестирования, заключается в том, что удивительное количество NAT-маршрутизаторов уровня потребителя добавляет случайные заголовки HTTP или выполняют прозрачное проксирование. Возможно, в вашей сети есть какое-то оборудование, которое добавляет или изменяет заголовок Accept-Encoding, чтобы ваше соединение выглядело быстрее.

...