Предположим, у меня есть следующая строка
@x = "<a href='#'>Turn me into a link</a>"
На мой взгляд, я хочу, чтобы ссылка отображалась. То есть я не хочу, чтобы все в @x было экранировано и отображалось в виде строки. Какая разница между использованием
<%= raw @x %>
<%= h @x %>
<%= @x.html_safe %>
?
ruby-on-rails
erb
grautur
источник
источник
<%== @x %>
что это псевдоним<%= raw(@x) %>
edgeguides.rubyonrails.org/…Ответы:
Учитывая Rails 3:
html_safe
на самом деле «устанавливает строку» как HTML Safe (это немного сложнее, но это в основном так). Таким образом, вы можете возвращать строки HTML Safe от помощников или моделей по желанию.h
может использоваться только из контроллера или представления, так как это от помощника. Это заставит выход быть экранированным. На самом деле это не рекомендуется, но вы, скорее всего, больше не будете его использовать: единственное использование - «отменить»html_safe
объявление, довольно необычно.Предварительное добавление выражения к
raw
фактически эквивалентно вызову,to_s
связанному сhtml_safe
ним, но оно объявляется помощником, точно так же, какh
его можно использовать только в контроллерах и представлениях.« SafeBuffers and Rails 3.0 » - хорошее объяснение того, как работает
SafeBuffer
s (класс, который творитhtml_safe
магию).источник
h
когда-либо будет осуждается. Использование"Hi<br/>#{h@ user.name}".html_safe
является довольно распространенным и приемлемым использованием.raw
иhtml_safe
на практике:raw(nil)
возвращает пустую строку, аnil.html_safe
выдает исключение.h
не будет "возвращать" объявление html_safe. Когда строка естьhtml_safe
,h
ничего не будет делать.Я думаю , что стоит повторить:
html_safe
это не HTML-бежать вашу строку. Фактически, это предотвратит выход вашей строки.поставит:
в ваш источник HTML (да, так безопасно!), а:
появится диалоговое окно с предупреждением (вы уверены, что это то, что вы хотите?). Таким образом, вы, вероятно, не хотите вызывать
html_safe
любые введенные пользователем строки.источник
html_safe
это не избежать ни экранирования в . В то время как конечный результат маркировки что - то , как не HTML безопасно, а затем , используя неявное вытекание из Еврорадио <% = тег, может быть таким же , как неэкранированные данные , а затем повторно спасаясь его на выходе, функционально он не будет ни делать. Вроде как разница (6 * -1 * -1), против 6.Разница между Rails
html_safe()
иraw()
. Иегуда Кац написал отличную статью об этом, и она сводится к следующему:Да,
raw()
это обертка вокруг,html_safe()
которая вызывает ввод для String и затем вызываетhtml_safe()
его. Это также тот случай, когда онraw()
является помощником в модуле, тогдаhtml_safe()
как метод класса String создает новый экземпляр ActiveSupport :: SafeBuffer, в котором есть@dirty
флаг.Обратитесь к разделу " Rails 'html_safe против raw ".
источник
html_safe
:Отмечает строку как надежную. Он будет вставлен в HTML без дополнительного экранирования.
raw
:raw
это просто обертка вокругhtml_safe
. Используйте,raw
если есть вероятность, что строка будетnil
.h
псевдоним дляhtml_escape
:Служебный метод для экранирования символов HTML-тега. Используйте этот метод, чтобы избежать любого небезопасного содержимого.
В Rails 3 и выше он используется по умолчанию, поэтому вам не нужно использовать этот метод явно
источник
Лучший безопасный способ:
<%= sanitize @x %>
Это позволит избежать XSS!
источник
В терминах Simple Rails:
h
удалите HTML-теги в числовые символы, чтобы рендеринг не нарушал ваш HTMLhtml_safe
устанавливает логическое значение в строке так, чтобы строка рассматривалась как сохранение HTMLraw
Конвертирует в html_safe в строкуисточник
h
Этоhtml_safe
означает, что HTML отображается как есть.