我有一个应该读取UTF-8编码文件的jar文件 – 我在Windows下的文本编辑器中编写，并将字符显示在屏幕上。 在OS X和Linux下这工作完美无瑕。 我有一些麻烦，让它在Windows下工作，但我已经定义了一个读者和写作者是这样的：
FileInputStream file = new FileInputStream(args[0]); InputStreamReader reader = new InputStreamReader(file, "UTF8"); PrintStream writer = new PrintStream(System.out, true, "UTF8"); 我也改变了命令提示字体到Lucida Console和字符编码为chcp 65001 UTF-8，依次。
现在，当我运行java -jar Read.jar file.txt ，提示符java -jar Read.jar file.txt出来。
áéí ñóú []óú []
但是，如果我运行type file.txt ，提示正确显示文件的内容。
áéí ñóú
我已经尝试使用和不使用BOM来保存文件，但是这没有什么区别。 （UTF-8甚至不需要物料清单，因为它缺乏字节顺序，是否正确？）我试着用javac -encoding utf8 *.java编译，但是同样的事情发生了。
我现在没有想法了。 任何人都在帮忙吗？
代码页65001已损坏。 MS C运行时stdio函数返回在65001下运行时读取和写入的字节数不准确，导致像这样的奇怪行为。
这是不可修复的 – 您不能可靠地使用Windows控制台来处理来自使用C stdlib字节I / O函数（包括Java）的应用程序的Unicode I / O。 您可以通过调用Win32 API函数WriteConsoleW来直接获取Unicode内容到控制台，但是您必须担心检测何时标准输出实际上是一个控制台（不重定向到文件）。
这是MS表示无意修理的一个长期存在的祸根。
看起来可能是你换行符。 当我在标准英文ISO-8859-1中使用换行符时，我使用char []数组，因为Windows字符'\ r'和'\ n'以及UNIX / Linux只是换行符。 赢4个字节，unix 2个字节。 一个不是，在字符转换器类的API文档中，编码转换系统可能会留下虚假的字节，以取决于编码和字符大小的要求。
尝试使用BufferReader来读取你的文件，
BufferedReader in = new BufferedReader( new InputStreamReader( new FileInputStream(file), "UTF8"));