raw vs. html_safe vs. h to unescape html
Considering Rails 3:
html_safe
actually "sets the string" as HTML Safe (it's a little more complicated than that, but it's basically it). This way, you can return HTML Safe strings from helpers or models at will.
h
can only be used from within a controller or view, since it's from a helper. It will force the output to be escaped. It's not really deprecated, but you most likely won't use it anymore: the only usage is to "revert" an html_safe
declaration, pretty unusual.
Prepending your expression with raw
is actually equivalent to calling to_s
chained with html_safe
on it, but is declared on a helper, just like h
, so it can only be used on controllers and views.
"SafeBuffers and Rails 3.0" is a nice explanation on how the SafeBuffer
s (the class that does the html_safe
magic) work.
I think it bears repeating: html_safe
does not HTML-escape your string. In fact, it will prevent your string from being escaped.
<%= "<script>alert('Hello!')</script>" %>
will put:
<script>alert('Hello!')</script>
into your HTML source (yay, so safe!), while:
<%= "<script>alert('Hello!')</script>".html_safe %>
will pop up the alert dialog (are you sure that's what you want?). So you probably don't want to call html_safe
on any user-entered strings.
The difference is between Rails’ html_safe()
and raw()
. There is an excellent post by Yehuda Katz on this, and it really boils down to this:
def raw(stringish)
stringish.to_s.html_safe
end
Yes, raw()
is a wrapper around html_safe()
that forces the input to String and then calls html_safe()
on it. It’s also the case that raw()
is a helper in a module whereas html_safe()
is a method on the String class which makes a new ActiveSupport::SafeBuffer instance — that has a @dirty
flag in it.
Refer to "Rails’ html_safe vs. raw".