Raw vs. html_safe против h для unescape html
Предположим, что у меня есть следующая строка
@x = "<a href='#'>Turn me into a link</a>"
На мой взгляд, я хочу, чтобы отображалась ссылка. То есть, я не хочу, чтобы все в @x было unescaped и отображалось как строка. Какая разница между использованием
<%= raw @x %>
<%= h @x %>
<%= @x.html_safe %>
?
Ответы
Ответ 1
Учитывая рельсы 3:
html_safe
фактически "устанавливает строку" как HTML Safe (это немного сложнее, но в основном это). Таким образом, вы можете возвращать безопасные строки HTML из помощников или моделей по своему усмотрению.
h
может использоваться только из контроллера или представления, поскольку он из помощника. Это заставит выход быть экранированным. Это не очень устарело, но вы, скорее всего, больше не будете его использовать: единственное использование - "вернуть" объявление html_safe
, довольно необычное.
Превращение выражения с помощью raw
на самом деле эквивалентно вызову to_s
с цепью html_safe
на нем, но объявляется в помощнике, как и h
, поэтому его можно использовать только для контроллеров и представлений.
" SafeBuffers and Rails 3.0 - это отличное объяснение того, как работает SafeBuffer
(класс, выполняющий магию html_safe
),
Ответ 2
Я думаю, что это повторяется: html_safe
делает не HTML-escape-строку. Фактически, это предотвратит экранирование вашей строки.
<%= "<script>alert('Hello!')</script>" %>
поставит:
<script>alert('Hello!')</script>
в ваш источник HTML (yay, так безопасно!), а:
<%= "<script>alert('Hello!')</script>".html_safe %>
появится диалоговое окно предупреждения (вы уверены, что хотите?). Поэтому вы, вероятно, не хотите вызывать html_safe
для любых введенных пользователем строк.
Ответ 3
Разница между Rails html_safe()
и raw()
. На этом есть отличный пост Иегуды Кац, и это действительно сводится к следующему:
def raw(stringish)
stringish.to_s.html_safe
end
Да, raw()
является оберткой вокруг html_safe()
, которая заставляет вход в String, а затем вызывает на нем html_safe()
. Это также случай, когда raw()
является помощником в модуле, тогда как html_safe()
является методом класса String, который создает новый экземпляр ActiveSupport:: SafeBuffer, который имеет в нем флаг @dirty
.
Обратитесь к разделу Rails html_safe vs. raw.
Ответ 4
-
html_safe
:
Пометка строки как надежного безопасного. Он будет вставлен в HTML без дополнительной эвакуации.
"<a>Hello</a>".html_safe
#=> "<a>Hello</a>"
nil.html_safe
#=> NoMethodError: undefined method `html_safe' for nil:NilClass
-
raw
:
raw
- это всего лишь обертка вокруг html_safe
. Используйте raw
, если есть вероятность, что строка будет nil
.
raw("<a>Hello</a>")
#=> "<a>Hello</a>"
raw(nil)
#=> ""
-
h
для html_escape
:
Утилита для экранирования символов HTML-тегов. Используйте этот метод, чтобы избежать любого небезопасного содержимого.
В Rails 3 и выше используется по умолчанию, поэтому вам не нужно явно использовать этот метод
Ответ 5
Лучший безопасный способ: <%= sanitize @x %>
Это позволит избежать XSS!
Ответ 6
В простых терминах Rails:
h
удалите html-теги в числовые символы, чтобы рендеринг не нарушил ваш html
html_safe
задает логическое значение в строке, так что строка считается html save
raw
Он преобразуется в html_safe в строку