在AnySQL.net中搜索标签(Tags) 'Charset' 的结果:

Oracle不行再用AUL

    继上次DUL搞不定CLOB中文问题后, 又遇到了NVARCHAR2中文问题, 有人在正式库中使用了这种数据类型, 遇到数据库损坏(System表空间被覆盖)后, 请人用Oracle DUL去搞的, 好象搞不定NVARCHAR2中的中文问题.     原因只有两种, 没有搞明白Oracle DUL这方面的设置参数, 或者是Oracle DUL实在不支持这种数据类型中的中文. CLOB的中文问题, 我还是费了两个晚上搞定的, 这一次的NVARCHAR2问题, 则没有费任何事, 早就支持了. 只是没有用户真的使用这种数据类型, 一直没有发挥作用而已, 没想到一上来又和Oracle DUL PK了一把.     照这样下去, AUL可以卖给Oracle了, 至少可以卖给Oracle中国, 反正这种事中国遇到的特别多. 只要用心去考虑和做事, 可以做得比原厂更出色啊.     能PK过Oracle自已的东西, 还是很有轻飘飘的感觉的....

导出时的字符集转换

    Oracle数据库支持多种字符集, 目标是为了方便支持全球的各种不同语言, 但在实际生活中则常给我们带来麻烦, 98年刚出道时在老板兼师傅的指导下犯过一次错, 将所有的中文都导出成了问号, 最后客户请了一个学五笔输入法的班来重新纠正那些问号, 因此需要特别加注意, 一般情况下不允许在导出时进行字符集转换.     准确的方法是, 导出工具所用的NLS_LANG设置和数据库的字符集一致就对了, 在exp的日志输出中可以看到以下信息: Connected to: Oracle Database 10g Enterprise Edition ...... With the Partitioning, OLAP and Data Mining options Export done in UTF8 character set and AL16UTF16 NCHAR...

Oracle csscan工具的工作原理

    再来回顾一下上一篇中的两条样本数据. SQL> col col2 format a40 SQL> select col1, dump(col2) col2 from t_charset; COL1       COL2 ---------- ---------------------------------------- ZHS16GBK   Typ=1 Len=6: 228,184,173,229,155,189 UTF8       Typ=1 Len=4: 214,208,185,250     其实csscan的工作原理和CONVERT函数一样, 如果数据库中存放的已经是UTF8字符集了, 那么肯定可以转换到UTFE字符集, 因此我们在使用csscan或CONVERT函数时, 源字符集指定为UTF8而目标字符集指定为UTFE(因为是UTF8的超集). 先测试第一条, 数据库中存放的不是UTF8格式的, 因此转换就报错了. SQL> SELECT CONVERT(COL2,'UTF8','UTFE')...

Oracle的字符集转换的一个小测试

    对于Oracle的字符集, 一直不是很明白的, 除了在出道的当年(98年)范过一次这方面的错后, 到还没有第二次, 算是走运了. 下面来做一个小实验, 加深一下理解, 我测试用的数据库端是UTF8格式的, 测试用的表结构如下, 第一个字段用于记录NLS_LANG的设置, 第二列则为相同的值. create table t_charset(col1 varchar2(10), col2 varchar2(20));     接下来, 我在Windows在命令窗口(cmd.exe)中更改NLS_LANG的设置为中文, 然后插入一条记录. set NLS_LANG=.ZHS16GBK SQL> insert into t_charset values ('ZHS16GBK','中国');     接下来更改NLS_LANG的设置为中文, 然后插入另一条记录. set NLS_LANG=.UTF8 SQL> insert...

dmp2utf8的下载量骤增, 不知什么原因?

    上个月的统计中还没有发现有多少人下载这个的, 这个月却发现下载量惊人, 短短的10天中, 从站点的AWStats统计看已经被下载了1300多次, 真是不可思议?     这个工具的唯一作用是去改Oracle DMP文件头中的字符集标识, 并没有多少的实际用途, 难道最近玩字符集的人这么多?     希望其他的一些个人工具也有这么大的下载量....

为什么到二十一世纪还要改sys.props$呢?

    很久没有人去改sys.props$表了, 今天却出了一个, 在9i以前的话, 改错了NLS_CHARACTERSET的值是不行的, 数据库就起不来了. 但到了9i后, 是可以的, 也许有人知道了这一点所以放心地去做了. 为了慎重起见, 我重做了如下实验: SQL> UPDATE PROPS$ SET VALUE$='WE8ISO8859PP'   2  WHERE NAME='NLS_CHARACTERSET'; 1 row updated.     单改这一个值是可以起来的, 接下来我改其他所有的值呢? SQL> UPDATE PROPS$ SET VALUE$='WE8ISO8859PP'; 27 rows updated.     这样改了就是起不来的, 另外eygle在同一时间测试, 发现单改错了NLS_NCHAR_CHARACTERSET就不行了. SQL>...

WE8ISO8859P1字符集下,JDBC的中文支持问题

    当数据库的字符集为US7ASCII, WE8DEC, WE8ISO8859P1及WE8MSWIN1252等单字节的字符集时, 使用JDBC时总发现不能准确地处理中文字符, 这个问题几年前就困扰着我, 一直也没有解决的办法. 以前遇到这些数据库的字符集时, 总是将$JAVA_HOME\lib目录下的charsets.jar移走来解决, 但是这样并不能解决CLOB中的中文字符问题. 昨天coolyl又问了这个同样的问题, 我在试验时发现JRE 1.6版本和JRE 1.4版本有所区别, 通过用-Dfile.encoding=ISO-8859-1的命令行选项, 在1.6下可以成功显示汉字, 而1.4下面同样的方法却不行. c:\jdk\sun160\bin\java -Dfile.encoding=ISO-8859-1 -jar jlib\oasql.jar c:\jdk\sun142\bin\java -Dfile.encoding=ISO-8859-1 -jar jlib\oasql.jar     使用1.6版本的JRE时, 情况如下: ASQL> select * from nls_database_parameters     2    where parameter='NLS_CHARACTERSET'; PARAMETER        VALUE ---------------- ------------...

更改dmp文件中的字符集 -- dmp2utf8

    看到过几次"如何修改dmp文件字符集"的问题, 我自已仅在刚入门时, 在老板的指导下用过一次. 到现在也不知道这种直接更新dmp文件第二个和第三个字节的方法到底安全不安全, 因为除了第二个第三个字节外, dmp文件中, 每个字符列都有相应的字符集标识的.     虽然如此, 还是发布一个小工具吧, 可以用于修改dmp中的字符集标识, 新工具命令为: dmp2utf8, 命令使用语法如下: Usange: dmp2utf8 dmpfile [charset id]     如果不指定第二个参数, 则默认将改dmp文件为utf-8字符集, 这就是名字的由来.     更安全的做法应当是Clone一个数据库, 然后更新字符集: ALTER DATABASE CHARACTER SET INTERNAL_USE target_char_set;     然后进行导出,...

根据标记(Tags)来查找:

分类 | Categories

本站基于MT-3.36免费版, 和Fenng设计的模板.
(©)版权所有, 2004 - 2008, www.AnySQL.net, 保留所有权利.
MSN: loufangxin(a)msn.com, Mail: anysql(at)126.com/support(at)iamdba.com, Skype ID:anysql