这是将字符串写入文件的代码

System.IO.File.WriteAllText("test.txt", "P                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 ");

它基本上是字符 'P' 后跟总共 513 个空格字符。

当我在 Notepad++ 中打开文件时,它似乎没问题。但是,当我在 Windows 记事本中打开时,我看到的只是乱码。

如果我添加 514 或 512 而不是 513 个空格字符,它会在记事本中正常打开。

我错过了什么?

最佳答案

您缺少的是记事本在猜测,并不是因为您的长度特别是 513 个空格……而是因为它是 偶数字节 并且文件大小 >= 100 总字节。尝试使用 511 或 515 个空格……或 99 个……您会看到对文件内容的相同误解。对于奇数字节,记事本可以假设您的文件不是任何双字节编码,因为这些都会导致每个字符 2 个字节 = 文件中总字节数的偶数。如果您在开头给文件提供更多的低位 ASCII 字符(例如,“PICKLE”+空格),记事本会更好地理解它应该将内容视为单字节字符。

包含 Encoding.UTF8 的建议方法是最简单的修复方法......它会在文件的开头写入一个 BOM,告诉记事本(和 Notepad++ )数据的格式是什么,这样它就不必求助于此猜测行为(您可以通过在 Notepad++ 中打开两者来查看原始方法和 BOM 方法之间的区别,然后查看应用程序的右下角。使用 BOM,它会告诉您编码是 UTF-8-BOM ... 没有它,它只会说 UTF-8 )。

我还应该说,您的文件内容本身并没有“错误”……这种奇怪的格式纯粹是由于记事本的“猜测”算法造成的。因此,除非要求人们使用记事本来读取包含 1 个字母和大量奇数空格的文件……也许只是不要担心。如果您确实更改为使用 Encoding.UTF8 写入文件,那么您确实需要确保读取您文件的任何其他系统都知道如何遵守 BOM,因为 对文件内容的真正更改。如果您无法验证您的文件的所有使用者是否可以/将处理 BOM,那么了解记事本碰巧对您的特定用例做出错误猜测并完全按照您的需要保留原始内容可能会更安全。

您可以通过执行二进制读取然后将它们转换为字符串来验证文件与 BOM 中的物理差异(您无法使用 ReadAllText “看到”更改,因为它尊重并剥离 BOM):

byte[] contents = System.IO.File.ReadAllBytes("test.txt");
Console.WriteLine(Encoding.ASCII.GetString(contents));

关于c# - 在 C# 中用 513 个空格字符将文本写入文件,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/51865151/

10-12 01:11
查看更多