Java BreakIterator 怎样按本地化规则拆分用户可见字符

如果 Java 界面需要“最多显示 N 个字符”，不要直接把 String.length() 或 substring(0, N) 当成用户看到的字符数。Java 的字符串按 UTF-16 存储，一个 emoji、组合音标或连接序列可能跨越多个 char。更稳妥的做法是使用 BreakIterator.getCharacterInstance(locale)，按字符边界逐段前进，再在边界处截断。

Oracle Java API 地址：https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/text/BreakIterator.html

真正要保护的是用户看到的字符完整性：把数字当作“字符数”之前，先确认它代表 UTF-16 单元、Unicode 码点，还是扩展字素簇的数量。

先分清三种长度

String.length() 返回 UTF-16 char 单元数量；codePointCount() 统计 Unicode 码点数量；而用户界面通常需要的是用户感知的字符边界。组合音标、旗帜或家庭 emoji 可能由多个码点组成，逐个码点截断也可能把一个视觉单元拆开。

Oracle 的 API 说明把字符边界分析定位为用户移动光标等交互所需的行为，默认实现遵循 Unicode 扩展字素簇边界。这个语义正适合做 UI 文本的遍历和截断，但不应扩展成编程语言词法分析器。

用字符实例遍历完整片段

先按实际界面语言选择 Locale，再创建字符级迭代器。first() 把当前位置放到开头，后续每次 next() 返回下一个边界；当前边界和下一个边界之间的区间才是要交给 substring 的安全片段。

import java.text.BreakIterator;
import java.util.ArrayList;
import java.util.List;
import java.util.Locale;

public final class VisibleCharacters {
    private VisibleCharacters() {
        // 工具类不需要被实例化
    }

    public static List split(String text, Locale locale) {
        BreakIterator iterator = BreakIterator.getCharacterInstance(locale);
        iterator.setText(text);

        List result = new ArrayList();
        int start = iterator.first();
        for (int end = iterator.next(); end != BreakIterator.DONE; end = iterator.next()) {
            // 只在迭代器返回的边界处切片，避免切入组合序列
            result.add(text.substring(start, end));
            start = end;
        }
        return result;
    }

    public static void main(String[] args) {
        String text = "A🇨🇳e\u0301👨‍👩‍👧‍👦开发";
        List pieces = split(text, Locale.SIMPLIFIED_CHINESE);

        // 逐段打印只是观察边界，不把每段当成一个 UTF-16 char
        for (String piece : pieces) {
            System.out.println("片段=" + piece + ", utf16Units=" + piece.length());
        }
    }
}

这里的 start 和 end 仍然是 Java 字符串下标，但它们来自字符边界迭代器，所以 substring(start, end) 不会随意落在扩展字素簇中。列表中的元素才是更接近用户“看到一个字符”的单位。

封装按用户可见字符数截断

实际项目通常不需要先生成完整列表，而是边走边数，达到上限后立即在最后一个完整边界返回。下面的方法保留前 limit 个字符片段；如果上限超过文本中的片段数，就直接返回原文本。

import java.text.BreakIterator;
import java.util.Locale;

public final class UiText {
    private UiText() {
        // 工具类不需要公开构造器
    }

    public static String takeVisible(String text, int limit, Locale locale) {
        if (text == null || text.isEmpty() || limit 

如果业务还要追加省略号，应把省略号作为显示策略单独处理，例如先为它预留一个字符额度，再把完整片段交给 substring。不要先截断再尝试修补半个 emoji，因为此时已经丢失了原始边界信息。

Locale 选择和边界参数要明确

getCharacterInstance(locale) 需要一个非空的 Locale。界面有明确语言环境时，优先传入该环境，而不是让默认 Locale 随服务器进程或请求线程变化。对于跨语言内容，可以把 Locale 作为调用方参数传入，避免在工具方法内部偷偷读取全局状态。

• 空文本：直接返回空字符串，避免对迭代器做无意义扫描。
• 上限小于等于零：把它定义为不展示文本；如果业务要拒绝该参数，应在外层抛出明确异常。
• 上限超过文本长度：遍历到 DONE 后返回完整原文，不要用空格或零值补齐。
• 边界索引：following(offset)、preceding(offset) 等方法接收的是文本下标，越界会抛出 IllegalArgumentException，不能把用户可见字符序号直接传进去。
• 适用范围：BreakIterator 的工厂实例面向自然语言文本；源码标识符、协议字段等编程语言 token 需要另一套词法规则。

把错误切分路径挡在代码审查之外

在安全威胁建模的视角里，资产不是秘密数据，而是“用户看到的字符必须保持完整”。最危险的路径通常是把一个外部传入的显示上限直接当作 substring 的 UTF-16 终点。它可能导致乱码、孤立代理项或组合音标脱离基础字符，随后又被日志、缓存和 UI 层放大。

这类控制的重点不是把所有字符串操作都替换成 BreakIterator，而是只在“字符数会影响用户界面完整性”的边界使用它。协议长度、数据库字节限制和存储字段截断仍然要按各自的编码和单位设计。

回归清单

1. 加入普通拉丁字母、中文和数字，确认每个片段都能按边界拼回原文。
2. 加入补充平面 emoji，确认它没有被拆成两个代理项。
3. 加入组合音标，确认基础字符和音标不会在截断点分离。
4. 加入连接序列和旗帜 emoji，按产品支持范围确认完整性预期。
5. 使用至少两个 Locale 调用同一方法，确认 Locale 从调用方明确传入。
6. 覆盖空文本、零上限、负上限、上限大于文本片段数和空 Locale 参数策略。

最终可以把 BreakIterator 看成一条边界防线：它不替你决定 UI 应该显示多少内容，却能保证“显示 N 个字符”这个决定在合法的用户可见边界上执行。只要把计数变量和下标变量分开命名，后续的省略号、分页标题和输入框预览都更容易保持一致。

常见问题

为什么不用 String.length()？

因为它统计 UTF-16 单元，不是用户可见字符。补充平面字符可能占两个单元，组合序列还可能包含更多码点。

codePointCount() 能完全替代 BreakIterator 吗？

不能。码点数量比 UTF-16 单元更接近 Unicode 字符，但仍不等于扩展字素簇或用户看到的字符数量。

Locale 改变后每个字符边界都会改变吗？

不一定。它提供本地化字符边界分析所需的环境，具体边界仍由 Java 实现的规则和文本决定，不能假设只换 Locale 就会得到固定数量。

BreakIterator 返回的是字符还是下标？

迭代方法返回的是文本边界下标。两个相邻边界之间的 substring 片段才是本次遍历得到的字符边界单元。

依据：Oracle Java SE 26 BreakIterator API 文档。本文示例只讨论自然语言 UI 文本的字符边界和安全截断，不把它当作编程语言分词器或字节长度计算器。