QA@IT
«回答へ戻る

edit

2024
 個人的には「どれも使わない」ですね。
 
-昔のRailsはhの使用頻度が高く(hにエイリアスされてるのはその名残り)、必要なところで抜けるとユーザが入力したタグがそのまま通ってしまい大変でしたが、Rails 3からは`active_support/core_ext/string/output_safety`でStringを拡張してデフォルトで自動エスケープされるようになったので、むしろ逆にエスケープさせたくない場所で`raw`メソッドや`html_safe`メソッドを使う局面が多くなると思います。
+昔のRailsはhの使用頻度が高く、必要なところで抜けるとユーザが入力したタグがそのまま通ってしまい大変でしたが、Rails 3からは`active_support/core_ext/string/output_safety`でStringを拡張してデフォルトで自動エスケープされるようになったので、むしろ逆にエスケープさせたくない場所で`raw`メソッドや`html_safe`メソッドを使う局面が多くなると思います。
 
 使用頻度の低さを考えると、1文字エイリアスはgrepもしにくいしwebでも探しにくいし、逆にソース中で頻出すると目が痛くなるし、あまり好きになれません。
 

個人的には「どれも使わない」ですね。

昔のRailsはhの使用頻度が高く、必要なところで抜けるとユーザが入力したタグがそのまま通ってしまい大変でしたが、Rails 3からはactive_support/core_ext/string/output_safetyでStringを拡張してデフォルトで自動エスケープされるようになったので、むしろ逆にエスケープさせたくない場所でrawメソッドやhtml_safeメソッドを使う局面が多くなると思います。

使用頻度の低さを考えると、1文字エイリアスはgrepもしにくいしwebでも探しにくいし、逆にソース中で頻出すると目が痛くなるし、あまり好きになれません。

とくにjson_escapeは実装が恣意的すぎてJSON仕様違反だし、なぜこれがcoreに入ってるのか不思議なぐらいです。(用途にピッタリはまる人には嬉しいのでしょうが、この仕様はむしろ普及して欲しくないです)

url_encodeも使いドコロとしてはURLを自分で組み立てて云々することだとおもうのですが、実際には全体をエスケープしたいのかパラメータの一部だけエスケープしたいのかなど用途によって細かくニーズがわかれてくるので、一個のメソッドで用が足りるということでもありません。JSでもescape() / encodeURI() / encodeURIComponent()と段階を追って追加されてきた経緯があります。

なので、これらのメソッドを使いたくなったらcode smellを疑う、というのが正しい態度であるような気がしています。

個人的には「どれも使わない」ですね。

昔のRailsはhの使用頻度が高く、必要なところで抜けるとユーザが入力したタグがそのまま通ってしまい大変でしたが、Rails 3からは`active_support/core_ext/string/output_safety`でStringを拡張してデフォルトで自動エスケープされるようになったので、むしろ逆にエスケープさせたくない場所で`raw`メソッドや`html_safe`メソッドを使う局面が多くなると思います。

使用頻度の低さを考えると、1文字エイリアスはgrepもしにくいしwebでも探しにくいし、逆にソース中で頻出すると目が痛くなるし、あまり好きになれません。

とくにjson_escapeは実装が恣意的すぎてJSON仕様違反だし、なぜこれがcoreに入ってるのか不思議なぐらいです。(用途にピッタリはまる人には嬉しいのでしょうが、この仕様はむしろ普及して欲しくないです)

url_encodeも使いドコロとしてはURLを自分で組み立てて云々することだとおもうのですが、実際には全体をエスケープしたいのかパラメータの一部だけエスケープしたいのかなど用途によって細かくニーズがわかれてくるので、一個のメソッドで用が足りるということでもありません。JSでも`escape() / encodeURI() / encodeURIComponent()`と段階を追って追加されてきた経緯があります。

なので、これらのメソッドを使いたくなったらcode smellを疑う、というのが正しい態度であるような気がしています。

回答を投稿

個人的には「どれも使わない」ですね。

昔のRailsはhの使用頻度が高く(hにエイリアスされてるのはその名残り)、必要なところで抜けるとユーザが入力したタグがそのまま通ってしまい大変でしたが、Rails 3からはactive_support/core_ext/string/output_safetyでStringを拡張してデフォルトで自動エスケープされるようになったので、むしろ逆にエスケープさせたくない場所でrawメソッドやhtml_safeメソッドを使う局面が多くなると思います。

使用頻度の低さを考えると、1文字エイリアスはgrepもしにくいしwebでも探しにくいし、逆にソース中で頻出すると目が痛くなるし、あまり好きになれません。

とくにjson_escapeは実装が恣意的すぎてJSON仕様違反だし、なぜこれがcoreに入ってるのか不思議なぐらいです。(用途にピッタリはまる人には嬉しいのでしょうが、この仕様はむしろ普及して欲しくないです)

url_encodeも使いドコロとしてはURLを自分で組み立てて云々することだとおもうのですが、実際には全体をエスケープしたいのかパラメータの一部だけエスケープしたいのかなど用途によって細かくニーズがわかれてくるので、一個のメソッドで用が足りるということでもありません。JSでもescape() / encodeURI() / encodeURIComponent()と段階を追って追加されてきた経緯があります。

なので、これらのメソッドを使いたくなったらcode smellを疑う、というのが正しい態度であるような気がしています。

個人的には「どれも使わない」ですね。

昔のRailsはhの使用頻度が高く(hにエイリアスされてるのはその名残り)、必要なところで抜けるとユーザが入力したタグがそのまま通ってしまい大変でしたが、Rails 3からは`active_support/core_ext/string/output_safety`でStringを拡張してデフォルトで自動エスケープされるようになったので、むしろ逆にエスケープさせたくない場所で`raw`メソッドや`html_safe`メソッドを使う局面が多くなると思います。

使用頻度の低さを考えると、1文字エイリアスはgrepもしにくいしwebでも探しにくいし、逆にソース中で頻出すると目が痛くなるし、あまり好きになれません。

とくにjson_escapeは実装が恣意的すぎてJSON仕様違反だし、なぜこれがcoreに入ってるのか不思議なぐらいです。(用途にピッタリはまる人には嬉しいのでしょうが、この仕様はむしろ普及して欲しくないです)

url_encodeも使いドコロとしてはURLを自分で組み立てて云々することだとおもうのですが、実際には全体をエスケープしたいのかパラメータの一部だけエスケープしたいのかなど用途によって細かくニーズがわかれてくるので、一個のメソッドで用が足りるということでもありません。JSでも`escape() / encodeURI() / encodeURIComponent()`と段階を追って追加されてきた経緯があります。

なので、これらのメソッドを使いたくなったらcode smellを疑う、というのが正しい態度であるような気がしています。