Unicode 为什么cygwin中的iconv（1）生产带有“-t UTF-16”的大端UTF-16？

在带有libiconv 1.14-2的cygwin 1.7.25上，当与

iconv-t UTF-16

一起使用时，iconv（1）将生成大端UTF-16（带BOM），即使x86是小端（windows生成的小端UTF-16）。对于默认的utf-16转换，libiconv不是应该使用依赖于平台的endianness吗？对于我正在使用的应用程序来说，这不一定是个问题（因为它们可以通过读取BOM来处理这两个问题），但仍然是一种特殊的行为：用记事本编辑一个新文件。它将与bom一起保存为utf-16le，在同一系统上通过iconv（1）运行它

-t utf-16

，您将得到一个重新排序的文件（使用大端bom）。

这不是完全重复的，但公认的答案是提出了一个简单且可脚本化的解决方案，即指定一个显式的端部，然后预编bom：

( printf "\xff\xfe" ; iconv -f utf-8 -t utf-16le UTF-8-FILE ) > UTF-16-FILE

---

Unicode规范表示优先使用big-endian，通常非Microsoft软件默认使用big-endian。特别是当UTF-16编码时没有BOM，并且没有更高级别的协议（例如声明字节顺序的媒体，如网络和网络字节顺序），字节顺序是big-endian。但是，有些软件不符合规范，并且在没有BOM时假设几乎没有endian，因此可以添加BOM以允许此类软件工作

对于默认的utf-16转换，libiconv不是应该使用依赖于平台的endianness吗

据我所知不是这样。你怎么会这样想？

从这个帖子：我猜我误读了关于libc-iconv和libiconv-iconv的部分…（尽管基思·汤普森暗示在RFC中，“utf-16”（不是明确的LE或BE）的结尾是特定于实现的）