代码之家 › 专栏 › 技术社区 › Blair Scott

SQL Server表中的日语/中文数据

collation asp-classic unicode sql-server-2005

Blair Scott · 技术社区 · 16 年前

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

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

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

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

到目前为止,我一直在努力研究排序规则,但我离SQL专家不远,所以这很困难。

如果需要的话,我可以提供更多的信息,任何能帮助我找到答案的信息,除了URL(机密性和全部)。

如果有人有什么想法,我会非常感激的。

其他信息:

-列类型为“ntext”

7 回复 | 直到 16 年前

cdonner 16 年前

排序规则只影响排序顺序,不影响编码。您需要确定您的中文和日语内容的编码是什么(请参见 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(例如Big5),则无法在UTF-8编码的网页上显示。

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

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

Justin Gallagher 16 年前

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

否则,您是否在所有数据库表中使用nvarchar或ntext字段?如果没有,那么你就失去了汉字和日文的水平。此外,如果您使用的是任何存储过程、函数等,则需要确保变量也是nvarchar或ntext。

最后,再次确认您的ASP页面在所有地方都保留了编码。我对ASP Classic不太熟悉,所以我会让其他人帮忙。

stealthyninja michkra 13 年前

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

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

David 16 年前

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

Dennis C 16 年前

你说你甚至不能从管理工作室读到它。检查是否有数据丢失是非常重要的。

为了知道如何恢复它,您必须知道它是如何被破坏的。

这些词是如何写入数据库的?任何转码(包括被ASP隐藏)在写入DB之前都已经完成了吗?
数据库中实际存储了什么? 您可以得到“中断”字的前两/三个字节,并将它们的字节范围与公共字符集进行比较。

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

Yishai 16 年前

如果修改了数据库,那么最可能的罪魁祸首就是字段的存储。您可以通过一个变量传递字段,该变量不是ntext,而是text或varchar。这将杀死进入的数据,然后在网页上返回时会出现错误。

您使用什么将数据插入数据库?

JasonTrue 16 年前

我怀疑你有几个问题。

实际上,有几种常用的方法来表示日文和中文文本,使用传统编码(日文的shift_-jis、euc-jp和jis变体,中文的其他几种变体)或Unicode(UTF-8或UTF-16)。对于多语言应用程序,首选的解决方案是以UTF-8格式传输页面内容;Windows本身更喜欢以UTF-16格式存储内容(这是NText和Nvarchar在MS SQL Server中使用的)。

为了使日文内容正确显示,您需要确保在数据管道的每个阶段都进行了正确的转换。让我们假设您将使用Unicode是为了保持理智,但是如果您有意选择使用shift-jis、big5、gb2312或其他更复杂的方法,那么答案将类似。

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

此外,还需要向用户代理(Web浏览器)提供使用UTF-8的提示。有两种技术,一种涉及HTTP头;另一种方法是使用meta标记来伪造HTTP头。

元标记解决方案:

HTTP头解决方案,使用我的Rusty ASP技能(假定为javascript,但您可能使用的是vbscript,这需要您删除分号) response.contenttype=“文本/html”; response.charset=“utf-8”;

如果您在feeds而不是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%>,而且您很幸运,内容没有完全弄乱。有几个黑客可以恢复hossed shift-jis-in-1252或iso-8859-1,但它们不是100%可靠。

对于SQL Server上的排序规则,这有两个影响。在nvarchar和ntext字段上,它只影响排序和查询(包括区分大小写、重音和假名)。在varchar和文本字段上,它也会影响编码,但这不是解决问题的最明智的方法。