UTF-8、UTF-16、UTF-32和BOM
有关UTF或编码形式的一般问题
Q： Unicode是16位编码吗？
在1991年至1995年的第一个版本中，Unicode是16位编码，但从Unicode 2.0开始（1996年7月）Unicode标准有编码字符范围U+0000..U+10FFFF，相当于21位代码空间。取决于编码形式你自己选择(UTF-8型，UTF-16型，或UTF-32型)，然后将每个字符表示为一到四个8位字节的序列，一个或两个16位代码单位，或单个32位代码单元。
Q： Unicode文本可以用多种方式表示吗？
有以下几种可能的表示Unicode数据，包括UTF-8型，UTF-16型和UTF-32型它们都能够表示所有Unicode，但它们的组成部分的位数不同代码单位.
此外，有一些压缩转换，如UTS#6:Unicode标准压缩方案(SCSU公司).
Q： 什么是UTF？
A类Unicode转换格式(联合技术框架)是一个每个Unicode的算法映射代码点（除代理代码点)转换为唯一字节顺序。ISO/IEC 10646标准使用术语“UCS公司 转换格式“用于UTF；这两个术语只是同一概念的同义词。
每个UTF都是可逆的，因此每个UTF支持无损往返：映射来自任何Unicode编码字符序列S到字节序列背面将再次产生S。为了确保往返，UTF映射必须拥有所有代码点的映射（代理代码点除外）。这包括保留或未分配的代码点和66非字符（包括U+FFFE和U+FFFF）。除了无损之外，UTF是唯一的：任何给定的编码字符序列都会为给定的UTF生成相同的字节序列。
这个SCSU公司尽管压缩方法是可逆的，但它不是UTF，因为同一字符串可以映射到许多不同的字节序列，具体取决于SCSU公司压缩机。[自动对焦]
Q： 我在哪里可以获得更多信息编码表单？
对于联合技术文件看见第3.9节，Unicode编码形式在里面这个Unicode标准。有关的详细信息编码形式看见UTR#17:Unicode字符编码模型.[自动对焦]
Q： 如何编写UTF转换器？
免费的开源项目Unicode的国际组件
(重症监护室)有联合技术框架转换。最新版本可能是已下载来自ICU项目网站。许多其他库可能有内置的转换器，因此您可能不必编写自己的转换器。[自动对焦]
Q： 是否有任何字节序列不是由UTF生成的？我应该如何解释它们？
这些都不是联合技术文件可以生成每一个任意字节顺序。例如，在UTF-8型表格110xxxxx的每个字节2
必须后跟形式为10xxxxxx的字节2. 序列，如<110xxxxx20xxxxxxx个2> 是非法的，决不能生成。当面对这种非法行为时转换或解释时的字节序列，符合UTF-8进程必须处理第一个字节110xxxxx2作为非法终止错误：例如，发出错误信号，过滤掉字节，或用标记表示字节，例如FFFD公司(替换字符)。在后两种情况下，它将继续第二字节0xxxxxxx处的处理2.
一致的过程不能解释非法或格式错误的字节序列作为字符，但可能会出错恢复操作。没有一致的进程可以使用不规则的字节要编码的序列银行外信息。
Q： 我需要支持哪些UTF？
UTF-8型在网络上最常见。UTF-16型Java和Windows（.Net）使用。UTF-8和UTF-32型是用于Linux和各种Unix系统。它们之间的转换为基于算法，快速无损。这样便于支持以多种格式输入或输出数据，同时使用特定联合技术框架用于内部存储或处理。[自动对焦]
Q： 有哪些区别在UTF之间？
下表总结了每个联合技术文件.
在表中，<BOM>表示字节顺序为由字节顺序标记，如果出现在数据的开头流，否则它是大引擎。[自动对焦]
Q： 为什么有些UTF有BE或LE如UTF-16LE？
UTF-16型和UTF-32型使用代码单位那是2和4字节长。对于这些联合技术文件，有三种亚口味：BE、LE和未标记。BE表单使用大发动机 字节序列化（最高有效字节优先），LE形式使用小发动机字节序列化（最低有效字节优先）和未标记形式使用默认情况下，大字节序列化，但可能包括字节顺序作记号在开头指示实际使用的字节序列化。[自动对焦]
Q： 是否有标准方法打包Unicode字符，所以它适合8位ASCII流？
有几个选项可以使Unicode适合8位格式：
使用UTF-8型.这是蜜饯ASCII码，但不是拉丁语-1，因为字符>127与拉丁语-1不同。UTF-8使用ASCII中的字节仅用于ASCII字符。因此，它是有效的在ASCII字符具有重要意义的任何环境中语法字符，例如文件名语法、标记语言等，但其中所有其他字符可以使用任意字节。
例如：“拉丁语小写字母“急性”（015B）将是编码为两个字节：C59B。
使用Java或C风格的转义符，格式为\uXXXX或\xXXXX。此格式不是文本文件的标准格式，但在讨论中的语言框架，主要用于源文件。
例如：波兰语单词“wyj she cie”，带有字符“Latin Small”中间带有“锐音符”（015B）的字母s（sh是一个字符）将看起来像：“wyj\u015Bcie”。
使用&#XXXX年X月X日；或&#DDD；数字字符转义如中所示HTML格式或XML格式。同样，这些不是标准的纯文本文件夹，但在这些标记语言的框架内定义良好。
例如：“wyj shi cie”看起来像“wyjś；国际原子能委员会”
-
使用Puny代码用于将作为网络标识符的一部分的标签转换为与ASCII标签兼容的形式。此方法是必需的IDNA 2008年和更早的国际化域名(国际域名)。它将Unicode重新编码为ASCII字符子集，其中只包含字母和数字.
例如：的领域名字“wyj-si-cie.com”看起来像“xn-wyjcie-5ib.com网站”，前缀为“xn--”微代码以及前面收集的任何ASCII字符。
使用SCSU公司. 此格式将Unicode压缩为8位格式，保留了ASCII，但使用一些控制代码作为解码器的命令。然而，虽然ASCII文本在编码后看起来像ASCII文本在里面SCSU公司，其他字符有时可能使用相同的字节进行编码值，使SCSU不适合盲目解释的8位通道ASCII字符形式的任何字节。
例如：“<SC2>wyjÛcie”其中<SC2>表示字节0x12和“Û”对应于字节0xDB。[自动对焦]
Q： 哪种将Unicode字符打包到8位流中的方法最好？
方法的选择取决于环境：
- UTF-8型是最广泛使用的ASCII兼容编码形式用于Unicode。它是为使用而设计的透明地，这意味着ASCII码仍然是ASCII格式（并且相对位置没有变化），其他部分也没有。它也相当紧凑，独立于字节顺序问题。它已成为Unicode文本文件的首选格式。
- UTF-8的缺点是，如果不转换为可以在系统上显示的格式，您就无法分辨数据中的哪些非ASCII字符。字符转义或数字字符实体，您可以查看代码点已被转义，即使您在ASCII环境中工作或没有字体查看字符，甚至当您可能无法识别字符时。在适当的情况下，它们适用于源代码或源文档。字符转义和实体使用了更多的空间，这使得除了偶尔使用之外，其他地方都不太吸引人。
- Puny代码作为的一部分领域名称协议，但不适用于除短字符串以外的任何内容。
SCSU公司设计用于压缩短字符串。它占用的空间最少，但无法使用透明地在大多数8位环境中。[自动对焦]
Q： 以下哪种格式是“最标准的”？
中列出的所有四种方法以上答案要求接收人能够理解格式，但a）是ASCII码三种其他等效标准的兼容选择Unicode码编码表单。它不仅受到广泛支持，而且在许多情况下是默认格式。在其外部使用纯ASCII和b）或c）在支持它们的协议中给定上下文肯定会被认为是非标准的，但也可能是内部数据传输的良好解决方案。使用SCSU公司是技术上是一个标准（用于压缩数据流），但很少有通用性接收机支持SCSU，因此它在内部或协议特定数据中同样非常有用变速箱。[自动对焦]
UTF-16常见问题
Q： 什么是UTF-16？
UTF-16型使用单个16位代码单元用Unicode编码60000多个最常见的字符，以及一对16位代码单元，称为代理，以Unicode编码大约100万个字符的剩余部分.
最初，Unicode设计为纯16位编码，旨在代表所有现代脚本（古代文字将由代表私人用途字符.）随着时间的推移，以及特别是在增加了14500多个复合字符对于兼容性对于传统设置，16位显然不是足够用户社区使用。由此产生了UTF-16。[自动对焦]
Q： 什么是代理？
代理是代码点来自两个特殊的Unicode范围值，保留用作成对的前导值和尾随值代码单位在里面UTF-16型.主要代理，也称为高代理项，被编码从D80016至DBFF16、和尾部代理，或低代理，来自DC0016至DFFF16。它们被称为代理，因为它们不直接表示字符，而只是作为一对。
Q： 转换的算法是什么UTF-16到代码点？
而Unicode标准用于包含短算法，现在它只提供了一个位分布表，该表显示了代理项和结果之间的关系补充代码点.下面是三个简短的代码片段将位分布表中的信息转换为C将转换为和从中转换的代码UTF-16型.
使用以下类型定义
typedef无符号int16 UTF16；typedef无符号int32 UTF32；
第一个片段计算字符代码C的高位（或前导）代理项。
常量UTF16 HI_SURROGATE_START=0xD800
UTF16 X=（UTF16）C；UTF32 U=（C>>16）&（（1<<5）-1）；UTF16 W=（UTF16）U-1；UTF16 HiSurrogate=HI_SURROGATE_START|（W<<6）|X>>10；
其中“X”、“U”和“W”对应于表中使用的标签3-5UTF-16位分布。下一个代码段对低代理项执行相同的操作。
常量UTF16 LO_SURROGATE_START=0xDC00
UTF16 X=（UTF16）C；UTF16 LoSurrogate=（UTF16）（LO_SURROGATE_START|X&（（1<<10）-1））；
最后，相反，hi和lo分别是高和低代理，“C”是结果字符
UTF32 X=（hi&（（1<<6）-1））<<10|lo&（（1<<10）-1）；UTF32 W=（hi>>6）&（1<<5）-1）；UTF32 U=W+1；
UTF32 C=U<<16 | X；
呼叫者需要确保“C”、“hi”和“lo”位于适当的范围。[自动对焦]
Q： 是否有一种更简单的方法可以将UTF-16转换为代码点？
有一种更简单的计算方法，它不试图遵循位分布表。
//常数常量UTF32 LEAD_OFFSET=0xD800-（0x10000>>10）；常量UTF32 SURROGATE_OFFSET=0x10000-（0xD800<<10）-0xDC00；//计算UTF16引线=lead_OFFSET+（码点>>10）；UTF16轨迹=0xDC00+（码点&0x3FF）；UTF32码位=（lead<<10）+trail+SURROGATE_OFFSET；
[医学博士]
Q： UTF-16需要考虑哪些因素？
UTF-16型有时需要两个代码单位以表示单个字符。因此，它是一种可变宽度编码，就像东亚的一些遗留字符一样集，如日文(上海国际机场)代码单位在两种宽度之间交替。熟悉这些字符集的人都很熟悉可变宽度的问题代码可能会导致。然而，这些机制之间存在一些重要差异用于SJIS和UTF-16：
重叠:
频率:
-
绝大多数SJIS字符需要2个单位，但是使用单个单位的字符经常出现，并且通常特别重要，例如在文件名中。
-
对于UTF-16，需要2个单元的字符相对较少。大多数常用字符都是单个代码单元。即使在东亚文本中代理对应该是平均不到所有文本存储的1%。（确定当然，文档中代理的发生率可能更高成对，就像肺结核是一个相当罕见的词英语，但可能经常出现在特定的学术文本中。）
-
最近表情符号表示广泛使用的百分比补充字符也增加了对代理项对的支持。[自动对焦]
Q： UTF-16是否会扩展到更多超过一百万个字符？
否。Unicode和ISO 10646标准有正式将未来代码分配限制为可以用当前值表示的整数范围UTF-16型（0至1,114,111). 即使其他编码表单（即其他联合技术文件)可以代表较大的整数，这些策略意味着所有编码形式都将始终表示相同的字符集。超过一百万个可能的代码远远不够对于Unicode编码字符的目标，而不是字形.Unicode是不设计用于编码任意数据。如果例如，你想在纸上给出每个“角色的实例”纵观历史“它自己的代码，你可能需要数万亿或数以万亿计的此类代码；尽管这种努力可能很高尚，但你不会使用Unicode进行这种编码。[自动对焦]
Q： 是否有任何16位值无效？
未配对的代理在中无效联合技术文件。这些包括任何值在D800范围内16至DBFF16后面没有DC00范围内的值16至DFFF16，或DC00范围内的任何值16至DFFF16前面没有D800范围内的值16至DBFF16.[自动对焦]
Q： 非字符呢？它们是无效的吗？
一点也不。非字符在中有效联合技术文件并且必须正确转换。有关非字符的定义和使用以及它们在每个UTF中的正确表示的更多详细信息，请参阅非字符常见问题解答.
Q： 因为大多数补充字符都不常见，这是否意味着我可以忽略它们？
大多数补充字符（用表示代理对在里面UTF-16型)不太常见。然而，确实如此不意思是补充字符应该被忽略。其中包括一些非常流行的单个字符以及许多集合对东亚采购规范很重要。值得注意的是补充字符为：
Ken Lunde有一个关于这个主题的有趣演示文件十大列表：为什么支持Beyond-BMP代码点？
Q： 我应该如何处理代码中的补充字符？
与相比BMP字符作为一个整体补充字符在文本中不太常见。现在这仍然是事实，尽管许多标准中增加了数千个补充字符，和一些个人角色，例如流行表情符号，已成为非常常见。BMP字符的相对频率，以及这个ASCII码中的子集BMP公司，可以当优化实现以获得最佳性能：执行速度、内存使用和数据存储。
这种策略对于UTF-16型实现，其中BMP字符需要一个16位代码单元处理或存储，而补充字符需要两个。
针对BMP进行优化的策略对于UTF-8型实现，但如果数据的分发有保证ASCII子集的优化可能有意义，因为只有该子集需要单个字节以UTF-8格式进行处理和存储。
Q： UCS-2和UTF-16有什么区别？
UCS-2型是过时的指Unicode 1.1之前的Unicode实现的术语，之前 代理代码点和UTF-16型已添加到标准的2.0版。现在应该避免使用这个词。
UCS-2没有描述与UTF-16不同的数据格式，因为两者使用完全相同的16位代码单元陈述。然而，UCS-2没有解释代理代码点，因此不能用于一致表示补充字符.
在过去，有时一个实现被标记为“UCS-2”，表示它不支持补充字符，也不将代理代码点对解释为字符。这样的实现不会处理字符属性，代码点边界，整理等，它也不能支持大多数表情符号例如。[自动对焦]
UTF-32常见问题解答
Q： 什么是UTF-32？
任何Unicode字符都可以是表示为中的单个32位单元UTF-32型.这首单曲4代码单元对应于Unicode标量值，这是抽象数字与Unicode字符关联。UTF-32是编码的子集调用的机制UCS-4公司在里面ISO 10646标准。有关更多信息，请参阅第3.9节，Unicode编码形式在里面这个Unicode标准.
[自动对焦]
Q： 我应该使用UTF-32（或UCS-4）在内存中存储Unicode字符串？
使用它似乎很有吸引力UTF-32型作为内部字符串格式，因为它使用一种代码单元每代码点然而，Unicode字符很少被完全隔离处理。组合字符序列例如，可能需要作为一个单元进行处理。这个问题不仅影响复杂脚本，但看起来也很简单，比如表情符号其中许多被定义为组合序列。
定义API，使其主要用于字符串和子字符串，而不是字符和字符偏移量，这将更容易正确地支持组合字符序列。这也将区分使用UTF-32和其他编码表单相关性较小。
UTF-32的缺点它强制您对每个字符使用32位，而只有21位比特是永远需要的。所需的有效位数普通文本中的平均字符数要低得多，这使得这个比率实际上情况要糟糕得多。增加相同的存储字符数在处理大量文本数据：这可能意味着更快地耗尽缓存限制；它可以显著增加读/写时间或达到带宽限制；并且它需要更多的存储空间。许多实现所做的是用UTF-8型或UTF-16型，但单个字符值具有UTF-32。例如，要检索的API字符属性可能使用UTF-32代码单位作为参数。
如果您经常需要访问以下API要求字符串参数为UTF-32，这可能更方便始终使用UTF-32字符串。在许多无关紧要的情况下，但是每个字符具有固定数量的代码单元的便利性可能是决定因素。
Unicode的主要卖点是提供代表世界上所有的角色，消除了处理多个字符集并避免相关的数据损坏问题。这些特点足以使工业转向使用Unicode作为内存格式。虽然UTF-32表示确实使编程模型更简单，增加了平均存储大小有真正的缺点，使得完全过渡到UTF-32不那么引人注目。[自动对焦]
Q： 在我的API？
除了在某些将文本存储为UTF-32型英寸内存，大多数Unicode API都在使用UTF-16型。使用UTF-16 API低电平索引位于存储或代码单元级别，具有更高级别的机制对于字素或根据代码单位。这在低水平上提供了效率所需的高级功能。
如果有必要定位n个第个字符，按字符索引可以实现为高级操作。但是，在转换时从这样的UTF-16代码单元索引到字符索引，或者反之亦然，这是相当公平的简单来说，它确实涉及到对16位单元的扫描，最高可达索引点。例如，在测试运行中，以如下方式访问UTF-16存储字符而不是代码单元导致了10倍的降级。While期间可以执行一些有趣的优化，它将平均速度总是较慢。因此，确定其他边界，例如当字形、单词、行或句子的边界直接从代码单位索引，而不是通过中间字符代码间接索引。
在需要使用用户交互的“单元”的情况下，使用Unicode字符进行索引比使用代码单元进行索引的优势有限：许多时候用户认为是单个单元表情符号例如，表示为组合或其他字符序列，并且无论底层代码使用16位还是32位代码单元，在这些“单元”上迭代都没有什么区别。
Q： 正在进行只有UTF-16字符串API受到限制，而不是UTF-32字符API？
几乎所有的国际职能（上、下、，标题栏，箱子折叠，绘图，测量，整理, 音译、字形、单词、换行符等）字符串参数在API中，不单个代码点(UTF-32型)。单代码点API几乎总是产生错误的结果除了非常简单的语言，或者是因为你需要更多的上下文才能得到正确的答案，或者因为您需要生成一系列字符以返回正确答案，或两者兼而有之。
例如，任何与Unicode兼容的排序规则（请参见UTS#10:Unicode排序算法（UCA）)必须能够处理多个序列代码点，并将该序列视为单个实体。尝试通过处理单个代码点进行整理每次都会得到错误的答案。绘图也会发生同样的情况或者一次测量一个代码点的文本；因为脚本像阿拉伯语是上下文的，宽度x个加上的宽度年不相等宽度为xy公司。一旦你超越了基本的排版，同样的英语也是如此；因为紧排和结扎的宽度中的“fi”字体可能不同于“f”的宽度加上宽度“i”。套管作业必须返回字符串，而不是单个代码点；看见https://www.unicode网站.org/charts/case/尤其是，标题行操作需要字符串作为输入，而不是在时间。
存储单曲代码点在结构或类而不是字符串中，将排除对字素，例如斯洛伐克语的“ch”，其中单个代码点可能不够，但是一个字符序列需要表达什么是必需的。换句话说，复合的大多数API参数和字段数据类型应该不定义为字符，但定义为字符串。如果它们是字符串的内部表示形式字符串为。
鉴于任何行业实力文本和国际化支持API必须能够处理角色，它使字符串是否由内部序列UTF-16型 代码单位或通过一系列码点（=UTF-32码单元）。UTF-16和UTF-8型旨在简化子字符串的处理事实上，给定代码点的代码单元序列是独一无二。[自动对焦]
Q： 独占使用规则有例外吗API中的字符串参数？
主要异常非常低操作，如获取字符属性（例如。一般类别或标准在中的类UCD公司)。对于那些人来说，有接口很方便快速转换UTF-16型和UTF-32型，这样你就可以迭代返回UTF-32值的字符串（即使内部格式为UTF-16）。
Q： 如何转换UTF-16代理<D800 DC00>到UTF-32等配对？作为一个4字节序列或作为两个4字节序列？
定义UTF-32型要求补充的字符（使用代理对在里面UTF-16型)用编码单个4字节序列。
Q： 如何转换未配对的UTF-16代理到UTF-32？
如果未成对的在以下情况下遇到代理项转换ill-formedUTF-16型数据，任何一致转换器必须将此视为错误。通过在其拥有，结果UTF-32型数据流将变得不完整。尽管如此忠实地反映输入的性质，Unicode一致性要求编码形式转换总是产生有效数据流。[自动对焦]
字节顺序标记（BOM）常见问题解答
Q： 什么是BOM？
A类字节顺序标记 (物料清单)由角色组成在数据流的开头编写U+FEFF代码，可以在这里使用作为签名定义字节顺序和编码形式，主要是未标记的明文文件夹。在一些更高级别的协议中，BOM的使用可能是强制性的（或禁止）在其中定义的Unicode数据流中协议。[自动对焦]
Q： BOM在哪里有用？
A类物料清单在键入为的文件的开头很有用文本，但不知道它们是大端还是小端格式也可以作为指示文件使用Unicode的提示，如与传统编码不同，而且它还充当签名对于特定的编码形式已使用。[自动对焦]
Q： “endian”是什么意思？
计算机中可以存储长度超过一个字节的数据类型具有最高有效字节的内存(最高有效位)第一个或最后一个。前者是打电话大发动机，后者小发动机。交换数据时，字节在发送系统上以“正确”顺序出现的可能是接收系统出现故障。在这种情况下物料清单会看起来类似于0xFFFE，它是一个非字符，允许接收系统在处理数据之前应用字节反转。UTF-8型是面向字节的，并且因此没有这个问题。然而，初始BOM可能是用于将数据流标识为UTF-8。[自动对焦]
Q： BOM表是否仅用于16位Unicode文本？
A类物料清单可以用作签名无论怎样Unicode文本转换：UTF-16型，UTF-8型，或UTF-32型.确切的字节数组成BOM的是任何Unicode字符U+FEFF转化为转换格式。在该表格中，BOM用于指示它是Unicode文件，以及格式。示例：
| 字节 |
编码表单 |
| 00 00 FE全平面 |
UTF-32，大发动机 |
| 消防FE 00 00 |
UTF-32，小发动机 |
| FE全平面 |
UTF-16，大发动机 |
| FF前端 |
UTF-16，小发动机 |
| EF BB高炉 |
UTF-8型 |
Q： UTF-8数据流是否可以包含BOM字符（UTF-8格式）？如果是，那么我还能假设剩下的UTF-8字节是按大字节顺序排列的吗？
对，UTF-8型可以包含物料清单然而，它使不字节流的结束性的差异。UTF-8总是具有相同的字节顺序。初始BOM是只有用作签名-一个表示未标记的文本文件为UTF-8格式。请注意UTF-8编码数据的某些接收者不需要BOM。其中UTF-8已使用透明地在8位环境中，BOM的使用将干扰预期特定的任何协议或文件格式ASCII码字符，例如在Unix shell的开头脚本. [自动对焦]
Q： 我应该如何处理中的U+FEFF在文件中间？
如果没有支持其作为物料清单当不在文本流的开头，通常不应该出现U+FEFF。对于向后的兼容性它应该被视为零宽度非断裂空间（ZWNBSP），然后是文件或字符串内容的一部分U+2060字细木工与ZWNBSP相比，它更适合表达单词连接语义，因为它不能与BOM混淆。设计标记时语言或数据协议，U+FEFF的使用可以限制为属于字节顺序标记在这种情况下，出现在文件中间的任何U+FEFF都可以被视为不支持的字符.[自动对焦]
Q： 我使用的协议的BOM位于文本的开头。如何表示初始ZWNBSP？
使用U+2060字细木工而不是。
Q： 如何标记不将U+FEFF解释为BOM？
使用标签UTF-16BE型表示大发动机
UTF-16型文本，和UTF-16LE型表示小发动机UTF-16型文本。如果您确实使用物料清单，将文本标记为简单UTF-16型.[医学博士]
Q： 为什么我不总是使用协议需要BOM？
如果数据具有关联类型，例如数据库中的字段，一物料清单是不必要的。特别是，如果文本数据流标记为UTF-16BE型，UTF-16LE型，UTF-32BE标准或UTF-32LE型，BOM既不是必需的，也不是被允许. 任何U+FEFF都将被解释为ZWNBSP。
不要用BOM表标记数据库或字段集中的每个字符串，因为它浪费空间并使字符串连接复杂化。此外，这还意味着两个数据字段可能具有完全相同的内容，但不是二进制相等（其中一个是以BOM开头）。
Q： 我该怎么办使用BOM表？
以下是一些需要遵循的准则：
-
特定协议（例如，针对.txt文件）可能需要使用物料清单在某些Unicode数据上流，例如文件。当你需要遵守这样的协议时，使用BOM表。
-
某些协议允许在以下情况下使用可选BOM表未标记的文本。在这些情况下，
-
一些面向字节的协议期望ASCII码个字符，位于文件的开头。如果UTF-8型用于这些协议，请使用物料清单的编码形式应避免签名。
-
数据流的精确类型已知（例如。Unicode大字符或Unicode小发动机)，BOM不应为已使用。特别是，当数据流被声明为UTF-16BE型，UTF-16LE型，UTF-32BE标准或UTF-32LE型物料清单必须不是已使用。（另请参见Q： 什么是UCS-2和UTF-16之间的区别？.)[自动对焦]
