视图乱码根源在依赖字段、连接会话或客户端解码环节，须查字段级collation而非数据库默认值，确保字段、连接、客户端三者collation严格对齐，视图定义中需显式统一collation避免隐式转换。
视图本身不存数据也不定义字符集，乱码一定出在它依赖的字段、连接会话或客户端解码环节——查 collation 只是定位手段，不是修复动作。
查视图字段实际 collation 而非数据库默认值
视图字段的排序规则继承自底层表字段，不是数据库或服务器默认值。只看 SELECT DATABASEPROPERTYEX('db_name', 'Collation') 没用。
- 执行
SHOW CREATE TABLE your_base_table，确认每个VARCHAR/TEXT字段是否显式声明了COLLATE utf8mb4_unicode_ci（MySQL）或COLLATE Chinese_PRC_CI_AS（SQL Server） - 对 SQL Server，运行
SELECT name, collation_name FROM sys.columns WHERE object_id = OBJECT_ID('your_table') AND name = 'name_field'，直接看列级collation_name - MySQL 中字段 collation 为空时，按表 → 数据库 →
character_set_server逐级继承；SQL Server 中为空则继承自数据库，但 JOIN 时可能隐式转换
检查连接层 collation 是否匹配字段 collation
即使字段是 utf8mb4_unicode_ci，若连接的 collation_connection 是 latin1_swedish_ci，MySQL 会在拼接、比较、GROUP_CONCAT 时强制降级处理字节，结果就是乱码。
- MySQL：执行
SELECT @@collation_connection, @@collation_database，二者必须与字段 collation 兼容（推荐全为utf8mb4_unicode_ci） - SQL Server：连接字符串里必须含
ApplicationIntent=ReadWrite;Connect Timeout=30;，且驱动需支持UTF-8（如 Microsoft JDBC Driver 10.2+），否则即使列是Chinese_PRC_CI_AS，JDBC 仍可能用US-ASCII解码 - Oracle：
NLS_SORT和NLS_COMP必须与字段collation一致，例如NLS_SORT = BINARY时，ORDER BY不走中文拼音排序，但不会导致乱码；乱码只和NLS_LANG有关
避免视图定义中隐式 collation 冲突
视图里用 CONCAT()、UNION 或子查询拼接不同 collation 的字段，MySQL/SQL Server 都会按“ coercibility”规则选一个作为结果 collation，常导致中文字段被强制转成 latin1 或 SQL_Latin1_General_CP1_CI_AS。
- MySQL：用
CONVERT(col USING utf8mb4) COLLATE utf8mb4_unicode_ci显式统一，别依赖自动推导 - SQL Server：在视图 SELECT 列里加
COLLATE Chinese_PRC_CI_AS，例如name COLLATE Chinese_PRC_CI_AS AS name - UNION 查询必须所有分支字段 collation 一致，否则报错或静默降级；
UNION ALL不校验，但结果 collation 仍取第一个分支的
真正难排查的是跨库 JOIN 视图：两个库 collation 不同，字段 collation 却没显式声明，MySQL 会按 server 默认选一个，SQL Server 会按 database 默认 fallback，而这个 fallback 值往往和你预期不符。这时候光改视图定义没用，得从建表语句源头控制。
