In UNIX / Linux, the JVM supports Chinese output. In UNIX / Linux, the JVM supports Chinese output If the user uses Unix remote servers, it will encounter the problem of the Chinese font output in the image, especially Since many administrators don't like to set the host's locale to zh (because it is possible to garble or must install the micro graphics terminal icon ENCON, many cases do not have this condition). Most programmers' Java experience is limited to the JSP script, some skilled programmers probably open the Middleware, servlet, applet, or GUI program running on Windows. If the development of JFreeChart is running using Windows as a host, you can skip this segment, but if you use a UNIX type server, you often encounter unexpected Chinese display difficulties, and even until the output of the Chinese font, The program reports Display exception errors. The reason is that Java AWT turned out to be a program written for (X) Windows GUI, which often requires the display mode setting display mode, in server mode (like JSP or servlet), will not have XWindowns at all. Operation, this will cause the CAN NOT DIT Display Setting to 0: 0 in many programs, including JFreeChart. The solution is to increase the settings of -djava.awt.headless = true in the JVM startup. However, in this way, it will cause the use of Headless Exception in the code of the frame.getimage () method, causing the program to abort, and programs using ImageBuffer will not be affected. Java AWT, Java Swing, Java 2D API and programs are applied to Linux / UNIX, which is a problem that must be resolved, otherwise even JFReereport cannot be used. Servlet also encounters a similar problem, but the solution is relatively simple, servlet package has built-in solutions, in general, set up two sentences at the servlet: Response.setContentType ("text / html; charSet = UTF-8" ); Request.SetCharacterencoding ("UTF-8"); Chinese garbled should not exist. Compared with simple JSP / servlet character sets, this problem is much more complicated, even more complicated than in general Linux. Under normal circumstances, JRE only contains several fonts (font), but can be supported from the X system, like Windows to get the font support; therefore, if developers and users are developed on the Chinese Windows system, it is probably not found The existence of the problem. But once the program is released on the UNIX / Linux system, the Chinese characters in the graphic become a question mark or small box. At this time, the program like JSP / servlet is completely normal. In general, Java uses En_OTF-8 by default, or ISO_8859_1 is read into the string, so the JSP is usually used to force the transformation from 8859_1 to GB3312 / GBK, but in the case, in the above case, this It is completely invalid to force transformation.
why? If the programmer's system concept is clear, it will understand that the JSP / Servlet string output, just outputting a font, then reorganized by the client (generally browser) in the client desktop, using customers The end font, in contrast, the graphical program such as JFreeChart is an image, which is used by the font of the server-side JRE, and has nothing to do with the font of XWindows. When the system itself does not have a word type (font), this is common, and only fonts that support Chinese can only solve this problem at fundamental fonts to JRE. The font setting principle of JRE is similar to XWindows, and extensions the same tool. In fact, the binary font file extends the same criteria, the font sets, like Lenovo, Foundation, Microsoft, and Linux XWindows, completely You can copy each other, just the way the font is read, and the setting mode is slightly different. The catalog mentioned Linux Chinese articles, which is mainly to increase the support of Chinese fonts, a lot of nonsense, I don't know if it is, but I swatted to exclaim "I don't repeat". So I review it first, then the settings with JRE, the principle is relatively clearer. At present, Linux fonts have two places, one is the font under Linux console, and the other is the font of XWIN and other applications, including a pseudo console program like ENCON. Each program that applies fonts can have their own font settings; however, as Linux integration is strengthened, it is tenden to call XFS font services to pass the default UNIXSocket7000 port. Therefore, the font settings can be done with the settings of XFS. Some articles claim to stop XFS, actually unnecessary; XFS call is just as a fontpath option in Xfconfig, as another method of adding fonts, is to add a directory containing font to FontPath, then manually TTMKFDIR - just this is the XFS design instead of you. Users actually need to do, or directly add font files to fonts: // / in the graphics tool, or handmade the font file to the directory of the corresponding locale in the Directory of the XFS, generally in / usr / share / lib / fonts / zh_cn / trueType, restart XFS is getting it. As a directory, which is manually added to Xfconfig, in XWIN, simply, the font bitmap file is universal, including the JRE, in a directory, the user needs to do, where is the notification XWIN these directory where, set The location is in / etc / x11 / xconfig's FontPath item. Run the TTMKFDIR command to generate the fonts.dir file, actually all the compliance tables called by the font, and the user can edit the files such as Fonts.alias. The purpose is to let the font have an easy name. Therefore, the key to the font is in the font bitmap file (copy to a directory), the control file (generated by ttmkfdir command), and the font alias setting, the different is that these are automatically completed by XFS in XWIN, in JRE It is necessary to develop from hand.
For JRE, the font bitmap directory is fixed, in the $ jre_home / lib / fonts directory; Fonts.Dir * directory comparison table file is also the same, and is also generated by the TTMKDIR program, and equivalent to the alias and other settings. File, focus on the * font.properties * "file under the $ jre_home / lib directory. If the JVM can directly support Chinese output, then the * font.properties * The font model indicated in the property file is support Chinese ( In other words, JSDK comes with the font file that does not support Chinese). Press http://java.sun.com/j2se/1.3/docs/guide/intl/fontprop.html, JVM Search the font attribute file in the following order Heads of the JVM is the system properties of JVM detection: font.properties.
The second way is to focus on the font library, the TTF file under the Fonts directory on Microsoft Windows is generally available, but more all is from http://www.microsoft.com/china/windows2000/downloads/18030.asp to download it. The character set file, copy the TTF to the fonts directory of the JRE after installation; in addition, XWIN If you support Chinese, you can find one or two font files that support Chinese from / usr / lib / x11 / fonts / trueType. Putting these files into the Fonts directory of JRE and cannot make JVM immediately support Chinese, recalling the previously mentioned in the font.properties, must have a comparison table Fonts.DIR indicates how JVM calls users. The font type matches to the corresponding font file. Therefore, running TTMKFDIR> FONTS.DIR to generate a new comparison table. Use the VI to open this file, the top number is the number of fonts that can be called, the following attribute value is the physical typographic name on the left side, right is its number, which is used in the font.properties file specified in the font.properties file The number (including settings, the left side is the alias, the virtual font), the virtual font), the difference is just a few modifications in the settings in this setting in this type of 0-0C-0 accept the call parameters, Don't change, it is difficult to see a little big, it is not a good job, I don't care about it. After using the available font number instead of the invalid word settings in Font.properties, theoretically seems that JVM has supported Chinese, but in actual operation, it is still the question mark, space, because Java is The support of Chinese is not only related to the operating environment, but also related to the compilation parameters. If the class file is not compiled with GB2312 / Encoding, it is equivalent to reading whether it is OTF-8 / 8859_1, then the conversion is not used, so if it is DrawString, must be used (-Encoding GB2312); of course, if the operating system itself is already Chinese, this is automatically adopted by the compiler. Author Blog:
http://blog.9cbs.net/zwwwxy/
