我正在研究如何处理页面设置字符集之外的字符。
在这种情况下，页面设置为iso-8859-1，之前的程序员决定使用htmlentities（$ string，ENT_COMPAT）来逃避输入。然后将其存储到Mysql中的Latin1表中。
由于表格设置为与页面相同的字符集，我想知道是否需要该htmlentities步骤。 我在http://floris.workingweb.nl/experiments/characters.php上做了一些实验，看来对于Latin1里面的东西，有些字符被转义，但是例如捷克名称则没有。
这是因为那些字符在Latin1之外吗？如果是这样，那么可以删除htmlentities，因为它对Latin1之外的东西没有帮助，而且就Latin1而言，就我现在所见，它是不需要的......
答案 0 :(得分：1)
htmlentities只翻译它知道的字符（get_html_translation_table(HTML_ENTITIES)返回整个列表），剩下的就是原样。所以你是对的，将它用于非拉丁数据毫无意义。此外，数据库条目的html编码和使用latin1都是坏主意，我建议将它们都删除。
警告：在删除htmlentities（）之后，请记住您仍然需要为要在DB中插入的数据（mysql_escape_string或类似的）转义引号。
答案 1 :(得分：0)
他本可以将它作为基本的安全预防措施，即。防止用户在输入中插入HTML / Javascript（因为＆lt;和＆gt;也会被转义）。
btw如果您想支持东欧和西欧语言，我建议使用UTF-8作为默认字符编码。
答案 2 :(得分：0)
是的
虽然不是因为捷克语字符在Latin1之外，而是因为它们在表格中共享相同的位置。因此，数据库将其视为相应的latin1字符。
使用htmlentities总是很糟糕。存储不同语言的唯一合适的解决方案是使用UTF-8字符集。
答案 3 :(得分：0)
请注意htmlentities / htmlspecialchars为charset提供了第3个参数（自PHP 4.1.0起）。 ISO-8859-1是默认值，因此如果您将没有第三个参数的htmlentities应用于UTF-8字符串，则输出将被破坏。
你可以检测到＆amp;使用mb_detect_encoding和mb_convert_encoding转换输入字符串，以确保输入字符串与所需的字符集匹配。