问题标签 [utf-16le]

我有带有BOM的UTF-16LE编码的CSV文件。它们可能很大，所以我不太喜欢在内存中读取整个文件的想法。我该如何阅读它们？

我正在使用 UTF-16LE 编码的 CSV 文件。我使用 Perl 模块 Text::CSV_XS 来处理数据：

使用 Data::Dumper 打印第一行，BOM 显示在输出中：

根据perldoc，BOM 被保留，因为我明确声明内容为 UTF-16LE。仅写入时:encoding(UTF-16)，将删除 BOM。

但我想将其保留在代码中以明确说明所需的编码。我想这是一件好事。如果没有，请告诉我。

但是，我必须处理 BOM，例如通过编写：$header_row->[0] =~ s/^\x{FEFF}//;

这是正常的吗？在处理 utf-16 编码文件时，我是否必须关心字符串中的 BOM？还是我做错了什么？

我们需要从 Oracle DB 表中挑选数据并将该数据转储到 csv 文件和纯管道分隔的文本文件中。在应用程序上为用户提供链接，以便用户可以查看生成的 csv/文本文件。

由于涉及到大量的解析，所以我们编写了一个 Unix shell 脚本并从 Struts/J2ee 应用程序中调用它。

早些时候，我们在生成的文件中丢失了中文和罗马字符，生成的文件有 us-ascii 字符集（使用-> 文件 -i 进行检查）。后来我们使用 NLS_LANG=AMERICAN_AMERICA.AL32UTF8了，这给了我们 utf-8 格式的文件。

但是字符仍然是乱码，所以我们再次尝试了 iconv 命令并将 utf-8 文件转换为 utf-16le 字符集。 iconv -f utf-8 -t utf-16le $recordFile > $tempFile

这适用于生成的文本文件。但是对于 CSV，中文和罗马字符仍然不正确。现在，如果我们在记事本中打开这个 csv 文件并通过按键盘上的 Enter 键换行，保存它。用 MS-Excel 打开它，所有字符都很好，包括中文和罗马，但现在每行的文本都是单行而不是列。

不知道发生了什么。

Java 代码

如果我错过了任何细节，请告诉我。感谢大家抽出时间来解决这个问题。

I'm downloading some CSV files from playstore (stats etc) and want to process with python.

As you can see they are utf-16le.

I have some code on python 2.7 that works on some files and not on others:

This works until:

What is the proper way to do this? I've seen "re encode" use cvs module etc. but csv module does not handle encoding by itself, so it seems overkill for just dumping to a database

你知道为什么下面的第一行和第二行不产生文件的 BOM 而第三行吗？我认为 UTF-16LE 是正确的编码名称，并且该编码不会自动创建 BOM 到文件的开头。

另一个样品

印刷

和java

印刷

Java 不会产生 BOM，而 Groovy 会产生 BOM。

我在这里找到了一个非常有用的 perl ，它将文本文件的文件名写入文件的第一行。我从 OS X Yosemite 的终端运行它：

经过一些修改，我认为它已经解决了我的具体问题，但是我选择的文件是 UTF-16LE，我发现这个命令是用 UTF-8 编写的，并且使输出变得一团糟（文本明显正确但在 excel、filemaker 等的计算中不被识别）。

经过几次尝试后，我需要帮助以获取此脚本以将 UTF-16LE 中的文件名写入文件的开头。（注意：我现在确实有一种将文件批量转换为 UTF-8 的解决方法，然后运行它，但是我更愿意一步完成这个工作流程）。

我有一个在 Windows 上运行的 Ruby 程序，它使用 Open3 调用一个 shell 命令（已知输出 UTF-16）：

如果对 UTF_16LE 的 force_encoding 不起作用并引发异常，我只需保存字节，将其编码为 JSON 字符串并将其编码为 UTF_8。

好吧....抛出了异常，我在救援子句中捕获了输出字节数组。它看起来像这样：

如何将其转换回某种格式的文本。例如，如果我这样做：

有没有办法以编程方式将 [100, 111, 103] 转换为“狗”或 [224, 164, 149, 224, 165, 129, 224, 164, 164, 224, 165, 141, 224, 164, 176, 224, 164, 190] 回到“कुत्रा”？有没有办法弄清楚我的输出字节数组是什么意思？

- - - - - - - - - - - - - 更新 - - - - - - - - - - - - ---

我挖了一点，但花了一段时间，因为“解码”不是一件事。但是，我对变量message中保存的数组执行了以下操作：

所以我的问题解决了，因为错误消息不在 UTF-16LE 中。

但是，当我这样做时，我得到了以下结果：

如何将这个看起来很奇怪的字符串或字节序列转换为更有意义的 "कुत्रा" ？

我需要通过 UTF16-LE 中的 PHP 生成 csv 以支持 Excel（在 Windows 和 Mac OS X 上）。正如这里mb_convert_encoding所建议的，我在文件开头使用并添加了 BOM，然后是sep=;为了使其在 Excel 上正确打开。

字符编码没问题，但是当我尝试在 OpenOffice 中打开它时，我得到的是：

sep=;\n无法识别 - 它不应该在第一行。我认为这不是 BOM 问题，因为当我用十六进制编辑器打开它时，我得到的是：

BOM 似乎是正确的，因为它ÿþ是 UTF16-LE BOM。我尝试用 with\r\n代替\nafter sep，但没有运气。

我正在处理使用 UTF-16LE 编码的 .csv 文件，这种方法可以读取文件，但与 read_csv 相比，read.csv 非常慢。

不幸的是，我无法使 read_csv 工作，我只得到空行，而且我什至找不到在函数中指定编码的方法。

我无法分享我的数据，但如果有人处理过这种编码，我们将不胜感激。

旧测试中有一个问题让我感到困惑：“将文件从 UTF16-LE 转换为 UTF16-BE 之后，文件会变小还是变大？”

我认为这只是字节的不同顺序，但我不明白为什么它应该改变文件的大小？