Unix| Chinese
Original: On Unix/linux (Java) JVM supports Chinese output
First, on the unix/linux to enable the JVM to support Chinese output
If the user is using a UNIX remote server, will encounter the Chinese font in the image output problem, especially because many administrators do not like the host locale set as EN (because it means that may be garbled or have to install a micro-graphics terminal like Zhcon, but in many cases such conditions are not available). Most programmers ' Java experience is limited to JSP scripts, and some skilled programmers have probably developed middleware, servlet, applets, or GUI programs that run on Windows. If the development of the Jfreechart is to use Windows as a host to run, you can skip this paragraph, but if the use of Unix-type server, you often encounter unexpected Chinese display difficulties, and even not to the stage of the output of Chinese fonts, the program reports display abnormal error. The reason is that JAVA AWT was originally written for the (X) Windows GUI, and it often needs to be set up using display 1:0 settings, in server mode (like a JSP or servlet), there is no xwindowns running, The error of can not got display setting to 0:0 will be caused in many programs, including Jfreechart. The workaround is to add-djava.awt.headless=true settings to the JVM startup. This brings another problem, which causes headless Exception in code like the Frame.getimage () method, which causes the program to abort, while the program using Imagebuffer is unaffected.
Like Jfreechart based on the Java Awt,java Swing, Java 2D APIs and programs applied to the Linux/unix, the Chinese font output is a must solve the problem, or even jfreereport can not be used. The servlet also encounters a similar problem, but the solution is relatively simple, and the servlet package has built up a workaround, typically in the servlet header with two sentences:
Chinese garbled will not exist. This problem is much more complex than the simple Jsp/servlet character set conversion, even more complex than the average Linux culture. Under normal circumstances, the JRE contains only a few fonts (font), but it can be supported from the X system like Windows, so if developers and users are developing on a Chinese-language Windows system, they probably won't notice the problem. But once the program is published on the Unix/linux system, you will find that the Chinese characters in the graph become a question mark or a small box. At this point, a program like Jsp/servlet is completely normal in the client's display. In general, Java by default is the use of en_otf-8, or iso_8859_1 read the string, so, like JSP is usually used from the 8859_1 forced transformation to GB3312/GBK, you can display Chinese, but in the above cases, This kind of compulsory transition is completely ineffective. Why, then? If the programmer's system concept is clear, it will understand that the Jsp/servlet string output, but only the output font, then the client (generally the browser) on the client desktop to restructure the font, with the client's fonts, and on the contrary, Jfreechart such a graphics program output is an image , with the font of the server-side JRE, regardless of the xwindows font. When the system itself does not have a font (font), which is common to the server, only the JRE can be added to support Chinese fonts (font) to fundamentally solve this problem.
The Jre font setting principle is similar to xwindows, and the same tool is used, in fact, the binary font file is the same standard, the font set between companies, like Lenovo, founder, Microsoft and Linux xwindows is the same, can copy each other completely, The only way to read a font is to have a slightly different flow and settings. Directory refers to the Chinese version of Linux, which is mainly to increase the support of Chinese fonts, a lot of it is nonsense, I do not know the reason for the chaos after a pass and exclaimed "Buttoned up" such a form can not be repeated. So here is a review, and then the setting of the JRE, the principle will appear more clear. Currently, Linux fonts are used in two places, one is the font under the Linux console, the other is the font of applications such as Xwin, including pseudo console programs like Zhcon. Every program that applies a font can have its own font settings directory, but as the Linux integration level intensifies, it tends to call XFS's font services via the default unixsocket7000 port. Therefore, the font settings can be done only by setting the XFS. Some articles claim that it is unnecessary to stop XFS, and that the XFS call is just as a fontpath option in Xfconfig, as another way to add fonts, which is to add the directory containing the font directly to the Fontpath, and then manually perform the ttmkfdir-- This is the original XFS design instead of you to do. What the user actually needs to do is either to add the font file to the fonts:\\\ directly in the graphics tool, or to hand the font file to the corresponding locale directory in the XFS directory, usually in/usr/share/lib/fonts/zh_cn/ TrueType, restart XFS and it's done. As a manual addition to the Xfconfig directory, in Xwin, simply put, the font bitmap file is generic, including the JRE, in a directory, the user needs to do is to inform the Xwin where the directory, set the location of the/etc/x11/ The Fontpath item of the Xconfig. Running the Ttmkfdir command to generate Fonts.dir files is actually a comparison of the font invocation, and the user can edit the file Fonts.alias so that the font has an easy to remember name. Therefore, the key to the installation of fonts is the font bitmap file (copy to a directory), against the file (generated by the Ttmkfdir command), and font alias settings, the difference is that in the Xwin, these are automatically completed by the XFS, in the JRE, the developer will be manually completed.
In the case of JRE, the font bitmap directory is fixed, in the $jre_home/lib/fonts directory, the fonts.dir* table file is the same, the same is generated by the Ttmkdir program, and the equivalent of aliases and other settings of the file, concentrated in the $jre_home/ LIB directory, defined in the *font.properties* file. If the JVM can directly support Chinese output, then the font type indicated in the *font.properties* property file is required to support Chinese (in other words, Jsdk's own font files are not supported in Chinese). As described in http://java.sun.com/j2se/1.3/docs/guide/intl/fontprop.html, the JVM searches for the font properties file in the following order, which is the system properties detected by the JVM:
In most cases, however, you only need to target one font.properties file. It is a hard project to rewrite a font.properties file, but fortunately there is a Font.properties.zh.Turbo in Linux that is intended for turbolinux users, but in most cases it can be modified based on it. Rename this file to Font.properties, overwriting the original file, but the system still does not support Chinese, look, you will find the Font.properties.zh.Turbo file "- The tlc-song-medium-r-normal--*-%d-*-*-c-*-gbk-0 "Font" is not available in the Fonts.dir table, which is included in the Turbolinux system font library. The following methods have two, one is to install this font, the other is to change another font library and reassign. Turbolinux's font installation file name is ttf-zh-song*rpm, can be found on the Internet, installed after the/USR/LIB/X11/FONTS/TT under the TTF file copy to the $jre_home/lib/fonts directory, Regenerate the Fonts.dir file. The second approach is to find the font library, Microsoft Windows on the fonts directory of TTF files are generally available, but more complete from the http://www.microsoft.com/china/windows2000/downloads/18030. The ASP downloads its character set file, installs the TTF to the JRE's fonts directory, and, if Xwin supports Chinese, can find one or two font files supported in Chinese from/usr/lib/x11/fonts/truetype.
Copying these files to the fonts directory of the JRE does not allow the JVM to immediately support Chinese, and recall the previous mention The type of text specified in Font.properties must have a comparison table fonts.dir indicate how the JVM matches the font type that the user invokes to the corresponding font file. Therefore, run Ttmkfdir > Fonts.dir to generate a new comparison table. Open this file with VI, the top number is the number of glyphs that the system can call, and the following property value is the physical font name on the left, and the number on the right, which is the number specified in the Font.properties file (including the settings, the character alias on the left, the virtual font), The difference is only the 0-0-0c-0 of some of these settings to the wildcard and%d accept the call parameters, do not change the line, big deal the output of the word ugly (anyway I am not art, not very concerned). Using the available font numbers instead of the invalid font settings in font.properties, it seems theoretically that the JVM has supported Chinese, but in practice, it is still common to see question marks, spaces, and so on, because Java support for Chinese is not only related to the running environment, but also to the compilation parameters, If the class file is not compiled with gb2312/encoding, the equivalent of reading is otf-8/8859_1, then conversion is not used, so, if it is drawstring and so on, must remember to use (-encoding gb2312); If the operating system itself is already Chinese, this is automatically adopted by the compiler.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
