java中字符流的用途是什么？

java中字符流的用途是什么？为什么我们需要字节流呢？我已经浏览了很多网站，但我不能弄清楚…请让我弄清楚…请不要粘贴谷歌结果我想你是指界面吧？如果您使用的是文本，您不必担心每一层的二进制/文本转换。事实上，从概念上讲，您甚至可能没有要转换的二进制数据——例如

使用

阅读器

界面可以清楚地表明您确实需要文本，并且该文本背后的二进制数据与您无关，只要它可以以某种方式作为Unicode字符序列提供

在您的头脑中，二进制和文本是不同的，这一点非常清楚。如果试图将任意二进制数据视为文本（例如，试图将图像文件读入字符串），则会丢失信息。为什么不希望不同的类型处理不同形式的数据

---

这有点像是说，“我们可以将每个对象的数据存储在一个字节数组中，并在需要时转换其中的片段。”是的，我们可以（如果您可以将不透明的二进制数据转换为引用或从引用转换而来），但从封装的角度来看，这将是可怕的。

阅读器

接口是一个封装层，允许各种数据源公开字符数据（无论它们是否需要解码二进制数据）和其他代码来使用这些字符数据，而不必知道字符数据的确切来源。

很抱歉，谷歌搜索结果实际上回答了您的问题。从网站（首次在google上点击

字符流java

）：

为什么使用字符流？ 字符流的主要优点是，它们使编写不依赖于特定字符编码的程序变得容易，因此易于国际化

字符流的第二个优点是它们可能比字节流更高效。Java的许多原始字节流的实现都是以每次字节的读写操作为导向的。相比之下，字符流类是围绕每次缓冲区的读写操作来定向的。这种差异，再加上更有效的锁定方案，允许字符流类在许多情况下弥补编码转换的额外开销

---

是的，可以使用InputStream/OutputStream处理文本数据，但读写器接口提供了处理文本数据的有用方法。

我认为这只是遵循层次结构的问题。同样的原因是存在字符串，即使您可以简单地使用字符数组而不是字符串。

字符流是处理文本文件等字符数据的便捷方法。您可以获取字节流并为其提供字符编码并有效地将其转换为with character stream，同样，您可以获取字符流并提供字符编码并有效地将其转换为字节流

---

转换通常通过修饰流来完成。正如您可能猜到的，字符编码是一种将字符转换为字节的算法，反之亦然

冒着听起来讽刺的风险，它的目的是阅读一连串的字符

关键是字符与字节不同

一个字节是8位的集合，唯一可能的变化是它的大端或小端

角色是一种更复杂的小野兽。它属于字符集，受国家语言设置的影响

最简单的是ASCII，NLS设置为“C”，这与字节几乎相同，只是值具有特定的含义o=ings，例如x'30'是ASCII字符“0”，如果应用“isNumber（）”方法，它将返回true。 下一步是各种ISO八位代码页，它们通常将x'7F'以上的字符分配混洗，以处理欧洲口音的字符

此外，还有其他编码，如EBCDIC，仍然被广泛使用——这里“0”被编码为x“F0”

然后是unicode-16，它将对各种广泛使用的字母表中的数千个字符进行编码，unicode-32则对广泛使用和不广泛使用的字母表（如克林贡语和Mycinean语）中的数百万个字符进行编码

有一种中间utf-8编码，它保留了7位编码的普通旧ASCII字符，但也有非常聪明的算法将整个unicode字母表存储在两个、三个或四个字节中

此外，还有用于日文和中文字符的“传统”远东编码方案，这些方案具有复杂的方案，用于指示字符是保存在一个字节、两个字节还是三个字节中

---

关键是，字符流类知道所有这些代码页，并且可以通过字符输入做一些智能的事情，例如将cp874转换为unicode-16，而字节流类无法做到这一点。

本质上，问题是“一个字节”不能很好地映射到“一个字符”。Unicode指定的字符多于16位，因此8位是不够的

---

原因还有很多，但这是主要原因。

Java平台使用Unicode约定存储字符值。字符I/O流自动将此内部格式转换为本地字符集，或从本地字符集转换。在西方地区，本地字符集通常是ASCII的8位超集

对于大多数应用程序，使用字符流的I/O并不比使用二进制流的I/O复杂。使用流类完成的输入和输出自动转换为本地字符集，并从本地字符集进行转换

使用字符流代替字节流的程序会自动适应本地字符集，并准备好进行国际化—所有这些都无需程序员额外的努力

所有字符流类都是R的后代