Faraday: response.body имеет значение ASCII-8BIT, когда Content-Type имеет значение text / xml; charset = utf-8

Созданный на 16 апр. 2012  ·  9Комментарии  ·  Источник: lostisland/faraday

Первый раз использую faraday, поэтому я могу делать что-то неправильно, но кодировка response.body в следующем примере - 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

В 1.9.2 это заставляет REXML выдавать Encoding::CompatibilityError .

Я не мог найти способ заставить Фарадея предоставить response.body в UTF-8.

Какое решение для этого предпочтительнее?

Самый полезный комментарий

Я использовал следующее обходное решение:

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

Yahuda имеет диссертацию о проблеме здесь .

Все 9 Комментарий

Просто столкнулся с той же проблемой. Любые идеи?

Я использовал следующее обходное решение:

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

Yahuda имеет диссертацию о проблеме здесь .

Я почти уверен, что Фарадей просто передает тело ответа от нижележащего адаптера . Я не уверен, что хочу выдавать ошибки или выполнять преобразование данных с потерями по Фарадею. Это можно сделать с помощью специального промежуточного программного обеспечения, если оно вам действительно нужно.

Справедливо. Если проблема в другом месте, я думаю, со временем она будет устранена. Для меня это не шоу-стоп.

Закрытие, потому что это не ошибка Фарадея.

Я не уверен, что базовый адаптер - по крайней мере, net / http - выполняет какое-либо преобразование кодировки. Вы можете установить Ruby Encoding.default_external на что-то вроде «US-ASCII», а затем попасть в конечную точку с Content-Type = '...; charset = utf-8 '... net / http проанализирует строку кодировки и сделает ее доступной, но ничего не сделает с кодировкой строки тела. Возможно, за это должен отвечать net / http, но если это не так, промежуточное ПО ParseJson (например) может взорваться.

Провел еще несколько исследований по этому поводу - некоторые из базовых адаптеров обрабатывают кодировку Content-Type, а некоторые нет:

EM-HTTP-Request делает. [ совершить ].
Покровитель делает. [ совершить ].
HTTPClient выполняет [[совершает] (https://github.com/nahi/httpclient/commit/e5efea5afb3b5cf6ead3a131644dee71be1ee5e9)] [[проблема] (https://github.com/nahi/httpclient/issues/26)].
Typhoeus и Excon (и net / http) не работают.

Я думаю, что лучше всего было бы, возможно, предложить дополнительное промежуточное ПО для адаптеров, которые не пробуют, но, да, я согласен, это, вероятно, не должно быть ответственностью Фарадея.

@chrismo ты мой герой. Спасибо за это исследование!

Была ли эта страница полезной?
0 / 5 - 0 рейтинги