为什么我的 UTF-8 文档在 Azure Data Lake Analytics 中引发 UTF-8 编码错误？

Question

我有一个从未知来源系统以 gunzip 压缩的文档。它是使用 7zip 控制台应用程序下载和解压缩的。该文档是一个 CSV 文件，似乎以 UTF-8 编码。

然后在压缩后立即上传到 Azure Data Lake Store。然后有一个 U-SQL 作业设置，只需将它从一个文件夹复制到另一个文件夹。此过程失败并引发值的 UTF-8 编码错误：ée

测试

我从商店下载了该文档并删除了所有记录，但带有 Azure 标记值的记录除外。在 Notepad++ 中，它将文档显示为 UTF-8。我再次将文档保存为 UTF-8 并将其上传回商店。我再次运行该过程，该过程成功，该值为 UTF-8

我在这里缺少什么？原始文档是否可能不是真正的 UTF-8？是否还有其他原因导致误报？我有点困惑。

可能性

• 文件不是真正的UTF-8，需要重新编码
• 也许上传文件的方法是重新编码
• 也许 7zip 重新编码不正确

环境/工具

• 视窗服务器
• 蟒蛇 2.7
• Azure 数据湖存储
• Azure 数据湖分析
• 7Zip.exe
• gz
• Azure API

USQL

只是定义架构的基本 USQL 作业然后将所有字段选择到一个新目录。除了省略标题之外，不会发生任何转换。该文件是 CSV，用逗号分隔的字符串中的双引号。无论数据类型如何，架构都是字符串。尝试的提取器是 TEXT 和 CSV，两者都设置为编码：UTF8，即使根据系统上的 Azure 文档，两者都默认为 UTF8。

其他注意事项

1. 该文档过去曾上传到 BLOB 存储，并通过 Polybase 以相同方式导入 Azure 数据仓库，没有出现错误。
2. 导致 UTF-8 编码错误的值是在 100 万条其他记录中乱码的 URL。
3. 即使它是一个 UTF-8 文档，它看起来也有 ASCII 字符。
4. 当我将其转换为 ANSI 并使用 ASCII 提取器时，文件成功。
5. Azure Data Lake Analytics 不允许你忽略该错误，因为它是一个编码问题。我很乐意像您在 Azure 数据仓库中那样一起使记录无效。

Answer 1

UTF-8 编码的文件可以选择包含字节顺序标记 (BOM)。这是一个“幻数”，用于向使用软件表明该文件是 UTF 编码的。更复杂的是，BOM 可以是大尾数法或小尾数法。

Notepad++ 使所有这些都可以通过“编码”菜单可见。我建议您在您的文件（或其精简副本）中摆弄这些内容，看看哪些（如果有的话）有效。