在某些地方，我在—中使用像—（°）和°C这样的字符。包含这些字符的字符串回显功能为utf8_encode()的奇怪输出。
当我不使用utf8_encode()处理字符串时，字符会正确显示。但是，由于编码不匹配，函数wp_update_post()开始引发错误。 （我从一个SO问题中发现了这个问题。）
在网页上显示这些字符的正确方法是什么？
答案 0 :(得分：0)
您需要知道二进制字符串的编码是什么，并使用mb_convert_encoding而不是通过使用utf8_encode()来假定数据已经是ISO-8859-1格式
没有“正确的方法”，如果网页内容类型可以通过Content-Type标头支持编码，则可以将它们用作字符串文字。
从技术上讲，PHP字符串应该是二进制安全的，因此遵循PHP约定，它将以您使用过的任何编码方式进行编码。像一个有符号的int一样思考它，计算机不知道有符号的和无符号的二进制数据之间的区别，这全关乎您如何在程序中解释该二进制数据。
您正在使用utf8_encode()指定编码，只是没有意识到自己已经做到了。例如，假设您有一个二进制字符串$s = "TEST°";，该字符串当前在程序中是二进制的，它可能没有ASCII，并且完全是乱码，就像您读取exe文件的前5个字节一样。当您调用utf8_encode($s)时，您告诉PHP它可以继续进行，并假设$s是ISO-8859-1字符串，并根据该假设将$s转换为UTF-8。这与mb_convert_encoding("TEST°", "UTF-8", "ISO-8859-1")相同。由于“°”不是一个有效的ISO-8859-1值，所以造成了混乱，因为它是0xC2B0，因为我是从已经使用UTF-8表示该值的Web浏览器复制它的。度的8859-1值是0xB0，因此var_dump(mb_convert_encoding("TEST" . chr(0xB0), "UTF-8", "ISO-8859-1"))确实会产生正确的结果，其中0xB0转换为0xC2B0：TEST°
如果您没有为mb_convert_encoding()指定第3个参数，则默认使用mb_internal_encoding的值。此默认值不能保证为UTF-8，并且您不应该假定二进制字符串为UTF-8。您应该知道数据的编码方式。如果数据来自浏览器，它会在Content-Type中告诉您；在大多数情况下，它本身被假定为UTF-8，但同样不能保证。如果数据与RDBMS相关，那么它可能已经为您did this encoding conversion。