浅析Oracle多语言环境下to_date时间转换[Oracle防范]

现象:在多语言环境下利用过Oracle的同学想必都碰到过这样一个问题,

date_v date;  
date_v := to_date('2010/11/16');--或'2010/11/16' 

同一个服务器,差别Oracle clinet 不一定都行得通.

缘由: 不指定转换字符串的情形下,Oracle利用既定的格局串举行日期转换操作,履行SELECT * FROM NLS_SESSION_PARAMETERS;察看NLS信息,此中NLS_DATE_FORMAT是指当前利用的格局化字符串.我这里是"DD-MON-RR",dd代表日rr代表年mon代表月,所以to_date('2010/11/16')==to_date('2010/11/16','DD-MON-RR'),

MON在NLS_LANGUAGE为AMERICAN的情形下只辨认Nov而不是别11,所以转换失利.

办理: 既然知道问题缘由了,办理这个问题有三个办法.

1,更改NLS_LANGUAGE会使NLS_DATE_FORMAT同步为呼应的格局.我们这里需求japanese格局.我通过增添环境变量（NLS_LANG=JAPANESE_JAPAN.JA16SJIS）实现.

NLS_DATE_FORMAT变成RR-MM-DD了,测试,select to_date('2010/11/15') from dual--ok.

2,增添环境变量NLS_DATE_FORMAT（RR-MM-DD或yy-mm-dd或yy/mm/dd任何你需求的格局）.

测试,select to_date('2010/11/15') from dual--ok.

这里要注意经过我测试,rr和yy是一个意思 ,衔接标记-和/都可以使转换成功.

更改NLS_LANGUAGE或NLS_DATE_FORMAT的办法可以谷歌以下．

到这里基本大功告成了,但是你大概会说我们不能随便改正Oracle client的这些配置,因为其他实例大概需求它!下面是第三个办法

3,to_date有个重载办法,供应转换需求的format.

无论NLS_DATE_FORMAT是什么,select to_date('2010/11/15','yy/mm/dd') from dual--ok.

但是还是不要高兴过早了,select to_date('2010/nov/15','yy/mon/dd') from dual--不一定ok.

当NLS_LANGUAGE环境为AMERICAN时是OK的,为East Asia language时mon格局符真正辨认的是11月（这里japan和china还是不一样的,看起来是一个字,但是从我机械输入select to_date('2010/11月/15','yy/mon/dd') from dual却出错.

具体细节可以参考文章http://www.eygle.com/special/NLS_CHARACTER_SET_05.htm

目前问题懂得了,但办理办法这么多,莫非转换一个字符串到日期真的这么周折?

我挑选第三个办法,因为它是我能掌握的.select to_date('2010/11/15','yy/mm/dd') from dual--ok,因为mm的转译永久是阿拉伯数字啊.

案例:这样一个情形,目前有个存储要布置在未知地理未知服务器上,它需求一个date参数,plsql程序员想当然的吧它定义成了date,不巧,调用存储的另一个程序员是个想通过脚本来调用存储,并且通过windows筹划任务触发脚本履行,这个脚本给了一个2010/11/15,看起来没任何问题,但是不巧这台利用服务器的Oracle客户端的NLS_LANGUAGE=AMERICAN,真是无巧不成书啊,当Oracle做这样一个调用前的参数转换工作的时刻 date_v date; date_v := '2010/11/16'（这个转换是默许的不可控的）;灾难到临了.

怎么避免这样的灾难呢?参数改成nvarchar吧,自己做参数转换,利用上面我们的第三个办理办法data_v:= to_date(data_vchar,'yy/mm/dd'),其实灾难可以避免.

有人会说,调用存储的人传了个2010￥/11……/16!怎么办,你的yyyy/mm/dd若何处理?当然没法处理,我的办法是给出一个精确的文档奉告对方参数应当是什么格局的,出错了也可以解除责任了. 别的我自己转换可以增添一些非常机制来提醒问题,Oracle自动转换出错了但是很霸道的. 　　以上是“浅析Oracle多语言环境下to_date时间转换[Oracle防范]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：