资讯详情

深入了解 · 专业解读

用VC6 App调用第三方Java WebService后的结果字符串乱码问题的解决！

发布时间：2026/6/24 2:43:11
用VC6 App调用第三方Java WebService后的结果字符串乱码问题的解决！ 码的中文GBK解码utf-8字节码后的错乱形式它的Utf-8形式的字节码16进制为00000000h: E4 B8 8A E4 BC A0 E6 88 90 E5 8A 9F 21 ; 涓婁紶鎴愬姛!..| 乱码字符 | GBK 编码 (十六进制) | |----------|---------------------| | 涓 | E4 B8 | | 婁 | 8A E4 | | 紶 | BC A0 | | 鎴 | E6 88 | | 夽 | 90 E5 | | 姛 | 8A 9F |同样的还可以将这个16进制用UTF-8 格式每三个字节码显示一个中文E4 B8 8A → 上 E4 BC A0 → 传 E6 88 90 → 成 E5 8A 9F → 功 21 → !所以我们要还原这个过程将GBK乱码反解成utf-8的原始字节再将utf-8格式转成unicode就能正确在VC中 messagebox了不及格的程序员-八神其实事情并不是这样的简单首先它传回来时并不是以e4b88a 这种utf-8 原始码传回来的现在我们看到的都是系统平台转换后的后面我为了捕捉原始码上了代理软件截取了通信的二进制原始信息它不仅可以返回成功信息还可以返回错误信息//下面为上传失败的返回错误信息涓婁紶澶辫触锛佷紒涓氬敮涓鏍囪瘑鐮侀獙璇佷笉閫氳繃锛//返回的乱码翻译过来上传失败企业唯?? 标识码验证不通过?? 正常脑补后修正实际应为上传失败企业唯一标识码验证不通过下面我们来分析一下为什么没有正确解码现在拿出乱码部分 utf-16的 中文显示涓婁紶澶辫触锛佷紒涓氬敮涓鏍囪瘑鐮侀獙璇佷笉閫氳繃锛 00000000h: 93 6D 41 5A 36 7D B6 6F AB 8F E6 89 1B 95 77 4F ; 搈AZ6}秓珡鎵.晈O 00000010h: 12 7D 93 6D 2C 6C 6E 65 93 6D FD FF CD 93 EA 56 ; .}搈,lne搈?蛽闢 //cd93 镙 00000020h: 11 76 2E 94 80 4F 59 73 87 74 77 4F 09 7B AB 95 ; .v.攢OYs噒wO.{珪 00000030h: 33 6C 43 7E 1B 95 FD FF ; 3lC~.朂 //FDFF ? 然后 好巧不巧地 与 UTF-8 格式的 gbk式 解码 高度相似 中文为上传失败企业唯?? 标识码验证不通过?? 00000000h: E4 B8 8A E4 BC A0 E5 A4 B1 E8 B4 A5 EF BC 81 E4 ; 涓婁紶澶辫触锛佷 00000010h: BC 81 E4 B8 9A E5 94 AF E4 B8 20 E6 A0 87 E8 AF ; 紒涓氬敮涓 鏍囪? //??(E4B820)标(e6a087)识(E8AF86)码(E7A081) 00000020h: 86 E7 A0 81 E9 AA 8C E8 AF 81 E4 B8 8D E9 80 9A ; 嗙爜楠岃瘉涓嶉€? 00000030h: E8 BF 87 EF BC 20 ; 杩囷?通过以上对比结论是 乱码的GBK编码的16进制就是它的 正确UTF-8格式的字节码就是说将这些字节按utf-8格式解码就显示出正确的中文了FDFF是未能找到映射字符被充的空白占位符未能被解析也不能还原原始码已丢失。 UTF-8 : EF BF BDHTTP/1.1 200 Server: nginx/1.26.2 Date: Thu, 23 Apr 2026 08:09:39 GMT Content-Type: text/xml;charsetUTF-8 Transfer-Encoding: chunked Connection: close soap:Envelope xmlns:soaphttp://schemas.xmlsoap.org/soap/envelope/ xmlns:xsdhttp://www.w3.org/2001/XMLSchema xmlns:xsihttp://www.w3.org/2001/XMLSchema-instancesoap:Bodyns1:uploaddevicemanagesoldreturnrecordsResponse xmlns:ns1DevManagens1:outlt;?xml version1.0 encodingUTF-8?lt;resultlt;error涓婁紶澶辫触锛佷紒涓氬敮涓 鏍囪瘑鐮侀獙璇佷笉閫氳繃锛 lt;/errorlt;/result/ns1:out/ns1:uploaddevicemanagesoldreturnrecordsResponse/soap:Body/soap:Envelope我们可以看到它内存里返回的字符串信息 soap 包裹着乱码中文 e6 b6 93 就是涓 utf-8的表示0:000 x *** WARNING: Unable to verify checksum for C:\WINDOWS\assembly\NativeImages_v4.0.30319_32\System\f291ffc218da543ab4e20e70929af20d\System.ni.dll 0019f358 this 0x024d26fc 0019f354 request 0x02631504 0019f350 res 0x02664034 0019f34c httpWebResponse 0x02664034 0019f348 memoryStream 0x02664370 0019f344 responseStream 0x02663dc0 0019f340 buffer 0x02664408 0019f33c bytesRead 0n517 0019f338 strUtf8 0x026656ec soap:Envelope xmlns:soaphttp://schemas.xmlsoap.org/soap/envelope/ xmlns:xsdhttp://www.w3.org/2001/XMLSchema xmlns:xsihttp://www.w3.org/2001/XMLSchema-instancesoap:Bodyns1:uploaddevicemanagesoldreturnrecordsResponse xmlns:ns1DevManagens1:outlt;?xml version1.0 encodingUTF-8?lt;resultlt;error涓婁紶澶辫触锛佷紒涓氬敮涓鏍囪瘑鐮侀獙璇佷笉閫氳繃锛lt;/errorlt;/result/ns1:out/ns1:uploaddevicemanagesoldreturnrecordsResponse/soap:Body/soap:Envelope 0019f334 CS$1$0000 0x00000000 0019f330 CS$4$0001 true db 0x02664408 L1000 02664408 40 5c 70 6d 00 10 00 00-3c 73 6f 61 70 3a 45 6e \pm....soap:En 02664418 76 65 6c 6f 70 65 20 78-6d 6c 6e 73 3a 73 6f 61 velope xmlns:soa 02664428 70 3d 22 68 74 74 70 3a-2f 2f 73 63 68 65 6d 61 phttp://schema 02664438 73 2e 78 6d 6c 73 6f 61-70 2e 6f 72 67 2f 73 6f s.xmlsoap.org/so 02664448 61 70 2f 65 6e 76 65 6c-6f 70 65 2f 22 20 78 6d ap/envelope/ xm 02664458 6c 6e 73 3a 78 73 64 3d-22 68 74 74 70 3a 2f 2f lns:xsdhttp:// 02664468 77 77 77 2e 77 33 2e 6f-72 67 2f 32 30 30 31 2f www.w3.org/2001/ 02664478 58 4d 4c 53 63 68 65 6d-61 22 20 78 6d 6c 6e 73 XMLSchema xmlns 02664488 3a 78 73 69 3d 22 68 74-74 70 3a 2f 2f 77 77 77 :xsihttp://www 02664498 2e 77 33 2e 6f 72 67 2f-32 30 30 31 2f 58 4d 4c .w3.org/2001/XML 026644a8 53 63 68 65 6d 61 2d 69-6e 73 74 61 6e 63 65 22 Schema-instance 026644b8 3e 3c 73 6f 61 70 3a 42-6f 64 79 3e 3c 6e 73 31 soap:Bodyns1 026644c8 3a 75 70 6c 6f 61 64 64-65 76 69 63 65 6d 61 6e :uploaddeviceman 026644d8 61 67 65 73 6f 6c 64 72-65 74 75 72 6e 72 65 63 agesoldreturnrec 026644e8 6f 72 64 73 52 65 73 70-6f 6e 73 65 20 78 6d 6c ordsResponse xml 026644f8 6e 73 3a 6e 73 31 3d 22-44 65 76 4d 61 6e 61 67 ns:ns1DevManag 02664508 65 22 3e 3c 6e 73 31 3a-6f 75 74 3e 26 6c 74 3b ens1:out 02664518 3f 78 6d 6c 20 76 65 72-73 69 6f 6e 3d 22 31 2e ?xml version1. 02664528 30 22 20 65 6e 63 6f 64-69 6e 67 3d 22 55 54 46 0 encodingUTF 02664538 2d 38 22 3f 3e 26 6c 74-3b 72 65 73 75 6c 74 3e -8?result 02664548 26 6c 74 3b 65 72 72 6f-72 3e e6 b6 93 e5 a9 81 error...... 02664558 e7 b4 b6 e6 be b6 e8 be-ab e8 a7 a6 e9 94 9b e4 ................ 02664568 bd b7 e7 b4 92 e6 b6 93-e6 b0 ac e6 95 ae e6 b6 ................ 02664578 93 ef bf bd e9 8f 8d e5-9b aa e7 98 91 e9 90 ae ................ 02664588 e4 be 80 e7 8d 99 e7 92-87 e4 bd b7 e7 ac 89 e9 ................ 02664598 96 ab e6 b0 b3 e7 b9 83-e9 94 9b ef bf bd 26 6c ..............l 026645a8 74 3b 2f 65 72 72 6f 72-3e 26 6c 74 3b 2f 72 65 t;/error/re 026645b8 73 75 6c 74 3e 3c 2f 6e-73 31 3a 6f 75 74 3e 3c sult/ns1:out 026645c8 2f 6e 73 31 3a 75 70 6c-6f 61 64 64 65 76 69 63 /ns1:uploaddevic 026645d8 65 6d 61 6e 61 67 65 73-6f 6c 64 72 65 74 75 72 emanagesoldretur 026645e8 6e 72 65 63 6f 72 64 73-52 65 73 70 6f 6e 73 65 nrecordsResponse 026645f8 3e 3c 2f 73 6f 61 70 3a-42 6f 64 79 3e 3c 2f 73 /soap:Body/s 02664608 6f 61 70 3a 45 6e 76 65-6c 6f 70 65 3e 00 00 00 oap:Envelope我为了看着方便简单对照了一下UTF-8 涓E6 B6 93, GBK 涓 E4 B8UTF-8 婁E5 9A 81, GBK 婁 8A E4UTF-8 紶E7 B4 B6, GBK 紶 BC A0UTF-8 上E4 B8 8A 传E4 BC A0并用 wingate 通信代理截取通信内容是否为原始信息//不及格的程序员-八神00041860h: 55 54 46 2D 38 0D 0A 54 72 61 6E 73 66 65 72 2D ; UTF-8..Transfer- 00041870h: 45 6E 63 6F 64 69 6E 67 3A 20 63 68 75 6E 6B 65 ; Encoding: chunke 00041880h: 64 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 63 ; d..Connection: c 00041890h: 6C 6F 73 65 0D 0A 0D 0A 32 30 35 0D 0A 3C 73 6F ; lose....205..so 000418a0h: 61 70 3A 45 6E 76 65 6C 6F 70 65 20 78 6D 6C 6E ; ap:Envelope xmln 000418b0h: 73 3A 73 6F 61 70 3D 22 68 74 74 70 3A 2F 2F 73 ; s:soaphttp://s 000418c0h: 63 68 65 6D 61 73 2E 78 6D 6C 73 6F 61 70 2E 6F ; chemas.xmlsoap.o 000418d0h: 72 67 2F 73 6F 61 70 2F 65 6E 76 65 6C 6F 70 65 ; rg/soap/envelope 000418e0h: 2F 22 20 78 6D 6C 6E 73 3A 78 73 64 3D 22 68 74 ; / xmlns:xsdht 000418f0h: 74 70 3A 2F 2F 77 77 77 2E 77 33 2E 6F 72 67 2F ; tp://www.w3.org/ 00041900h: 32 30 30 31 2F 58 4D 4C 53 63 68 65 6D 61 22 20 ; 2001/XMLSchema 00041910h: 78 6D 6C 6E 73 3A 78 73 69 3D 22 68 74 74 70 3A ; xmlns:xsihttp: 00041920h: 2F 2F 77 77 77 2E 77 33 2E 6F 72 67 2F 32 30 30 ; //www.w3.org/200 00041930h: 31 2F 58 4D 4C 53 63 68 65 6D 61 2D 69 6E 73 74 ; 1/XMLSchema-inst 00041940h: 61 6E 63 65 22 3E 3C 73 6F 61 70 3A 42 6F 64 79 ; ancesoap:Body 00041950h: 3E 3C 6E 73 31 3A 75 70 6C 6F 61 64 64 65 76 69 ; ns1:uploaddevi 00041960h: 63 65 6D 61 6E 61 67 65 73 6F 6C 64 72 65 74 75 ; cemanagesoldretu 00041970h: 72 6E 72 65 63 6F 72 64 73 52 65 73 70 6F 6E 73 ; rnrecordsRespons 00041980h: 65 20 78 6D 6C 6E 73 3A 6E 73 31 3D 22 44 65 76 ; e xmlns:ns1Dev 00041990h: 4D 61 6E 61 67 65 22 3E 3C 6E 73 31 3A 6F 75 74 ; Managens1:out 000419a0h: 3E 26 6C 74 3B 3F 78 6D 6C 20 76 65 72 73 69 6F ; lt;?xml versio 000419b0h: 6E 3D 22 31 2E 30 22 20 65 6E 63 6F 64 69 6E 67 ; n1.0 encoding 000419c0h: 3D 22 55 54 46 2D 38 22 3F 3E 26 6C 74 3B 72 65 ; UTF-8?lt;re 000419d0h: 73 75 6C 74 3E 26 6C 74 3B 65 72 72 6F 72 3E E6 ; sultlt;error? 000419e0h: B6 93 E5 A9 81 E7 B4 B6 E6 BE B6 E8 BE AB E8 A7 ; 稉濠佺炊婢惰精瑙 000419f0h: A6 E9 94 9B E4 BD B7 E7 B4 92 E6 B6 93 E6 B0 AC ; ﹂敍浣风磼娑撴艾 00041a00h: E6 95 AE E6 B6 93 EF BF BD E9 8F 8D E5 9B AA E7 ; 鏁稉锟介弽鍥 00041a10h: 98 91 E9 90 AE E4 BE 80 E7 8D 99 E7 92 87 E4 BD ; 槕閻線鐛欑拠浣 00041a20h: B7 E7 AC 89 E9 96 AB E6 B0 B3 E7 B9 83 E9 94 9B ; 风瑝闁俺绻冮敍 00041a30h: EF BF BD 26 6C 74 3B 2F 65 72 72 6F 72 3E 26 6C ; 锟?lt;/errorl 00041a40h: 74 3B 2F 72 65 73 75 6C 74 3E 3C 2F 6E 73 31 3A ; t;/result/ns1: 00041a50h: 6F 75 74 3E 3C 2F 6E 73 31 3A 75 70 6C 6F 61 64 ; out/ns1:upload 00041a60h: 64 65 76 69 63 65 6D 61 6E 61 67 65 73 6F 6C 64 ; devicemanagesold 00041a70h: 72 65 74 75 72 6E 72 65 63 6F 72 64 73 52 65 73 ; returnrecordsRes 00041a80h: 70 6F 6E 73 65 3E 3C 2F 73 6F 61 70 3A 42 6F 64 ; ponse/soap:Bod 00041a90h: 79 3E 3C 2F 73 6F 61 70 3A 45 6E 76 65 6C 6F 70 ; y/soap:Envelop 00041aa0h: 65 3E ; e HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.9044) Content-Type: text/xml; charsetutf-8 SOAPAction: Host: 222.185.127.216:7003 Content-Length: 609 Expect: 100-continue Connection: Keep-Alive到目前为止我们认为它是 将utf-8的文字gbk编码了一次又再utf-8的输出给客户端当时我就想用java来还原这个过程看看我猜的对不对但是我是在android手机的java环境测试的 ,代码如下结果并没有返回我期望的上传失败企业唯?? 标识码验证不通过??而是“上传失败企业唯一标识码验证不通过?”package com.bosd.javatest; ..//忽略 public class MainActivity extends AppCompatActivity { private AppBarConfiguration appBarConfiguration; private ActivityMainBinding binding; Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); binding ActivityMainBinding.inflate(getLayoutInflater()); setContentView(binding.getRoot()); setSupportActionBar(binding.toolbar); String correctMessage null; try { correctMessage 上传失败企业唯一标识码验证不通过; } catch (Exception e) { } System.out.println(1. 正确的原始消息: correctMessage); byte[] wrongGbkBytes new byte[0]; // 获取正确的 UTF-8 字节 try { wrongGbkBytes correctMessage.getBytes(utf-8); } catch (UnsupportedEncodingException e) { throw new RuntimeException(e); } System.out.println(Original UTF-8 Hex); printHex(wrongGbkBytes); String corruptedString null; try { corruptedString new String(wrongGbkBytes,GBK); System.out.println(After GBK Encode Utf-8 Hex); printHex(corruptedString.getBytes(gbk)); } catch (Exception e) { } System.out.println(2. 服务端错误解读后产生的乱码字符串: corruptedString); byte[] finalBytesSent new byte[0]; try { finalBytesSent corruptedString.getBytes(utf-8); } catch (UnsupportedEncodingException e) { throw new RuntimeException(e); } System.out.println(3. 最终发送给客户端的 UTF-8 字节 (十六进制): ); printHex(finalBytesSent); String whatClientSees null; try { whatClientSees new String(finalBytesSent, utf-8); } catch (UnsupportedEncodingException e) { throw new RuntimeException(e); } System.out.println(4. 客户端最终看到的内容: whatClientSees); byte[] restoredUtf8Bytes new byte[0]; try { restoredUtf8Bytes whatClientSees.getBytes(GBK); } catch (UnsupportedEncodingException e) { throw new RuntimeException(e); } String fixedMessage new String(restoredUtf8Bytes, StandardCharsets.UTF_8); System.out.println(5. 修复后的消息: fixedMessage); try { testprinthex(); } catch (UnsupportedEncodingException e) { throw new RuntimeException(e); } }private static void printHex(byte[] bytes) { for (byte b : bytes) { System.out.printf(%02X , b); } System.out.println(); } } }1. 正确的原始消息: 上传失败企业唯一标识码验证不通过 2026-04-28 15:15:39.989 29708-29708 System.out com.bosd.javatest I Original UTF-8 Hex 2026-04-28 15:15:39.993 29708-29708 System.out com.bosd.javatest I E4 B8 8A E4 BC A0 E5 A4 B1 E8 B4 A5 EF BC 81 E4 BC 81 E4 B8 9A E5 94 AF E4 B8 80 E6 A0 87 E8 AF 86 E7 A0 81 E9 AA 8C E8 AF 81 E4 B8 8D E9 80 9A E8 BF 87 EF BC 81 2026-04-28 15:15:39.995 29708-29708 System.out com.bosd.javatest I After GBK Encode Utf-8 Hex 2026-04-28 15:15:40.000 29708-29708 System.out com.bosd.javatest I E4 B8 8A E4 BC A0 E5 A4 B1 E8 B4 A5 EF BC 81 E4 BC 81 E4 B8 9A E5 94 AF E4 B8 80 E6 A0 87 E8 AF 86 E7 A0 81 E9 AA 8C E8 AF 81 E4 B8 8D E9 80 9A E8 BF 87 EF BC 3F 2026-04-28 15:15:42.102 29708-29708 System.out com.bosd.javatest I €涓? 2026-04-28 15:15:43.054 29708-29708 System.out com.bosd.javatest I 2. 服务端错误解读后产生的乱码字符串: 涓婁紶澶辫触锛佷紒涓氬敮涓€鏍囪瘑鐮侀獙璇佷笉閫氳繃锛 2026-04-28 15:15:43.054 29708-29708 System.out com.bosd.javatest I 3. 最终发送给客户端的 UTF-8 字节 (十六进制): 2026-04-28 15:15:43.062 29708-29708 System.out com.bosd.javatest I E6 B6 93 E5 A9 81 E7 B4 B6 E6 BE B6 E8 BE AB E8 A7 A6 E9 94 9B E4 BD B7 E7 B4 92 E6 B6 93 E6 B0 AC E6 95 AE E6 B6 93 E2 82 AC E9 8F 8D E5 9B AA E7 98 91 E9 90 AE E4 BE 80 E7 8D 99 E7 92 87 E4 BD B7 E7 AC 89 E9 96 AB E6 B0 B3 E7 B9 83 E9 94 9B EF BF BD 2026-04-28 15:15:43.063 29708-29708 System.out com.bosd.javatest I 4. 客户端最终看到的内容: 涓婁紶澶辫触锛佷紒涓氬敮涓€鏍囪瘑鐮侀獙璇佷笉閫氳繃锛 2026-04-28 15:15:43.065 29708-29708 System.out com.bosd.javatest I 5. 修复后的消息: 上传失败企业唯一标识码验证不通过? 2026-04-28 15:15:43.069 29708-29708 System.out com.bosd.javatest I 构造的字节序列: E6 B6 93 E5 A9 81 E7 B4 B6 E6 BE B6 E8 BE AB E8 2026-04-28 15:15:43.071 29708-29708 System.out com.bosd.javatest I A7 A6 E9 94 9B E4 BD B7 E7 B4 92 E6 B6 93 E6 B0 2026-04-28 15:15:43.073 29708-29708 System.out com.bosd.javatest I AC E6 95 AE E9 94 9F E8 8A A5 E7 88 A3 E7 92 87 2026-04-28 15:15:43.075 29708-29708 System.out com.bosd.javatest I E5 97 99 E7 88 9C E6 A5 A0 E5 B2 83 E7 98 89 E6 2026-04-28 15:15:43.077 29708-29708 System.out com.bosd.javatest I B6 93 E5 B6 89 E2 82 AC E6 B0 B3 E7 B9 83 E9 94 2026-04-28 15:15:43.078 29708-29708 System.out com.bosd.javatest I 9B EF BF BD此时事件并没有结束我们只是证明了它用GBK重新编码了UTF-8的中文最后又把它转成UTF-8输出给客户端并没有完全实现好比是确定某人是杀人凶手却没有发现作案工具你说是刀口所至命的那是什么刀小李飞刀还是金丝大环刀呢? 无法在卷宗上结案啊需要继续探究。因为你会发现从信息上传失败企业唯一标识码验证不通过 到 上传失败企业唯??标识码验证不通过?? 没有一个完整性论证我的JAVA代码在中文还原时输出的是 上传失败企业唯一标识码验证不通过?,用了许多方式来调试来调整字符串的拼接也没用好气啊每天都在脑中重复这个过程我试着在头脑中解析这个GBK编码的方式直觉一直告诉我我的方法没有问题测试也没有问题但返回的结果就是不对返复在脑海里重现 解析 一字的 UTF-8编码E4 B8 80,E4 B8 用GBK来读就是涓 0x80GBK没有映射就应该是0xEFBFBD 替换符涓的UTF-8字节码E6 B6 93但Win java 这里却返回了 欧元符号€经过反复的思考后我觉得应该是Windows系统的问题然后我就找到原生Linux Java 平台再次运行我同样的JAVA代码结果不出所料的与我期望的结果一至了我得到了如下输出1. 正确的原始消息: 上传失败企业唯一标识码验证不通过 Original UTF-8 Hex E4 B8 8A E4 BC A0 E5 A4 B1 E8 B4 A5 EF BC 81 E4 BC 81 E4 B8 9A E5 94 AF E4 B8 80 E6 A0 87 E8 AF 86 E7 A0 81 E9 AA 8C E8 AF 81 E4 B8 8D E9 80 9A E8 BF 87 EF BC 81 After GBK Encode Utf-8 Hex E6 B6 93 E5 A9 81 E7 B4 B6 E6 BE B6 E8 BE AB E8 A7 A6 E9 94 9B E4 BD B7 E7 B4 92 E6 B6 93 E6 B0 AC E6 95 AE E6 B6 93 EF BF BD E9 8F 8D E5 9B AA E7 98 91 E9 90 AE E4 BE 80 E7 8D 99 E7 92 87 E4 BD B7 E7 AC 89 E9 96 AB E6 B0 B3 E7 B9 83 E9 94 9B EF BF BD 2. 服务端错误解读后产生的乱码字符串: 涓婁紶澶辫触锛佷紒涓氬敮涓鏍囪瘑鐮侀獙璇佷笉閫氳繃锛 3. 最终发送给客户端的 UTF-8 字节 (十六进制): E6 B6 93 E5 A9 81 E7 B4 B6 E6 BE B6 E8 BE AB E8 A7 A6 E9 94 9B E4 BD B7 E7 B4 92 E6 B6 93 E6 B0 AC E6 95 AE E6 B6 93 EF BF BD E9 8F 8D E5 9B AA E7 98 91 E9 90 AE E4 BE 80 E7 8D 99 E7 92 87 E4 BD B7 E7 AC 89 E9 96 AB E6 B0 B3 E7 B9 83 E9 94 9B EF BF BD 4. 客户端最终看到的内容: 涓婁紶澶辫触锛佷紒涓氬敮涓鏍囪瘑鐮侀獙璇佷笉閫氳繃锛这个结果让我觉得Windows 平台中GBK 编码中有微软自已的实现与扩充比如对于 80 就被映射到了€符号.... 标准JAVA GBK编码并没有这个设定它直接变成不可识别的标志字符串”EFBFBD“, 所以Webservice的平台是非Windows系统的java 标准 GBK 编码实现的真相大白了。这个编码策略的底层平台实现差异违背了 Java WORAWrite Once, Run Anywhere一次编写随处运行的理念微软画蛇添足。但是....第二天我时而翻来复去地在脑海里复现这个过程想来想去发现一个细思极恐的问题我的测试方法好像有问题因为我是在Android手机上运行的程序并没有在windows本身中运行java,那么我的结论还正确吗于是我又在Win 10上用命令行 编译了这段代码并在命令行中运行结果与上面是一至的是我错怪了Windows 冤枉了好人啊于是再用GB18030(国标严格的GBK标准)在手机上运行了一次这回的结果是对的了 说明是Android手机上的GBK有私自扩展将拉丁字符0x80映射过来了可但是 windows api /.net 原生app调用GBK编码的结果同样是被映射的它执行的CodePage936扩展行为也不算冤枉。//下面为android手机中的gbk解码器描述手机兼容了 cp936的行为。corruptedString new String(wrongGbkBytes,gbk); this {CharsetICU5219} icuCanonicalName windows-936-2000 这是android手机中的编码器名子 aliasSet {Collections$UnmodifiableSet5223} aliases [GBK, iso-ir-58, csISO58GB231280, csGB2312, chinese, MS936, GB_2312-80, GB2312, windows-936, CP936]GBK解码时是按双字节读取中文但utf-8是三字节表示中文所以反复编解码会产生字节丢失变成了\uFFFD就不能还原成原来的中文了。这是服务端的webservice错误编码中文所至所以我们客户端现在只能提示上传失败企业唯??标识码验证不通过?? ,哦不 我们手动替换一下吧 手动把错误信息修正.

相关新闻