宽度属性与成因
宽度问题源于字符集的演化：东亚传统编码里，汉字与标点占两个西文字符的位置（全角），因此 Unicode 为码位标注了东亚宽度属性——全角（Wide）、半角（Narrow）、宽（Fullwidth、模糊（Ambiguous）等。终端与等宽字体按这些属性与自身配置决定渲染宽度：全角字符占两格、ASCII 占一格、组合标记不占位。而「字符数」的口径更复杂：UTF-8 字节数、码点数、字形簇数、显示宽度四种计数结果都可能不同，做表格对齐时必须选显示宽度。
基本信息
| 常用口径 | 字节数、码点数、字形簇数、显示宽度四种 |
|---|---|
| 全角 | 汉字、全角标点，通常占 2 格 |
| 半角 | ASCII 与多数西欧字符，占 1 格 |
| 零宽 | 组合标记不占位，需与基字符合并统计 |
| 模糊宽度 | 在部分终端占 1 格、部分占 2 格，需按环境约定 |
| 常见受害者 | 终端表格错位、日志对不齐、按宽度截断出现半截字符 |
典型使用场景
- 终端与日志表格：按显示宽度补空格才能对齐
- 文本截断：按宽度截断时不能切开全角字符或组合序列
- 界面自适应：CJK 内容所需宽度约为同长度英文的两倍，布局要预留
- 报表导出：CSV 与固定宽文本文件需按显示宽度而非字节数填充
- 字段长度设计：数据库列宽按字节计、界面按宽度计，两者需分别评估
宽度计算示例
宽度计算示例
python -c "import unicodedata as u; print(u.east_asian_width('中'), u.east_asian_width('A'), u.east_asian_width('\uff21'))" # W Na F
python - <<'EOF'
# 按东亚宽度估算显示宽度：W/F 记 2，其余记 1（模糊宽度需按环境另定）
import unicodedata as u
def width(s):
return sum(2 if u.east_asian_width(c) in 'WF' else 1 for c in s)
print(width('中文abc'), len('中文abc'), len('中文abc'.encode('utf-8')))
EOF
# 对齐演示：按宽度补空格
printf '%-*s' $((12)) '中文' | cat -A # 观察实际填充列数，与终端设置有关计数口径对照
| 口径 | 中文两个字的结果 | 适用场景 |
|---|---|---|
| UTF-8 字节数 | 6 | 存储容量、网络传输限制 |
| 码点数 | 2 | 字符逻辑处理、码位校验 |
| 字形簇数 | 2 | 用户感知的字数统计 |
| 显示宽度 | 4 | 终端对齐、文本截断、界面布局 |
| UTF-16 编码单元数 | 2 | Java/JS 字符串长度语义 |
模糊宽度字符是终端对齐的主要麻烦：同一字符在不同终端或不同语言环境下占 1 格或 2 格，脚本用固定规则计算就会错位。涉及模糊宽度内容时，优先避免用空格做对齐，改用制表符、表格库或直接输出结构化格式。
按宽度截断要按字形簇进行：组合标记与 emoji 序列被拆开会渲染成孤立符号或方块。稳妥做法是先按字形簇切分，再累加宽度直到达到上限，而不是按码点逐个截断。
宽度属性随 Unicode 版本更新：新增 emoji 与符号的宽度定义可能变化，不同版本的库算出的宽度可能不同。跨系统对齐要求严格的场景，应锁定依赖版本并在目标环境实测。