我之前踩过类似的链接服务器中文乱码的坑，结合你给出的动态SQL代码和查询场景来看，问题基本出在Unicode编码传递中断或者字符集配置不匹配上，给你几个针对性的解决步骤：

1. 检查链接服务器的ODBC数据源字符集配置 #

• 打开ODBC数据源管理器（注意选32位或64位，对应你的SQL Server版本），找到POLODBC对应的数据源，进入配置界面。
• 确保字符集设置为支持中文的选项，比如GBK、UTF-8或者与源数据库一致的中文排序规则（比如Chinese_PRC_CI_AS）。很多时候乱码就是因为驱动默认用了非中文的字符集，把中文转换成了无法识别的字符。

2. 强制动态SQL全链路使用Unicode #

你已经用了NVARCHAR类型，但还有两个关键细节要注意：

• 所有含中文的字符串必须加N前缀：如果你的@Parameter_List里包含中文参数值，比如@Status='待处理'，必须改成@Status=N'待处理'，不加N的话SQL Server会自动把它转成非Unicode的VARCHAR，传递到链接服务器时就会变成???。
• 确保拼接后的完整命令是纯Unicode：哪怕@Sproc和@Parameter_List都是NVARCHAR，拼接时也要避免隐性转换。可以在构造@FullCommand时显式加固：

  SET @FullCommand = CONCAT(N'', @Sproc, @Parameter_List)
  

3. 在查询中指定字段的排序规则 #

如果直接查询链接服务器的表时中文正常，但动态SQL里不行，可以在SELECT语句里强制指定字段的中文排序规则，比如：

SELECT 
  PCN, 
  Container_Status COLLATE Chinese_PRC_CI_AS, 
  Inventory 
FROM [POLODBC].[你的数据库名].[你的Schema].[目标表名]

这样能确保返回的中文字段按照正确的编码解析。

4. 更新ODBC驱动版本 #

老版本的ODBC驱动对Unicode的支持很差，尤其是针对非SQL Server的数据源（比如你用的POLODBC），建议更新到对应数据库的最新ODBC驱动，确保驱动能正确处理Unicode字符串的传递。

5. 排查动态SQL vs 直接查询的差异 #

先测试不用动态SQL的直接查询：

SELECT PCN, Container_Status, Inventory 
FROM [POLODBC].[你的数据库名].[你的Schema].[目标表名]

如果这个查询中文显示正常，那问题肯定出在动态SQL的参数拼接上，重点检查@Parameter_List里的中文参数有没有加N前缀，以及拼接后的@FullCommand是否完整保留了Unicode编码。

内容的提问来源于stack exchange，提问作者Sumit