到目前为止，UTF-8是否是使用非ASCII字符的二维码的首选编码？

Question

谷歌使用UTF-8it作为其非常流行的编码器的默认格式。据我所知，它们甚至没有添加字节顺序标记。

问题是，大多数扫描仪似乎仍然使用JIS8 (QR 2000)而不是iso-8859 (QR 2005)作为默认设置，因此使用iso-8859进行编码通常不起作用。

看起来utf-8是唯一的选择，即使它违反了规范。

编辑:我将使用没有ECI和BOM的utf-8。违反所有规范和精神，但目前效果最好。

Answer 1

该规范指出ISO-8859-1是字节模式编码的默认值。然而，在实践中，是的，您会在日本看到很多Shift-JIS或UTF-8。

UTF-8是正确的选择。要正确执行此操作，您需要在流中添加一些指示，表明它是UTF-8。规范确实考虑到了这一点。您需要在字节段前面加上一个表示UTF-8的ECI segment。

如果您向zxing编码器发送编码为UTF-8的提示，zxing编码器将为您完成此操作。

Answer 2

BOM无济于事

我的经验表明，BOM并没有帮助。如果QR扫描仪无法显示来自正确编码的UTF-8字符串(数据流中的8位字节模式)的字符串，即使使用ECI，添加BOM也没有任何区别。

扫描器即使在正确编码的UTF-8上也会失败

作为无法显示正确的UTF-8字符串的扫描仪的示例，请以安装了MIUI Global v11.0.3 (带有本机扫描仪应用程序)的小米手机为例。即使在ECI中指定了此字符集，这些电话也无法正确显示以UTF-8编码的西里尔字符串。西里尔字母显示为问号。但是如果您添加一个中文/日文字符(例如日)转换为西里尔文文本，则整个文本将由小米正确显示。这与BOM无关。

这些是真正重要的字符，而不是编码

您已经假设在QR代码中使用UTF-8比ISO-8859-1更好，因为ISO-8859-1不是2000年发布的早期QR代码标准(ISO/IEC 18004: 2000 )中的默认编码。该标准确实指定了符合JISX0201( ISO-2022-JP)的8位拉丁语/假名字符集作为8位模式的默认编码，而2005年发布的更新标准确实将缺省值更改为JIS8-8859-1。因此，您假设“使用iso-8859进行编码基本上不起作用”。这取决于US-ASCII字符对您是否足够(具体地说，是20-7E范围内的可打印ANSI X3.4-1986字符)，而您不需要在加泰罗尼亚语、法语、加利西亚语、德语、欧西坦语和西班牙语中使用带有变音/发音的ISO-8859-1字符。

如果您只需要US-ASCII，那么使用不带任何ECI的ISO-8859-1比使用带ECI的UTF-8更安全。无论如何，20-7E范围内的US-ASCII字符的二进制八位数字符串将是相同的，无论它是编码为ISO-8859-1还是UTF-8。如果您只使用US-ASCII字符，扫描仪使用的启发式软件应该能够自动找出所使用的字符集。如果您需要带有变音/分音的字符，则使用UTF-8。这不是因为QR代码标准的2000和2005修订版之间的默认编码已从JIS X 0201更改为ISO-8859-1，而是因为QR扫描仪使用启发式自动检测编码，而这种启发式在某些情况下会失败。

为什么QR扫描仪使用启发式方法来检测编码

如你所知，在二维码中存储文本有4种模式：(1)数字，(2)字母数字，(3) 8位和(4)汉字。

因此，QR码标准本身并不支持UTF-8。要在8位字符串中使用UTF8编码(而不是默认的“ISO-8859-1”或“JIS8”)，实现必须在该字符串之前插入一个ECI (扩展通道解释)。ECI是二维码的一个可选的附加功能，但它至少在2000年就在二维码标准中定义了。ECI使用默认字符集以外的字符集启用数据编码。它还允许对其他数据解释(例如，使用定义的压缩方案压缩的数据)或其他行业特定要求进行编码。

ECI协议在AIM公司开发的规范中定义，不是免费提供的，但可以在https://www.aimglobal.org/technical-symbology.html上以50美元的价格购买

扫描器可能会忽略ECI协议

不幸的是，并不是所有的QR扫描仪都可以处理ECI协议，即使是在将默认编码更改为UTF-8这样的基本情况下也是如此。大多数实现使用试探法，即用于猜测编码的一个或另一个字符编码检测算法，即使在解码的QR码的ECI中明确指定编码也是如此。他们使用启发式算法，不仅是因为在2000年到2005年之间，默认编码从JIS8更改为ISO-8859-1。主要原因是缺乏适当的ECI协议支持，可能是因为QR码规范和AIM ECI协议规范是不同的文档。一些QR编码器没有通过ECI指定字符编码，并对8位字符串(JIS8、Shift_JIS、ISO-8859-1、UTF-8)使用不同的编码，因此扫描器必须解决这个问题。

您写道“看起来utf-8是唯一的选择”，但扫描仪使用的启发式算法即使使用UTF-8也可能失败，就像我给出的小米示例一样。您还编写了UTF-8“不符合规范”，但只有在没有通过ECI显式指定UTF-8编码的情况下才会如此。

ECI和UTF-8的替代方案，但不是完全解决方案

附注:除了使用ECI之外，还有一种替代方法。您可以使用“Kanji”模式对带有变音/分音或西里尔字母的拉丁字符进行编码。在此模式下，“Shift_JIS”用于对8140-9FFC和E040-EBBF范围内的JISX0208字符进行编码。在这里，您不能对其他范围中的字符进行编码，例如按字节代码20对空格进行编码，但可以将其编码为JIS X 0208第1行第1列21，即2121)。由于JISX0208包含罗马(第3行)、希腊语(第6行)和西里尔文(第7行)行，以及标点符号(第1行和第2行)等特殊字符，因此可以在JIS字符范围8140-9FFC和E040-EBBF中完全使用变音/变音或西里尔文本(包括空格和标点符号)对拉丁字符进行编码。在这种情况下，不需要ECI扩展。但不能保证扫描仪软件中的启发式方法不会破坏您正确编码的文本。

结论

使用UTF-8并通过ECI指定它并不是一个完全的解决方案(因为在这种情况下，一些扫描器将使用容易出错的启发式方法)，但至少它对兼容的扫描器有帮助，而不像BOM完全没有帮助。