sql server存储过程中正确声明unicode参数必须三点：参数类型用nvarchar而非varchar；调用时字符串字面量加n前缀；内部变量统一声明为nvarchar，避免隐式转换导致中文、日文等变为问号或乱码。
SQL Server 中存储过程如何正确声明 Unicode 参数？
不加 N 前缀或不声明 nvarchar 类型，中文、日文等会变成问号或乱码。SQL Server 默认用 varchar（单字节），根本存不下 UTF-16 字符。
实操必须做到三点：
- 所有接收文本的参数声明为
nvarchar，而非varchar，例如：@name nvarchar(100) - 调用时字符串字面量加
N前缀，例如：EXEC usp_insert_user N'张伟', N'日本語' - 内部变量也统一用
nvarchar，避免隐式转换丢数据，比如：DECLARE @msg nvarchar(200)
MySQL 存储过程中处理多语言字符的关键配置项
即使字段是 utf8mb4，存储过程仍可能出乱码——问题常出在连接层和 routine 字符集上。
必须检查并设置以下三项：
- 数据库和表默认字符集：确保为
utf8mb4，建表语句中显式写CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 存储过程创建时指定字符集：
CREATE PROCEDURE sp_log_msg(IN msg TEXT) CHARACTER SET utf8mb4 - 客户端连接必须带
charset=utf8mb4，例如 JDBC URL 中加?characterEncoding=utf8mb4
漏掉任意一项，INSERT INTO log_table VALUES (@msg) 都可能把 emoji 或越南文截成 。
PostgreSQL 函数里怎么安全拼接多语言字符串？
PostgreSQL 虽默认支持 UTF-8，但字符串拼接时若混入 bytea 或未标注编码的 text 变量，仍会触发 invalid byte sequence for encoding "UTF8" 错误。
稳妥做法：
- 所有输入参数用
text类型（它原生支持 UTF-8，无需额外前缀） - 避免用
||拼接来自外部不可信源的 raw bytes；如有必要，先用convert_from(bytea, 'UTF8')显式转义 - 函数定义末尾加上
SET client_encoding = 'UTF8'，防止会话级编码被意外修改 - 调试时用
SELECT octet_length('中文') = length('中文') * 3快速验证是否真为 UTF-8 多字节
跨数据库移植时最易忽略的 collation 兼容性问题
同一个中文名，在 SQL Server 的 Chinese_PRC_CI_AS 和 MySQL 的 utf8mb4_0900_as_cs 下排序结果可能不同，甚至 WHERE 匹配失败。
这不是 bug，是 collation 设计使然。上线前必须核对：
- WHERE 条件中的比较操作（如
@lang = 'zh-CN'）是否依赖大小写/重音敏感性？对应 collation 是否一致？ - ORDER BY 结果是否要求符合某语言习惯？例如德语中
ä应排在a之后，而非末尾 - 应用层做排序或去重，比依赖数据库 collation 更可控；尤其当存储过程要导出给多个 DB 使用时
collation 是隐形开关，改起来不报错，但数据逻辑就悄悄偏了。
