stringtokenizer因将分隔符视为无序字符集合且跳过空字段,无法正确解析含混合分隔符(如"a|b||c;d e")的报文;应改用string.split(" [|; ]", -1)或专用解析器。

StringTokenizer 不支持正则或动态定界符,遇到多个不同字符作分隔符时容易漏切、多切或跳过空字段——它只把定界符当“集合”处理,不区分顺序也不保留空项。
为什么 StringTokenizer 会错误切分含混合分隔符的报文
比如原始报文是 "A|B||C;D E"(用 |、;、 混合分隔),传入 new StringTokenizer(line, "|;\t") 后,StringTokenizer 把这串当作“任意一个字符都算分隔符”,且自动跳过连续分隔符之间的空段。结果 "B" 和 "C" 之间那两个 | 只算一次切割,""(空字段)直接消失。
更麻烦的是,它不识别转义、不处理引号包裹字段、不支持回溯——所有这些在真实报文(如 EDI、日志拼接字段)里都很常见。
- 定界符字符串中的每个字符独立生效,
"|;"≠ 正则"\|;",更不等于字面量"|;" - 无法判断某个
|是分隔符还是字段内容(比如字段本身含|但被转义) -
hasMoreTokens()和nextToken()调用顺序错乱会导致NoSuchElementException
替代方案:用 String.split() 处理多分隔符且保留空字段
真正需要“按多个字符或模式切分并保留空项”时,split() 是更可控的选择。关键在正则写法和参数控制:
- 用方括号写字符类:
"[|;\t]"表示匹配任一分隔符(注意要写成\t) - 加负数限制参数保留末尾空字段:
str.split("[|;\t]", -1) - 若需匹配字面量
"|;"这个组合而非单个字符,正则要写成"\|;"(双反斜杠转义)
示例:
Java开发手册规约集合,基于阿里巴巴Java开发手册(嵩山版)。 涵盖7大维度:编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要:(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
String line = "A|B||C;D E";
String[] parts = line.split("[|;\t]", -1);
// 结果:["A", "B", "", "C", "D", "E"] —— 空字段没丢
遇到嵌套结构或带引号字段时必须换解析器
如果报文类似 "name="John|Doe";age=30;city="New York"",即字段含分隔符但被引号包裹,StringTokenizer 和 split() 都无能为力。
- 没有状态机,无法识别引号起止、转义引号(
")、引号内分隔符应忽略 - 真实场景如 CSV、HTTP header、自定义协议报文,建议直接用成熟库
- 轻量选
org.apache.commons.text.StringSubstitutor不合适;推荐opencsv(CsvParser支持自定义分隔符+引号+转义)或手写简易状态循环
手写要点:逐字符扫描,设 inQuotes = false,遇 " 切换状态,状态为真时跳过分隔符判断。
StringTokenizer 唯一适合的场景:简单、固定、无空字段的旧协议
只有当你确认报文满足全部条件时,才考虑用它:每字段非空、分隔符互不相邻、无嵌套/引号/转义、性能敏感且已测出比 split 快(极少见)。
- 典型例子:POSIX shell 的
PATH环境变量(/usr/bin:/bin:/usr/local/bin) - 别在日志解析、配置文件、网络报文中硬套它——看似省事,后续字段错位问题难定位
- JDK 1.0 遗留类,官方文档明确建议优先使用
String.split()或java.util.Scanner
复杂报文的分隔逻辑从来不在“怎么切”,而在于“哪些字符此时算分隔符”——这个判断需要上下文,StringTokenizer 没有上下文。
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










