6 楼 JamesKing 2007-03-08
听了搂主的描述,也说一下自己做的一个国际化项目的经验。这个项是使用
架构:VC++的ATL Server进行开发;
页面:web页面是UTF-8编码,CodePage=65001;
应用服务器程序:编译好的dll是Unicode编码;
操作系统:中文Windows 2003 Server;
数据库联接方式:OLEDB
数据库:中文MSSQL Sever2005,显示Codepage=936,
字段都是支持Unicode的nchar,nvarcha,nText;
SELECT COLLATIONPROPERTY('Chinese_PRC_Stroke_CI_AI', 'CodePage')
936
________________________________________________
发现从Web页面提交的数据到数据后查询总是乱码,经过检查,发现保存的数据直接就是是UTF-8编码,其CodePage=65001,而数据默认显示支持的Unicode语言版本Codepage=936(即是简体中文),所以数据查询的就是乱码,想过两种方案:
1,怀疑是数据时UTF-8编码,而SQLServer是UCS-2 版本,相通过UTF-8-〉UCS-2转换,发现还是行不通,仍然乱码,此路不通;
2,搜索了网络发现并没有现成的例子,经过测试中文系统使用Web页面为GB2312编码提交的数据到数据很正常,基于Windows2003是支持Unicode(UCS-2),排除操作系统的问题,这个过程经过分析可以这么理解:936(Web页面编码GB2312)-〉Unicode(应用服务器端)-〉Unicode(数据库OLEDB传输)-〉UCS-2(数据库)-〉自动转化为936(Unicode简体中文语言版本),而使用UTF-8的Web页面这个过程就是:65001(Web页面编码UTF-8)-〉Unicode(应用服务器端)-〉Unicode(数据库OLEDB传输)-〉UCS-2(数据库)-〉自动转化为936(Unicode简体中文语言版本),所以最后的使用数据分析查询器看到的就是乱码,最后确定的方案就是两种手段:一是更改数据查询分析器的Codepage为65001,很显然当前的SQLServer没有这个功能(没找到?知道的告诉我);二是将前端的UTF-8转为GB2312编码,很显然这个最后成功了,这个过程程序还是保留了所有的多语言的特性,一位UTF-8-〉GB2312,这个过程是无损的,因为是UTF-8->Unicode->GB2312.
总结:
1,MSSQL Server不支持UTF-8(Codepage=65001)直接显示,数据库查询的显示数据使用默认的Codepage,如简体中文版就是936,繁体中文是950,韩文949等,因此从使用的Web页面UTF-8提交的数据自动转换为所用的Codepage显示,因此就是乱码,这个有待MS SQL Server进一步发展,因为现在Oracle和MySQL是可以支持直接UTF-8存储显示,国际化时请先将数据由UTF-8编码转化为MSSQL数据库默认的编码,读写出来这个过程着相反进行转化,这个过程看起来会因为转化过程影响处理速度(抉择于国际化);
2,ASP/ASPX/JSP/PHP使用MSSQL Server编程支持UTF-8都会面临这样的问题,可以看看MSDN有关这个方面的解释
http://support.microsoft.com/kb/232580/zh-cn
演示网址:http://www.bomege.comhttp://www.bomege.com 留言部分
概要
某些应用程序 (尤其是基于 Web) 必须处理是用 UTF-8 编码方法编码 Unicode 数据。 SQL Server 7.0 和 SQL Server 2000 使用 Unicode 编码 (UCS-2) 不同和不识别 UTF-8 作为有效字符数据。 本文讨论一些选项用于处理与此情况。
更多信息
可以以许多不同方式进行编码 Unicode 数据。 UCS-2 和 UTF-8 是两种常见方法来存储表示 Unicode 字符位模式。 作为 UCS-2 MicrosoftWindowsNT、 SQLServer、 Java、 COM, 和 SQLServerODBC 驱动程序和 OLEDB 提供所有内部表示 Unicode 数据。
用于使用 SQL Server 7.0 或 SQL Server 2000 作为后端服务器对于应用程序, 发送和接收 Unicode 数据是以 UTF-8 编码选项包括: 1. 如果应用程序使用 Active Server Pages (ASP) 并且您使用 Internet Information Server (IIS) 5.0 和 Microsoft Windows 2000, " < % Session.Codepage=65001 % > " 添加到您的服务器端 ASP 脚本。 这指示 IIS 以转换所有动态生成字符串 (Response.Write) 从 UCS-2 以 UTF-8 它们发送到客户端之前自动示例:。
如果您不想启用会话, 也可以使用服务器端指令 " < > % @ CodePage " = 65001 %。
自动从客户端发送到服务器通过 GET 或 POST 任何 UTF-8 数据还转换为 UCS-2。 Session.Codepage 属性是推荐方法以处理 Web 应用程序中 UTF-8 数据。 IIS 4.0 和 Windows NT 4.0 上没有此 Codepage 设置。 有关其他信息, 请参阅下列 Microsoft 知识库文章:
254313 (http://support.microsoft.com/kb/254313/EN-US/) 错误消息: ActiveServerPages 错误 ASP 0203 ' ' 无效代码
2. 根据应用程序中翻译与 UCS-2 或 UTF-8。 对于该类型转换的示例代码是在 Unicode 联合会的站点位于:
http://www.unicode.org/Public/PROGRAMS/CVTUTF (http://www.unicode.org/Public/PROGRAMS/CVTUTF)
Internet Request For Comments 文档 RFC2279 中可以找到要转换为 UTF-8 UCS-2 算法的高级说明。
在 WindowsNT 或 Windows 2000, 您可能使用 Win 32 函数 MultiByteToWideChar 和 WideCharToMultiByte 来通过传递常量 CP_UTF8 UTF-8 转换与 UCS-2 作为第一个参数对函数 (65001)。
3. 修改应用程序以使用 UCS-2 代替 UTF-8 编码。
4. 使用 BINARY / VARBINARY / IMAGE 列在服务器上存储实际 UTF-8 数据。 SQLServer 上存储 UTF-8 数据意味着您可不使用 SQLServer 来排序或查找数据一样有效字符数据的这些值范围。 类型的列包含 UTF-8 数据不会返回预期结果包括 " ORDERBY ", 更上 - 比操作 < > 并小于 "-" 比 " 比较和内置 SQLServer 字符串处理函数如 SUBSTRING() "。
但是, 相等比较, 工作只要等效字符串比较是在字节级别。 注意: 您如果 UTF-8 数据存储在 SQLServer 应该不使用字符列 (CHAR/NCHAR / VARCHAR 和等等)。 UTF-8 是无效字符数据到 SQLServer, 和通过非字符数据存储在字符列可能遇到问题如以下 Microsoft 知识库文章中讨论问题:
155723 (http://support.microsoft.com/kb/155723/EN-US/) INF: SQLServer 截断的 DBCS 字符串
234748 (http://support.microsoft.com/kb/234748/EN-US/) PRB: SQLServerODBC 驱动程序将语言事件转换为 Unicode
如果考虑此选项, 请记住您将需要执行从 UTF-8 转换为 UCS-2 如 ODBC、 OLEDB、 COM, 此应用程序中如果曾经需要访问 UTF-8 数据从 Web 浏览器 (例如, 从非基于 Web 的 ODBC 应用程序) 以外任何应用程序存储在 SQLServer Win32API 调用、 VB 和 C 运行时字符串处理函数不能使用 UTF-8 数据。 这将是翻译负担移到其他应用程序。
5. 如果要求不包含需要存储数据的语言是无法满足由单个代码页, 组合可能不需要使用 Unicode。
Unicode 支持引入到 SQLServer 以 SQL Server 7.0。 因为 SQL Server 6.5 不支持的 Unicode 数据, 存储仅选项对于 SQL Server 6.5 列于步骤 4 和步骤 5。
架构:VC++的ATL Server进行开发;
页面:web页面是UTF-8编码,CodePage=65001;
应用服务器程序:编译好的dll是Unicode编码;
操作系统:中文Windows 2003 Server;
数据库联接方式:OLEDB
数据库:中文MSSQL Sever2005,显示Codepage=936,
字段都是支持Unicode的nchar,nvarcha,nText;
SELECT COLLATIONPROPERTY('Chinese_PRC_Stroke_CI_AI', 'CodePage')
936
________________________________________________
发现从Web页面提交的数据到数据后查询总是乱码,经过检查,发现保存的数据直接就是是UTF-8编码,其CodePage=65001,而数据默认显示支持的Unicode语言版本Codepage=936(即是简体中文),所以数据查询的就是乱码,想过两种方案:
1,怀疑是数据时UTF-8编码,而SQLServer是UCS-2 版本,相通过UTF-8-〉UCS-2转换,发现还是行不通,仍然乱码,此路不通;
2,搜索了网络发现并没有现成的例子,经过测试中文系统使用Web页面为GB2312编码提交的数据到数据很正常,基于Windows2003是支持Unicode(UCS-2),排除操作系统的问题,这个过程经过分析可以这么理解:936(Web页面编码GB2312)-〉Unicode(应用服务器端)-〉Unicode(数据库OLEDB传输)-〉UCS-2(数据库)-〉自动转化为936(Unicode简体中文语言版本),而使用UTF-8的Web页面这个过程就是:65001(Web页面编码UTF-8)-〉Unicode(应用服务器端)-〉Unicode(数据库OLEDB传输)-〉UCS-2(数据库)-〉自动转化为936(Unicode简体中文语言版本),所以最后的使用数据分析查询器看到的就是乱码,最后确定的方案就是两种手段:一是更改数据查询分析器的Codepage为65001,很显然当前的SQLServer没有这个功能(没找到?知道的告诉我);二是将前端的UTF-8转为GB2312编码,很显然这个最后成功了,这个过程程序还是保留了所有的多语言的特性,一位UTF-8-〉GB2312,这个过程是无损的,因为是UTF-8->Unicode->GB2312.
总结:
1,MSSQL Server不支持UTF-8(Codepage=65001)直接显示,数据库查询的显示数据使用默认的Codepage,如简体中文版就是936,繁体中文是950,韩文949等,因此从使用的Web页面UTF-8提交的数据自动转换为所用的Codepage显示,因此就是乱码,这个有待MS SQL Server进一步发展,因为现在Oracle和MySQL是可以支持直接UTF-8存储显示,国际化时请先将数据由UTF-8编码转化为MSSQL数据库默认的编码,读写出来这个过程着相反进行转化,这个过程看起来会因为转化过程影响处理速度(抉择于国际化);
2,ASP/ASPX/JSP/PHP使用MSSQL Server编程支持UTF-8都会面临这样的问题,可以看看MSDN有关这个方面的解释
http://support.microsoft.com/kb/232580/zh-cn
演示网址:http://www.bomege.comhttp://www.bomege.com 留言部分
概要
某些应用程序 (尤其是基于 Web) 必须处理是用 UTF-8 编码方法编码 Unicode 数据。 SQL Server 7.0 和 SQL Server 2000 使用 Unicode 编码 (UCS-2) 不同和不识别 UTF-8 作为有效字符数据。 本文讨论一些选项用于处理与此情况。
更多信息
可以以许多不同方式进行编码 Unicode 数据。 UCS-2 和 UTF-8 是两种常见方法来存储表示 Unicode 字符位模式。 作为 UCS-2 MicrosoftWindowsNT、 SQLServer、 Java、 COM, 和 SQLServerODBC 驱动程序和 OLEDB 提供所有内部表示 Unicode 数据。
用于使用 SQL Server 7.0 或 SQL Server 2000 作为后端服务器对于应用程序, 发送和接收 Unicode 数据是以 UTF-8 编码选项包括: 1. 如果应用程序使用 Active Server Pages (ASP) 并且您使用 Internet Information Server (IIS) 5.0 和 Microsoft Windows 2000, " < % Session.Codepage=65001 % > " 添加到您的服务器端 ASP 脚本。 这指示 IIS 以转换所有动态生成字符串 (Response.Write) 从 UCS-2 以 UTF-8 它们发送到客户端之前自动示例:。
如果您不想启用会话, 也可以使用服务器端指令 " < > % @ CodePage " = 65001 %。
自动从客户端发送到服务器通过 GET 或 POST 任何 UTF-8 数据还转换为 UCS-2。 Session.Codepage 属性是推荐方法以处理 Web 应用程序中 UTF-8 数据。 IIS 4.0 和 Windows NT 4.0 上没有此 Codepage 设置。 有关其他信息, 请参阅下列 Microsoft 知识库文章:
254313 (http://support.microsoft.com/kb/254313/EN-US/) 错误消息: ActiveServerPages 错误 ASP 0203 ' ' 无效代码
2. 根据应用程序中翻译与 UCS-2 或 UTF-8。 对于该类型转换的示例代码是在 Unicode 联合会的站点位于:
http://www.unicode.org/Public/PROGRAMS/CVTUTF (http://www.unicode.org/Public/PROGRAMS/CVTUTF)
Internet Request For Comments 文档 RFC2279 中可以找到要转换为 UTF-8 UCS-2 算法的高级说明。
在 WindowsNT 或 Windows 2000, 您可能使用 Win 32 函数 MultiByteToWideChar 和 WideCharToMultiByte 来通过传递常量 CP_UTF8 UTF-8 转换与 UCS-2 作为第一个参数对函数 (65001)。
3. 修改应用程序以使用 UCS-2 代替 UTF-8 编码。
4. 使用 BINARY / VARBINARY / IMAGE 列在服务器上存储实际 UTF-8 数据。 SQLServer 上存储 UTF-8 数据意味着您可不使用 SQLServer 来排序或查找数据一样有效字符数据的这些值范围。 类型的列包含 UTF-8 数据不会返回预期结果包括 " ORDERBY ", 更上 - 比操作 < > 并小于 "-" 比 " 比较和内置 SQLServer 字符串处理函数如 SUBSTRING() "。
但是, 相等比较, 工作只要等效字符串比较是在字节级别。 注意: 您如果 UTF-8 数据存储在 SQLServer 应该不使用字符列 (CHAR/NCHAR / VARCHAR 和等等)。 UTF-8 是无效字符数据到 SQLServer, 和通过非字符数据存储在字符列可能遇到问题如以下 Microsoft 知识库文章中讨论问题:
155723 (http://support.microsoft.com/kb/155723/EN-US/) INF: SQLServer 截断的 DBCS 字符串
234748 (http://support.microsoft.com/kb/234748/EN-US/) PRB: SQLServerODBC 驱动程序将语言事件转换为 Unicode
如果考虑此选项, 请记住您将需要执行从 UTF-8 转换为 UCS-2 如 ODBC、 OLEDB、 COM, 此应用程序中如果曾经需要访问 UTF-8 数据从 Web 浏览器 (例如, 从非基于 Web 的 ODBC 应用程序) 以外任何应用程序存储在 SQLServer Win32API 调用、 VB 和 C 运行时字符串处理函数不能使用 UTF-8 数据。 这将是翻译负担移到其他应用程序。
5. 如果要求不包含需要存储数据的语言是无法满足由单个代码页, 组合可能不需要使用 Unicode。
Unicode 支持引入到 SQLServer 以 SQL Server 7.0。 因为 SQL Server 6.5 不支持的 Unicode 数据, 存储仅选项对于 SQL Server 6.5 列于步骤 4 和步骤 5。
5 楼 BingJetMa 2006-11-19
问题解决了。在INSERT,UPDATE,查询的SQL语句中,凡是nvarchar(),nchar的字段前面加上N,SQL SERVER 就可以自动把页面传过来的UTF-8编码的字串转化成UCS-2,SQL SERVER 所支持的。显示到页面的时候,在UTF-8页面上直接显示数据库里的UCS-2编码的字符串,也没有乱码。
4 楼 BingJetMa 2006-11-17
together 写道
看起来是你数据库的字符集的问题,
可以查一下类似下面的语句,第一个参数是安装数据库时所选的字符集:
SELECT COLLATIONPROPERTY('Chinese_PRC_Stroke_CI_AI_KS_WS', 'CodePage')
如果返回值不是936,说明不支持GBK。
sqlserver里带N的类型,表示是使用utf-8存储的。
sqlserver7/2k采用ucs-2而没有采用utf-8是有它自己的小99的。不知道2005版如何。
可以查一下类似下面的语句,第一个参数是安装数据库时所选的字符集:
SELECT COLLATIONPROPERTY('Chinese_PRC_Stroke_CI_AI_KS_WS', 'CodePage')
如果返回值不是936,说明不支持GBK。
sqlserver里带N的类型,表示是使用utf-8存储的。
sqlserver7/2k采用ucs-2而没有采用utf-8是有它自己的小99的。不知道2005版如何。
曾想过通过升级数据库的方式解决,我查过资料sql server 2005,依然是ucs-2。
![](https://i-blog.csdnimg.cn/blog_migrate/e5ecfc697454465e03da92a37ef5d2ee.gif)
"sqlserver里带N的类型,表示是使用utf-8存储的。" 这句话不太对,带N的类型是指nchar,nvarchar,ntext这些吧,他们代表使用UNICODE存储,但是内部的UNICODE编码是UCS-2,据我所知。
3 楼 together 2006-11-17
看起来是你数据库的字符集的问题,
可以查一下类似下面的语句,第一个参数是安装数据库时所选的字符集:
SELECT COLLATIONPROPERTY('Chinese_PRC_Stroke_CI_AI_KS_WS', 'CodePage')
如果返回值不是936,说明不支持GBK。
sqlserver里带N的类型,表示是使用utf-8存储的。
sqlserver7/2k采用ucs-2而没有采用utf-8是有它自己的小99的。不知道2005版如何。
可以查一下类似下面的语句,第一个参数是安装数据库时所选的字符集:
SELECT COLLATIONPROPERTY('Chinese_PRC_Stroke_CI_AI_KS_WS', 'CodePage')
如果返回值不是936,说明不支持GBK。
sqlserver里带N的类型,表示是使用utf-8存储的。
sqlserver7/2k采用ucs-2而没有采用utf-8是有它自己的小99的。不知道2005版如何。
2 楼 BingJetMa 2006-11-17
Readonly 写道
偶们的系统在SQL Server上好像没有遇到这种问题,偶们后台的数据库栏位类型都是varchar,不用nvarchar,前台用UTF-8编码。
你可以贴一些乱码的繁体或者韩日文来么,偶在自己的系统上试试看。
你可以贴一些乱码的繁体或者韩日文来么,偶在自己的系统上试试看。
谢谢回复,从GOOGLE 搜来的日文,韩文,你拿来试试,理论上讲用varchar()是不支持UNICODE的,SQL SERVER 支持UNICODE 就是通过nchar, nvarchar,ntext这些数据类型,而不像ORACLE既有unicode编码的数据类型,同时还有unicode编码的数据库,在安装的时候就指定了。
日文:
URLが変更となりました。 2006年4月1日をもちまして、豊田通商株式会社と株式会社トーメンは合併し、URLはhttp://www.toyota-tsusho.comに変更になりました。 豊田通商株式会社のホームページをご覧になられる方は下記よりご覧ください
韩文:我机子上字库没有安装,看到的乱码,拷贝不过来。
繁体中文:
如果利用地表陸地的1%的面積來截取太陽能,再假設太陽能的轉換率是10%的話,其所產生的瓦數,將是相等於我們目前全世界能源消耗量的兩倍。」上述科學研究的精算結果,明確指出發展永續能源的重要性與高度應用價值... >> 全文
你可以试一下。
1 楼 Readonly 2006-11-17
偶们的系统在SQL Server上好像没有遇到这种问题,偶们后台的数据库栏位类型都是varchar,不用nvarchar,前台用UTF-8编码。
你可以贴一些乱码的繁体或者韩日文来么,偶在自己的系统上试试看。
你可以贴一些乱码的繁体或者韩日文来么,偶在自己的系统上试试看。