Faraday: response.body é ASCII-8BIT quando Content-Type é text / xml; charset = utf-8

Criado em 16 abr. 2012 · 9Comentários · Fonte: lostisland/faraday

Primeira vez usando faraday, então posso estar fazendo as coisas incorretamente, mas a codificação response.body a seguir é 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

No 1.9.2, isso faz com que o REXML lance um Encoding::CompatibilityError .

Não consegui encontrar uma maneira de forçar o faraday a fornecer response.body em UTF-8.

Qual é a solução preferida para isso?

bug

Fonte

auxbuss

Comentários muito úteis

A solução alternativa que usei é:

response.body.force_encoding('utf-8')

Yahuda tem uma dissertação sobre o problema aqui .

auxbuss em 17 abr. 2012

👍4 🎉1

Todos 9 comentários

Acabei de encontrar o mesmo problema. Alguma ideia?

ghost em 17 abr. 2012

A solução alternativa que usei é:

response.body.force_encoding('utf-8')

Yahuda tem uma dissertação sobre o problema aqui .

auxbuss em 17 abr. 2012

👍4 🎉1

Tenho certeza de que Faraday apenas passa o corpo de resposta do adaptador subjacente . Não tenho certeza se desejo gerar erros ou realizar conversões com perdas dos dados em Faraday. Isso pode ser feito em um middleware personalizado, se você realmente precisar.

technoweenie em 1 mai. 2012

É justo. Se o problema estiver em outro lugar, como parece, acho que será resolvido com o tempo. Não é um obstáculo para mim.

auxbuss em 1 mai. 2012

Fechando porque não é um bug do Faraday.

mislav em 29 mai. 2012

Não tenho certeza se o adaptador subjacente - pelo menos net / http - faz alguma transformação de codificação. Você pode definir Encoding.default_external do Ruby para algo como 'US-ASCII' e, em seguida, atingir um endpoint com Content-Type = '...; charset = utf-8 '... net / http irá analisar a string do conjunto de caracteres e torná-la disponível, mas não faz nada para a codificação da string do corpo. Talvez net / http deva ser o responsável por isso, mas se não for, o middleware do ParseJson (por exemplo) pode explodir.

chrismo em 20 set. 2014

Fiz mais pesquisas sobre isso - alguns dos adaptadores subjacentes lidam com o charset Content-Type, outros não:

EM-HTTP-Request sim. [ commit ].
O patrono faz. [ commit ].
HTTPClient faz [[commit] (https://github.com/nahi/httpclient/commit/e5efea5afb3b5cf6ead3a131644dee71be1ee5e9)] [[problema] (https://github.com/nahi/httpclient/issues/26)].
Typhoeus e Excon (e net / http) não parecem.

Acho que a melhor coisa a fazer seria talvez oferecer um middleware opcional para adaptadores que não tentam, mas, sim, eu concordo, isso provavelmente não deveria ser responsabilidade de Faraday.

chrismo em 20 set. 2014

❤4

tente https://github.com/qhwa/string_utf8