dblink 两端数据库字符集不同导致的乱码解决办法
来源:互联网 发布:网络综艺节目收视率 编辑:程序博客网 时间:2024/06/05 00:16
场景:
数据库A: WE8DEC字符集
数据库B: ZHS16GBK
dblink A->B : to_b
SELECT
显示的结果为乱码:?????
原因:
作为dblink的两端,在A通过to_b访问B数据库时,A为B的客户端,由于数据库A的字符集为WE8DEC,为了使A数据库服务器上的其他应用正常使用,所以在A数据库服务器上的已经设置环境变量NLS_LANG=AMERICAN_AMERICA.WE8DEC,而此客户端字符集和B数据库的核心字符集ZHS16GBK不同,因此在返回结果时,要进行字符集转换,但由于WE8DEC和ZHS16GBK不兼容,因此转换失败,出现乱码;
解决方法:
方法一:在A数据库上修改环境变量NLS_LANG为AMERICAN_AMERICA.ZHS16GBK,使其和数据库核心字符集兼容的字符集;
这样做法,存在一个较难接受的问题,即A数据库服务器上的应用例如sqlplus、exp等,需要每次运行时考虑NLS_LANG的设置。
方法二:使用UTL_RAW包进行处理
1),在B数据库上,创建视图:
create or replace view v_user_info as select utl_raw.cast_to_raw(cn_name) cn_name from user_info;
2),在A数据库上,创建视图:
create or replace view v_user_info as select utl_raw.cast_to_varchar2(cn_name) cn_name
这样就让A/B之间的数据传输,变成了裸数据的传输,避免了字符集的不兼容性转换。
结果显示正常。
- dblink 两端数据库字符集不同导致的乱码解决办法
- 演示字符集不同导致插入,查询产生乱码的过程
- Oracle数据库字符集和客户端字符集不同的解决办法
- 输出字符集和javascript的字符集冲突导致乱码的解决办法!
- MySQL数据库的字符集和copy_and_convert 字符集不同导致CPU资源额外消耗
- jdbc连接字符集为us7ascii的oracle数据库乱码解决办法
- 不同数据库间的数据访问--dblink
- 字符集的不同导致内存泄露
- jdbc操作非中文字符集oracle数据库导致的中文字符读写乱码的解决方案
- 不同字符集写文件的乱码问题
- Oracle不同数据库访问DBLink
- 解决不同字符集数据库数据传输中文乱码问题
- 数据库乱码的解决办法
- 创建oracle dblink&sql操作不同数据库的表
- oracle使用dblink和cursor更新不同数据库的记录
- Oracle 数据库字符集与客户端字符集不一致,导致中文数据显示乱码
- mysql 乱码解决办法---创建数据库时指定字符集
- MySQL 字符集导致SQL连接之后中文乱码的问题!
- mysql 中文字段排序( 按拼音首字母排序) 的查询语句
- DirectX11 龙书 暴力输出调试信息方法
- JavaScript slice() 方法
- 经典排序——冒泡排序——C语言版
- 高级篇(5.6) 02. VDOM 虚拟域
- dblink 两端数据库字符集不同导致的乱码解决办法
- Android开发"夜间模式"换肤功能
- java多线程核心接口 — ExecutorService 的理解与使用
- Windows API调用对话框资源
- node+express+mongodb,登陆代码备份(自用)
- Spring AOP的一些基础知识
- RAID详解
- GPS信噪比解析
- iOS多线程开发其实很简单