应使用预建全角到半角字符映射字典逐字符替换，因string.Normalize()无效、char.IsFullWidth覆盖不全、正则和StringInfo均不适用，且需严格区分存储与显示场景。
全角 ASCII 字符怎么批量转半角
全角字母、数字、标点（如 ＡＢＣ１２３，。）本质是 Unicode 中的全角区字符（U+FF01–U+FF5E），不是编码问题，而是字符映射不同。C# 没有内置“自动转换”函数，string.Normalize() 对它们完全无效——它只处理组合字符、兼容性分解等，不碰全角/半角映射。
实操建议用查表法最稳：
- 用
char.IsFullWidth判断是否为全角字符（注意：它只对 CJK 全角字符返回 true，不覆盖所有全角 ASCII） - 更可靠的是预建映射字典：
Dictionary<char char></char>，键为全角字符（如'Ａ'），值为对应半角（'A'） - 对输入字符串逐字符检查，命中则替换，否则保留原字符
- 别用正则全局替换——全角字符范围不连续，且中文标点（如 ，、 。）和 ASCII 全角不在同一逻辑块里
示例关键片段：
private static readonly Dictionary<char, char> FullToHalfMap = new()
{
['Ａ'] = 'A', ['Ｂ'] = 'B', ['１'] = '1', ['２'] = '2',
['，'] = ',', ['。'] = '.', [' '] = ' ' // 注意全角空格
};
半角字符转全角时要注意哪些边界
半角转全角比反向更危险：一不小心就把英文字母全塞进全角区，导致搜索、校验、数据库索引失效。比如用户输 "admin123"，转成 "ａｄｍｉｎ１２３" 后，.Contains("admin") 返回 false，WHERE username = 'admin123' 查不到数据。
常见错误现象：string.Replace("a", "ａ") 这种硬替换会漏掉大小写、忽略数字标点，还可能把变量名或 HTML 属性值也误换。
使用场景必须明确限定：
- 仅用于显示层（如打印报表、PDF 渲染），绝不用于存储或比对
- 只转换用户可见文本内容，跳过
class、id、data-属性值等结构字段 - 避免对 URL、邮箱、电话号码等结构化字段做全角化
- 全角空格
' '和半角空格' '行为差异极大：前者在 CSS 中不触发 word-break，也不被Trim()清除
为什么 StringInfo 和 TextElementEnumerator 不适合这个任务
这两个类专为处理 Unicode 文本单元（grapheme clusters）设计，比如带变音符号的 "é"、emoji 组合 ??，但全角/半角转换是字符级一对一映射，和字形渲染、光标移动无关。
误用后果明显：
-
StringInfo.LengthInTextElements对"ＡＢ"和"AB"都返回 2，无法区分宽窄 -
TextElementEnumerator会把一个全角汉字（如'中'）当作单个 text element，但它根本不管这个字是不是“全角 ASCII” - 强行套用只会增加 CPU 开销，且掩盖真正要解决的字符映射问题
简单说：它们管“怎么切字”，你实际需要的是“怎么换字”。别混用。
用户输入规范该在哪一层做
别在 UI 层（WinForms/WPF TextBox 的 TextChanged）实时转换——用户还没输完就改内容，体验极差；也别在数据库写入前统一转换——丢失原始意图，审计困难。
推荐位置只有两个：
- 提交前校验环节（如 ASP.NET Core 的
IValidatableObject或自定义ValidationAttribute），只对特定字段（如姓名、地址）做全半角归一化，并记录原始值用于日志 - 查询前的参数预处理（如 EF Core 查询前，把搜索关键词中的全角空格替换成半角，再调用
Contains()）
最容易被忽略的一点：全角破折号 '——'、全角省略号 '……' 和半角对应物语义不同，不能无脑替换。这类字符必须按业务规则单独判断，而不是扔进通用映射表。
