Rails - sujet mail est du charabia dans hotmail

Question

emails d'envoi fonctionne parfaitement pour tous les clients de messagerie, à l'exception hotmail (et quelques autres), il montre que:

=?windows-1255?Q?Z33=30_=F9=22=E7=20=F2=E1=E5=F8_=F9=E5=E1=F8=20=E1=F9=E5=E5=E9=20=36=30_=F9=22=E7=20=EC=22=EE=F8=E2=E5=E6=E4=22=2C_=E1=E9=FA_=F7=F4=E4=20=E5=EE=E0=F4=E9=E9=E4_=EE=F9=F4=E7=FA=E9=FA=2C=20=E1=EE=FA=E7=ED=20=F9=E5=F7=20=E4=F4=F9=F4=

matière dosn't si elle est UTF8 ou pas. Il semble que hotmail ne peut pas lire de longs sujets cités, parce que pour les plus courts, ça se voit bien.

AFAIK ce que Gmail fait par exemple est de diviser le sujet en morceaux, 64 (ou quelque chose) caractères longs ... Mais je ne peux pas comprendre comment faire cela dans les rails (2.3.8). Rails encode le sujet par défaut, sous forme de guillemets, ne peut pas trouver comment remplacer cela afin que je puisse le diviser par moi-même ...

Merci.

Answer 1

C'est ce qui a fonctionné pour moi:

 
module ActionMailer 
    module Quoting 
    def quoted_printable(text, charset) 
     require 'base64' 
     #text.scan_utf8(/.{1,64}/m).map{|text| "=?#{charset}?B?#{Base64.b64encode(text)}?="}.join("\n") 
     "=?#{charset}?B?#{Base64.b64encode(text).gsub(/\n/, '')}?=" 
    end 
    end 
end 

module TMail 
    class SubjectHeaderField < UnstructuredHeader 
    def parse 
     #Do nothing 
    end 
    end 

    class HeaderField 
    FNAME_TO_CLASS = FNAME_TO_CLASS.merge('subject' => SubjectHeaderField) 
    end 
end 

Answer 2

Si vous avez une ligne de sujet très long alors vous pourriez avoir besoin de diviser sur plusieurs lignes en utilisant = comme ce qui suit:

Subject: =?iso-8859-1?Q?This_is_a_really_long_subject_that_should_need_so?= 
=?iso-8859-1?Q?me_encoding_to_make_sure_that_it_all_fits_correct?= 
=?iso-8859-1?Q?ly_=E7?= 

je devais mettre un « C » à la fin du ligne d'objet pour obtenir Apple Mail pour le citer, mais il devrait vous donner l'image. Je ne peux pas me rappeler exactement combien de temps il devrait être avant de le diviser, je pense que son 78 après encodage, mais pas sûr à 100%, 64 sera en sécurité si c'est ce que vous voyez.