Development of J2EE Application Chinese Problems on Solaris

There are many articles on the Internet on the Chinese issues and processing methods for JSP and J2EE. This problem is not very prominent in the operating system of the Chinese kernel, which is not very prominent, and more obvious in other systems (such as Linux, Solaris). Recently, a J2EE application system is developed on Solaris, the environment is Solaris 2.7 minij2ee mysql. The system does not have Chinese processing in Windows and Linux, but all Chinese is displayed as it is deployed to Solaris? Later, after analysis, found that the reason is on the system code. Since the default system encoded as ASCII is installed when installing Solaris, the Chinese character is lost when the default system encoding string is lost. The following, a simple JSP program illustrates this problem: <% @ page contentType = "text / html; charSet = GB2312"%> <% string str = request.getParameter ("i"); // Byte [] b = STR .GetBytes ("ISO-8859-1"); byte [] b = str.getbytes (); out.println (new string (b, "gb2312"));%> Enter foo.jsp? i in your browser = Chinese, the result is displayed as ??. If BYTE [] B = Str.getBytes (); replaced by BYTE [] B = Str.GetBytes ("ISO-8859-1") ("ISO-8859-1") ("ISO-8859-1") ("ISO-8859-1");, "Chinese" is displayed. Check the driver of MySQL JDBC and the same problem. There are two methods that consider the solution, one is to modify the JDBC driver, and the other is to encode the Chinese characters into 7 bits. From the convenient perspective, the latter is selected. However, the latter's disadvantage is that the string length is increased, and the database cannot be modified directly through the SQL tool. There is a method of Chinese character encoding on the Internet. It is to put the Chinese characters in the high position. This method has a defect, because a specific Chinese character encoding will appear in "'" and other SQL statements with ambiguous character, causing SQL fail. I took the encoding method in MiniJ2EE, which represents the byte to its 16-based encoding. The following is the source code: public string encode () {Try {stringbuffer sb = new stringbuffer (); byte [] Bytes = M_enc.comPareto (") == 0? m_str.getbytes (): m_str.getbytes (m_enc);

For (int i = 0; i > 4) & 0xF, 16); sb.append (ch); ch = character. Fordigit (Bytes [i] & 0xF, 16); Sb.Append (ch);} Return Sb.toString ();} catch (java.io.unsupportedEncodingexception e) {throw new runtimeException ("unsupported encoding type.");} }

Public void decode (String EncodeStr) {StringBuffer SB = new stringbuffer (); int i = 0; while (i! = encodeStr.length ()) {sb.append ((char) integer.parseint (Encodestr.substring (i, I 2), 16)); i = 2;} m_str = new unistring (sb.to-8859-1 "). CVT (m_enc);} After using the encoding, the problem is resolved. Also, a Unistring class is provided in the latest version of MiniJ2ee to solve Chinese issues on all operating systems. Using the Unistring object, you do not need to care about the string itself. You can get the required encoding when you use the function. If you call unistring.GB () in JSP (), you can output a string in GB2312, and call unistring.sys at the data stock. () You can encode the output string in the system default, whether in the Chinese kernel or the operating system of the English kernel. Huang Kai

More technical documents, all in the Minij2ee Technical Document Center, please visit http://www.minij2ee.com/document/.