Ruby on Rails 3 表单中的 _snowman 参数是什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3222013/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is the _snowman param in Ruby on Rails 3 forms for?
提问by Matthew Savage
In Ruby on Rails 3 (currently using Beta 4), I see that when using the form_tagor form_forhelpers there is a hidden field named _snowmanwith the value of ? (Unicode\x9731) showing up.
在 Ruby on Rails 3（目前使用 Beta 4）中，我看到在使用form_tagorform_for帮助器时有一个隐藏字段_snowman，其值为 ? ( Unicode\x9731) 出现。
So, what is this for?
那么，这是为了什么？
采纳答案by Matthew Savage
This is here to support Internet Explorer 5 and encourage it to use UTF-8for its forms.
这是为了支持 Internet Explorer 5 并鼓励它对其表单使用UTF-8。
The commit message seen heredetails it as follows:
此处看到的提交消息详细说明如下：
Fix several known web encoding issues:
- Specify accept-charset on all forms. All recent browsers, as well as IE5+, will use the encoding specified for form parameters
- Unfortunately, IE5+ will not look at accept-charset unless at least one character in the form's values is not in the page's charset. Since the user can override the default
charset (which Rails sets to UTF-8), we provide a hidden input containing a unicode character, forcing IE to look at the accept-charset.- Now that the vast majority of web input is UTF-8, we set the inbound parameters to UTF-8. This will eliminate many cases of incompatible encodings between ASCII-8BIT and
UTF-8.- You can safely ignore params[:_snowman]
修复几个已知的 Web 编码问题：
- 在所有表单上指定 accept-charset。所有最近的浏览器，以及 IE5+，都将使用为表单参数指定的编码
- 不幸的是，IE5+ 不会查看接受字符集，除非表单值中的至少一个字符不在页面的字符集中。由于用户可以覆盖默认
字符集（Rails 设置为 UTF-8），我们提供了一个包含 unicode 字符的隐藏输入，强制 IE 查看接受字符集。- 现在绝大多数 Web 输入都是 UTF-8，我们将入站参数设置为 UTF-8。这将消除 ASCII-8BIT 和
UTF-8之间编码不兼容的许多情况。- 您可以安全地忽略 params[:_snowman]
In short, you can safely ignore this parameter.
简而言之，您可以放心地忽略此参数。
Still, I am not sure why we're supporting old technologies like Internet Explorer 5. It seems like a very non-Ruby on Rails decision if you ask me.
不过，我不知道为什么我们要支持像 Internet Explorer 5 这样的旧技术。如果你问我，这似乎是一个非常非 Ruby on Rails 的决定。
回答by Yehuda Katz
This parameter was added to forms in order to force Internet Explorer (5, 6, 7 and8) to encode its parameters as unicode.
将此参数添加到表单中是为了强制 Internet Explorer（5、6、7和8）将其参数编码为 unicode。
Specifically, this bug can be triggered if the user switches the browser's encoding to Latin-1. To understand why a user would decide to do something seemingly so crazy, check out this google search. Once the user has put the web-site into Latin-1 mode, if they use characters that can be understood as both Latin-1 and Unicode (for instance, é or ?, common in names), Internet Explorer will encode them in Latin-1.
具体来说，如果用户将浏览器的编码切换为 Latin-1，就会触发此错误。要了解为什么用户会决定做一些看似如此疯狂的事情，请查看此 google 搜索。一旦用户将网站设置为 Latin-1 模式，如果他们使用可以被理解为 Latin-1 和 Unicode 的字符（例如，é 或 ?，在名称中很常见），Internet Explorer 会将它们编码为拉丁语-1.
This means that if a user searches for "Ché Guevara", it will come through incorrectly on the server-side. In Ruby 1.9, this will result in an encoding error when the text inevitably makes its way into the regular expression engine. In Ruby 1.8, it will result in broken results for the user.
这意味着如果用户搜索“Ché Guevara”，它将在服务器端错误地通过。在 Ruby 1.9 中，当文本不可避免地进入正则表达式引擎时，这将导致编码错误。在 Ruby 1.8 中，它会导致用户的结果损坏。
By creating a parameter that can only be understood by IE as a unicode character, we are forcing IE to look at the accept-charset attribute, which then tells it to encode all of the characters as UTF-8, even ones that can be encoded in Latin-1.
通过创建一个只能被 IE 理解为 unicode 字符的参数，我们迫使 IE 查看 accept-charset 属性，然后告诉它把所有字符编码为 UTF-8，即使是那些可以编码的字符在拉丁语 1。
Keep in mind that in Ruby 1.8, it is extremely trivial to get Latin-1 data into your UTF-8 database (since nothingin the entire stack checks that the bytes that the user sent at any point are valid UTF-8 characters). As a result, it's extremely common for Ruby applications (and PHP applications, etc. etc.) to exhibit this user-facing bug, and therefore extremely common for users to try to change the encoding as a palliative measure.
请记住，在 Ruby 1.8 中，将 Latin-1 数据放入 UTF-8 数据库非常简单（因为整个堆栈中都没有检查用户在任何时候发送的字节是否为有效的 UTF-8 字符）。因此，Ruby 应用程序（和 PHP 应用程序等）出现这种面向用户的错误非常普遍，因此用户尝试更改编码作为一种姑息措施非常普遍。
All that said, when I wrote this patch, I didn't realize that the name of the parameter would ever appear in a user-facing place (it does with forms that use the GET action, such as search forms). Since it does, we will rename this parameter to _e, and use a more innocuous-looking unicode character.
尽管如此，当我编写这个补丁时，我没有意识到参数的名称会出现在面向用户的位置（它会出现在使用 GET 操作的表单中，例如搜索表单）。既然如此，我们将把这个参数重命名为_e，并使用一个看起来更无害的 unicode 字符。
