ASCII函数返回值实际取值范围是0–127，仅针对纯ASCII字符；处理多字节UTF-8字符时，MySQL返回首字节值（如228），PostgreSQL直接报错。
ASCII函数返回值的实际取值范围是多少
ASCII 函数在主流 SQL 引擎（如 MySQL、PostgreSQL、SQL Server）中，只处理字符串第一个字符，并返回其 ASCII 码值（0–127）。注意：它**不支持 UTF-8 多字节字符的完整编码判断**，遇到中文、 emoji 或带重音的拉丁字母（如 é、ñ）时，行为因数据库而异——MySQL 5.7+ 默认返回首字节值（可能为 194、226 等），PostgreSQL 则直接报错 invalid byte sequence。
所以别指望用 ASCII('中') 得到 U+4E2D 这样的 Unicode 码点。它只适合判断纯 ASCII 子集（如英文、数字、标点）：
- 空格是
32 - 数字
'0'–'9'对应48–57 - 大写字母
'A'–'Z'是65–90 - 小写字母
'a'–'z'是97–122
如何安全判断字段是否全为 ASCII 可打印字符
单纯查单个字符不够，得验证整字段。MySQL 可用正则配合 ASCII 辅助过滤；PostgreSQL 更推荐用 convert_to + length 比较字节长与字符长；SQL Server 则依赖 DATALENGTH 和 LEN 差值。
MySQL 示例（判断 name 是否仅含 ASCII 可打印字符，即 32–126）：
SELECT name FROM users WHERE name REGEXP '^[ -~]+$';
这个正则比逐字符调 ASCII() 高效得多，且规避了多字节截断风险。若必须用函数逻辑，可写：
SELECT name FROM users WHERE LENGTH(name) = LENGTH(REGEXP_REPLACE(name, '[ -~]', '')) = 0;
但注意：REGEXP_REPLACE 在 MySQL 8.0+ 才可用，旧版只能用嵌套 IF + SUBSTRING 循环——性能差，慎用。
为什么用 ASCII 函数判断中文会出错
因为中文字符在 UTF-8 中占 3 字节（如 '中' 编码为 0xE4 0xB8 0xAD），而 ASCII() 在 MySQL 中只取第一个字节 0xE4（即十进制 228），远超标准 ASCII 范围；PostgreSQL 直接拒绝解析，抛出 ERROR: invalid byte sequence for encoding "UTF8"。
真正想判断 Unicode 范围（比如是否为汉字），应该：
- MySQL：用
CONVERT(name USING utf8mb4)确保编码正确，再结合正则name REGEXP '[\u4e00-\u9fff]'（需开启utf8mb4和正则支持） - PostgreSQL：用
name ~ '^[一-龥]$'（注意：Unicode 表意文字块匹配不完全等价于 u4e00–u9fff） - SQL Server：改用
UNICODE(SUBSTRING(name, 1, 1))，它返回的是 Unicode 码点，不是字节值
ASCII 函数在数据清洗中的真实适用场景
它最稳的用途是快速筛掉控制字符或乱码首字节，比如日志表里混入的 、 、
：
SELECT * FROM logs WHERE ASCII(SUBSTRING(message, 1, 1)) NOT BETWEEN 32 AND 126;
或者批量清理开头不可见字符：
UPDATE logs SET message = TRIM(LEADING FROM message) WHERE ASCII(LEFT(message, 1)) IN (0, 9, 10, 13); -- , , ,
但只要涉及非英文内容、国际化字段、或需要精确到 Unicode 区块（如判断是否 emoji、是否日文平假名），ASCII() 就该被弃用——它本质是个字节级函数，不是字符编码判断工具。
真要跨语言做字符分类，优先查数据库是否提供 UNICODE()、CHR()、REGEXP 或扩展函数，而不是硬套 ASCII()。
