我正在使用 anInputStream從 TCP 服務器(用 C# 編寫)讀取byte[]字節(jié)到 ,并使用new String(byteArray, "UTF-16LE"). 這種方法可以很好地編碼基本多語言平面中的字符,但不能處理增補字符。我知道 C# 中的字節(jié)是無符號的,而 Java 字節(jié)是有符號的,并且補充字符可以由一個或兩個 unicode 值組成。 ByteBuffer wrapped = ByteBuffer.wrap(dataBytes); wrapped.order(ByteOrder.LITTLE_ENDIAN); short noOfSites = wrapped.getShort(); for(int i = 0; i < noOfSites; i++){ short siteNo = wrapped.getShort(); short textLength = wrapped.getShort(); byte[] textBytes = new byte[textLength]; wrapped.get(textBytes, 0, textLength); for(byte bite : textBytes){ System.out.print(bite+" "); } //just to see what's in the byte array String siteText = new String(textBytes, "UTF_16LE"); System.out.println(siteNo + ": " + siteText); siteList.add(new Site(siteNo, siteText)); publishProgress(siteNo + " - " + siteText); }在這個例子中,dataBytes是包含從服務器讀取的字節(jié)的字節(jié)數(shù)組,noOfSites是要從服務器讀取的對象的數(shù)量,siteNo是一個 ID,textLength是包含站點名稱的字節(jié)數(shù),textBytes是保存的數(shù)組這些字節(jié)。當從服務器接收到單詞“MüNSTER”時,讀入緩沖區(qū)的字節(jié)是: 77 0 -3 -1 78 0 83 0 84 0 69 0 82 0。-3 -1但是,無法識別“ü”字符,我認為這是由于 Java 嘗試(但未能)編碼的 UTF-16 值造成的。我知道在 C# 中,“ü”由 表示DC-00,但我不明白為什么-3 -1在 Java 中會變成這樣。任何幫助將不勝感激。
1 回答

GCT1015
TA貢獻1827條經(jīng)驗 獲得超4個贊
“?”字符未在您的源代碼中編碼 - 到達接收器端“-3,-1”的序列是-替換字符0xfffd
的 UTF 16 LE 編碼。
如果沒有看到服務器端代碼,很難判斷發(fā)生了什么,但它很糟糕。Utf-16 可以處理像“ü”這樣的字符而不會妨礙它。實際上,它甚至不在前 256 個 unicode 代碼點之外,更不用說在 Base Multilingual Plane 之外了。(這是一個在許多西方語言中很常見的字符,甚至是拉丁字符,它怎么會脫離為世界上所有語言設計的字符的平面?)
發(fā)生的事情是,從您的文本到用于電匯的 utf-16 的代碼路徑在某些時候被明確指示為任何不僅僅是 ASCII 的字符設置替換字符(舊版 unicode 代碼點 0x20 -0x7f,其中僅包括無重音的拉丁字符)。
明確地說,換句話說:數(shù)據(jù)在服務器端被破壞,所有非 ASCII 適合的字符都可能被壓縮為“替換字符”。對客戶端代碼進行再多的改動也無法解決這個問題。
添加回答
舉報
0/150
提交
取消