Why does Premailer convert ASCII code into symbols/characters?

[adamt19]

Premailer converts [& copy ;](without spaces) to ©, [& quot ;] to ", [& amp ;] to &.. and I can't imagine a use case where this would be helpful. I've emailed Alex about this and I believe he told me that some people want it different ways.

I don't get it - this takes a perfectly-validated email transmission, and leaves with potentially hundreds of validation errors.

It makes premailer no-longer a useful tool for us, and I imagine most people, at all.

WHO are the people that told Alex they needed premailer to behave like this? Are they a majority?

[alexdunae]

Nobody told me that -- it's just an artifact of Hpricot, the HTML parser used by Premailer. It's definitely on my list fix.

[davidrivers]

Will this be fixed soon? This is unfortunately a deal-breaker for my team, too :(

[akzhan]

It looks that resolved because we can now use Nokogiri parser instead of Hpricot.

I wait for release :)

[adamt19]

Can't wait! :)

On Sat, Mar 26, 2011 at 1:24 PM, akzhan <
reply@reply.github.com>wrote:

It looks that resolved because we can now use Nokogiri parser instead of
Hpricot.

I wait for release :)

Reply to this email directly or view it on GitHub:
https://github.com/alexdunae/premailer/issues/30#comment_920679

[akzhan]

alexdunae, any estimations about premailer release with Nokogiri integration?

[alexdunae]

@akzhan -- Tuesday at the latest. I'd like to finish getting the test suite up to scratch.

[akzhan]

Good news. We/ll plan to release later :)

[adamt19]

Hey Alex, we noticed the change to the new parser, but then it seems things have been reverted?

[adamt19]

Hey Alex, we noticed the change to the new parser, but then it seems things have been reverted?

[akzhan]

Send :adapter => :nokogiri option to Premailer.new to use alternate (and more effective) parser.

[adamt19]

Sorry for the newb question, but could someone be more specific as to what I'd need to do in order to use nokogiri? We're using the bookmarklet right now, but if I can host a modified version of the script on my own, I'd like to do so -- at least until v2! Thx

[alexdunae]

I've added a Nokogiri option to http://premailer.dialect.ca/ -- I'll take a look at how to create an option via the bookmarklet.

[mehas]

The Nokogiri parser still has the same problem. For example, ’ is converted to ’ after being run through Premailer using the Nokogiri parser.

What's more, it appends 
 to the end of every line.

[egid]

As I commented in issue 92 (duplicate), the temporary, hacky workaround seems to be to remove the charset from your meta tag.

I am now using <meta http-equiv="Content-Type" content="text/html" /> without issues.

[parxier]

another dup #148?

[akzhan]

another dup #160

[pduersteler]

Is there something we can do to resolve this issue? Do we know where the actual problem is? I'd invest time and create a pull request, since I need to have this worked out. Removing a charset line and/or adding <meta http-equiv="Content-Type" content="text/html" /> didn't helped, neither did setting adapter: :nokogiri.

I just checked out the charset-branch to test things, and the problem does not appear there. I am not sure how accurate a compare is, but maybe this gives some hints on where to look: https://github.com/premailer/premailer/compare/charset

[amclin]

I ran into this suddenly today when setting up my build system on a new machine.

• When using Hpricot, html encoded characters ®``© are preserved
• When using Nokogiri, html encoded characters ®``© are converted to UTF-8 ®``©

[amclin]

So apparently Nokogiri always rewrites HTML entities to UTF-8 characters. You can get HTML entities back using doc.to_html(encoding:'US-ASCII')

http://stackoverflow.com/questions/7756123/nokogiri-leaving-html-entities-untouched

It won't give you the friendly-name entity © but at least it will give you a working entity ©

[akzhan]

Closed due to #181.