|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
而学习JAVA我觉得最应该避免的就是:只学习,不思考,只记忆,不实践!js|mysql|交互|办理|中文|中文乱码
起首完成了一个StringConvertbean(GBtoISO()和ISOtoGB()两个办法),办理了与MySQL数据库交互的时分的部分中文乱码成绩:在JSP程序中读取MySQL的中文内容,用这两个办法能够办理乱码成绩。
可是从JSP写进到MySQL的中文内容都成了乱码,而且再读出来的时分也显现为“??”,在这里应当呈现了编码转换过程当中的字符信息丧失。忧郁的是,我在命令行窗口中上岸到MySQL后,实行如“INSERTINTOcustomerVALUES(字符,...)”如许的语句时,写进到数据表中的中文内容又是显现一般的!!!数据库利用的字符集是utf8。
受阻屡次,终究发明一条办理成绩的路径:检察MySQL手册的时分,看到一条如许的语句:Toallowmultiplecharactersetstobesentfromtheclient,the"UTF-8"encodingshouldbeused,eitherbyconfiguring"utf8"asthedefaultservercharacterset,orbyconfiguringtheJDBCdrivertouse"UTF-8"throughthecharacterEncodingproperty.
别的,在查阅《MySQL威望指南》时,发明在查询语句中可使用如许的语法将字符串转换到一个给定的字符集:_charsetstr。
个中charset必需是服务器撑持的某个字符集。在本例中,shopdb数据库利用的默许字符集是utf8,因而入手下手测试:
先输出INSERTINTO publishValues(8,_gb2312初等教导出书社)写进后中文酿成“??”
再试INSERTINTO publishValues(8,_gbk初等教导出书社)了局同上
INSERTINTO publishValues(8,_utf8初等教导出书社)这下更爽性,甚么都没有!!
快疯了!!没举措,用showcharacterset;命令检察MySQL撑持的字符集,心想我都试一遍总有一个能乐成吧。扫瞄了一下,发明没有几个熟习的字符集,就只剩下一个latin1(ISO-8859-1)对照罕见了,不会是它吧,一试之下公然即是。
INSERTINTO publishValues(8,_latin1初等教导出书社)输出中文可以准确显现。
这下总算找到办法了,把Tomcat下设置的数据库毗连池的url改成"...characterEncoding=UTF-8",然后把写进数据库的中文内容用
Strings2=newString(s1.getBytes("gb2312"),"ISO-8859-1")举行转码,个中s1为中笔墨符串.然后再写进到数据库统统显现一般。
为办理这个成绩检察了n多材料,现作一个总结:因为字符集和字符编码体例的分歧,在OS和程序之间传送数据(特别是multiplecharactersets中的数据)时便会发生乱码和字符信息的丧失.办理这个成绩的关头即是懂得数据输入端和吸收端利用的字符集和字符编码体例,假如这两种编码体例分歧,便必要在数据出口或出口处举行转码。一样平常的说,在编写代码,编译,和运转时代城市字符数据的传送,因而必要出格当心。
在编写代码的时分,你大概会利用某种开辟工具,比方我正在利用的Eclipse.也许在写的时分统统一般,但是一旦保留后再次翻开文档,一切的中笔墨符都酿成了乱码。这是由于在编写的时分,这些字符数据都在内存的某个stream中,ok,这没成绩,但是保留的时分这个stream中的数据会被写进到硬盘,利用的就是你的开辟工具默许的编码体例,假如很不幸你的开辟工具默许编码体例是ISO-8859-1,中笔墨符信息就不克不及准确地存储。Eclipse中能够如许检察并修正默许字符编码体例:Project->Properties->info,这里有"defaultencodingfortextfile"。假如设置为GBK,那末编写代码并保留这关就过了。
关于JSP程序而言,编写完代码后就交给Container,起首它们会被转成.java文件,然后编译成.class才干提交给服务器实行.这个历程也存在字符编码成绩.java编译器(javac)利用操纵体系的言语情况作为默许的字符编码体例,JRE(JavaRuntimeEnvironment)也是如许。只要当编译和运转情况的字符编码体例与存储源文件的编码体例不异时,中笔墨符才干准确地显现。不然就必要在运转时举行转码,使它们利用兼容的编码。这里的设置能够分为几个条理:操纵体系层撑持的言语,这是最主要的,由于它会影响JVM的默许字符编码体例,同时对字符的显现,如字体等有间接影响;J2EE服务器层,年夜多半服务器都能够对字符编码举行自界说的设置,比方Tomcat就能够经由过程web.xml中设置javaEncoding参数设置字符编码,默许是UTF-8.
IE也能够设置成老是利用UTF-8编码来发送哀求.使用程序层,每一个设置在服务器下的程序都能够设置本人的编码体例,这个我今朝还没有效到,今后再进修。
运转时的转码,运转时代,使用程序极可能必要与内部体系举行交互,比方对数据库举行读写,对内部文件举行读写.在这些情形下,使用程序免不了要和内部体系举行数据互换。那末关于中笔墨符,数据收支口的编码体例就显得出格主要了。一样平常内部体系都有本人的字符编码体例,我的例子中设置的MySQL就是利用的UTF-8编码。JSP页面经由过程设定"charset=gb2312",
利用gb2312编码,在它与数据库交互的时分就必要举行显式的转码才干准确处置中笔墨符。
大型的应用一般不会用这些框架(因为性能考虑);开发人员根据需要选择用一些框架,也可以不选用框架;不用框架并不代表要自己写框架;修改框架的可能性更小。 |
|