吐槽:绝望的C#:文本流StreamWriter StreamWriter无法正确定位

        这两天用C#写文件处理的程序,发现一个大BUG:

        StreamWriter和StreamWriter的Seek和Position是很奇葩的。

        文本文件如果用UTF-8格式,会被添加三字节的BOM,就是这三个字节引出了无穷问题。似乎是想兼容原来没有BOM的操作方式导致的,似驴似马,非驴非马,时驴时马。

目录

新建文件写数据

Seek(0)再写

关了文件重开再Seek(n)写

读文件的Position是读到缓存的位置

不确定的问题


新建文件写数据

        新建文件,Position是0,写入两个字节,Position是5,因为写了BOM嘛,可以理解。

Seek(0)再写

        BOM没有了,从第一个字节开始覆盖,因此重新写入的数据与之前相比错位了三个字节,可以理解,但是不科学嘛,你不会保证文件开始处有三个字节的BOM吗?为什么新建文件写你就知道写BOM呢?

关了文件重开再Seek(n)写

        好嘛!在文件中间又写一次BOM,合着你是第一次写自动加BOM啊?后面就不加了啊?你不看文件位置的吗?

读文件的Position是读到缓存的位置

        读文件的Position就更奇葩了,大概他们压根没想过会有人在文本文件里来回读吧,这个Position的值是读到缓存的位置,而不是你获取的位置,所以如果你用Position来记录读取到的位置你就傻了。

不确定的问题

        观察到有时候读的Position比实际的少了3,也可能我搞错了,因为后来我放弃了,改用ASCII了,这样就没有BOM的问题。反正写文件、读文件的都是我,我可以把内容都转码成ASCII。

(这里是结束)

你可能感兴趣的:(dotnet,c#,开发语言,StreamWriter,streamReader,文本文件)