Faraday: response.body es ASCII-8BIT cuando Content-Type es text / xml; juego de caracteres = utf-8
La primera vez que uso faraday, por lo que podría estar haciendo las cosas incorrectamente, pero la codificación response.body en lo siguiente es ASCII-8BIT:
def self.search(term)
connection = Faraday.new(url: 'https://en.wikipedia.org')
response = connection.get do |req|
req.options = { :timeout => 5, :open_timeout => 3 }
req.url '/w/api.php' , action: 'opensearch', format: 'xml', search: term
end
puts response.body.encoding
end
En 1.9.2, esto hace que REXML arroje un Encoding::CompatibilityError .
No pude encontrar una manera de obligar a Faraday a proporcionar response.body en UTF-8.
¿Cuál es la solución preferida para esto?
auxbuss
Todos 9 comentarios
Acabo de encontrar el mismo problema. ¿Algunas ideas?
ghost
en 17 abr. 2012
La solución alternativa que utilicé es:
response.body.force_encoding('utf-8')
Yahuda tiene una disertación sobre el problema aquí .
auxbuss
en 17 abr. 2012
Estoy bastante seguro de que Faraday simplemente pasa el cuerpo de respuesta del adaptador subyacente . No estoy seguro de querer generar errores o realizar conversiones con pérdida de datos en Faraday. Eso se puede hacer en un middleware personalizado si realmente lo necesita.
technoweenie
en 1 may. 2012
Lo suficientemente justo. Si el problema está en otra parte, como parece, supongo que se solucionará a tiempo. No es un obstáculo para mí.
auxbuss
en 1 may. 2012
Cerrando porque no es un error de Faraday.
mislav
en 29 may. 2012
No estoy seguro de que el adaptador subyacente, al menos net / http, realice alguna transformación de codificación. Puede configurar Ruby's Encoding.default_external en algo como 'US-ASCII', luego alcanzar un punto final con Content-Type = '...; charset = utf-8 '... net / http analizará la cadena del juego de caracteres y la pondrá a disposición, pero no modificará la codificación de la cadena del cuerpo. Quizás net / http debería ser responsable de eso, pero si no lo es, el middleware ParseJson (por ejemplo) puede explotar.
chrismo
en 20 sept. 2014
Investigué un poco más sobre esto: algunos de los adaptadores subyacentes manejan el juego de caracteres Content-Type, otros no:
EM-HTTP-Request lo hace. [ comprometerse ].
El patrón lo hace. [ comprometerse ].
HTTPClient hace [[commit] (https://github.com/nahi/httpclient/commit/e5efea5afb3b5cf6ead3a131644dee71be1ee5e9)] [[problema] (https://github.com/nahi/httpclient/issues/26)].
Typhoeus y Excon (y net / http) no parecen hacerlo.
Supongo que lo mejor que puede hacer sería ofrecer un middleware opcional para los adaptadores que no lo intentan, pero sí, estoy de acuerdo, esto probablemente no debería ser responsabilidad de Faraday.
chrismo
en 20 sept. 2014
cyzgbw
en 2 mar. 2016
@chrismo eres mi héroe. ¡Gracias por hacer esa investigación!
etipton
en 4 jul. 2016
Temas relacionados
jedeleh
·
3Comentarios
subvertallchris
·
5Comentarios
Lewiscowles1986
·
4Comentarios
asf-stripe
·
3Comentarios
t3hk0d3
·
3Comentarios
Comentario más útil
La solución alternativa que utilicé es:
Yahuda tiene una disertación sobre el problema aquí .