Rails翻譯性能影響<％= raw t（vs. <％= t（

Question

）我正在構建一個使用rails-i18n Ruby on Rails的多語言應用程序 我需要翻譯的大部分內容（和數據庫條目）都是純文本雖然它的一部分有一些嵌入式的HTML。

我想用<%= raw t('translation_key') %>而不是直<%= t('translation_key') %>的考慮未來的變化，可能包括HTML的。

如果我採用<%= raw t('translation_key') %>遍及所有的網站，我是將會得到任何（負面）影響

1. 網站性能
2. 網站安全

Answer 1

你剛纔只是追加_html你的代碼鍵翻譯標記處理HTML：

en: 
    key_one: test text 
    key_one_html: <p>test text</p> 

那麼標準的代碼將工作：

<%= t('key_one_html') %> 

Answer 2

您也可以使用全球化gem來獲得更大的text/html內容部分。

https://github.com/globalize/globalize/blob/master/README.md

它也支持，如果你擔心性能預先加載。

Answer 3

的性能方面：

對性能的影響可以忽略不計。調用raw將參數複製到一個新字符串（準確地說是ActiveSupport::SafeBuffer），其html_safe標誌設置爲true。另一方面，不再對該字符串執行HTML轉義。

安全方面：

有較大幅度的缺點，使用raw無處不在。

你說你的翻譯是從數據庫中讀取的。用戶可以編輯這些翻譯嗎？如果是這樣的話......

• 您冒着HTML注入的風險：惡意用戶可能只需輸入一個<script>標記。
• 全部您的翻譯必須從現在開始HTML安全。這意味着您必須手動轉義所有翻譯，即您必須替換<，>和&。

替代方案：

還有其他的選擇，如果你需要把HTML到您的翻譯：

• 使用_html後綴明智防止自動逃逸
• 使用本地化意見和部分，即index.en.html，_footer.de-DE.html來翻譯你的v的大部分IEWS。

爲了簡化數據庫條目的翻譯，你試試

• Globalize
• hstore_translate（PostgreSQL只）

結論：

使用raw到處都將導致人沿途有許多問題。爲自己節省很多麻煩，並根據需要使用它。