浏览器/ PHP如何处理设置字符集外的字符？

我正在研究如何处理页面集字符集之外的字符。浏览器/ PHP如何处理设置字符集外的字符？

在这种情况下，页面被设置为iso-8859-1，并且前面的程序员决定使用htmlentities（$ string，ENT_COMPAT）转义输入。然后将其存储到Mysql的Latin1表中。

由于表设置为与页面相同的字符集，我想知道是否需要该步骤。我在http://floris.workingweb.nl/experiments/characters.php上做了一些实验，看起来对于拉丁文1里面的东西来说，有些字符是逃脱的，但是例如有一个捷克名字他们没有。

这是因为那些字符在Latin1之外？如果是这样，那么可以删除这些特性，因为它对拉丁文1以外的内容无帮助，并且对于拉丁文内部1，现在我不能看到它了......

2010-03-30 Maarten

htmlentities只能翻译它的字符知道（get_html_translation_table(HTML_ENTITIES)返回整个列表），并保持原样。所以你是对的，将它用于非拉丁数据是没有意义的。而且，数据库条目的html编码和使用latin1都是不好的想法，而且我建议将两者都删除。

一句警告：删除htmlentities（）后，请记住您仍然需要为要插入到数据库（mysql_escape_string或类似文件）中的数据转义引号。

2010-03-30 13:43:43 user187291

谢谢，这就是我一直在寻找的东西。至于其他评论，我知道utf-8，但这是为了以后，现在我需要解决手头上摆脱数据库中逃脱的东西的问题，我需要知道我是否在正确的轨道上 – Maarten 2010-03-30 14:00:35

是的，数据库中的HTML编码数据是一种巨大的代码异味。在将文本放入HTML页面时应该调用htmlspecialchars，而不是与数据层有关。摆脱！ – bobince 2010-03-30 14:05:17

@Maarten：不要忘记您的数据仍然需要转义（请参阅答案更新）。为安全起见，应使用htmlspecialchars代替 – user187291 2010-03-30 14:19:35

他本可以使用它作为基本的安全预防措施，即。以防止用户将HTML/Javascript插入到输入中（因为<和>也会被转义）。

btw如果你想支持东欧和西欧语言，我会建议使用UTF-8作为默认字符编码。

2010-03-30 13:43:55 wimvds

。而不是在插入，但在显示部分 – 2010-03-30 13:53:16

约定，不要混乱的输入，如果你可以避免它，只对sql注入过滤 – Maarten 2010-03-30 14:01:13

“只对sql注入过滤”错误，你听说过XSS攻击吧？还有更多的安全性，然后检查SQL注入。顺便说一句，这只是一个基本的猜测是什么编码者的动机可能是使用htmlentities，而不是我自己的观点，如何实现安全... – wimvds 2010-03-30 19:48:05

是
虽然不是因为捷克字符不在Latin1中，而是因为它们在表格中共享相同的位置。所以，数据库把它作为相应的latin1字符。

使用htmlentities总是不好。存储不同语言的唯一适当的解决方案是使用UTF-8字符集。

2010-03-30 13:51:38

呃...你不是说使用'htmlentities'总是不好？这是'htmlspecialchars'，这是转义' bobince 2010-03-30 14:03:49

非常感谢，我的坏，我的意思是实体。 – 2010-03-30 14:06:16

请注意，htmlentities/htmlspecialchars具有charset的第三个参数（自PHP 4.1.0起）。 ISO-8859-1是默认值，因此如果您将没有第三个参数的htmlent应用于UTF-8字符串，则输出将被损坏。

您可以检测到&将输入字符串转换为mb_detect_encoding和mb_convert_encoding以确保输入字符串与所需的字符集匹配。

2010-03-30 13:53:08 AlexV

mb_detect_encoding也永远不会被信任和无用。内容类型的页面是足够的 – 2010-03-30 14:00:35

内容类型通常是足够的，但如果输入是用户定义的，字符串可以是不同于内容类型指定的字符集。 – AlexV 2010-03-30 16:34:41

回答