我有一个测试站点和测试数据库都设置为windows-1252. 当我在 Chrome 中输入Alt+时234，它会将这个符号放在字段中：Ω. 当我提交表单时，它会发布并存储它，因为Ω 我假设这是浏览器说“嘿，这不在指定的字符集中，但我知道一个 html 等价物，所以我会发布它”。美好的。保存后符号正确显示，我可以保存，保存，保存，它总是显示正常。但是如果我用Alt+尝试同样的事情，230浏览器不会提交它的 html 实体值µ。相反，在 Chrome DevTool 窗口中查看 POST 时，我看到“（无法解码值）”。它最终作为问号存储在数据库中。
为什么它对待Alt+ 234( ) 与+ ( Ω) 不同？Alt230µ
我知道我应该切换到 UTF8，但我仍然想知道为什么它会以这种方式运行。谢谢！
使用encodeURIComponent包装值解决了这个问题。
破碎的：
`?value=${myValue}`
在职的：
`?value=${encodeURIComponent(myValue)}`
U+03A9Ω希腊大写字母 omega 不是Windows 代码页 1252的一部分。
U+00B5µ微符号（与希腊语 mu 不完全相同）是 1252（字节 181）的一部分。
Alt+键盘快捷键编号通常与代码页 1252 或当前的 ANSI 代码页不一致，因此能够从该快捷方式键入字符并不意味着这些代码页的成员资格。相反，它们来自DOS 代码页 437。
当我提交它发布的表单并将其存储为 Ω 我假设这是浏览器说“嘿，这不在指定的字符集中，但我知道一个 html 等价物，所以我会发布那个代替”
是的，这是 HTML5 最终标准化的一个长期存在的怪异不可恢复的修改，因为当页面请求的编码中的字符不可编码时。
相反，在 Chrome DevTool 窗口中查看 POST 时，我看到“（无法解码值）”。它最终作为问号存储在数据库中。
浏览器会将该字符作为代码页 1252 字节 181 发送。devtools 和您的应用程序不希望处理代码页 1252 字节......可能他们期待 UTF-8。因为字节 181 本身不是有效的 UTF-8 序列，所以他们无法保留它。