一个字符是几个字？3个避坑指南教你写出最佳实践
刚接手一个老项目，复制了一段处理中文文本的代码，结果在 Java 8 环境下跑不通，报错信息模棱两可，让人抓狂。这种“复制来的代码跑不通不知道怎么调”的困境，在开发圈太常见了。很多人以为“一个字符”就是“一个字”，但在不同编码和语言环境下，这个认知往往导致内存溢出或数据截断。今天不讲虚的，直接上硬货，通过一个实战项目，拆解“一个字符是几个字”背后的内存布局真相，分享一套经过生产环境验证的最佳实践，帮你彻底搞懂这块坑，下次遇到类似问题，3分钟就能定位。
项目目标：从混乱到清晰的字符认知
很多开发者对字符大小的认知停留在“ASCII 码占 1 字节”的层面，这在大厂高并发、多语言混合业务中是致命的。本项目旨在构建一个可视化工具，输入任意字符串，输出其在 Java、JavaScript、Python 等不同环境下的实际内存占用，并自动识别潜在的数据截断风险。
我们设定三个核心目标：精确计算：区分 char、String、byte[] 在不同编码（UTF-8, GBK, ISO-8859-1）下的字节数。
可视化对比：直观展示 ASCII 字符、中文汉字、Emoji 表情在内存中的差异。
实战落地：提供可直接集成到后端服务的工具类，避免硬编码导致的 Bug。为什么这个工具重要？因为在数据库字段长度限制、Redis 缓存 Key 生成、日志切割场景中，一旦搞错字符与字节的换算，轻则数据截断，重则服务崩溃。
目录结构：模块化设计确保可维护性
为了保持代码的整洁和可复用性，我们采用标准的 Maven 多模块结构。以下是核心目录规划：
char-byte-calculator/
├── src/
│ ├── main/
│ │ ├── java/com/example/calculator/
│ │ │ ├── CharByteCalculator.java # 核心计算逻辑
│ │ │ ├── EncodingHelper.java # 编码转换辅助类
│ │ │ ├── model/
│ │ │ │ └── ByteInfo.java # 结果数据模型
│ │ │ └── controller/
│ │ │ └── CalcController.java # REST API 接口
│ │ └── resources/
│ │ └── application.yml # 配置文件
│ └── test/
│ └── java/com/example/calculator/
│ └── CharByteCalculatorTest.java # 单元测试
├── pom.xml
└── README.md设计思路说明：CharByteCalculator：核心引擎，不依赖 Spring 上下文，便于在其他非 Spring 项目中复用。
EncodingHelper：封装了各种编码的转换逻辑，避免在核心类中出现大量 if-else。
ByteInfo：统一的数据返回结构，包含原始字符串、字节数组、不同编码下的长度等字段。这种结构符合“高内聚低耦合”原则，后续如果增加新的编码支持，只需修改 EncodingHelper，无需改动核心计算逻辑。
核心代码实现：逐行解析内存布局
这是本项目的灵魂部分。我们将重点讲解 Java 中字符串内存占用的计算逻辑，因为 Java 是后端开发的主力语言，其 String 内部结构（char[] 或 byte[]，取决于 JDK 版本）极具代表性。
1. 核心计算类 CharByteCalculator.java
package com.example.calculator;import java.nio.charset.Charset;
import java.util.HashMap;
import java.util.Map;/*** 字符与字节换算核心计算器* 注意：Java 9+ 的 String 内部使用 byte[] 存储 (Latin-1 或 UTF-16)* Java 8 及以下使用 char[] 存储 (UTF-16)*/
public class CharByteCalculator {private static final MapString, Charset CHARSET_MAP = new HashMap();static {// 预加载常用编码，避免重复创建 Charset 对象CHARSET_MAP.put(UTF-8, Charset.forName(UTF-8));CHARSET_MAP.put(GBK, Charset.forName(GBK));CHARSET_MAP.put(ISO-8859-1, Charset.forName(ISO-8859-1));CHARSET_MAP.put(UTF-16, Charset.forName(UTF-16));}/*** 计算字符串在指定编码下的字节长度* @param input 输入字符串* @param encoding 编码名称，如 UTF-8* @return 字节长度*/public int calculateByteLength(String input, String encoding) {if (input == null || input.isEmpty()) {return 0;}Charset charset = CHARSET_MAP.get(encoding.toUpperCase());if (charset == null) {// 如果未预加载，动态获取，防止 NPEcharset = Charset.forName(encoding);}// 关键步骤：将字符串转换为指定编码的字节数组// 这一步会触发实际的编码转换，耗时相对较多byte[] bytes = input.getBytes(charset);return bytes.length;}/*** 分析单个字符的内存占用* 用于教学和理解，生产环境建议直接算总字节* @param charObj 单个字符* @return 该字符在 UTF-8 下占用的字节数*/public int getCharUTF8Size(char charObj) {String str = String.valueOf(charObj);return str.getBytes(Charset.forName(UTF-8)).length;}/*** 判断字符串是否包含非 ASCII 字符* 用于快速判断是否需要复杂的编码处理*/public boolean containsNonAscii(String input) {if (input == null) return false;for (char c : input.toCharArray()) {if (c 127) {return true;}}return false;}
}代码深度解析：Charset 缓存：Charset.forName() 内部有缓存机制，但在高频调用场景下，预加载常用编码到 Map 中可以减少哈希查找开销。
getBytes() 的性能陷阱：这是最耗时的操作。它不是简单的数学计算，而是遍历每个字符，查表或执行算法进行编码转换。在处理 GB 级大文本时，必须考虑分片处理。
ASCII 判断：c 127 是一个快速过滤手段。如果全是 ASCII，UTF-8 下 1 字符=1 字节；如果包含中文，UTF-8 下 1 汉字=3 字节，1 个 Emoji 可能=4 字节。2. 数据模型 ByteInfo.java
package com.example.calculator.model;import lombok.Data;
import lombok.AllArgsConstructor;
import lombok.NoArgsConstructor;@Data
@AllArgsConstructor
@NoArgsConstructor
public class ByteInfo {private String originalString;private int charLength; // 字符个数private int utf8Bytes; // UTF-8 编码字节数private int gbkBytes; // GBK 编码字节数private int utf16Bytes; // UTF-16 编码字节数 (Java内部)private boolean hasNonAscii; // 是否包含非ASCII字符
}运行与测试：验证最佳实践的有效性
代码写得再好，不跑测试都是空谈。我们使用 JUnit 5 编写单元测试，覆盖边界情况。
1. 测试用例 CharByteCalculatorTest.java
package com.example.calculator;import com.example.calculator.model.ByteInfo;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;class CharByteCalculatorTest {private CharByteCalculator calculator;@BeforeEachvoid setUp() {calculator = new CharByteCalculator();}@Testvoid testAsciiString() {// 场景1：纯 ASCII 字符串 HelloString input = Hello;int utf8Len = calculator.calculateByteLength(input, UTF-8);int gbkLen = calculator.calculateByteLength(input, GBK);// 最佳实践：ASCII 在 UTF-8 和 GBK 下都是 1 字节/字符assertEquals(5, utf8Len);assertEquals(5, gbkLen);assertFalse(calculator.containsNonAscii(input));}@Testvoid testChineseString() {// 场景2：中文字符串 你好String input = 你好;int utf8Len = calculator.calculateByteLength(input, UTF-8);int gbkLen = calculator.calculateByteLength(input, GBK);int utf16Len = calculator.calculateByteLength(input, UTF-16);// UTF-8: 每个汉字 3 字节 - 2 * 3 = 6assertEquals(6, utf8Len);// GBK: 每个汉字 2 字节 - 2 * 2 = 4assertEquals(4, gbkLen);// UTF-16: 每个汉字 2 字节 - 2 * 2 = 4 (BOM 除外，Java getBytes 默认不带 BOM)assertEquals(4, utf16Len);assertTrue(calculator.containsNonAscii(input));}@Testvoid testEmojiString() {// 场景3：Emoji 字符串 😀String input = 😀;int utf8Len = calculator.calculateByteLength(input, UTF-8);int utf16Len = calculator.calculateByteLength(input, UTF-16);// UTF-8: 4 字节assertEquals(4, utf8Len);// UTF-16: 2 个字符 (Surrogate Pair) - 4 字节// 注意：Java 中 emoji 占用 2 个 charassertEquals(4, utf16Len);}
}2. 常见坑点复现
在实际调试中，我发现一个高频错误：在 MySQL 中定义字段为 VARCHAR(100)，以为能存 100 个汉字，结果报错 Data too long for column。
原因分析：如果表字符集是 utf8mb4，1 个汉字占 3 字节（MySQL 5.5+ 的 utf8 其实是 utf8mb3，最高 3 字节；utf8mb4 最高 4 字节）。
VARCHAR(100) 指的是字符数，不是字节数。但在某些旧版本驱动或特定连接配置下，可能会混淆。
真正的坑：如果在 Java 代码中手动计算字节数，并试图用 substring 按字节截断，而没有考虑多字节字符的边界，会导致乱码或异常。解决方案：
永远使用 String.substring() 按字符截断，而不是按字节。如果需要按字节截断（如某些底层协议要求），必须使用 InputStream 或 ByteBuffer 并处理多字节边界。
优化扩展：应对高并发与大文本
在基础版本运行稳定后，我们需要考虑生产环境的性能挑战。
1. 大文本分片处理
如果输入字符串超过 10MB，一次性调用 getBytes() 会导致堆内存飙升。我们引入分片策略：
public long calculateLargeTextByteLength(String input, String encoding, int chunkSize) {if (input == null || input.isEmpty()) return 0;int totalBytes = 0;int len = input.length();Charset charset = CHARSET_MAP.get(encoding.toUpperCase());for (int i = 0; i len; i += chunkSize) {int end = Math.min(i + chunkSize, len);// 关键：substring 会产生新字符串对象，频繁调用需优化// 优化方案：使用 StringBuilder 或直接处理 char[]String sub = input.substring(i, end);totalBytes += sub.getBytes(charset).length;}return totalBytes;
}优化建议：如果内存允许，直接操作 char[] 或 byte[]，避免 String 对象的频繁创建。
使用 Unsafe 类（谨慎使用）或 ByteBuffer 进行零拷贝操作。2. 多语言支持扩展
除了 Java，我们还需要支持 JavaScript 和 Python 的对比。
JavaScript 差异：JS 的 String.length 返回的是 UTF-16 代码单元的数量。
一个 Emoji 在 JS 中 length 为 2。
要获取真实字符数，需使用 Array.from(str).length 或 [...str].length。Python 差异：Python 3 的 str 是 Unicode 序列。
len(str) 返回字符数。
sys.getsizeof(str) 返回内存占用，但包含对象头开销，不纯粹是编码字节数。
要获取编码字节数，需 len(str.encode('utf-8'))。对比表格：特性
Java (UTF-8)
JavaScript (UTF-16)
Python 3 (UTF-8)A 长度
1 字节
1 字节 (length: 1)
1 字节中 长度
3 字节
2 字节 (length: 1)
3 字节😀 长度
4 字节
4 字节 (length: 2)
4 字节内部存储
char[] (JDK8) / byte[] (JDK9+)
UTF-16 序列
UCS-2 / UTF-16 / UTF-32 自适应这个表格可以直接放在博客中，帮助读者快速建立跨语言认知。在 CSDN 等社区的技术分享中，这类对比表格通常能获得较高的收藏率，因为它解决了多语言团队协同时的沟通障碍。
小结：从字符到字节的思维跃迁
回到最初的问题：“一个字符是几个字？”答案并不是固定的数字，而是取决于编码方式、语言环境和字符类型。ASCII 字符：在 UTF-8、GBK、ISO-8859-1 下通常都是 1 字节。
中文汉字：UTF-8 下 3 字节，GBK 下 2 字节，UTF-16 下 2 字节。
Emoji：UTF-8 下 4 字节，UTF-16 下 2 个字符（4 字节）。最佳实践总结：不要假设：永远不要假设 1 字符 = 1 字节，除非你确定是纯 ASCII。
统一编码：全链路统一使用 UTF-8，减少转换开销和歧义。
按字符截断：业务逻辑中尽量按字符数截断，避免字节截断导致的乱码。
工具化：将字符计算逻辑封装成工具类，并在单元测试中覆盖多语言、多表情场景。这个知识点看似基础，但在处理国际化业务、日志系统、数据库存储时，往往是隐藏的 Bug 源头。很多资深工程师也会在这里翻车，因为经验主义让我们忽略了编码的多样性。
这个知识点你面试被问过吗？留言说说 一个字符是几个字？3个避坑指南教你写出最佳实践
一个字符是几个字？3个避坑指南教你写出最佳实践
刚接手一个老项目，复制了一段处理中文文本的代码，结果在 Java 8 环境下跑不通，报错信息模棱两可，让人抓狂。这种“复制来的代码跑不通不知道怎么调”的困境，在开发圈太常见了。很多人以为“一个字符”就是“一个字”，但在不同编码和语言环境下，这个认知往往导致内存溢出或数据截断。今天不讲虚的，直接上硬货，通过一个实战项目，拆解“一个字符是几个字”背后的内存布局真相，分享一套经过生产环境验证的最佳实践，帮你彻底搞懂这块坑，下次遇到类似问题，3分钟就能定位。
项目目标：从混乱到清晰的字符认知
很多开发者对字符大小的认知停留在“ASCII 码占 1 字节”的层面，这在大厂高并发、多语言混合业务中是致命的。本项目旨在构建一个可视化工具，输入任意字符串，输出其在 Java、JavaScript、Python 等不同环境下的实际内存占用，并自动识别潜在的数据截断风险。
我们设定三个核心目标：精确计算：区分 char、String、byte[] 在不同编码（UTF-8, GBK, ISO-8859-1）下的字节数。
可视化对比：直观展示 ASCII 字符、中文汉字、Emoji 表情在内存中的差异。
实战落地：提供可直接集成到后端服务的工具类，避免硬编码导致的 Bug。为什么这个工具重要？因为在数据库字段长度限制、Redis 缓存 Key 生成、日志切割场景中，一旦搞错字符与字节的换算，轻则数据截断，重则服务崩溃。
目录结构：模块化设计确保可维护性
为了保持代码的整洁和可复用性，我们采用标准的 Maven 多模块结构。以下是核心目录规划：
char-byte-calculator/
├── src/
│ ├── main/
│ │ ├── java/com/example/calculator/
│ │ │ ├── CharByteCalculator.java # 核心计算逻辑
│ │ │ ├── EncodingHelper.java # 编码转换辅助类
│ │ │ ├── model/
│ │ │ │ └── ByteInfo.java # 结果数据模型
│ │ │ └── controller/
│ │ │ └── CalcController.java # REST API 接口
│ │ └── resources/
│ │ └── application.yml # 配置文件
│ └── test/
│ └── java/com/example/calculator/
│ └── CharByteCalculatorTest.java # 单元测试
├── pom.xml
└── README.md设计思路说明：CharByteCalculator：核心引擎，不依赖 Spring 上下文，便于在其他非 Spring 项目中复用。
EncodingHelper：封装了各种编码的转换逻辑，避免在核心类中出现大量 if-else。
ByteInfo：统一的数据返回结构，包含原始字符串、字节数组、不同编码下的长度等字段。这种结构符合“高内聚低耦合”原则，后续如果增加新的编码支持，只需修改 EncodingHelper，无需改动核心计算逻辑。
核心代码实现：逐行解析内存布局
这是本项目的灵魂部分。我们将重点讲解 Java 中字符串内存占用的计算逻辑，因为 Java 是后端开发的主力语言，其 String 内部结构（char[] 或 byte[]，取决于 JDK 版本）极具代表性。
1. 核心计算类 CharByteCalculator.java
package com.example.calculator;import java.nio.charset.Charset;
import java.util.HashMap;
import java.util.Map;/*** 字符与字节换算核心计算器* 注意：Java 9+ 的 String 内部使用 byte[] 存储 (Latin-1 或 UTF-16)* Java 8 及以下使用 char[] 存储 (UTF-16)*/
public class CharByteCalculator {private static final MapString, Charset CHARSET_MAP = new HashMap();static {// 预加载常用编码，避免重复创建 Charset 对象CHARSET_MAP.put(UTF-8, Charset.forName(UTF-8));CHARSET_MAP.put(GBK, Charset.forName(GBK));CHARSET_MAP.put(ISO-8859-1, Charset.forName(ISO-8859-1));CHARSET_MAP.put(UTF-16, Charset.forName(UTF-16));}/*** 计算字符串在指定编码下的字节长度* @param input 输入字符串* @param encoding 编码名称，如 UTF-8* @return 字节长度*/public int calculateByteLength(String input, String encoding) {if (input == null || input.isEmpty()) {return 0;}Charset charset = CHARSET_MAP.get(encoding.toUpperCase());if (charset == null) {// 如果未预加载，动态获取，防止 NPEcharset = Charset.forName(encoding);}// 关键步骤：将字符串转换为指定编码的字节数组// 这一步会触发实际的编码转换，耗时相对较多byte[] bytes = input.getBytes(charset);return bytes.length;}/*** 分析单个字符的内存占用* 用于教学和理解，生产环境建议直接算总字节* @param charObj 单个字符* @return 该字符在 UTF-8 下占用的字节数*/public int getCharUTF8Size(char charObj) {String str = String.valueOf(charObj);return str.getBytes(Charset.forName(UTF-8)).length;}/*** 判断字符串是否包含非 ASCII 字符* 用于快速判断是否需要复杂的编码处理*/public boolean containsNonAscii(String input) {if (input == null) return false;for (char c : input.toCharArray()) {if (c 127) {return true;}}return false;}
}代码深度解析：Charset 缓存：Charset.forName() 内部有缓存机制，但在高频调用场景下，预加载常用编码到 Map 中可以减少哈希查找开销。
getBytes() 的性能陷阱：这是最耗时的操作。它不是简单的数学计算，而是遍历每个字符，查表或执行算法进行编码转换。在处理 GB 级大文本时，必须考虑分片处理。
ASCII 判断：c 127 是一个快速过滤手段。如果全是 ASCII，UTF-8 下 1 字符=1 字节；如果包含中文，UTF-8 下 1 汉字=3 字节，1 个 Emoji 可能=4 字节。2. 数据模型 ByteInfo.java
package com.example.calculator.model;import lombok.Data;
import lombok.AllArgsConstructor;
import lombok.NoArgsConstructor;@Data
@AllArgsConstructor
@NoArgsConstructor
public class ByteInfo {private String originalString;private int charLength; // 字符个数private int utf8Bytes; // UTF-8 编码字节数private int gbkBytes; // GBK 编码字节数private int utf16Bytes; // UTF-16 编码字节数 (Java内部)private boolean hasNonAscii; // 是否包含非ASCII字符
}运行与测试：验证最佳实践的有效性
代码写得再好，不跑测试都是空谈。我们使用 JUnit 5 编写单元测试，覆盖边界情况。
1. 测试用例 CharByteCalculatorTest.java
package com.example.calculator;import com.example.calculator.model.ByteInfo;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;class CharByteCalculatorTest {private CharByteCalculator calculator;@BeforeEachvoid setUp() {calculator = new CharByteCalculator();}@Testvoid testAsciiString() {// 场景1：纯 ASCII 字符串 HelloString input = Hello;int utf8Len = calculator.calculateByteLength(input, UTF-8);int gbkLen = calculator.calculateByteLength(input, GBK);// 最佳实践：ASCII 在 UTF-8 和 GBK 下都是 1 字节/字符assertEquals(5, utf8Len);assertEquals(5, gbkLen);assertFalse(calculator.containsNonAscii(input));}@Testvoid testChineseString() {// 场景2：中文字符串 你好String input = 你好;int utf8Len = calculator.calculateByteLength(input, UTF-8);int gbkLen = calculator.calculateByteLength(input, GBK);int utf16Len = calculator.calculateByteLength(input, UTF-16);// UTF-8: 每个汉字 3 字节 - 2 * 3 = 6assertEquals(6, utf8Len);// GBK: 每个汉字 2 字节 - 2 * 2 = 4assertEquals(4, gbkLen);// UTF-16: 每个汉字 2 字节 - 2 * 2 = 4 (BOM 除外，Java getBytes 默认不带 BOM)assertEquals(4, utf16Len);assertTrue(calculator.containsNonAscii(input));}@Testvoid testEmojiString() {// 场景3：Emoji 字符串 😀String input = 😀;int utf8Len = calculator.calculateByteLength(input, UTF-8);int utf16Len = calculator.calculateByteLength(input, UTF-16);// UTF-8: 4 字节assertEquals(4, utf8Len);// UTF-16: 2 个字符 (Surrogate Pair) - 4 字节// 注意：Java 中 emoji 占用 2 个 charassertEquals(4, utf16Len);}
}2. 常见坑点复现
在实际调试中，我发现一个高频错误：在 MySQL 中定义字段为 VARCHAR(100)，以为能存 100 个汉字，结果报错 Data too long for column。
原因分析：如果表字符集是 utf8mb4，1 个汉字占 3 字节（MySQL 5.5+ 的 utf8 其实是 utf8mb3，最高 3 字节；utf8mb4 最高 4 字节）。
VARCHAR(100) 指的是字符数，不是字节数。但在某些旧版本驱动或特定连接配置下，可能会混淆。
真正的坑：如果在 Java 代码中手动计算字节数，并试图用 substring 按字节截断，而没有考虑多字节字符的边界，会导致乱码或异常。解决方案：
永远使用 String.substring() 按字符截断，而不是按字节。如果需要按字节截断（如某些底层协议要求），必须使用 InputStream 或 ByteBuffer 并处理多字节边界。
优化扩展：应对高并发与大文本
在基础版本运行稳定后，我们需要考虑生产环境的性能挑战。
1. 大文本分片处理
如果输入字符串超过 10MB，一次性调用 getBytes() 会导致堆内存飙升。我们引入分片策略：
public long calculateLargeTextByteLength(String input, String encoding, int chunkSize) {if (input == null || input.isEmpty()) return 0;int totalBytes = 0;int len = input.length();Charset charset = CHARSET_MAP.get(encoding.toUpperCase());for (int i = 0; i len; i += chunkSize) {int end = Math.min(i + chunkSize, len);// 关键：substring 会产生新字符串对象，频繁调用需优化// 优化方案：使用 StringBuilder 或直接处理 char[]String sub = input.substring(i, end);totalBytes += sub.getBytes(charset).length;}return totalBytes;
}优化建议：如果内存允许，直接操作 char[] 或 byte[]，避免 String 对象的频繁创建。
使用 Unsafe 类（谨慎使用）或 ByteBuffer 进行零拷贝操作。2. 多语言支持扩展
除了 Java，我们还需要支持 JavaScript 和 Python 的对比。
JavaScript 差异：JS 的 String.length 返回的是 UTF-16 代码单元的数量。
一个 Emoji 在 JS 中 length 为 2。
要获取真实字符数，需使用 Array.from(str).length 或 [...str].length。Python 差异：Python 3 的 str 是 Unicode 序列。
len(str) 返回字符数。
sys.getsizeof(str) 返回内存占用，但包含对象头开销，不纯粹是编码字节数。
要获取编码字节数，需 len(str.encode('utf-8'))。对比表格：特性
Java (UTF-8)
JavaScript (UTF-16)
Python 3 (UTF-8)A 长度
1 字节
1 字节 (length: 1)
1 字节中 长度
3 字节
2 字节 (length: 1)
3 字节😀 长度
4 字节
4 字节 (length: 2)
4 字节内部存储
char[] (JDK8) / byte[] (JDK9+)
UTF-16 序列
UCS-2 / UTF-16 / UTF-32 自适应这个表格可以直接放在博客中，帮助读者快速建立跨语言认知。在 CSDN 等社区的技术分享中，这类对比表格通常能获得较高的收藏率，因为它解决了多语言团队协同时的沟通障碍。
小结：从字符到字节的思维跃迁
回到最初的问题：“一个字符是几个字？”答案并不是固定的数字，而是取决于编码方式、语言环境和字符类型。ASCII 字符：在 UTF-8、GBK、ISO-8859-1 下通常都是 1 字节。
中文汉字：UTF-8 下 3 字节，GBK 下 2 字节，UTF-16 下 2 字节。
Emoji：UTF-8 下 4 字节，UTF-16 下 2 个字符（4 字节）。最佳实践总结：不要假设：永远不要假设 1 字符 = 1 字节，除非你确定是纯 ASCII。
统一编码：全链路统一使用 UTF-8，减少转换开销和歧义。
按字符截断：业务逻辑中尽量按字符数截断，避免字节截断导致的乱码。
工具化：将字符计算逻辑封装成工具类，并在单元测试中覆盖多语言、多表情场景。这个知识点看似基础，但在处理国际化业务、日志系统、数据库存储时，往往是隐藏的 Bug 源头。很多资深工程师也会在这里翻车，因为经验主义让我们忽略了编码的多样性。
这个知识点你面试被问过吗？留言说说