Let Javamail can handle Unicode-1-1-UTF-7 encoded Email

xiaoxiao2021-03-06  44

Customers always report that some email can be displayed normally in Outlook, and the client written in JavaMail is displayed in a blank. Look at the log report is unsupportedEncodingexception. I let customers download the email from Outlook, and open it. I found that the code and the code used were Unicode-1-1-UTF-7. Since UTF-8, I haven't encountered garbled problems for a long time. Unicode-1-1-UTF-7 This encoding is really seeing. On a search on Google, there are really many people who have encountered this problem using JavaMail. I don't want this to be Java's bug, see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4304013. It is difficult to understand why Java has been 1.4.2 does not support UTF-7 encoding (J2SDK1.5 does not know if it is not fixed). Take a look at RFC and some online information, basically understand UTF-7, extract as follows: UTF-7: A Mail-Safe Transformation Format of Unicode (RFC1642). This is an encoding that converts the Unicode code using a 7-bit ASCII code. Its design is still to deliver information in order to pass only the 7 mail gateway encoded. UTF-7 is displayed directly to English letters, numbers, and common symbols, and other symbols are encoded with correction base64. Symbol and - the start and pause of the encoding process. So if there is English word in garbled, there is a number and-number, which may be UTF-7 encoding. Customers cannot accept excuses such as the program platform BUG, ​​so it's important to get this code. Google is another wild search, honestly say no Google, I don't know if I can still continue to work very prominent work. But if you come back, Google also makes me an inert, basically no longer think about it when you encounter an exception you don't understand. There are more people on the Internet, and those who solve problems are less, and some people find some people to provide a solution. They have never thought of being a Japanese. I am a hatred, except for a three-year OLYMPUS digital camera, I have been strict with self-discipline, not dyed Japanese goods. But I still pay tribute to the Japanese people named Wood letter. He wrote a whole book to share its experience using JavaMail, "JavaMail completely explained". One of the articles describe how to deal with UTF-7 encoding and provide source code download. See: http://www.sk-jp.com/cgi-bin/treebbs.cgi? Kako = 1 & all = 1220 & s = 1220, the Source involved can be downloaded from http://www.sk-jp.com/software. In conjunction with the Japanese solution, my partial handling code is as follows: Private Static String Decodestream (InputStream in, String Chars) THROWS IOException {//system.out.println (iF (ISUTF7 (ISUTF7 (isuTF7)) {ByTearRayoutputStream out = new byteArrayoutputStream (); int C;

While ((c = in.read ())! = -1) {Out.write (c);} byte [] bytes = out.tobyteaRray (); try {bytetocharutf7 btc = new bytetocharutf7 (); char [] Chars = New char [bytes.length / 2 1]; btc.convert (Bytes, 0, Bytes.length, Chars, 0, Chars.Length; Return New String (chars);} catch (Exception E) {log. WARN ("Error Occurred While Parse Stream with Charset" Charset ". Cause By:" E.GetMessage ()); // may throw Sun.io.ConversionBufferFullexception, then decode Return New String directly with the default encoded String Bytes, "ISO8859-1");

} else {return Ioutils.toTostring (in, charset);}}

Private static boolean isutf7 (string charset) {Return "UTF-7" .Equalsignorecase (charset) || "unicode-1-1-utf-7" .Equalsignorecase (charset);} Fully according to the Japanese solution, often throw SUN.IO.CONVERSIONBUFFERFULLEXCEPTION. The problem may be in the default hypothesis string. If the string contains only ASCII, then the exception is thrown (UTF-7 is directly displayed by English letters, numbers, and common symbols, and for other symbols The corrected base64 encoding, see the description of UTF7). So if the CATCH is exception, use ISO8859-1 coding. I hope Java quickly supports UTF-7. I have always been a semi-solving for Unicode, I feel that this is quite complex. It is mainly to see the code in the code >>, << such a bit operator is awkward. It is not the class.

转载请注明原文地址:https://www.9cbs.com/read-59550.html

New Post(0)