urlopen Urllib, повреждающийся на некоторых сайтах (например, StackApps api): результаты мусора возвратов
Я использую urllib2 urlopen функция, чтобы попытаться получить JSON следует из StackOverflow api.
Код я использую:
>>> 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 ответ
Это почти похоже на то, что вы кормите маринадом. Возможно, что-то в строке 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 , чтобы ваше соединение казалось более быстрым.