Please let me know the JVM version.
What is default encoding of your JVM/OS?
You can validate the result using service: pub.xml:xmlStringToXMLNode, with setting different encoding.
First, make sure the tool you used to view the file supports displaying Chinese characters. It may well be the case that the file is properly encoded, but you just can’t view it properly. (what you shown here indicates that)
2ndly, make sure the actual file encoding is consistent with the XML encoding attributes. If you file is from an old system, they may be encoded in GB2312 or Big5, not UTF-8 or UTF-16. So you need to decode it accordingly.
Iftikhar,
In the receiving service is the “xmlNodeToDocument” step failing?
Did you setup save/restorepipelinetofile and step thru it the pipeline and yes as Tong Wang said you can fully ignore that entry [ISC.0076.0007W] XMLCoder decode invalid data type: com.wm.lang.xml.Document shown in the server log.
receiveService2 (Input nothing)
pub.flow:getTransportInfo
pub.file:getFile (take Input from filePolling/filename and load as bytes and encoding = UTF-8)
pub.xml:xmlStringToXMLNode
pub.xml:xmlNodeToDocument
On this occasion the Chinese Charset are shown in the correct way. I cant understand, why I need to extra operation like “pub.file:getFile” and set the enconding typ.
we have also incorparated the same logic in our project , but the filetype is of flatfile. we used to get chinese characters in our flat file .
those characters use to miss when we recieve them. but we havent changed any encoding at our end, but have asked source system to change their encoding type and send,. that solved our issue.
anyways coming to your issue,
i tried with the xml file you have given , i have written a service contating the following steps:
the last step is to check whether i am getting the corecct characters. i got an email perfectly with chinese characters.please find attached email for refernece
Which version of WM IS are you running?
in “webMethods Integration Server: Upgrading from 6.0.1 to 6.1” it mentioned the change of default encoding from JRE’s default to UTF-8 for xml content handler.
I guess the behavior for any version newer than 6.1 should be the same, unless a different content handler is used