根本原因是直接按字节或char索引截断破坏了utf-8/utf-16中汉字、emoji等字符的编码完整性；解决关键是按unicode码点（code point）截取，使用codepointcount与offsetbycodepoints确保不切断代理对，或借助apache commons lang的stringutils.substring安全处理。
Java 截取指定长度字符串时出现乱码，根本原因是：直接按字节或字符索引截断，破坏了 UTF-8（或其他多字节编码）中汉字、emoji 等字符的编码完整性。解决关键在于——按 Unicode 码点（code point）而非 char（UTF-16 单元）截取，并确保编码一致。
用 codePointCount + offsetByCodePoints 安全截取
Java 的 String 内部用 UTF-16 表示，但一个汉字或 emoji 可能占 1 个或 2 个 char（即代理对）。直接用 substring(0, n) 很容易在代理对中间切断，导致乱码或 。
正确做法是按“逻辑字符”（Unicode code point）计数和定位：
-
str.codePointCount(0, str.length())获取真实字符数（不是length()返回的 char 数） -
str.offsetByCodePoints(0, targetLength)找到截断位置对应的 char 索引 - 再用
substring(0, endIndex)安全截取
示例（截取前 5 个汉字/符号）：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
public static String safeSubstring(String str, int codePointLimit) {
if (str == null || codePointLimit
注意输入输出编码，避免源头乱码
截取只是中间环节；如果原始字符串本身已乱码（比如从 GBK 字节错误解码为 UTF-8），再怎么安全截取也无济于事。
- 读文件时显式指定编码：
new InputStreamReader(new FileInputStream("f.txt"), StandardCharsets.UTF_8) - HTTP 请求响应头检查
Content-Type: text/plain; charset=utf-8 - 控制台输出乱码？确认终端/IDE 控制台编码设为 UTF-8（IntelliJ → Settings → Editor → File Encodings）
简单场景：用 Apache Commons Lang（推荐）
不想手写逻辑？引入 commons-lang3，它内置了按字符数截取且防乱码的方法：
// Maven 依赖 <dependency><groupid>org.apache.commons</groupid><artifactid>commons-lang3</artifactid><version>3.14.0</version></dependency>
然后直接调用：
-
StringUtils.substring("Hello你好?", 0, 5)—— 按字符数截取（自动处理代理对） -
StringUtils.abbreviate("超长文本…", 10)—— 带省略号的安全截断
额外提醒：JSON 和数据库字段长度限制
很多乱码问题实际发生在存储或传输后：
- MySQL
VARCHAR(10)在utf8mb4下最多存 10 个字符（含 emoji），但若应用层按字节截取就可能超限或截断不完整 - JSON 序列化时，Jackson 默认正确处理 Unicode；但若手动拼接 JSON 字符串并错误截取，会破坏双引号或转义结构
- 建议：入库/发 JSON 前，统一用上述 codePoint 方式校验或截断长度
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
