mikel/mail — Issue #359: Address#decoded and #encoded change output of other methods
Author: halfbyte
Created: 2012-02-21 22:44:18+00:00
State: open

While using `Mail::Address` to decode some Sendgrid Parse request fields, I noticed that `Mail::Address#name` outputs an undecoded string. After calling `#decoded`, `#name` suddenly returns a decoded string (which is what I wanted, of course).

Here's the IRB session for you to judge:

```ruby
ruby-1.9.2-p290 :002 > require 'mail'
=> true
ruby-1.9.2-p290 :003 > a = Mail::Address.new('=?ISO-8859-1?Q?Jan_Kr=FCtisch?= ')
=> #| >
ruby-1.9.2-p290 :004 > a.name.to_s
=> "=?ISO-8859-1?Q?Jan_Kr=FCtisch?="
ruby-1.9.2-p290 :005 > a.decoded
=> "\"Jan Krütisch\" "
ruby-1.9.2-p290 :006 > a.name.to_s
=> "Jan Krütisch"
ruby-1.9.2-p290 :007 > exit
```

I tested this in a Rails 3.1 app but already verified that the problem is present in the current version. The relevant lines are (in [address.rb](https://github.com/mikel/mail/blob/master/lib/mail/elements/address.rb):

```ruby
def encoded
@output_type = :encode
format
end

def decoded
@output_type = :decode
format
end
````

Now, my current workaround of course is to call `#decoded` before I call `#name` and I am suspecting I might not be the only one, which should be considered when "fixing" this. Also, I didn't really check if this is a common problem in the code base or if address.rb is a special case.

I would totally volounteer to fix this issue myself by providing a pull req, but actually I'm not quite sure how this should be handled. Should all sub fields of Address always be returned in decoded format? shouldn't they?

I would love to see some discussion on this, before I actually change code.