在Java中:为什么有些Stream方法采用int而不是byte或甚至是char？

Question

为什么有些写入bytes/chars流的方法需要int代替byte/char？

有人在int的情况下告诉我而不是char:因为char在java中只有2个字节的长度,对于已经使用的大多数字符符号都可以,但对于某些字符符号(中文或其他),该字符表示为2个以上字节,因此我们使用int代替.

这个解释与真相有多接近？

编辑:我用这个stream词来表示二进制和字符流(不只是二进制流)

谢谢.

Answer 1

在int的情况下有人告诉我而不是char:因为java中的char只有2个字节的长度,对于已经使用的大多数字符符号都可以,但对于某些字符符号(中文或其他),字符表示更多超过2个字节,因此我们使用int代替.

假设此时您正在专门讨论该Reader.read()方法,那么您所述的"某人"的陈述实际上是不正确的.

确实,某些Unicode代码点的值大于65535,因此无法表示为单个Java char.但是,ReaderAPI实际上会生成一系列Java char值(或-1),而不是一系列Unicode代码点.这在javadoc中明确说明.

如果您的输入包含(适当编码的)Unicode代码点大于65535,那么您实际上需要调用该read()方法两次才能看到它.你会得到一个UTF-16代理对; 即两个一起表示代码点的Java char值.实际上,这符合Java String,StringBuilder和StringBuffer类的工作方式; 它们都使用基于UTF-16的表示......具有嵌入式代理对.

Reader.read()返回int非a 的真正原因char是允许它返回-1信号表示没有更多字符要读取.同样的逻辑解释了为什么InputStream.read()返回int不是a byte.

假设,我认为Java设计者可以指定read()方法抛出异常来表示"流结束"条件.但是,这只会将一个潜在的错误源(无法测试结果)替换为另一个(未能处理异常).此外,异常相对昂贵,并且流的结束实际上不是意外/异常事件.简而言之,目前的方法更好,IMO.

(ReaderAPI 的16位特性的另一个线索是该read(char[], ...)方法的签名.如果未使用代理对,如何处理大于65535的代码点？)

编辑

这种情况DataOutputStream.writeChar(int)确实有点奇怪.但是,javadoc明确指出该参数被写为2字节值.事实上,实现清楚地只将底部的两个字节写入底层流.

我不认为这是有充分理由的.无论如何,有一个错误数据库条目(4957024),标记为"11-Closed,Not a Defect",其中包含以下注释:

"这不是一个伟大的设计或借口,但它太过于让我们改变了."

...... 至少从设计的角度来看,这是一种承认它是缺陷的东西.

但IMO并不值得大惊小怪.