我将以下字节数组从Java应用程序发送到Vb.Net文件：
byte[] buffer = "<CMD>{§}SETUP US THE BOMB".getBytes("UTF-16LE");
以下是Vb.Net端如何将数组解析为字符串：
Dim result as String = (New System.Text.UnicodeEncoding(False, False)).GetString(buffer)
之后我将结果字符串记录到控制台（字节转储在VB.Net到达时完成）：
HEX: 60 0 67 0 77 0 68 0 62 0 123 0 167 0 125 0 83 0 69 0 84 0 85 0 80 0 32 0 85 0 83 0 32 0 84 0 72 0 69 0 32 0 66 0 79 0 77 0 66 0
STR: <CMD>{§}SETUP US THE BOMB
如果我不使用eclipse并且编码似乎在某种程度上被破坏，则收到的字节数组会有所不同......
HEX: 60 0 67 0 77 0 68 0 62 0 123 0 239 0 191 0 189 0 125 0 83 0 69 0 84 0 85 0 80 0 32 0 85 0 83 0 32 0 84 0 72 0 69 0 32 0 66 0 79 0 77 0 66 0
STR: <CMD>{�}SETUP US THE BOMB
当我从开发代码切换到实际使用代码时，看起来Java端会发生一些事情。
使用Udp传输将字节数组本地发送到Vb.Net应用程序。
我使用普通的java.net.datagramsocket进行通信。
更新
我也尝试从Java中记录数组，因为我认为它可能会有所帮助：
[D] =发展[P] =生产[J] = Java [R] =由Vb.Net收到
[D] [J]：60 0 67 0 77 0 68 0 62 0 123 0 -89 0 125 0 83 0 69 ...
[D] [R]：60 0 67 0 77 0 68 0 62 0 123 0 167 0 125 0 83 0 69 ...
[P] [J]：60 0 67 0 77 0 68 0 62 0 123 0 -17 0 -65 0 -67 0 125 0 83 0 69 ...
[P] [R]：60 0 67 0 77 0 68 0 62 0 123 0 239 0 191 0 189 0 125 0 83 0 69 ...
确实有问题，就好像在发送之前重新编码字符串一样。
答案 0 :(得分：0)
这对于正确的评论来说太长了，但这不是一个真正的答案......
我试图在VB .NET中对字符串进行编码，但我没有和你一样的字节：
Dim buf As Byte()
buf = System.Text.UnicodeEncoding.Unicode.GetBytes("<CMD>{§}SETUP US THE BOMB")
导致：
60 0 67 0 77 0 68 0 62 0 123 0 167 0 125 0 83 0 69 0 84 0 85 0 80 0 32 0 85 0 83 0 32 0 84 0 72 0 69 0 32 0 66 0 79 0 77 0 66 0
而来自Java的缓冲区是：
60 0 67 0 77 0 68 0 62 0 123 0 239 0 191 0 189 0 125 0 83 0 69 0 84 0 85 0 80 0 32 0 85 0 83 0 32 0 84 0 72 0 69 0 32 0 66 0 79 0 77 0 66 0
所以我想说这个问题来自Java编码，因为该字符应该输出为两个六进制数而不是六个...
答案 1 :(得分：0)
我最终确定了这个问题，因为我正在使用一个外部工具（gradle），它不会将我的* .java文件视为UTF-8/16（如eclipse所做），而是作为Latin / windows /其他东西和“§”文字然后没有被转义。
要解决此问题，我必须将“§”转换为“\ u00A7”。
PS。我认为gradle中的一些配置技巧会允许跳过转义但由于我没有完全控制开发环境，所以我没有进一步调查。