
我在给客户服务中,遇到过乱码问题,在连接字串中加入:charset=gb2312,问题解决。但你用的是JDBC连接,他使用的ODBC连接,应该类似,当时的具体情况是:
用户使用DBSync软件做MySQL的数据同步,MySQL的数据库字符集为utf8mb4,连接字符串采用ODBC 351,在任务设置的step2,列出的中文数据是乱码,在连接字串中加入:charset=gb2312,问题解决。
<%@
CODEPAGE=65001
%>
<%
ResponseCodePage=65001%>
<%
ResponseCharset="GBK"
%>
用写字板把
asp
文件另存为
GBK字符集
------------------------------------------------------------
或者查询之前先执行下面这一句
set
chs=connExecute("SET
NAMES
'gb2312'")
'查询数据库表
sql
=
"SELECT
FROM
tb_commondata"
Set
rs
=
connExecute(sql)
这样就不会乱码了
首先写一个数据库test,然后写一个表table,最后插入你想要写入的字段"工资"。出现了了乱码。就得1 启动MySQL,在里面输入 ALTER DATABASE `test` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin,将test数据库的编码设为utf8。2 修改表的编码:ALTER TABLE `category` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin 以上命令就是将一个表category的编码改为utf8 。3 修改字段的编码:直接在MySQL里右击表,然后点编辑表,在里面修改或输入代码: ALTER TABLE `test` CHANGE `dd` `dd` VARCHAR ( 45 ) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL。4得删除之前插入的字段之类的,再重新导入之前的字段
1 服务器指定字符集与客户字符集不同,而与加载数据字符集一致。
解决方法:对于这种情况,只需要设置客户端字符集与服务器端字符集一致就可以了,具体 *** 作如下:
查看当前字符集:
SQL> select from sysprops$
2 WHERE NAME=‘NLS_CHARACTERSET’;
NAME value$
NLS_CHARACTERSET ZHS16GBK
可以看出,现在服务器端Oracle数据库的字符集为‘ZHS16GBK’
根据服务器的字符集在客户端作相应的配置或者安装Oracle的客户端软件时指定:
如果还没安装客户端,那么在安装客户端时,指定与服务器相吻合的字符集即可;如果已经安装好了客户端,并且客户端为 sqlnet 20 以下版本,进入Windows的系统目录,编辑oracleini文件,用US7ASCII替换原字符集,重新启动计算机,设置生效;否则,如果,客户端为 sqlnet 20 以上版本,在Win98 下 运 行REGEDIT,第一步选HKEY_LOCAL_MACHINE,第二步选择SOFTWARE, 第三步选择 Oracle, 第四步选择 NLS_LANG, 键 入 与服 务 器 端 相 同 的 字 符 集
(本例为:HKEY_LOCAL_MACHINE/
SOFTWARE/ORACLE/NLS_LANG :AMERICAN _ AMERICA ZHS16GBK)。
如果是UNIX客户端,则:
SQL> conn / as sysdba
Connected
SQL> SQL> UPDATE sysPROPS$ SET value$=‘SIMPLIFIED CHINESE’
2 WHERE NAME=‘NLS_LANGUAGE’;
2 服务器指定字符集与客户字符集相同,与加载数据字符集不一致。
解决方法:强制加载数据字符集与服务器端字符集一致。要做到这一点,可以通过重新创建数据库,并选择与原卸出数据一致的字符集,然后IMP数据,这种情况仅仅适用于空库和具有同一种字符集的数据。
解决这类问题,也可以先将数据加载到具有相同字符集的服务器上,然后用转换工具卸出为foxbase 格式或access格式数据库,再用转换工具转入到不同字符集的Oracle数据库中,这样就避免了Oracle字符集的困扰。目前数据库格式转换的工具很多,像power builder50以上版本提供的pipeline及Microsoft Access数据库提供的数据导入/导出功能等。
3 服务器指定字符集与客户字符集不同,与输入数据字符集不一致。
对于这种情况,目前为止都还没有太好的解决方法。
通过上面的了解,我们知道,导致在后期使用数据库时出现种种关于字符集的问题,多半是由于在数据库设计、安装之初没有很好地考虑到以后的需要,所以,我们完全可以通过在服务器上和客户端使用相同的字符集来避免由此类问题引出的麻烦
怎样修改查看Oracle字符集
a数据库服务器字符集select from nls_database_parameters,其来源于props$,是表示数据库的字符集。
b客户端字符集环境select from nls_instance_parameters,其来源于v$parameter,
表示客户端的字符集的设置,可能是参数文件,环境变量或者是注册表
c会话字符集环境 select from nls_session_parameters,其来源于v$nls_parameters,表示会话自己的设置,可能是会话的环境变量或者是alter session完成,如果会话没有特殊的设置,将与nls_instance_parameters一致。
客户端的字符集要求与服务器一致,才能正确显示数据库的非Ascii字符。如果多个设置存在的时候,alter session>环境变量>注册表>参数文件
实际情况
我用select from nls_database_parameters
PARAMETER VALUE
------------------------------ ------------------------------
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS ,
NLS_CHARACTERSET ZHS16GBK
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HHMISSXFF AM
PARAMETER VALUE
------------------------------ ------------------------------
NLS_TIMESTAMP_FORMAT DD-MON-RR HHMISSXFF AM
NLS_TIME_TZ_FORMAT HHMISSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HHMISSXFF AM TZR
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_RDBMS_VERSION 102010
说明我在创建数据库时指定的字符集是ZHS16GBK,我用
update sysprops$ set value$='AL32UTF8' where name='NLS_CHARACTERSET';
修改了字符集,但插入中文时仍然有问题,这或许就如上面资料所说的通过修改SYSPROPS$来修改主要是对应客户端的显示,与存储无关,
所以仍旧是乱码。
然后我重新创建了个数据库,指定字符集为AL32UTF8,插入中文就没问题了。
可见我们如果要在数据库中显示中文,在创建数据库时一定哟指定好所用的字符集。
解决get请求乱码问题:若你的Tomcat版本服务器在80以下,则更改Tomcat下conf目录下的serverxml,如下图所示
再解决post请求乱码问题,在web项目的webxml最开始加上:
再看看你的页面的编码问题:
a若是jsp页面
b若是html页面
4 最后还是没解决,修改数据库的编码问题:
在mysql的连接文件properties的中的jdbcurl最后面加上
?characterEncoding=utf-8&allowMultiQueries=true
如下图所示:
若有帮助,记得点赞,若能关注,最好点个关注,谢谢!
以上就是关于使用JDBC连接SQL SERVER的数据库后,读取出来的中文数据是乱码全部的内容,包括:使用JDBC连接SQL SERVER的数据库后,读取出来的中文数据是乱码、关于ASP程序读取MYSQL数据库中文显示乱码的问题、数据库写入的中文变成乱码如何解决等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)