【发布时间】：2015-11-30 02:13:03
【问题描述】：
我最近一直在阅读有关 Unicode 的所有内容，因为它的工作原理非常有趣。
所以我读到UTF-32 是固定的 4 个字节。好吧，我觉得这很奇怪，当我在我的两台 MacBook Air 上保存一个简单的文件时，其中有一个字母 (t)，它保存了 8 个字节。 UTF-16 也发生了这种情况，它占用了 4 个字节（虽然并不奇怪）。有人知道为什么吗？
注意：我确实检查过，里面没有空格
【问题讨论】：
标签： utf-32
【发布时间】：2015-11-30 02:13:03
【问题描述】：
很可能在t 字符前面的文件开头保存了一个UTF BOM。 BOM 用于指定使用哪种 UTF 编码对文件进行编码，在 UTF-16 和 UTF-32 的情况下使用哪种字节序。
UTF-16LE：BOM（2 个字节）+t（2 个字节）=4 个字节FF FE74 00
UTF-16BE：BOM（2 个字节）+t（2 个字节）=4 个字节FE FF00 74
UTF-32LE：BOM（4 个字节）+t（4 个字节）=8 个字节FF FE 00 0074 00 00 00
UTF-32BE：BOM（4 个字节）+t（4 个字节）=8 个字节00 00 FE FF00 00 00 74
【讨论】：
-
或者最后可能是 EOF ？
-
没有人在文本文件中写入实际的 EOF 字符。 EOF 被控制台和网络协议使用。但可以肯定的是，使用十六进制编辑器来查看文件的实际字节数。
-
那为什么我的 UTF-8 文件没有 BOM 呢？
-
因为 Unicode 规范不鼓励（但不阻止）在 UTF-8 文本文件中使用 BOM，主要是为了向后兼容可以处理 ASCII 文本文件但不能处理 BOM 的应用程序。 UTF-8 旨在向后兼容 ASCII。请参阅UTF-8, UTF-16, UTF-32 & BOM 常见问题解答。一些文本编辑器可以选择保存带有或不带有 BOM 的 UTF-8 文件。
-
使用
hexdump -C path-to-file转储文件内容以查看其中的确切内容。