根本原因是直接按字节或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 个汉字/符号):
立即学习“Java免费学习笔记(深入)”;
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
public static String safeSubstring(String str, int codePointLimit) {
if (str == null || codePointLimit <= 0) return "";
int len = str.length();
int codePointLen = str.codePointCount(0, len);
if (codePointLen <= codePointLimit) return str;
int endIndex = str.offsetByCodePoints(0, codePointLimit);
return str.substring(0, endIndex);
}
// safeSubstring("Hello你好?", 5) → "Hello你好"
注意输入输出编码,避免源头乱码
截取只是中间环节;如果原始字符串本身已乱码(比如从 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 方式校验或截断长度

















