Java中String以UTF-16存储，网络传输必须显式编码为字节（如getBytes("UTF-8")）并用相同编码解码，否则中文必乱码；不同编码影响中文字节数与兼容性。

Java 中字符编码与网络传输的关系，核心在于“String 是 Unicode，而网络只传字节”。必须显式完成编码（String → byte[]）和解码（byte[] → String），否则中文极易乱码。

字符编码是网络传输的必经转换环节

Java 内存中 String 默认按 UTF-16 存储，但 TCP/UDP 等底层协议只收发原始字节流。发送前不指定编码，就会调用系统默认 Charset（如 Windows 中可能是 GBK，Linux 多为 UTF-8），接收端若用不同编码解析，必然错乱。

• 发送端必须明确调用 str.getBytes("UTF-8")，不能依赖无参 getBytes()
• 接收端必须用相同编码还原：new String(bytes, 0, len, "UTF-8")
• HTTP 协议头、JSON 字符串、自定义协议报文，都需在文档或约定中固定编码格式

常见编码选择与实际影响

不同编码对中文占用字节数不同，直接影响传输效率与兼容性：

Java调试

通过 JDWP 实现 Java 远程调试：连接远程 JVM、设置断点、单步执行代码、查看变量值、获取调用栈。适用于需要调试远程 Java 应用、排查运行时状态、追踪代码执行流程的场景。 术语注解 JDWP：Java Debug Wire Protocol，Java 调试有线协议（Java 远程调试底层通信协议） remote JVM：远程 Java 虚拟机 step through code：代码单步调试（步入 / 步过 / 步出调试） inspect variables：变量查看 / 变量检视 stac

下载

• UTF-8：中文占 3 字节，兼容 ASCII，跨平台安全，现代系统首选
• GBK：中文占 2 字节，国内旧系统常见，但无法表示生僻字或 emoji
• ISO-8859-1：单字节，不能表示中文；常被误用于“透传”场景（如先用它解出乱码字节再转 UTF-8），但属权宜之计，易出错

对象传输也绕不开编码问题

即使传输的是 Student、Order 等对象，只要走文本协议（如 JSON、XML、表单），就仍需编码：

• JSON 库（如 Jackson、Gson）默认输出 UTF-8 字节，但写入 Socket 前仍要确认 OutputStream 是否被包装为 OutputStreamWriter 并指定了 UTF-8
• 若用 DataOutputStream 直接 writeUTF()，它内部用的是 Modified UTF-8，与标准 UTF-8 不完全等价，服务端需对应处理
• 二进制序列化（如 Java Serializable）虽不显式编码，但依赖 JVM 版本和类结构一致性，生产环境不推荐

调试乱码的关键检查点

出现中文显示为问号、方块或异常符号时，逐项核对：

• 发送端 getBytes(...) 用的什么编码？是否硬编码为 "UTF-8"？
• 接收端 new String(...) 的编码参数是否与发送端严格一致？
• Socket 输入流是否被 InputStreamReader 包装？其构造参数是否传了 Charset？
• 抓包查看原始字节（如 Wireshark 或打印十六进制），确认发送内容本身是否已损坏

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南