用处理流打印一串英文字符是总会出现239？？？

本文链接：https://blog.csdn.net/dream_one_day/article/details/98535897

当在Win10系统下以UTF-8编码创建.txt文件并尝试通过Java代码打印内容时，首字符经常出现239，这是因为Win10的UTF-8文件带有BOM。BOM（Byte Order Mark）用于标识字节顺序，其UTF-8编码是EF BB BF。要解决这个问题，可以使用Notepad++打开文件，选择“Encode in UTF-8”再保存，即可消除BOM并正常打印内容。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

哎呦，今天被这个239搞到疯了?
用电脑?右击创建一个.txt文档。由于win10默认是ANSI格式，将文件另存为UTF-8时，用Java代码实现打印文件内容，运行结果第一个总是打印239。搞疯了，用字节流输入时别人打印中文的时候用 byte[2] 就可以将中文内容打印出来。我的总是乱码，调试之后发现我的总有一个空格。
这个是为什么呢？？？
原来win10自带的UTF-8是带BOM的。
百度百科中这样介绍BOM
BOM — Byte Order Mark，中文名译作“字节顺序标记”。下面是关于 BOM 的说明：
在UCS 编码中有一个叫做 “Zero Width No-Break Space” ，中文译名作“零宽无间断间隔”的字符，它的编码是 FEFF。而 FFFE 在 UCS 中是不存在的字符，所以不应该出现在实际传输中。UCS 规范建议我们在传输字节流前，先传输字符 “Zero Width No-Break Space”。这样如果接收者收到 FEFF，就表明这个字节流是 Big-Endian 的；如果收到FFFE，就表明这个字节流是 Little- Endian 的。因此字符 “Zero Width No-Break Space” （“零宽无间断间隔”）又被称作 BOM。
UTF-8 不需要 BOM 来表明字节顺序，但可以用 BOM 来表明编码方式。字符 “Zero Width No-Break Space” 的 UTF-8 编码是 EF BB BF。所以如果接收者收到以 EF BB BF 开头的字节流，就知道这是 UTF-8编码了。Windows 就是使用 BOM 来标记文本文件的编码方式的。
字符U+FEFF如果出现在字节流的开头，则用来标识该字节流的字节序，是高位在前还是低位在前。如果它出现在字节流的中间，则表达零宽度非换行空格的意义，用户看起来就是一个空格。从Unicode3.2开始，U+FEFF只能出现在字节流的开头，只能用于标识字节序，就如它的名称——字节序标记——所表示的一样；除此以外的用法已被舍弃。取而代之的是，使用U+2060来表达零宽度无断空白。
类似WINDOWS自带的记事本等软件，在保存一个以UTF-8编码的文件时，会在文件开始的地方插入三个不可见的字符（0xEF 0xBB 0xBF，即BOM）。它是一串隐藏的字符，用于让记事本等编辑器识别这个文件是否以UTF-8编码。
再说一遍，Windows就是使用BOM来标记文本文件的编码方式的。！！！
在这里插入图片描述