php - 导致 PHP 在转换为 UTF-8 之前无法检测到正确的字符编码导致数据丢失的已知问题字符列表

Question

PHP 并不总是正确的，我写的必须总是正确的。在这种情况下，带有主题的电子邮件包含 en dash character .这个线程是关于检测奇怪的字符，当单独(比方说，在其他纯 ASCII 文本中)被 PHP 错误地检测到。我已经确定了一个静态示例，但我的目标是创建一个包含尽可能接近我们可能创建的插入代码版本的最终线程。

这是我从电子邮件主题 header 开始的字符串:

<?php
//This is AFTER exploding the : of the header and using trim on $p[1]:
$s = '=?ISO-8859-1?Q?orkut=20=96=20convite=20enviado=20por=20Lais=20Piccirillo?=';
//orkut – convite enviado por Lais Piccirillo
?>

通常下一步是执行以下操作:

$s = imap_mime_header_decode($s);//orkut � convite enviado por Lais Piccirillo

通常超过那个点我会做以下事情:

$s = mb_convert_encoding($subject, 'UTF-8', mb_detect_encoding($s));//en dash missing!

现在我收到了 a static answer for an earlier static question .最终我能够将这组工作代码放在一起:

<?php
$s1 = '=?ISO-8859-1?Q?orkut=20=96=20convite=20enviado=20por=20Lais=20Piccirillo?=';

//Attempt to determine the character set:
$en = mb_detect_encoding($s1);//ASCII; wrong!!!
$p = explode('?', $s1, 3)[1];//ISO-8859-1; wrong!!!

//Necessary to decode the q-encoded header text any way FIRST:
$s2 = imap_mime_header_decode($s1);

//Now scan for character exceptions in the original text to compensate for PHP:
if (strpos($s1, '=96') !== false) {$s2 = mb_convert_encoding($s2[0]->text, 'UTF-8', 'CP1252');}
else {$s2 = mb_convert_encoding($s2[0]->text, 'UTF-8');}

//String is finally ready for client output:
echo '<pre>'.print_r($s2,1).'</pre>';//orkut – convite enviado por Lais Piccirillo
?>

现在要么我的编程仍然不正确，要么 在 PHP 中我遗漏了一些东西(尝试了 html_entity_decode、iconv 的多种组合>、mb_convert_encoding 和 utf8_encode) 或者，至少在目前使用 PHP 8 时，我们将被迫检测特定字符并像我所做的那样手动覆盖编码在第 12 行。在后一种情况下，如果已经存在针对此问题的特定错误报告，则需要创建或可能更新错误报告。

所以技术上的问题是:

我们如何正确检测所有字符编码以防止在将字符串转换为 UTF-8 期间丢失任何字符？

如果不存在这样的正确答案，则有效答案包括在其他纯 ASCII 文本中导致 PHP 无法正确检测正确字符编码的字符，从而导致不正确的 UTF-8 编码字符串。假设这个问题在未来得到解决，并且可以针对所有其他相关答案中列出的所有奇怪字符进行验证，然后可以接受一个正确的答案。

Answer 1

您将 PHP 无法解决的问题归咎于 PHP:

• $s1 是一个ASCII字符串；正如字符串“笑脸表情符号”是 ASCII，即使它描述字符串“🙂”。
• $s2 根据您收到的信息解码。事实上，它被解码为原始字节序列和输入中提供的标签。

您的实际问题是您收到的信息是错误的 - 发送给您的系统犯了一个常见的错误，将 Windows-1252 错误标记为 ISO-8859-1。

这两种编码在 256 个可能的 8 位值中有 224 个的含义一致。他们不同意从 0x80 到 0x9F 的值:这些是 ISO 8859 中的控制字符，并且(大部分)分配给 Windows-1252 中的可打印字符。

请注意，任何系统都无法自动告诉您预期的解释是什么 - 无论哪种方式，内存中都只有一个字节包含(例如)0x96。但是，来自 ISO 8859 的额外控制字符很少使用，因此如果字符串声称是 ISO-8859-1 但包含该范围内的字节，则几乎可以肯定它采用其他编码。由于 Windows-1252 的使用非常广泛(并且经常以这种方式被错误标记)，一个常见的解决方案是简单地假设任何标记为 ISO-8859-1 的数据实际上是 Windows-1252。

这使得解决方案非常简单:

// $input is the ASCII string you've received
$input = '=?ISO-8859-1?Q?orkut=20=96=20convite=20enviado=20por=20Lais=20Piccirillo?=';

// Decode the string into its labelled encoding, and string of bytes
$mime_decoded = imap_mime_header_decode($input);
$input_encoding = $mime_decode[0]->charset;
$raw_bytes = $mime_decode[0]->text;

// If it claims to be ISO-8859-1, assume it's lying
if ( $input_encoding === 'ISO-8859-1' ) {
    $input_encoding = 'Windows-1252';
}

// Now convert from a known encoding to UTF-8 for the use of your application
$utf8_string = mb_convert_encoding($raw_bytes, 'UTF-8', $input_encoding);