Faraday: response.body est ASCII-8BIT lorsque Content-Type est text/xml ; jeu de caractères=utf-8

Créé le 16 avr. 2012 · 9Commentaires · Source: lostisland/faraday

La première fois que j'utilise faraday, je fais peut-être les choses de manière incorrecte, mais l'encodage response.body dans ce qui suit est 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

Dans la version 1.9.2, REXML lance un Encoding::CompatibilityError .

Je n'ai pas trouvé de moyen de forcer faraday à fournir response.body en UTF-8.

Quelle est la solution préférée à cela?

bug

Source

auxbuss

Commentaire le plus utile

La solution de contournement que j'ai utilisée est la suivante :

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

Yahuda a une thèse sur le problème ici .

auxbuss le 17 avr. 2012

👍4 🎉1

Tous les 9 commentaires

Je viens de rencontrer le même problème. Des idées?

ghost le 17 avr. 2012

La solution de contournement que j'ai utilisée est la suivante :

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

Yahuda a une thèse sur le problème ici .

auxbuss le 17 avr. 2012

👍4 🎉1

Je suis presque sûr que Faraday ne fait que transmettre le corps de la réponse

technoweenie le 1 mai 2012

Assez juste. Si le problème est ailleurs, comme il apparaît, je suppose qu'il sera nettoyé à temps. Ce n'est pas un spectacle pour moi.

auxbuss le 1 mai 2012

Fermeture car ce n'est pas un bug avec Faraday.

mislav le 29 mai 2012

Je ne suis pas sûr que l'adaptateur sous-jacent - au moins net/http - effectue une transformation d'encodage. Vous pouvez définir Ruby's Encoding.default_external sur quelque chose comme 'US-ASCII', puis atteindre un point de terminaison avec Content-Type = '...; charset=utf-8' ... net/http analysera la chaîne du jeu de caractères et la rendra disponible, mais ne fera rien pour l'encodage de la chaîne du corps. Peut-être que net/http devrait être responsable de cela, mais si ce n'est pas le cas, le middleware ParseJson (par exemple) peut exploser.

chrismo le 20 sept. 2014

A fait quelques recherches supplémentaires à ce sujet - certains des adaptateurs sous-jacents gèrent le jeu de caractères Content-Type, d'autres non :

EM-HTTP-Request le fait. [ commettre ].
Le patron le fait. [ commettre ].
HTTPClient fait [[commit](https://github.com/nahi/httpclient/commit/e5efea5afb3b5cf6ead3a131644dee71be1ee5e9)] [[issue](https://github.com/nahi/httpclient/issues/26)].
Typhoeus et Excon (et net/http) ne semblent pas le faire.

Je suppose que la meilleure chose à faire serait peut-être d'offrir un middleware en option pour les adaptateurs qui n'essaient pas, mais, oui, je suis d'accord, cela ne devrait probablement pas être la responsabilité de Faraday.

chrismo le 20 sept. 2014

❤4

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