DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15130>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15130 malformed encoding when SOAPBodyElement's data are not ISO8859_1 characters ------- Additional Comments From [EMAIL PROTECTED] 2002-12-17 14:48 ------- I run across the same problem and found a way to fix it: The utility class org.apache.axis.attachments.MimeUtils is used to create a MimeMultipart object from the String representation of the SOAPEnvelope, which is at that time still an unicode Java-String. The content type of the created part is set to "text/xml; charset=UTF-8" which leads to a corresponding header field on the "wire" but not to the correct encoding. This has to be done separately just before creating the MimeMultipart object as sugested below: <snip> public static MimeMultipart createMP(String env, Collection parts) throws AxisFault { MimeMultipart multipart = null; try { String rootCID = SessionUtils.generateSessionId(); multipart = new MimeMultipart( "related; type=\"text/xml\"; start=\"<" + rootCID + ">\""); MimeBodyPart messageBodyPart = new MimeBodyPart(); // MODIFICATION: call setText() using a String converted to UTF-8 try { messageBodyPart.setText(new String(env.getBytes("UTF-8"))); } catch (UnsupportedEncodingException ex) { messageBodyPart.setText(env); } messageBodyPart.setHeader("Content-Type","text/xml;charset=UTF-8"); messageBodyPart.setHeader("Content-Id","<" + rootCID + ">"); messageBodyPart.setHeader("Content-Transfer-Encoding","binary"); multipart.addBodyPart(messageBodyPart); <snip> This method is only called if there is at least one attachment. Otherwise the SOAPEnvelope will be written to the wire using an OutputStreamWriter(os,"UTF-8") in Method public void writeTo(java.io.OutputStream os) of org.apache.axis.Message I patched Axis 1.0 with this modification and it worked fine (at least at the first glance :-). I would suggest this or a similar fix for a future release.