UD5工具箱
UTF-16是一种Unicode字符编码方案，使用16位（2字节）作为基本编码单元。对于基本多文种平面（BMP）中的字符，UTF-16使用单个16位码元编码；对于补充平面字符（如部分emoji表情和罕见汉字），UTF-16使用两个16位码元（即代理对）来编码。UTF-16与UTF-8的主要区别在于编码效率的场景不同：UTF-8对英文和ASCII字符更高效（1字节 vs UTF-16的2字节），而UTF-16对中文、日文等CJK字符更高效（2字节 vs UTF-8的3字节）。UTF-8是互联网和Web的主流编码，UTF-16则是Windows操作系统、Java和JavaScript等平台的内部编码。
小端序（Little-Endian）和大端序（Big-Endian）是两种不同的多字节数据存储顺序。以Unicode字符"中"（U+4E2D）为例：在小端序编码中，低位字节2D存储在前，高位字节4E存储在后，编码结果为2D 4E；在大端序编码中，高位字节4E在前，低位字节2D在后，编码结果为4E 2D。选择建议：如果您在Windows平台上进行开发，或使用Java、C#、JavaScript等语言，推荐选择UTF-16LE，因为这是这些平台的默认字节序。如果您需要与网络协议或特定的大端序系统交互，选择UTF-16BE。如果您不确定目标系统的字节序，可以选择带BOM的选项（UTF-16LE with BOM或UTF-16BE with BOM），BOM（字节顺序标记）会在文件开头写入FF FE或FE FF，让读取器自动识别字节序。
BOM（Byte Order Mark，字节顺序标记）是Unicode标准定义的一个特殊不可见字符U+FEFF，放置在文本数据的最前面。BOM的字节表示取决于文本使用的字节序：UTF-16LE的BOM为FF FE，UTF-16BE的BOM为FE FF。BOM的核心作用是让文本读取器能够自动检测文件的字节序，无需额外的元数据或约定。适用场景：当文本文件可能在不同字节序的系统之间传输或共享时（如跨平台文件交换），使用BOM可以确保接收端正确解码。不适用场景：在某些Unix/Linux环境、HTTP协议处理、数据库存储等场景中，BOM可能导致兼容性问题，建议不使用BOM。在本工具中，您可以根据实际需求选择"with BOM"或不带BOM的选项。
代理对（Surrogate Pair）是UTF-16编码中用于表示补充平面字符的机制。Unicode标准总共定义了超过149,000个字符，其码点范围从U+0000到U+10FFFF。而UTF-16的基本编码单元是16位，直接表示范围仅为0x0000到0xFFFF（65,536个值），无法覆盖完整的Unicode空间。为了解决这个问题，UTF-16将U+10000到U+10FFFF范围内的字符（称为补充字符）映射到一对特殊的16位码元——高代理（U+D800到U+DBFF）和低代理（U+DC00到U+DFFF）。例如，笑脸emoji "😀"的Unicode码点是U+1F600，位于补充平面。通过代理对机制，它被编码为高代理D83D加低代理DE00两个码元。因此，在UTF-16中，一个emoji"占用"了4字节（两个码元），这在统计时体现为码元数大于字符数。Unicode 15.0版本引入的emoji（如新的表情符号、手势和旗帜）大多位于补充平面，都需要使用代理对编码。
在UTF-16编码中，一个常用中文字符（位于Unicode基本平面BMP内，如"中"、"文"、"字"等）编码后占用2个字节（1个UTF-16码元）。这是UTF-16处理CJK文字的一个重要优势——相比之下，UTF-8编码一个中文字符需要3个字节。例如，字符串"你好"在UTF-16LE中编码为4字节，而在UTF-8中需要6字节。需要注意的是，一些罕见汉字（如扩展A区到扩展G区的字符）和部分emoji位于Unicode补充平面，这些字符在UTF-16中需要4字节（2个码元/代理对）来编码。Unicode 15.0扩展G区的CJK汉字就属于这种情况。在使用本工具时，可以通过字符详情表查看每个字符的具体编码字节数。
判断文件是否使用UTF-16编码主要有以下几种方法：第一种是检查文件开头的BOM（字节顺序标记）。如果文件的前两个字节是FF FE，则为UTF-16LE编码；如果是FE FF，则为UTF-16BE编码。这是最可靠的判断方法，但前提是文件包含BOM。第二种是分析字节模式。UTF-16编码的文本通常包含大量的00字节（对于英文内容）或规律性的字节对。例如，英文文本在UTF-16LE中每个字符后跟一个00字节，在UTF-16BE中每个字符前有一个00字节。通过hex编辑器观察字节模式可以初步判断编码类型。第三种是使用专业的编码检测工具，如chardet、ICU或Python的chardet库，它们基于统计模型和启发式规则来推断文本编码。第四种是查看文件的元数据或配置，例如HTTP响应头中的Content-Type字段（charset=UTF-16）、HTML文件的meta标签或XML文件的encoding声明。综合使用这些方法可以准确判断文件的编码类型。
JavaScript引擎的字符串内部使用UTF-16编码，这意味着String.length返回的是码元数而非实际字符数。正确处理UTF-16字符串的关键要点：第一，对于emoji等补充字符，str.length返回2（两个码元）而非1（一个字符），使用Array.from(str)或[...str]可以正确分割为单个字符。第二，字符串截取（slice、substring等）以码元为单位，截取补充字符中间可能产生无效的代理对。第三，正则表达式需使用/u标志启用Unicode模式，才能正确匹配代理对和Unicode属性。第四，String.prototype.codePointAt()方法返回完整的Unicode码点（而非仅高代理的值），适合需要获取字符实际码点的场景。本工具的编码结果可以帮助开发者验证和调试UTF-16字符串处理逻辑，特别是检查代理对编码是否正确。
UTF-16和UTF-8文件大小的比较取决于文本内容的字符组成。对于纯英文/ASCII文本，UTF-8明显更小（每字符1字节 vs UTF-16的2字节），UTF-16文件大小约为UTF-8的两倍。对于中文、日文等CJK文本，UTF-16更小（每字符2字节 vs UTF-8的3字节），UTF-16文件大小约为UTF-8的三分之二。对于混合内容（中英文混合），需要根据两种字符的比例来计算。一个粗略的估算：如果文本中非ASCII字符（如中文字符）占比超过约33%，UTF-16可能更小；如果非ASCII字符占比较低，UTF-8更优。对于包含大量emoji和补充字符的文本，UTF-16可能需要4字节/字符（代理对），而UTF-8同样需要4字节/字符，两者大小相同。实际项目中选择编码方案时，除了文件大小，还需要考虑系统兼容性、生态支持和团队技术栈等因素。
不会。UTF-16编码解码工具的所有计算都在您的浏览器本地完成（客户端计算），输入的文本内容、编码结果和分析数据都不会被发送到任何远程服务器。这意味着您可以安全地使用本工具处理敏感信息、个人数据或商业机密内容。工具的源代码完全在浏览器端运行，利用JavaScript的字符串处理能力完成编码转换、统计计算和字符分析。这种设计不仅保护了您的数据隐私，还提供了极快的响应速度——所有操作都是即时完成的，无需等待网络请求和服务器响应。