Encoding::CompatibilityError
Original error message:
/Library/Ruby/Gems/2.0.0/gems/ruby-msg-1.5.1/lib/mime.rb:109:in `join': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError)
from /Library/Ruby/Gems/2.0.0/gems/ruby-msg-1.5.1/lib/mime.rb:109:in `to_s'
from /Library/Ruby/Gems/2.0.0/gems/ruby-msg-1.5.1/bin/mapitool:104:in `block in process_message'
from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:36:in `open'
from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:36:in `open'
from /Library/Ruby/Gems/2.0.0/gems/ruby-msg-1.5.1/bin/mapitool:125:in `process_message'
from /Library/Ruby/Gems/2.0.0/gems/ruby-msg-1.5.1/lib/mapi/msg.rb:344:in `open'
from /Library/Ruby/Gems/2.0.0/gems/ruby-msg-1.5.1/bin/mapitool:46:in `block in each_message'
from /Library/Ruby/Gems/2.0.0/gems/ruby-msg-1.5.1/bin/mapitool:30:in `each'
from /Library/Ruby/Gems/2.0.0/gems/ruby-msg-1.5.1/bin/mapitool:30:in `each_message'
from /Library/Ruby/Gems/2.0.0/gems/ruby-msg-1.5.1/bin/mapitool:52:in `run'
from /Library/Ruby/Gems/2.0.0/gems/ruby-msg-1.5.1/bin/mapitool:171:in `mapitool'
from /Library/Ruby/Gems/2.0.0/gems/ruby-msg-1.5.1/bin/mapitool:174:in `<top (required)>'
from /usr/bin/mapitool:23:in `load'
from /usr/bin/mapitool:23:in `<main>'
I ran through your how-to in IRB and traced it to line 109 of lib/mime
Changing
parts.map { |part| "\r\n" + part.to_s(opts) + "\r\n" }
to
parts.map { |part| "\r\n" + part.to_s(opts).force_encoding('UTF-8') + "\r\n" }
seems to have addressed the issue.
I'll attach a pull request to this issue tomorrow morning with my change.
This project was originally written for ruby 1.8 and I've never really spent the time to properly address some of these issues. I don't think forcing the encoding to UTF8 is the way to go though - different MIME parts could conceivably have different encodings, as would be noted in the Content-Type charset. The code which concatenates parts should just be treating them as opaque blobs rather than text with a known encoding. I probably need to just add the special "encoding: ASCII-8BIT" comments to the files to fix the string literals and it should work fine.
+1 for merging this fix
+1 for merge
+1 on merge here. I just came to the same conclusion as the OP for the solution and implemented it locally, but in lieu of a better solution, perhaps this one should be adopted?
I did some digging on this and I found that .eml files are encoded in ascii while msg files support multiple encodings. It appears the proper fix is to change the encodings of the outputs to ascii so that the resulting eml file is 100% ascii. I'm going to work on a different PR.