所以我遇到了一个有趣的问题，我需要更快的帮助，而不是让我的SQL技能达到标准。
我们有一个包含大量文本的表，所有文本都使用不同的语言。大多数此类数据在浏览器中正确显示，但是，中文或日文的任何内容都会被浏览器完全破坏。
这是一个ASP.old应用程序，我们用它来显示来自运行MS SQL Server 2005的服务器的数据。
之前，我们遇到了同样的问题，我们通过更改ASP页面中的编码来解决它。自从我们这样做以来，这些文件没有改变，但问题再次浮出水面。因此，我必须得出结论，问题在于数据库，因为这是自我们上次修复以来唯一已更新的内容。
到目前为止，我一直在努力调查整理，但我还远远没有SQL专家，因此很难。
如果需要，我可以提供更多信息，任何有助于我找到答案的内容，缺少网址（机密性和所有内容）。
如果有人有任何想法，我会非常感激。
附加信息：
-column type是'ntext'
答案 0 :(得分：4)
归类仅影响排序顺序，而不影响编码。您需要确定您的中文和日语内容的编码是什么（请参阅this）。如果它不是UCS-2，则会出现问题（因为您不能同时支持多页编码）。如果它是UCS-2，您需要确保ASP页面的编码也设置为UTF-8（并且浏览器通过正确地将编码设置为UTF-8来识别它 - 请参阅查看/编码）。 / p>
或者更简单地说：如果创建内容的应用程序不使用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中安装相应的语言包才能正确查看字符。不幸的是，编码问题并不容易诊断。
答案 1 :(得分：4)
这里可能会有一些问题，但既然你说你以前解决了这个问题，那么它可能只是一个浏览器显示问题。您应该确保正确设置了编码并安装了语言包。您可以在几台不同的计算机和浏览器上进行检查，以确定它是否与特定计算机，浏览器或一般问题有关。
否则，您是否在所有数据库表中使用nvarchar或ntext字段？如果没有，那么你就失去了那个级别的中文和日文字符。此外，如果您正在使用任何存储过程，函数等，则需要确保变量也是nvarchar或ntext。
最后，重新确认您的ASP页面是否在所有位置保留了编码。我对ASP经典不太熟悉，所以我会让别人帮忙。
答案 2 :(得分：1)
您的ASP文件中是否包含以下内容？
<%@codepage=65001%>
Session.CodePage = 65001
答案 3 :(得分：0)
ntext已在SQL 2005（http://geekswithblogs.net/johnsPerfBlog/archive/2008/04/16/ntext-vs-nvarcharmax-in-sql-2005.aspx）中弃用。不确定它是否有帮助，但您可以尝试将ntext转换为nvarchar。
答案 4 :(得分：0)
你说你甚至无法从Management Studio阅读它。 检查是否已丢失任何数据非常重要。
为了知道如何恢复它，你必须知道它是如何被破坏的。
这些单词是如何写入数据库的？任何转码（包括隐藏的ASP）在写入DB之前已经完成了吗？
实际存储在数据库中的是什么？ 你可以得到“破碎”字的前两个/三个字节，并将它们的字节范围与普通字符集进行比较。
如果数据来自浏览器，则应检查表单页面的编码。 浏览器使用页面编码来编码和提交数据。如果charset / encoding与接收者（例如你的ASP页面）不匹配，它可能会错误地解码这些单词。
答案 5 :(得分：0)
如果您修改了数据库，那么最可能的罪魁祸首就是存储字段。您可以通过非ntext的变量传递字段，而只是文本或varchar。这会杀死进入的数据，然后在网页上看起来会出错。
您使用什么方法将数据插入数据库？
答案 6 :(得分：0)
我怀疑你有几个问题。
实际上有几种常用的方法来表示日文和中文文本，使用旧版编码（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或其他东西，那么答案就会相似，只是更复杂。
如果您的数据主要来自网络表单，则需要确保您的代码页设置为65001，通常使用＆lt;％@ codepage = 65001％＆gt;每个ASP文件顶部的指令。
此外，您需要向使用UTF-8的用户代理（Web浏览器）提供提示。有两种技术，一种涉及HTTP头;另一种选择是使用元标记伪造HTTP标头。
元标记解决方案：
HTTP标头解决方案，使用我生锈的ASP技能（假设javascript，但你可能正在使用vbscript，这将要求你删除分号） Response.ContentType = “text / html的”; Response.Charset的= “UTF-8”;
如果您要在Feed中使用数据而不是Web表单，则还需要确保数据正确转换。根据您的导入机制，指定源编码的方法是不同的，因此我将把它留作“读者练习”。
接下来，在将数据提交到SQL Server时，需要确保使用正确的SQL输入机制。如果你没有参数化你的查询（你应该是），你需要记住在查询中放置文本参数时使用N'MyText'表单而不是'MyText'。如果您要对文本进行参数化，那么当您使用adVarChar时，您应该使用adVarWChar。 （每种ADO数据类型都有相应的“W”类型）。
此外，某些浏览器使用HTML LANG属性作为提示，以便以适当的字体显示内容语言的文本。如果您碰巧知道您的内容所在的语言，可以将LANG =“ja-jp”添加到任何HTML元素（包括BODY）。然后，浏览器应使用该语言的合理默认字体（但如果您愿意，可以明确指定一种）。即使您为特定语言选择了不合适的默认字体，过去5年中制作的大多数浏览器都会做一些字体链接魔术，但如果使用合适的字体，您将获得更可靠的结果和更好的渲染性能。
作为补充说明， 如果您在浏览器上手动强制编码为shift-jis时获得几乎正确的结果，则表示您可能使用windows-1252作为您的字符集＆lt;％@ codepage = 1252％＆gt;并且你很幸运，内容并没有完全搞砸。有几个黑客可以恢复流入的Shift-Jis-in-1252或iso-8859-1，但它们不是100％可靠。
对于SQL Server上的排序规则，这有两个影响。在NVARCHAR和NTEXT字段上，它仅影响排序和查询（包括大小写，重音和假名敏感度）。在varchar和text字段上，它也会影响编码，但它不是解决问题的最明智的方法。