Comments on: Two Amazing Things: Thing #1

By: Radar

Radar — Fri, 03 Jul 2009 01:49:29 +0000

Fantastic thanks Nathan!

By: Nathan Weizenbaum

Nathan Weizenbaum — Wed, 01 Jul 2009 07:22:53 +0000

I’ve just pushed (what should be) a fix for this issue that will get released soon in Haml 2.2. Haml now has an :encoding option that specifies which encoding to use for the template; this defaults to UTF-8. It won’t automatically re-encode input – that’s Merb’s job – but as long as the input matches the template, these problems shouldn’t arise.

By: Ryan Bigg

Ryan Bigg — Wed, 01 Jul 2009 01:49:28 +0000

I can see how it was interpreted that way, my bad.

By: James Healy

James Healy — Wed, 01 Jul 2009 00:01:58 +0000

You're right - if it's your own view you can be sure the content is UTF-8 and can safely force the encoding yourself.

I read the post as proposing a patch for HAML that does the force_encoding() call. That would be dangerous since it's possible developers will want to generate non UTF-8 HAML files.

By: Bodaniel Jeanes

Bodaniel Jeanes — Tue, 30 Jun 2009 21:09:48 +0000

James,

This is true. How would you best handle it? HAML is appending two strings together, one is UTF-8 and one is not. If they differ, an exception gets raised...

Also, in this context, the string is coming from the HAML views. It was outputting the user's search query onto the page, sure, but whatever passed it to us (in this case it was Merb's params, I suppose) was obviosly butchering the encoding to make the string ASCII-8BIT in the first place...

By: James Healy

James Healy — Tue, 30 Jun 2009 12:12:42 +0000

Except that forcing a string into UTF-8 isn't necessarily the correct thing to do.

What if the user's browser has submitted iso-8859-1, Shift-JIS or Big-5 data?