页面加载时，是否需要将我从用户代理收到的所有内容（HTML表单和URI）转换为UTF-8？
否。用户代理应该以UTF-8格式提交数据；否则，您将失去Unipre的优势。
确保用户代理以UTF-8格式提交的方法是提供包含以UTF-8编码提交的表单的页面。使用Content-
Type标头（如果要保存表单并独立工作，也可以使用meta http-equiv）。
我听说您也应该将表单标记为UTF-8（accept-charset =“ UTF-8”）
别。
在HTML标准中，这是一个不错的主意，但是IE却没有做到这一点。本来应该声明允许的字符集的排他性列表，但是IE将其视为按字段尝试的其他字符集的列表。因此，如果您有ISO-8859-1页面和“
accept-charset =“ UTF-8””表单，则IE首先会尝试将字段编码为ISO-8859-1，如果非8859-1字符， 然后
使用UTF-8。
但是由于IE不会告诉您它是否使用过ISO-8859-1或UTF-8，因此这绝对对您没有用。您将不得不分别针对每个字段猜测正在使用哪种编码！没用。忽略该属性，并将您的页面作为UTF-8服务；这是您目前可以做的最好的事情。
如果UTF字符串编码不正确，将会出问题
如果让这样的顺序进入浏览器，您可能会遇到麻烦。有些“超长序列”会以比所需长度更长的字节序列来编码低编号的代码点。这意味着，如果要通过按字节顺序查找ASCII字符来过滤“
<”，则可能会漏掉一个，并将脚本元素放入您认为是安全的文本中。
在Unipre成立之初，就禁止使用过长的序列，但是微软花了很长时间才把它们弄得一团糟：IE直到IE6 Service Pack 1才将字节序列’ xC0
xBC’解释为’<’。
Opera甚至在版本7上也弄错了。幸运的是，这些较旧的浏览器正在逐渐消失，但是仍然值得过滤掉冗长的序列，以防那些浏览器仍然存在（或者新的白痴浏览器将来会犯同样的错误）
）。你可以这样做，并修复等不良序列，用正则表达式只允许适当的UTF-8通过，比如这一个从W3。
如果在PHP中使用mb_函数，则 可能 会遇到这些问题。我不能肯定地说，因为当我还在写PHP时mb_ *是不可用的脆弱。
无论如何，这也是删除控制字符的好时机，控制字符是大量的错误源，通常是不被重视的。除了W3正则表达式删除的其他字符外，我还将从提交的字符串中删除字符9和13。对于您不应该将其视为多行文本框的字符串，也可以删除普通的换行符。
是否编写了UTF-16以解决UTF-8中的限制？
不，UTF-16是每代码点两个字节的编码，用于使索引Unipre字符串在内存中更容易（从所有Unipre都可以容纳两个字节的时代开始；像Windows和Java这样的系统仍然可以这样做）。与UTF-8不同，它与ASCII不兼容，并且在Web上几乎没有用。但是您有时会在保存的文件中遇到它，通常是Windows用户保存的文件，这些文件被Windows在另存为菜单中将UTF-16LE描述为“
Unipre”而误导了。
seen_utf8
与正则表达式相比，这是非常低效的！
另外，请确保在所有表上使用utf8_unipre_ci。
实际上，您可以在这种情况下摆脱困境，将MySQL视为只存储字节的存储，而在脚本中仅将它们解释为UTF-8。使用utf8_unipre_ci的优点是它将使用有关非ASCII字符的知识来整理（排序并进行不区分大小写的比较）。“ŕ”和“Ŕ”是相同的字符。如果使用非UTF8归类，则应坚持二进制（区分大小写）匹配。
无论您选择哪种方式，都必须始终如一地进行操作：对表使用与连接相同的字符集。您要避免的是脚本和数据库之间的有损字符集转换。
