如何使用Java的StringTokenizer类_字符串解析的旧版API方案-java教程-PHP中文网

如何使用java的stringtokenizer类_字符串解析的旧版api方案

StringTokenizer 还能用吗？

能用，但不推荐新项目使用——它被标记为 Legacy，Java 官方文档明确说“建议用 String.split() 或 java.util.Scanner 替代”。它不支持正则、不能跳过空 token、不可重用，且 API 设计僵硬。除非维护老代码或嵌入式环境（如某些 Java ME 场景），否则别主动选它。

StringTokenizer 构造时分隔符传错会怎样？

传入空字符串 "" 会直接抛 NullPointerException；传入 null 同样崩。更常见的是误把正则当普通字符：比如想按点号 . 切分 "a.b.c"，却写成 new StringTokenizer("a.b.c", ".")——这其实没问题，因为 StringTokenizer 不走正则，. 就是字面量。但如果你习惯 split("\.")，这里反而容易多加转义，白折腾。

注意这些细节：

StringTokenizer 的分隔符是「字符集合」，不是「分隔字符串」：传 " ,;" 表示空格、逗号、分号任一都切，不是匹配整个子串
默认分隔符是 " "（空格、tab、换行等），且自动忽略首尾空白，中间连续分隔符只算一个
第三个布尔参数 returnDelims 设为 true 时，分隔符本身也会作为 token 返回，但顺序和原始位置不易推断，慎用

nextToken() 调用前不检查 hasMoreTokens() 会崩溃

这是最常踩的坑：nextToken() 遇到末尾直接抛 NoSuchElementException，它不返回 null。不像 Iterator.next() 至少有文档提醒，StringTokenizer 的这个行为非常反直觉。

Gradle 9.8.0

下载

安全写法只有这一种模式：

StringTokenizer st = new StringTokenizer("a,b,c", ",");
while (st.hasMoreTokens()) {
    String token = st.nextToken(); // 此时 guaranteed 安全
    System.out.println(token);
}

别写 if (st.hasMoreTokens()) st.nextToken() 然后接着调第二次——只要没再判，就可能崩。

为什么 split() 比 StringTokenizer 更可靠？

根本差异在语义：前者是「按分隔模式切分字符串」，后者是「按字符集逐个扫描跳过」。这导致几个实际问题：

处理 CSV 类数据时，StringTokenizer 无法区分 "a,,b" 中的空字段（它会返回 "a"、"b"，丢掉中间那个空 token）；而 "a,,b".split(",", -1) 能保留全部三个 token
split() 支持正则，可处理复杂边界，比如 "foo, bar; baz".split("[,;]\s*")
StringTokenizer 是 mutable 对象，不可重用；split() 是无状态纯函数，线程安全
性能上，简单单字符分隔时 StringTokenizer 略快，但现代 JVM 优化后差距微乎其微，不值得为这点吞吐牺牲可维护性