3

所以我遇到了一个有趣的问题，我需要帮助的速度比我使用 SQL Server 的技能要快得多。

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

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

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

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

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

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

附加信息：

-列类型是'ntext'

4

7 回答 7

4

排序规则只影响排序顺序，不影响编码。你需要确定你的中文和日文内容的编码是什么（见这个）。如果不是 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 中安装相应的语言包才能正确查看字符。不幸的是，编码问题并不容易诊断。

于 2009-02-20T15:05:41.033 回答
4

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

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

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

于 2009-02-20T15:19:36.990 回答
1

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

<%@codepage=65001%>
Session.CodePage = 65001
于 2009-04-29T01:13:45.897 回答
0

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

于 2009-04-29T14:31:49.770 回答
0

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

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

  1. 这些词是如何写入数据库的？任何转码（包括被 ASP 隐藏）在写入 DB 之前是否已完成？

  2. 实际上已经存储在数据库中的是什么？您可以获得“损坏”字的前两个/三个字节，并将它们的字节范围与常见字符集进行比较。

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

于 2009-05-02T15:55:34.753 回答
0

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

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

于 2009-05-04T13:52:07.560 回答
0

我怀疑你有几个问题。

实际上有几种常用的方法来表示日文和中文文本，使用传统编码（用于日文的 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 或其他东西，答案将是相似的，只是更复杂。

如果您的数据主要来自 Web 表单，则需要确保将代码页设置为 65001，通常使用每个 ASP 文件顶部的 <%@codepage=65001%> 指令。

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

元标记解决方案：

HTTP 标头解决方案，使用我生疏的 ASP 技能（假设是 javascript，但您可能使用的是 vbscript，这需要您删除分号） Response.ContentType="text/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 作为您的字符集 <%@codepage=1252%> 并且您很幸运，内容并没有完全混乱。有一些黑客可以恢复软管的 Shift-Jis-in-1252 或 iso-8859-1，但它们不是 100% 可靠的。

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

于 2009-05-05T18:09:18.993 回答