Java StringCharacterIterator 的结束哨兵为什么不是null

我第一次用 StringCharacterIterator 时，最容易误判的地方就是“遍历结束为什么不是 null”。答案其实很直接：它实现的是 CharacterIterator，而这些读取方法返回类型是基本类型 char，char 没有 null 这个值。API 统一使用 CharacterIterator.DONE 作为范围外哨兵，它的值是 \uFFFF。

不要把结束条件写成“返回值等于 null”，而要把 char 和 CharacterIterator.DONE 放在同一个协议里理解：有效字符来自 [beginIndex, endIndex)，到达 endIndex 后返回 DONE。

官方地址：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/text/StringCharacterIterator.html

为什么 char 哨兵不能用 null

StringCharacterIterator.current()、first()、last()、next() 和 previous() 的返回类型都是 char。这是 Java 的 16 位基本类型，不是对象引用，所以既不能返回 null，也不能通过装箱把“没有字符”混进正常的返回协议。

更不能随便约定 '\0' 代表结束，因为空字符本身可以出现在 Java 字符串中。CharacterIterator.DONE 选择的是 \uFFFF，官方接口把它描述为“not a character”值：它不是有效 Unicode 字符串中应出现的字符，因此适合承担哨兵角色。这里的重点是协议约定，而不是把它当成一个可以写回文本的普通字符。

这也解释了为什么判断式应写成 c != CharacterIterator.DONE，而不是比较字符串、对象或 null。

先看懂它的索引范围

StringCharacterIterator 使用半开区间。getBeginIndex() 是起点，最后一个可读取字符的索引是 getEndIndex() - 1，而 getEndIndex() 自身仍是一个允许设置的当前位置。这个设计让空范围也有明确表示：当 begin 和 end 相等时，当前位置可以停在 end，但读取结果是 DONE。

因此，下面这些位置的含义不同：endIndex - 1 可能对应真实字符；endIndex 是边界位置；在边界位置调用 current() 或继续向前移动时，返回的是 DONE，而不是一个“空的字符对象”。

用 DONE 写出不依赖 null 的遍历

前向遍历最稳妥的写法是让迭代器自己返回哨兵，并在循环条件中比较 CharacterIterator.DONE。这比手工维护字符串长度更贴合接口，也能自然覆盖空文本。

import java.text.CharacterIterator;
import java.text.StringCharacterIterator;

public class ForwardWalk {
    public static void printCharacters(String text) {
        // 迭代器保存当前索引，读取方法返回的是 char 而不是 Character 引用。
        CharacterIterator iterator = new StringCharacterIterator(text);

        // first() 会把位置放到 beginIndex；空文本会直接返回 DONE。
        for (char c = iterator.first();
             c != CharacterIterator.DONE;
             c = iterator.next()) {
            // 这里只处理有效范围内的字符，DONE 不会被当成正文输出。
            System.out.println(c);
        }

        // 循环结束时，当前位置已经落在 endIndex，便于继续读取边界信息。
        System.out.println("endIndex=" + iterator.getEndIndex());
    }
}

反向遍历同理：last() 从最后一个字符开始，空文本或退到 beginIndex 时返回 DONE。需要注意，previous() 在起点不会把索引减到 beginIndex 之外；它会保持边界位置并返回哨兵。

import java.text.CharacterIterator;
import java.text.StringCharacterIterator;

public class BackwardWalk {
    public static void printBackwards(String text) {
        // last() 对非空文本定位到 endIndex - 1，对空文本返回 DONE。
        CharacterIterator iterator = new StringCharacterIterator(text);

        for (char c = iterator.last();
             c != CharacterIterator.DONE;
             c = iterator.previous()) {
            // 反向读取仍然只消费真实字符，不把边界哨兵当作数据。
            System.out.println(c);
        }
    }
}

子范围和 UTF-16 边界要单独留意

构造器可以接收 begin、end 和 pos，所以它不一定遍历整个字符串。比如只遍历中间片段时，DONE 表示“到达这次迭代的 end”，不是“到达原字符串的 length”。任何调用 setIndex() 的位置都必须落在 begin 到 end 的闭区间内，超出范围会抛出 IllegalArgumentException。

还有一个经常被忽略的边界：这里的“字符”是 Java char，本质上是 UTF-16 code unit。补充平面字符可能由两个 char 组成，迭代器会分别经过这两个单元；它不会自动把它们组合成一个 Unicode code point。如果业务按用户感知的字符计数或截取，应改用 codePoints()、Character.codePointAt() 等面向 code point 的 API，而不是把一次 next() 当成一个完整汉字、表情或其他视觉字符。

把几个边界记成一张速查表

所以，Java StringCharacterIterator 的结束哨兵不是 null，不是遗漏，也不是异常结果，而是由接口返回类型和历史协议共同决定的 char 常量。把结束条件写成 DONE，并始终把 endIndex 当作“最后字符之后的位置”，遍历逻辑就不会被空文本、子范围或 UTF-16 边界带偏。

相关问题

StringCharacterIterator 的 endIndex 能读取到字符吗？

不能把它当作字符索引读取。它是最后一个字符之后的位置，允许作为当前索引存在，但读取方法在这里返回 DONE。

为什么不用字符串长度判断 next() 是否结束？

完整字符串时可以用长度辅助判断，但子范围迭代还要考虑 begin 和 end；直接遵守 CharacterIterator 的 DONE 协议更不容易把原字符串边界误当成当前范围边界。

DONE 会不会和真实文本冲突？

接口把 DONE 定义为 \uFFFF 这个“not a character”值。业务代码仍应把它只当作迭代协议的哨兵，不要把它写入正文或把它当成普通字符参与业务处理。