爲什麼Java使用modified UTF-8而不是標準的UTF-8用於對象序列化和JNI?爲什麼Java使用修改的UTF-8而不是UTF-8?
一個可能的解釋是修改後的UTF-8不能包含空字符,因此可以使用對空字符進行操作的函數。還有其他原因嗎?
爲什麼Java使用modified UTF-8而不是標準的UTF-8用於對象序列化和JNI?爲什麼Java使用修改的UTF-8而不是UTF-8?
一個可能的解釋是修改後的UTF-8不能包含空字符,因此可以使用對空字符進行操作的函數。還有其他原因嗎?
處理補充字符(通過不處理它們)更快更簡單。
Java代表個字符爲16位char
s,但unicode已演變爲包含超過64K個字符。所以有些字符,即補充字符,必須用Java編碼在2 char
s(代理對)中。
嚴格的UTF-8要求編碼器將代理對轉換爲字符,然後將字符編碼爲字節。解碼器需要將補充字符分割回代理對。
chars -> character -> bytes -> character -> chars
由於兩端都是Java,我們可以採取一些快捷方式,並直接在char
水平
char -> bytes -> char
既不編碼解碼器,也不需要進行編碼擔心代理對。
我懷疑這是主要原因。在C域中,不得不處理字符串可能包含嵌入的NUL會使事情變得複雜。
對Unicode Explained - Page 306中的修改UTF-8有很好的描述,但它沒有說明爲什麼修改了UTF-8。
在Java自己的文檔中,還非常詳細地解釋瞭如何支持非BMP Unicode字符最初添加到Java:Supplementary Characters in the Java Platform。但是,再次,沒有解釋爲什麼修改的UTF-8決定。
我不認爲你會發現一個爲什麼,除非你直接問Java的建築師。
這是_how_的一個很好的描述,但我在_why_上看不到任何信息 – 2013-03-16 19:04:27
我couild問你爲什麼你想要讀取不在java中的序列化java對象:-) – radai 2013-03-15 19:39:30
@radai:我不讀任何東西,只是問一個問題。 =) – vitaut 2013-03-15 19:41:42
在這種情況下,我認爲NPE是正確的。看起來像他們在需要與C進行交互時使用它(序列化,JNI,類文件解析) – radai 2013-03-15 19:50:25