确保从扩展 ASCII 编码为 UTF8 时的一致性答案

【问题标题】：Ensuring consistency when encoding to UTF8 from extended ASCII确保从扩展 ASCII 编码为 UTF8 时的一致性
【发布时间】：2012-10-09 23:35:32
【问题描述】：

也许这不是问题，但我期待 SO 收集的智慧来帮助我找出答案。

我们正在努力确保跨平台的编码保持一致。要走的路显然是UTF8。但是，不幸的是，某些平台使用扩展的 ASCII（通常是某种形式的 Windows 代码页），我们担心当使用变音符号从 Windows 代码页到 UTF8 进行编码时，UTF8 中的字符有多种可能的选择。

在不同的平台（Linux、Mac OS）上，我们如何确保那里选择的 UTF8 字符是一致的？

正如我所说，也许这不是问题。也许有一些我不知道的标准映射。我们没有发现任何问题，但一位同事刚刚提出了问题，所以我正在寻找信息。

提前谢谢大家。

【问题讨论】：

我在视图中嵌入二维码时遇到了类似的问题。我意识到我错过了使用base64_encode() 方法，如下所示：<img src="data:image/png;base64, {!! base64_encode($qr) !!} " />（来自use SimpleSoftwareIO\QrCode\Facades\QrCode;）

【解决方案1】：

只要您先将原始文本正确转换为 Unicode，然后使用 Utf8 存储/传输数据，应该没有问题。

【讨论】：

【解决方案2】：

Unicode 联盟编译了一组mapping tables。名义上是信息性的，它们构成了事实上的标准。此外，那里的许多映射反映了正式标准，因为按照 Unicode 定义任何新的字符编码已成为常态，即通过指定每个字符的 Unicode 编号（和/或 Unicode 名称）。

一旦一个字符被映射到 Unicode（即，一个 Unicode 码位或 Unicode 数字），它在每个 Unicode 编码（例如 UTF-8）中的编码就被明确定义了。

所以问题是如何确保您使用的转换例程根据这些表工作。使用ICU在这方面可以认为是安全的。

附：没有扩展的 ASCII。字符编码有很多种，有的与 ASCII 一致，范围从 0 到 0x7F，有的不一致。

【讨论】：