这是将字符串写入文件的代码
System.IO.File.WriteAllText("test.txt", "P ");
基本上是字符“ P”,后跟总共513个空格字符。
当我在Notepad ++中打开文件时,看起来不错。但是,当我在Windows记事本中打开时,看到的只是乱码。
如果我用514或512代替513空格字符,则可以在记事本中正常打开。
我想念什么?
答案 0 :(得分:5)
您缺少的是记事本正在猜测,并不是因为您的长度专门是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,那么仅了解记事本碰巧对您的特定用例进行了错误猜测,并完全保留原始内容就可以了,这可能更安全。
您可以通过读取二进制文件,然后将它们转换为字符串来验证BOM表中的物理差异(您无法使用ReadAllText
“看到”更改,因为它会保留并剥离BOM):
byte[] contents = System.IO.File.ReadAllBytes("test.txt");
Console.WriteLine(Encoding.ASCII.GetString(contents));
答案 1 :(得分:3)
尝试传递不同的编码:
i. System.IO.File.WriteAllText(filename , stringVariable, Encoding.UTF8);
ii. System.IO.File.WriteAllText(filename , stringVariable, Encoding.UTF32);
iii. etc.
此外,您可以尝试使用另一种方式来构建您的字符串,以使其更易于阅读,更改和计数,而不是轻按空格键513次;
i。使用字符串构造函数(建议使用@Tigran)
var result = "P" + new String(' ', 513);
ii。使用stringBuilder
var stringBuilder = new StringBuilder();
stringBuilder.Append("P");
for (var i = 1; i <= 513; i++) { stringBuilder.Append(" "); }
iii。或两者皆有
public string AppendSpacesToString(string stringValue, int numberOfSpaces)
{
var stringBuilder = new StringBuilder();
stringBuilder.Append(stringValue);
stringBuilder.Append(new String(' ', numberOfSpaces));
return stringBuilder.ToString();
}