La ruptura de urliben de Urllib en algunos sitios (por ejemplo, api de StackApps): devuelve resultados de basura

Estoy usando la función urlopen para intentar obtener un resultado JSON de la api StackOverflow.

El código que estoy usando:

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

El resultado que estoy obteniendo:

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

Soy bastante nuevo en urllib, pero esto no parece ser el resultado que debería obtener. Lo he intentado en otros lugares y obtengo lo que espero (lo mismo que visitar la dirección con un navegador me da: un objeto JSON).

El uso de urlopen en otros sitios (por ejemplo, ” http://google.com “) funciona bien y me da el código HTML real. También he intentado usar urllib y da el mismo resultado.

Estoy bastante atascado, sin saber siquiera dónde buscar para resolver este problema. ¿Algunas ideas?

Eso casi parece algo que estarías amamantando. Tal vez algo en la cadena User-Agent o en el encabezado Acepta que urllib2 está enviando está haciendo que StackOverflow envíe algo que no sea JSON.

Un indicador es mirar conn.headers.headers para ver lo que dice el encabezado Content-Type.

Y esta pregunta, Resultado de formato de cadena impar de API Call , puede tener su respuesta. Básicamente, es posible que tenga que ejecutar su resultado a través de un descompresor gzip.

Doble comprobación con este código:

 >>> 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' 

Sí, definitivamente estás recuperando datos codificados con gzip.

Como parece que obtienes resultados diferentes en diferentes máquinas con la misma versión de Python, y en general parece que la API urllib2 requiere que hagas algo especial para solicitar datos codificados en gzip, supongo que tienes un proxy transparente allí. en algún lugar.

Vi una presentación de la EFF en CodeCon en 2009. Estaban haciendo pruebas de conectividad de extremo a extremo para descubrir trucos de ISP sucios de varios tipos. Una de las cosas que descubrieron al realizar estas pruebas es que un número sorprendente de enrutadores NAT de nivel de consumidor agregan encabezados HTTP aleatorios o hacen proxy transparente. Es posible que tenga algún equipo en su red que agregue o modifique el encabezado Accept-Encoding para que su conexión parezca más rápida.