java socket读xml需解决tcp粘包拆包问题：服务端应加长度头或分隔符，客户端循环读取至完整；解析时须显式指定utf-8编码，避免乱码；dom需等数据收全，sax可边收边解析但characters()可能多次触发。
Java Socket读取XML流时，为什么收不到完整数据
Socket本身不关心内容格式，它只负责收发字节流。XML是结构化文本，必须等完整报文到达才能解析，而TCP可能把一个XML拆成多次送达，或把多个XML粘在一起。常见现象是DocumentBuilder.parse()抛SAXParseException，提示“Premature end of file”或“Content is not allowed in prolog”。
- 别用
BufferedReader.readLine()——XML里可能有换行，且没有行尾标记 - 服务端必须明确约定结束方式：比如固定长度头（4字节表示后续XML字节数），或用特殊分隔符（如
" "），或发送完后主动关闭输出流（仅限单次通信） - 客户端需循环读取直到满足结束条件，不能只调一次
InputStream.read()
用DataInputStream读带长度头的XML流
这是最可控的方式：服务端先写4字节int表示XML长度，再写XML字节；客户端先读4字节，再读指定字节数。避免粘包/拆包干扰，也绕过字符编码猜测问题。
-
DataInputStream.readInt()读长度，注意大小端要和服务端一致（Java默认网络字节序，即大端） - 用
byte[] buffer = new byte[Length]+in.readFully(buffer)确保读满，别用read()返回值判断 - 构造
String时显式指定编码：new String(buffer, StandardCharsets.UTF_8)，XML声明里的encoding属性不可信
int len = dis.readInt(); byte[] xmlBytes = new byte[len]; dis.readFully(xmlBytes); String xmlStr = new String(xmlBytes, StandardCharsets.UTF_8);直接解析Socket输入流的坑：SAX vs DOM
想边收边解析？SAX可以，DOM不行。DOM必须拿到完整字符串或InputStream，而Socket的InputStream在数据未收全时会阻塞或返回-1，导致parse()失败。
- 用
SAXParser.parse(InputStream, DefaultHandler)是安全的——它内部会缓冲，等足够数据才触发事件 - 但 handler 中的
characters()可能被多次调用（因底层读取分片），别假设一次回调就拿到完整文本节点 - 如果必须用DOM，务必等完整XML字节收齐再传给
DocumentBuilder.parse(new ByteArrayInputStream(...))
中文XML解析乱码的典型原因
不是XML声明写了encoding="UTF-8"就万事大吉。Socket传输不带编码信息，jvm按平台默认编码（如windows是GBK）解码字节流，结果一解析就报错“Invalid byte 1 of 1-byte UTF-8 sequence”。
立即学习“Java免费学习笔记（深入）”；
- 服务端写XML前，确认用
OutputStreamWriter(out, StandardCharsets.UTF_8)包装，而不是裸OutputStream - 客户端读取后构建
String时，必须用StandardCharsets.UTF_8，别依赖new String(bytes)的默认行为 - 如果服务端用其他编码（如GBK），客户端必须严格匹配，且XML声明中的
encoding值要同步改
实际中最容易被忽略的是：服务端发完XML后没flush，或者没关流，导致客户端一直卡在read()上。TCP连接不关闭，就没有EOF信号，read()会永远等下去。