我得到了一个非常大的备份（.BAK）老挝使用的数据库，我在SQL Server 2014 Express（本地）服务器上恢复了这个数据库。它是一个包含许多列的数据库，其中包含Lao文本。当使用数据库的人通过客户端应用程序（某种泰国会计程序）访问它时，他们可以看到所有老挝数据在将其显示字体设置为Saysettha时正确显示，Saysettha是带有老挝字符的Unicode字体。
但是，我试图从SSMS导出表中的数据（通过简单的文本或csv文件，因为导出过程需要简单且可重复），并且数据永远不会正确显示。甚至在我在SSMS中进行表查询时也是如此。
我知道这可能是编码/整理的问题。列存储在VARCHAR列中。我已经尝试将它们转换为NVARCHAR列，但这并没有解决问题。我还尝试将列整理为Lao排序规则（恢复备份后服务器排序规则设置为Thai_CI_AS）;
我尝试将输出表保存为具有不同编码的CSV和TXT文件，但是当我在例如打开它们时Notepad ++我看到相同的错误字符。
不幸的是，由于我的笔记本电脑上没有运行客户端软件，因此我没有样本文本的样本。
理想情况下，我可以使用UTF-8编码导出列。
答案 0 :(得分：0)
我的理解是，老挝文本通常以UTF-8编码，UTF-16编码或Code page 1133编码存储。
当查看应用程序使用与存储数据时使用的编码相同的编码时，它看起来没问题。 不幸的是，有时候查看应用程序并没有准确地告知使用了什么编码，因此它“有用”地尝试guess，有时它会猜错。 通常错误的猜测对于看着显示器的人来说是显而易见的 - 字母甚至不是来自正确的语言。
更糟糕的是，当您告诉应用程序从数据库导出数据时，应用程序可以“帮助”将数据转换为不同的编码，而不是简单地导出文本的原始字节。 如果应用程序碰巧知道数据库中数据的实际编码，那么在导出工作时转换为UTF-16或UTF-8效果很好;否则导出的数据通常会被破坏并无法使用。
有时候最难解决的问题是系统实际工作正常，但我（错误地）认为存在问题。有时会发生这种情况是因为我用来查看问题的工具存在缺陷。 如果您在Notepad ++中看到大多数老挝字符，或者您可以在Notepad ++中更改编码，直到您看到大多数老挝字符，那么我怀疑您的文本或csv文件中的数据以及Notepad ++ guessed或您设置的编码Encoding -> Encode可能是正确的。
有没有办法让你看看数据是否正确地由数据库正确存储，处理，导出等，并且正确地由客户端应用程序显示，但是记事本或SSMS中的渲染故障是错误的一些重音标记？
