SQL Server 表中的日文/中文语言数据答案

【问题标题】：Japanese/Chinese language data in SQL Server tableSQL Server 表中的日文/中文语言数据
【发布时间】：2010-10-08 20:43:37
【问题描述】：

所以我遇到了一个有趣的问题，我需要帮助的速度比我的 SQL Server 技能达到标准要快。

我们有一个包含一堆文本的表格，所有这些文本都使用不同的语言。大多数这些数据在浏览器中正确显示，但是，中文或日文的任何内容都会被浏览器完全破坏。

这是一个 ASP.old 应用程序，我们用来显示来自运行 MS SQL Server 2005 的服务器的数据。

以前，我们也遇到过同样的问题，我们通过更改 ASP 页面中的编码解决了这个问题。自从我们这样做以来，这些文件没有改变，但问题又出现了。因此，我必须得出结论，问题在于数据库，因为这是我们上次修复它以来唯一更新的东西。

到目前为止，我一直在尝试研究排序规则，但我离 SQL 专家还差得很远，所以这很困难。

如果需要，我可以提供更多信息，任何可以帮助我找到答案的信息，除了 URL（保密和所有）。

如果有人有任何想法，我将不胜感激。

附加信息：

-列类型是'ntext'

【问题讨论】：

标签： sql-server-2005 unicode asp-classic collation

【解决方案1】：

排序规则只影响排序顺序，不影响编码。您需要确定您的中文和日文内容的编码是什么（参见this）。如果不是 UCS-2，你就有问题（因为你不能同时支持多个页面编码）。如果是 UCS-2，您需要确保您的 ASP 页面的编码也设置为 UTF-8（并且浏览器通过将编码正确设置为 UTF-8 来识别 - 请参阅查看/编码）。

或者更简单地说：如果创建内容的应用程序没有使用 Unicode 字符，那么在中文、日文和欧洲字符之间切换时，您将不得不切换页面编码。

如果您在数据库中正确编码了 Unicode 内容，并且在页面上使用了 UTF-8 编码，那么在显示任何特殊字符时应该不会有问题（只要您在页面上使用 Unicode 字体）：

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

我意识到有几个编辑我不是很清楚，所以让我添加一些基础知识。

字符集是一组字符（例如 ASCII、UNICODE...）的标准化表示。

字符编码是用于存储给定字符集字符的二进制表示。 ASCII 有自己的编码。 Unicode 是一个非常大的字符集，旨在支持现有的所有字符，它有多种编码（UTF-8、UTF-16、UCS-2...）。

只有 Unicode 才能让您使用相同的数据库和应用程序设置同时支持西方和远东的内容。但是，中文和日语的旧字符集不是 Unicode。如果您的内容不是 Unicode（例如 BIG 5），则无法在 UTF-8 编码的网页上显示它。

如果创建内容的应用程序使用一种编码（例如 BIG-5）并且数据库将其存储为 Unicode 数据，这可能会变得很棘手。如果发生这种情况，信息可能会丢失。

您甚至必须在 Windows 中安装相应的语言包才能正确查看字符。不幸的是，编码问题并不容易诊断。

【讨论】：

有没有办法确定字段使用的编码？
在 Management Studio 中查询数据库时，您看到了什么？您在网页上获得的相同垃圾，还是正确的数据？如果您没有看到正确的数据，那么您的数据就是错误的。您可以使用 asc() 函数找出存储的内容，然后查找代码。得跑了，稍后再跑。
是的，数据库中的废话与页面上的一样。我们将尝试从备份中获取一些信息，看看是否正确。感谢您的所有帮助，非常感谢。
当您浏览yahoo.co.jp 时，您看到的是日语还是小方块？您确实需要客户端的语言支持。
是的，日语在正确显示时可以在我的机器上正常工作。事实上，它在我尝试修复的网站上运行良好，就像 3 个月前一样。

【解决方案2】：

这里可能有几个问题，但既然你说你之前解决了这个问题，它可能只是浏览器显示问题。您应该确保正确设置了编码并安装了语言包。您可以在几台不同的计算机和浏览器上进行检查，以确定它是特定机器、浏览器的问题还是一般问题。

否则，您是否在所有数据库表中都使用 nvarchar 或 ntext 字段？如果没有，那么您将在该级别丢失中文和日文字符。此外，如果您使用任何存储过程、函数等，您需要确保变量也是 nvarchar 或 ntext。

最后，请重新检查您的 ASP 页面是否在所有位置都保留了编码。我对 ASP 经典不是很熟悉，所以我会让其他人帮忙。

【讨论】：

我尝试将 FF 中的字符编码更改为一堆不同的。最接近正确的是使用“日语（SHIFT_JIS）”。由于对不同的编码类型相对无知，我不知道这意味着什么。数据存储在 ntext 类型的列中。
我的设置为 Unicode (UTF-8)，我可以查看汉字。试试看，如果你仍然有问题，那么它可能与 ASP 页面有关。这是以前出现问题的同一页面吗？
这实际上是一堆页面，但我只是在尝试将它修复在一个页面上。旧的修复工作正常（将其更改为 utf-8），但现在它不再工作了，我个人无法访问旧数据，我必须等待。

