为什么Java使用修改的UTF-8而不是UTF-8？

为什么Java使用而不是标准UTF-8进行对象序列化和JNI

---

一种可能的解释是，修改后的UTF-8不能嵌入空字符，因此可以使用对以空结尾的字符串进行操作的函数。还有其他原因吗？

我想这是主要原因。在C语言中，必须处理可能包含嵌入式NUL的字符串会使事情变得复杂。

处理补充字符（不处理它们）更快、更简单

Java将字符表示为16位

char

s，但unicode已经演变为包含超过64K个字符。因此，一些字符，即补充字符，必须在Java中编码为2

char

s（代理项对）

严格的UTF-8要求编码器将代理项对转换为字符，然后将字符编码为字节。解码器需要将补充字符拆分回代理项对

chars -> character -> bytes -> character -> chars

由于两端都是Java，我们可以采取一些快捷方式，直接在

char

级别进行编码

char -> bytes -> char

---

编码器和解码器都不需要担心代理项对。

中对修改的UTF-8有很好的描述，但它没有解释决定修改UTF-8的原因

chars -> character -> bytes -> character -> chars

Java自己的文档中也有一个非常详细的解释，说明了最初是如何将对非BMP Unicode字符的支持添加到Java中的：。但同样，没有就改良UTF-8的原因作出解释

---

除非你直接问Java的架构师，否则我不认为你会找到一个为什么。

我可以问你为什么要读非Java的序列化Java对象：-）@radai:我什么都不读，只是问一个问题。=）在这种情况下，我认为NPE是正确的。看起来他们在需要与C（序列化、JNI、类文件解析）交互时都会使用它。这个决定是Sun的一位员工很久以前做出的。可能那个人知道答案，其他人都不知道。你在这里得到的只是猜测。他会把他的秘密带进坟墓的@无法解释的否决票很容易被视为纯粹的网站破坏。如果您认为这个答案没有用，请说明原因。这样做的一个好处是永远不要将“修改的UTF-8”（例如，来自DataOutputStream）用于不打算从Java读回的外部存储。这是一个很好的说明，但我没有看到任何关于原因的信息