sql中不可见换行符为char(10)（lf）和char(13)（cr），需用对应函数而非'\n'匹配；postgresql用chr(10)；定位用locate/charindex/position；清除需嵌套replace且注意顺序。
CHAR(10) 和 CHAR(13) 是换行符的常见表示
在 SQL 中，不可见换行符通常指 CHAR(10)（LF，Unix/Linux/macOS 换行）和 CHAR(13)（CR，Windows 回车），有时二者连用为 CHAR(13) + CHAR(10)。直接用 WHERE column LIKE '%\n%' 是无效的——SQL 字符串字面量不解析转义序列 \n，必须显式拼出对应字符。
实操建议：
- 用
CHAR(10)替代'\n'，CHAR(13)替代'\r'，不同数据库对CHAR()参数支持一致（如 MySQL、SQL Server、PostgreSQL 均支持 ASCII 值） - PostgreSQL 用户注意：
CHR(10)是等价函数，CHAR(10)在 PostgreSQL 中不被识别，需改用CHR(10) - 若字段值含混合换行（如用户粘贴文本），建议同时检查两种组合：
CHAR(13)+CHAR(10)和单独的CHAR(10)
用 ASCII() 函数定位换行符位置
ASCII() 本身只返回单个字符的 ASCII 值，不能直接扫描整列；但配合 SUBSTRING() 或字符串逐位拆解，可定位首个换行符所在索引。这对清洗前探查数据很有用。
实操建议：
- MySQL 示例：找出第一个换行符位置：
LOCATE(CHAR(10), column_name)比手动循环调用ASCII(SUBSTRING(column_name, n, 1))更高效 - SQL Server 可用
CHARINDEX(CHAR(10), column_name)，返回从 1 开始的位置；若返回 0 表示未找到 - 避免在 WHERE 条件中对大字段反复调用
ASCII()+SUBSTRING()，性能差；优先用CHARINDEX/LOCATE等原生位置函数
替换或清除换行符的可靠写法
直接 REPLACE(column, '\n', '') 会失败，因为 '\n' 就是两个字符：反斜杠和字母 n。必须用 CHAR(10) 或 CHR(10) 构造真实换行符。
实操建议：
- 清除 LF：
REPLACE(column, CHAR(10), '')（SQL Server、MySQL）或REPLACE(column, CHR(10), '')（PostgreSQL） - 清除 CRLF 组合（更常见于表单提交）：
REPLACE(REPLACE(column, CHAR(13), ''), CHAR(10), '')，注意顺序：先清 CR 再清 LF，避免把CHAR(13)+CHAR(10)错误替换成残留CHAR(10) - 某些场景需保留空格替代换行，可用
REPLACE(column, CHAR(10), ' ')，但注意连续换行会变成多个空格，必要时叠加TRIM()或正则去重
WHERE 条件中检测含换行符的记录
最简方式不是匹配整个换行符，而是检查字段是否包含对应 ASCII 值的字符。但要注意：有些数据库（如 MySQL）在比较时忽略末尾空格和部分控制字符，导致 LIKE '%'+CHAR(10)+'%' 失效。
实操建议：
- 推荐用
CHARINDEX(CHAR(10), column) > 0（SQL Server）、LOCATE(CHAR(10), column) > 0（MySQL）、POSITION(CHR(10) IN column) > 0（PostgreSQL） - 避免用
column LIKE '%' + CHAR(10) + '%'：SQL Server 中+是字符串拼接，但若任意操作数为 NULL，结果全为 NULL，WHERE 条件恒假 - 如果字段定义为
TEXT或XML类型，部分旧版 SQL Server 不支持CHARINDEX直接作用于TEXT，需先CAST(column AS VARCHAR(MAX))
真正麻烦的是嵌套在 JSON 或 HTML 片段里的换行符——它们可能被双重编码（如
）或出现在注释中，此时 CHAR() 和 ASCII() 无能为力，得先解析结构再处理。
