<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/atom10full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?><feed xmlns="http://www.w3.org/2005/Atom" xmlns:openSearch="http://a9.com/-/spec/opensearchrss/1.0/" xmlns:georss="http://www.georss.org/georss" xmlns:gd="http://schemas.google.com/g/2005" xmlns:thr="http://purl.org/syndication/thread/1.0"><id>tag:blogger.com,1999:blog-7699289088757916196</id><updated>2012-02-20T21:53:44.378-08:00</updated><category term="JAVA" /><category term="Oracle" /><category term="Database" /><title type="text">新知识分子</title><subtitle type="html">每个人都应该肯定地感觉到，在他的周围或他努力能够达到的范围内……人类能够获得一种正当、人道的生存方式，而且正义是至关紧要的。</subtitle><link rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml" href="http://www.fengbin.com/feeds/posts/default" /><link rel="alternate" type="text/html" href="http://www.fengbin.com/" /><author><name>Feng Bin</name><uri>https://profiles.google.com/107654493011194497946</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="//lh4.googleusercontent.com/-SMyzitk_3yQ/AAAAAAAAAAI/AAAAAAAAAAA/kzRoO_DGEi8/s512-c/photo.jpg" /></author><generator version="7.00" uri="http://www.blogger.com">Blogger</generator><openSearch:totalResults>2</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>25</openSearch:itemsPerPage><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="self" type="application/atom+xml" href="http://feeds.feedburner.com/fengbin/tech" /><feedburner:info xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0" uri="fengbin/tech" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="hub" href="http://pubsubhubbub.appspot.com/" /><link rel="license" type="text/html" href="http://creativecommons.org/licenses/by/2.5/" /><logo>http://creativecommons.org/images/public/somerights20.gif</logo><entry><id>tag:blogger.com,1999:blog-7699289088757916196.post-16580858179770045</id><published>2012-02-20T21:20:00.001-08:00</published><updated>2012-02-20T21:45:04.128-08:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="JAVA" /><title type="text">JAVA环境中处理中文字符</title><content type="html">&lt;p&gt;周末上线一个应用，具体功能是由客户端通过调用WEB服务，将一段xml格式的数据传输给服务器，使用HTTP协议。这个应用在线上已经运行很久，最近只是做了轻微的修改。客户使用时反馈，有时会出现中文字符乱码，我一直以为是客户填写的时候编码有问题，没有在意，周一让同事处理这个问题，web服务很多方面都在用，所以主要找客户端的问题。&lt;/p&gt; &lt;p&gt;等快下班的时候，这个问题还没有搞定，我原以为不是多大的事情，就跟同事一起来梳理，同事说，其中有电话号码一项，填8位就不会出错，填少了会出错。我想那也太诡异了，决定一点点找，先是用tcpdump截取了客户机发出的以及服务器接收到的报文信息，对比，然后又查看对应汉字的编码，都是正确的。因为已经到下班时间，就让同事先走，一个人排查。既然报文是正确的，那么肯定不是客户端的问题了，可是我们服务端那么多人用了好多个月，怎么会出问题呢。无奈，翻出代码来看，发现其中有这么一段：&lt;/p&gt; &lt;blockquote&gt; &lt;p&gt;byte[] b = new byte[1024]; &lt;p&gt;int i = 0; &lt;p&gt;while ((i = in.read(b)) != -1) { &lt;p&gt;buf.append(new String(b, 0, i, "UTF-8")); &lt;p&gt;}&lt;/p&gt;&lt;/blockquote&gt; &lt;p&gt;这段代码是用来收取信息并编码成string的，联系之前的一些现象，马上判断出，是byte[]有问题，定了1024的长度，如果恰好把一个汉字分成两次处理，就出问题了。于是给同事发邮件，按这种思路修改。&lt;/p&gt; &lt;p&gt;现在想来，之前这个应用一直有问题，只是客户传送的信息中汉字较少，所以没有暴露出来，而解决问题时太主观，没有考虑服务端还会有这么低级的错误。&lt;/p&gt;  &lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/7699289088757916196-16580858179770045?l=www.fengbin.com' alt='' /&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.fengbin.com/feeds/16580858179770045/comments/default" title="帖子评论" /><link rel="replies" type="text/html" href="http://www.fengbin.com/2012/02/java-encoding-byte-string.html#comment-form" title="0 条评论" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/7699289088757916196/posts/default/16580858179770045" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/7699289088757916196/posts/default/16580858179770045" /><link rel="alternate" type="text/html" href="http://www.fengbin.com/2012/02/java-encoding-byte-string.html" title="JAVA环境中处理中文字符" /><author><name>Feng Bin</name><uri>https://profiles.google.com/107654493011194497946</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="//lh4.googleusercontent.com/-SMyzitk_3yQ/AAAAAAAAAAI/AAAAAAAAAAA/kzRoO_DGEi8/s512-c/photo.jpg" /></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-7699289088757916196.post-6710436851672121798</id><published>2011-10-11T05:09:00.000-07:00</published><updated>2011-10-11T05:16:31.943-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="Database" /><category scheme="http://www.blogger.com/atom/ns#" term="Oracle" /><title type="text">Oracle中sysdate的时区偏差</title><content type="html">国庆前有个应用上线，让DBA装了一个双机的Oracle RAC，装好后发现数据的sysdate不太对头，和机器时间差了16小时。这个问题后来解决了，也不复杂，只是这个过程异常曲折。&lt;br /&gt;网上有很多帖子说到了这个问题，操作系统本身的时间是正确的，Oracle里的current_date、current_timestamp都是正常的，就是sysdate有问题。提供的解决方法都是类似的一条命令：&lt;br /&gt;&lt;blockquote&gt;srvctl setenv database -d &amp;lt;dbname&amp;gt; -t TZ=EAT-8&lt;/blockquote&gt;看起来容易理解，差了16小时，可能是时区不对，于是把时区改成东八区（EAT-8），可DBA试了几次，都不见效果。其间也请教过其他人，也怀疑过是不是操作系统装的有问题，打算重装系统。直到在网上看到另外一段资料，才明白了其中的奥秘。&lt;br /&gt;&lt;blockquote&gt;&lt;strong&gt;Why is my SYSDATE time not the same as my system clock on Unix? &lt;/strong&gt;Sysdate is just a system call to the OS to get the time (a "gettimeofday" call). &lt;br /&gt;Sysdate does NOT use timezones in the database (select dbtimezone, sessiontimezone from dual . But OS (unix level) TZ settings DO alter the time that the OS will pass on to Oracle. &lt;br /&gt;To debug: &lt;br /&gt;telnet to the unix box and connect using sqlplus in the telnet session: &lt;br /&gt;1) once trought the listener using a tnsnames alias &lt;br /&gt;select to_char(sysdate,'DD-MON-YY HH24:MI:SS') from dual; &lt;br /&gt;2) once trough a "local" ORACLE_SID connection &lt;br /&gt;select to_char(sysdate,'DD-MON-YY HH24:MI:SS') from dual; &lt;br /&gt;if the result is different then it means that the listener is started with a different TZ &lt;br /&gt;then you current user env -&amp;gt;; stop and start listener with the TZ you want . &lt;br /&gt;If you are using RAC then use 'srvctl setenv database -d &amp;lt;dbname&amp;gt;; -t TZ=&amp;lt;the TZ you want&amp;gt;;' to define the correct TZ.&lt;/blockquote&gt;这段文字说sysdate是调用操作系统里的gettimeofday函数，不依赖oracle数据库里设置的时区，用的是操作系统的时区。而对linux来说，就是环境变量里设置的时区。按照这个解释，运行之前命令是正确的，问题就出在TZ的值上。&lt;br /&gt;运行命令&lt;br /&gt;&lt;blockquote&gt;cat /etc/sysconfig/clock&lt;/blockquote&gt;看到的时区是Asia/Beijing，而不是EAT-8，再到系统目录/usr/share/zoneinfo下查询，发现没有EAT-8。于是修改以前的命令，把TZ设成Asia/Beijing，问题解决。&lt;br /&gt;在此之前，已经有人有过这方面的提示，只是当时不是很清楚数据库里面的机制，误打误撞，总是设不对，明白原理之后，也就有的放矢了。&lt;br /&gt;&lt;br /&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/7699289088757916196-6710436851672121798?l=www.fengbin.com' alt='' /&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://www.fengbin.com/feeds/6710436851672121798/comments/default" title="帖子评论" /><link rel="replies" type="text/html" href="http://www.fengbin.com/2011/10/oracle-sysdate-timezone.html#comment-form" title="1 条评论" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/7699289088757916196/posts/default/6710436851672121798" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/7699289088757916196/posts/default/6710436851672121798" /><link rel="alternate" type="text/html" href="http://www.fengbin.com/2011/10/oracle-sysdate-timezone.html" title="Oracle中sysdate的时区偏差" /><author><name>Feng Bin</name><uri>https://profiles.google.com/107654493011194497946</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="//lh4.googleusercontent.com/-SMyzitk_3yQ/AAAAAAAAAAI/AAAAAAAAAAA/kzRoO_DGEi8/s512-c/photo.jpg" /></author><thr:total>1</thr:total><georss:featurename>3900 Rd, Coffeyville, KS 67337, USA</georss:featurename><georss:point>37.09024 -95.712891</georss:point><georss:box>11.6301275 -136.1425785 62.5503525 -55.2832035</georss:box></entry></feed>

