将字符串写入文件会生成意外内容

本文关键字：意外 字符串 文件 | 更新日期: 2023-09-27 18:30:48

我在文本编码方面有一个小问题。

我

有两个字符串，我正在从SQL Server 2008数据库（nvarchar-field）加载

从数据库加载它们后，Visual Studio 2010 在监视窗口中按如下方式显示它们：


str1 = "Test" str2 = "Test"

但与str1 = str2的比较False

如果我将这些字符串写入具有 UTF8 编码的文件，结果符合预期：

测试
测试

如果我将这些字符串写入具有 ANSI（默认）编码的文件，结果与预期不符：

？测试
测试

将字符串转换为字节：

System.Text.Encoding.Default.GetBytes(str1) 'Returns ByteArray {63, 84, 101, 115, 116}
System.Text.Encoding.Default.GetBytes(str2) 'Returns ByteArray {84, 101, 115, 116}
System.Text.Encoding.UTF8.GetBytes(str1) 'Returns ByteArray {239, 187, 191, 84, 101, 115, 116}
System.Text.Encoding.UTF8.GetBytes(str2) 'Returns ByteArray {84, 101, 115, 116}
在

ANSI 编码的情况下，字节 63 或字节 239、187、191（如果是 str1 的 UTF8 编码）来自哪里？

字节 239、187、191 是 UTF8 的 BOM。这里的问题更有可能是：为什么我获得 str1 的物料清单而不是 str2 的物料清单？

（嗯，这些值是传递给Web服务的值，Web服务将它们

插入数据库，初始值由我无法控制的客户端传递给此Web服务）

将字符串写入文件会生成意外内容

我很清楚，您确实从数据库中的两个不同记录中读取了两个字符串，对吗？不是以两种不同的方式来自一个记录？

那么，有人在一条记录中存储了 BOM。由于 BOM 在打印时不可见，因此您不会看到视觉差异。除非将字符串转换为无法存储 BOM 的编码。
这就是上面发生的事情。

要解决此问题，您需要清理数据库。读取每条记录，查看它是否以 BOM 开头，如果是，则写回内容（不带 BOM）。

编辑：我后来才注意到你说这个数据库是由网络服务即时创建的。在这种情况下，解决方案是联系网络服务的作者，并告诉他们他们的日常工作中有一个错误。

你自己回答了："这些值是传递给Web服务的值，Web服务将它们插入数据库，初始值由我无法控制的客户端传递给此Web服务"

物料清单将插入到此处。检查数据的插入方式，以及为什么使用 STR1 的 BOM 插入数据，而没有为 str2 插入数据。

我以前在将数据导入SQL时见过这种情况。实际上，导入是从CSV文件批量导入的。这导致第一行第一列中的数据包含 BOM，因此它使数据无效。

解决方案是清理数据库，但也要确保在插入之前清理从文件导入的所有新导入。

相关文章：