|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
Java编译的是字节码,跟C++相反,启动不够快,效率不够高,难以精确控制内存,但是优点是编程比C++容易,代码比较安全但是容易留下性能隐患,跨平台靠字节码在各个平台复制(一处编译到处调试)unix|中文
原文:在Unix/Linux上令(java)JVM撑持中文输入
1、在Unix/Linux上令JVM撑持中文输入
假如用户利用的是UNIX的远程服务器,就会碰到中笔墨体在图象中输入的成绩,出格是因为很多办理员其实不喜好把主机的locale定为zh(由于意味着大概出乱码或必需装微形图形终端象zhcon,但良多情形下如许的前提其实不具有)。年夜部分程序员的JAVA履历苟限于JSP剧本程序,部分纯熟的程序员也许开辟过两头件、servlet、applet或在WINDOWS上运转的GUI程序。假如开辟的jfreechart是利用WINDOWS作为主机运转的话,能够略过这一段,但假如利用的是UNIX范例的服务器的话,就经常碰到意想不到的中文显现坚苦,乃至还未到输入中笔墨体的阶段,程序就呈报display非常毛病。缘故原由就在于,JAVAawt本来是针对(X)windowsGUI编写的程序,它经常必要利用display1:0的设置设定显现体例,在服务器形式下(象jsp或servlet),基本就不会有XWindowns运转,这时候就会在很多程序中引发cannotgotdisplaysettingto0:0的毛病,包含jfreechart。办理举措是在JVM启动中增添-Djava.awt.headless=true的设置。但如许又带来另外一个成绩,会令利用象frame.getImage()办法的代码中引发headlessException,招致程序中断,而利用ImageBuffer的程序就不会遭到影响。
象jfreechart如许基于javaawt,javaSwing,java2DAPI和程序使用到Linux/UNIX上,中笔墨体的输入是一个必需办理的成绩,不然连jfreereport都不克不及利用了。servlet也会碰着相似的成绩,但办理体例显得绝对复杂,servletpackage已内置懂得决举措,一样平常情形下,在servlet仰面设两句:
response.setContentType("text/html;charset=UTF-8");request.setCharacterEncoding("UTF-8");
中文乱码就不得存在。与复杂的jsp/servlet字符集转换比拟,这个成绩要庞大很多,乃至比一样平常的linux中文明还要庞大。在一般情形下,jre只包括多数几种字体(Font),但能够从X体系,象windows取得喜好的字体撑持;因而,假如开辟者和利用者是在中文WINDOWS体系上开辟,也许不会觉察成绩的存在。但一旦当程序公布到UNIX/Linux体系上后,就会发明图形中的中笔墨符成为一个个的问号大概小方框。而此时,象jsp/servlet如许的程序在客户真个显现倒是完整一般的。一样平常情形下,JAVA默许情形下是利用en_OTF-8,大概ISO_8859_1读进字符串,因而,象JSP一般利用从8859_1强迫转型为gb3312/GBK,就能够一般显现中文,可是在上述的情况下,这类强迫转型地是完整有效的。为何呢?假如程序员的体系观点是明晰的话,就会分明,JSP/SERVLET的字符串输入,只是输入字型,然后由客户端(通常为扫瞄器)在客户端桌面重整字型,用的是客户真个字体,而相反,JfreeChart如许的图形程序输入的是一个图象,用的是服务器端jre的字体,与Xwindows的字体也有关。当体系自己不带有字型时(font),这恰是服务器所罕见的,就只能向jre增加撑持中文的字体(font)才干基本上办理这个成绩。
Jre的字体设置道理与Xwindows类似,并延用不异的工具,现实上,二进制字体文件延用不异的尺度,各个公司间的字体集,象遐想、朴直、微软和linuxXwindows下是不异的,完整能够相互拷贝,仅仅是读取字体的体例流程和设置体例稍有区分。目次说起linux汉化的文章,个中次要就是增添中笔墨体的撑持,良多是言之无物,不知其以是然乱闯一通后惊呼"弄定啦"如许不成反复的情势。以是这里先温习一下,然后和JRE的设置对比,道理就会显得对照明晰。今朝linux的字体有两处利用,一是linuxconsole下的字体,二是Xwin等使用程序的字体,包含象zhcon如许的伪console程序。每处使用字体的程序都能够有自已的字体设置目次;但跟着Linux集成水平的强化,都偏向向经由过程默许的unixsocket7000端口挪用xfs的字体服务。因而,字体设置只需对xfs举行设置就能够完成。一些文章宣称要停失落XFS,实践上毫无需要;xfs的挪用仅仅是作为一个在XFConfig中的FontPath选项,作为另外一个增加字体的办法,就是间接把包括字体的目次增加到FontPath,然先手工实行ttmkfdir——恰好这原本是xfs计划取代您往做的。用户实践上必要做的,要末是间接在图形工具中把字体文件增加到fonts:中,大概是手工把字体文件加到xfs的目次下的对应locale的目次中,通常为在/usr/share/lib/fonts/zh_CN/TrueType,重启xfs就弄定了。作为手工增加到XFConfig中的目次,在XWin中,复杂地说,字体位图文件是通用的,包含对JRE,放在某一个目次中,用户必要做的就是关照XWIN这些目次在甚么中央,设置的地位就在/etc/X11/XConfig的FontPath项。运转ttmkfdir命令天生fonts.dir文件,实践上都是字体挪用的对比表,别的用户能够编纂fonts.alias如许的文件,目标就是让字体有个易记的名字。因而,字体的安装关头在于字体位图文件(拷到某个目次),对比文件(由ttmkfdir命令天生),和字体别号设置,所分歧的是,在Xwin中这些由xfs主动完成,在jre中,就要开辟者自已手工完成。
就Jre而言,字体位图目次是流动的,在$JRE_HOME/lib/fonts目次中;fonts.dir*的目次对比表文件也是一样的,一样是由ttmkdir程序天生,而相称于别号等设置的文件,会合在$JRE_HOME/lib目次下的*font.properties*"文件中界说。假如JVM能间接撑持中文输入,那末就请求*font.properties*属性文件中唆使的字体型自己是撑持中文的(换言之,JSDK自带的字体文件是不撑持中文的)。按http://java.sun.com/j2se/1.3/docs/guide/intl/fontprop.html的申明,JVM按以下按次搜刮字体属性文件,尖括号是JVM检测的体系属性:
font.properties.<language>_<region>_<encoding>.<osVersion>font.properties.<language>_<region>_<encoding>font.properties.<language>_<region>.<osVersion>font.properties.<language>_<region>font.properties.<language>_<encoding>.<osVersion>font.properties.<language>_<encoding>font.properties.<language>_<osVersion>font.properties.<language>font.properties.<encoding>.<osVersion>font.properties.<encoding>font.properties.<osVersion>font.properties
但在年夜多半情形下,实践上只必要面向一个font.properties文件。从头编一个font.properties文件是一项艰辛的工程,幸亏在Linux中有一个font.properties.zh.Turbo,原本是面向TurboLinux用户,不外在年夜多半情形下能够基于它修正。把这个文件重定名为font.properties,掩盖失落本来的文件,但体系这时候仍不撑持中文,检察一下,就会发明font.properties.zh.Turbo文件中的"-tlc-song-medium-r-normal--*-%d-*-*-c-*-gbk-0"字型在fonts.dir对比表中其实不具有,这类字型包括在TurboLinux的体系字型库中。上面的办法有两个,一是安装这类字体,二是变动另外一种字体型库偏重新指定。TurboLinux的字体安装文件名字是ttf-zh-song*rpm,在互联网上能够找到,安装后把/usr/lib/X11/fonts/tt下的ttf文件拷贝到$JRE_HOME/lib/fonts目次下,从头天生fonts.dir文件。第二种举措就是重找字体库,微软WINDOWS上的fonts目次下的ttf文件一样平常可用,但更全的是从http://www.microsoft.com/china/windows2000/downloads/18030.asp下载它的字符集文件,安装后把ttf拷到JRE的fonts目次下;别的,XWin假如撑持中文的话,能够从/usr/lib/X11/fonts/TrueType下找到一两个撑持中文的字体文件。
把这些文件一切拷到JRE的fonts目次其实不能令JVM立即撑持中文,回忆一下后面提到的,在font.properties中指定的笔墨范例,必需有一个对比表fonts.dir唆使JVM怎样把用户挪用的font范例婚配到响应的字型文件上。因而,运转ttmkfdir>fonts.dir天生新的对比表。用Vi翻开这个文件,最下面的数字是体系能够挪用的字型数量,上面的属性值对左边就是物理字型称号,右边是它的编号,这就是用到font.properties文件中指明利用的编号(包括了设置,左边的就是字符的别号,即假造字型),区分仅仅是把0-0-0c-0这类设置中的某几项改作通配符和%d承受挪用参数罢了,不改也行,年夜不了输入的字丢脸一点(归正我不是美工,不太体贴)。用可用的字型编号取代了font.properties中有效的字型设置后,实际上仿佛JVM已撑持中文了,但在实践操纵上,还是常常见到问号、空格之类,缘故原由就在于JAVA对中文的撑持不仅与运转情况有关,还与编译参数有关,假如类文件不是以gb2312/encoding编译的话,同等于读进是OTF-8/8859_1,这时候再转换也没有效了,因而,假如是drawString之类的,必需牢记利用(-encodinggb2312);固然,假如操纵体系自己已是中文的话,这条就由编译器主动采取了。
net程序员的大部门代码都靠控件拖拽完成的,虽然java也有,但是无论从美观和速度上都没发和.net比。java程序员都是代码完成的,所以java程序员常戏称.net程序员是操作员,呵呵。 |
|