【解决方案3】：

您的 ASP 文件中有以下内容吗？

<%@codepage=65001%>
Session.CodePage = 65001

【讨论】：

【解决方案4】：

ntext 在 SQL 2005 (http://geekswithblogs.net/johnsPerfBlog/archive/2008/04/16/ntext-vs-nvarcharmax-in-sql-2005.aspx) 中已被弃用。不确定它是否有帮助，但您可以尝试将 ntext 转换为 nvarchar。

【讨论】：

这不会解决问题，虽然它是有趣的信息。

【解决方案5】：

您说您甚至无法从 Management Studio 中读取它。检查是否已经丢失任何数据非常重要。

为了知道如何恢复它，您必须知道它是如何损坏的。

这些词是如何写入数据库的？在写入 DB 之前是否已完成任何转码（包括被 ASP 隐藏）？
实际上已经存储在数据库中的是什么？您可以获取“损坏”单词的前两个/三个字节，并将它们的字节范围与常见字符集进行比较。

如果数据来自浏览器，则应检查表单页面的编码。浏览器使用页面的编码来编码和提交数据。如果字符集/编码与接收者不匹配（例如您的 ASP 页面），它可能会错误地解码单词。

【讨论】：

【解决方案6】：

如果您修改了数据库，那么最可能的罪魁祸首是字段的存储。您可以通过不是 ntext 的变量传递字段，而只是 text 或 varchar。这将杀死进入的数据，然后返回网页看起来会出错。

你用什么把数据插入数据库？

【讨论】：

【解决方案7】：

我怀疑你有几个问题。

实际上有几种常用的方法来表示日文和中文文本，使用传统编码（用于日文的 Shift_JIS、EUC-JP 和 JIS 变体，以及用于中文的其他几种）或 Unicode（UTF-8 或 UTF-16） .对于多语言应用程序，首选的解决方案是以 UTF-8 传输页面内容； Windows 本身更喜欢以 UTF-16 存储内容（这是 MS SQL Server 中使用的 NTEXT 和 NVARCHAR）。

为了正确显示日语内容，您需要确保在数据管道的每个阶段都进行正确的转换。让我们假设您为了理智而使用 Unicode，但如果您有意选择使用 Shift-JIS、big5、gb2312 或其他东西，答案将是相似的，只是更复杂。

如果您的数据主要来自网络表单，您需要确保将代码页设置为 65001，通常使用每个 ASP 文件顶部的指令。

此外，您需要向您的用户代理（Web 浏览器）提示您正在使用 UTF-8。有两种技术，一种涉及 HTTP 标头；另一种涉及 HTTP 标头。另一种选择是使用元标记伪造 HTTP 标头。

元标记解决方案：

HTTP 标头解决方案，使用我生疏的 ASP 技能（假设是 javascript，但您可能使用的是 vbscript，这需要您删除分号） Response.ContentType="文本/html"; Response.Charset="utf-8";

如果您在提要而不是 Web 表单中将数据导入 MSSQL，您还需要确保数据已正确转换。根据您的导入机制，指定源编码的方法是不同的，所以我不得不将其留作“读者练习”。

接下来，在将数据提交到 SQL Server 时，您需要确保使用正确的 SQL 输入机制。如果您没有对查询进行参数化（并且应该这样做），则在将文本参数放入查询中时，您需要记住使用 N'MyText' 表单而不是 'MyText'。如果您正在参数化您的文本，当您使用 adVarChar 时，您应该改用 adVarWChar。（每种 ADO 数据类型都有对应的“W”类型）。

此外，一些浏览器使用 HTML LANG 属性作为提示，以适合内容语言的字体显示文本。如果您碰巧知道您的内容使用哪种语言，您可以将 LANG="ja-jp" 添加到任何 HTML 元素（包括 BODY）。然后浏览器应该使用该语言的合理默认字体（但如果您愿意，可以明确指定一种）。即使您为特定语言选择了不合适的默认字体，过去 5 年中制造的大多数浏览器都会执行一些字体链接魔术，但如果您使用合适的字体，您将获得更可靠的结果和稍微更好的渲染性能。

作为补充说明，如果您在浏览器上手动强制编码为 shift-jis 时得到几乎正确的结果，这意味着您可能正在使用 windows-1252 作为您的字符集并且您很幸运内容并没有完全混乱。有几个 hack 可以恢复软管的 Shift-Jis-in-1252 或 iso-8859-1，但它们不是 100% 可靠的。

对于 SQL Server 上的排序规则，这有两个影响。在 NVARCHAR 和 NTEXT 字段上，它只影响排序和查询（包括区分大小写、重音和假名）。在 varchar 和 text 字段上，它也会影响编码，但这不是解决您的问题的最明智的方法。

【讨论】：