在带有libiconv 1.14-2的cygwin 1.7.25上，iconv（1）在与iconv -t utf-16一起使用时会生成big-endian UTF-16（带有BOM），即使x86是小端（并且windows产生小端） UTF-16）。是不是libiconv应该使用依赖于平台的字节顺序进行默认的utf-16转换？对于我正在使用的应用程序来说，这不一定是个问题（因为他们可以通过阅读BOM来处理这两个应用程序），但仍然有一些特殊的行为：使用记事本编辑新文件。它将保存为带有bom的utf-16le，在同一系统-t utf-16上通过iconv（1）运行它，然后你会得到一个重新排序的文件（带有big-endian bom）。
答案 0 :(得分：2)
Unicode规范表明对大端的偏好，默认情况下，非Microsoft软件通常会使用它。特别是当UTF-16没有BOM编码，并且没有更高级别的协议（例如媒体声明字节顺序，如网络和网络字节顺序）时，字节顺序是大端。但是，某些软件不符合规范，并且在没有BOM时假定为小端，因此可以添加BOM以允许此类软件工作。
libiconv不应该使用依赖于平台的字节顺序来进行默认的utf-16转换吗？
据我所知。是什么让你这么想？
答案 1 :(得分：1)
这不是一个重复，但是Convert UTF8 to UTF16 using iconv接受的答案提出了一个简单且可编写脚本的工作方法，用于指定显式字节顺序，然后预先添加BOM：
( printf "\xff\xfe" ; iconv -f utf-8 -t utf-16le UTF-8-FILE ) > UTF-16-FILE