Jsp Encoding problem

I am getting crazy by the jsp encoding things.
here is my code:         if (getPageContent.size()>0) {
           pageContent=getPageContent.get(0);
              pageContent=pageContent.replaceAll("'", "'");
           //pageContent = pageContent.replaceAll("–","-");
           if (pageContent.contains("B�inne")) out.println("B�inne");on my local machine, it works well. the FF2 just display B�inne well.
But when i tested it on a web server (S1). *�* just become *?* under the same FF2.
Then i tested it on another web server (S2). Displayed B�inne well again under the same FF2. .
S1 and S2 use the same data. All three testing uses the same jsp code. FF2 is set to use ISO-8895-1 as Character Encoding.
I really don't know what makes S1 show *?* instead of *�*.
Appreciate any helps.
Edited by: Wilson80s on May 28, 2008 2:43 PM

Another really strange thing happened after i did a urlrewrite!!!
here is the two link:
link1: http://www3t2.irelandin1.com/AboutIreland/Meath/index.jsp
link2: http://www3t2.irelandin1.com/about_ireland.jsp?county=Meath
Actually, link 1 will be redirected to link2. It means the actual code executed for two links are the same. And the server is the one obviously.
But, you can find the difference: B?inne shown on link2 and B�inne shown on link 1
WTXXXX
Forget �, which i am using ú
Any helps??
Thanks

Similar Messages

JSP - Encoding problem? Euro currency values display become corrupted

Hi
We are having problem on our web application when trying to displaying euro currency.
A expected string such as "229 810,00 € " is displayed as "229Â 810,00 â‚¬".
Note that the page encoding is UTF-8, the line "<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />" is present in the header. Manually changing encoding to UTF-8 in browser did not fix the problem.
We have also noticed that when we deploy the same application in tomcat, we do not have this problem. The Euro currency is displayed correctly.
Are we missing some settings in our WebLogic Application Server that causes this problem?
thanks
Peter

Another really strange thing happened after i did a urlrewrite!!!
here is the two link:
link1: http://www3t2.irelandin1.com/AboutIreland/Meath/index.jsp
link2: http://www3t2.irelandin1.com/about_ireland.jsp?county=Meath
Actually, link 1 will be redirected to link2. It means the actual code executed for two links are the same. And the server is the one obviously.
But, you can find the difference: B?inne shown on link2 and B�inne shown on link 1
WTXXXX
Forget �, which i am using ú
Any helps??
Thanks

Character encoding problem using XSLT and Tomcat on Linux

Hi,
I have an application running on a Tomcat 4.1.18 application server that applies XSLT transformations to DOM objects using standard calls to javax.xml.transform API. The JDK is J2SE 1.4.1_01.
It is all OK while running on a development enviroment (which is Windows NT 4.0 work station), but when I put it in the production enviroment (which is a red hat linux 8.0), it comes up with some kind of encoding problem: the extended characters (in spanish) are not shown as they should.
The XSL stylesheets are using the ISO-8859-1 encoding, but I have also tried with UTF-8.
These stylesheets are dynamicly generated from a JSP:
// opens a connection to a JSP that generates the XSL
URLConnection urlConn = (new URL( xxxxxx )).openConnection();
Reader readerJsp = new BufferedReader(new InputStreamReader( urlConn.getInputStream() ));
// Gets the object that represents the XSL
Templates translet = tFactory.newTemplates( new StreamSource( readerJsp ));
Transformer transformer = translet.newTransformer();
// applies transformations
// the output is sent to the HttpServletResponse's outputStream object
transformer.transform(myDOMObject, new StreamResult(response.getOutputStream()) );Any help would be appreciated.

Probably you need to set your LANG OS especific environment variable to spanish.
Try adding this line:
export LANG=es_ES
to your tomcat/bin/catalina.sh, and restart tomcat.
It should look like this:
# OS specific support. $var _must_ be set to either true or false.
cygwin=false
case "`uname`" in
CYGWIN*) cygwin=true;;
esac
export LANG=es_ES
# resolve links - $0 may be a softlink
PRG="$0"
.(BTW, keep using ISO-8859-1 encoding for your XSL)
HTH
Un Saludo!

What's the available value for weblogic.jsp.encoding in web application.

Hi,
          I'm using chinese windows nt 4.0 and weblogic 5.1 sp6.When I did not set
          weblogic.jsp.encoding to GB2312 , when the jsp file contain's chinese , the
          output will be error .And when I did not set it , the output is correct, but
          when I use request.getParameter("SomeFormElement")(the element inputed
          chinese), the return value is error.
          How should I set weblogic.jsp.encoding value to satisfy all this problem?
          When I set the value to ISO-8859, there is an exception:
          java.io.UnsupportedEncodingException: Charset: 'ISO-8859' not recognized,
          and there is no alias for it in the weblogic.httpd.charsets property. So
          What's the available value for weblogic.jsp.encoding in web application?
          Pan


hi ,
i think the best way is to create java beans ,in that bean call your EJB ,
and check the validation over there.
and make that bean scope to session.
in each and everypage try to check the session ,if it is not valid then forward to your login page...
otherwise continue to give access to him like guest
Regards,
AfTaB

HELP.....!!!!! Chinese jsp compilation problem.....

Hi,
Could someone please help on the above mentioned?
I'm using JDeveloper 3.2.3 for my program development under Chinese windows platform. I have created a simple JSP page, which contains few static Chinese words and I have included the line
<%@ page contentType="text/html;charset=UTF-8"%>
at the top of the page. When I tried to compile it using encoding "UTF8" (under compiler option), the compiler gave me this error:
C:\Program Files\Oracle\JDeveloper 3.2.3\myhtml\Chinese_html\ChineseList.jsp
Error: (0) sun.io.MalformedInputException.
Btw, when I have removed the line <%@ page contentType="text/html;charset=UTF-8"%> from the page and compile, I've got this error:
C:\Program Files\Oracle\JDeveloper 3.2.3\myhtml\Chinese_html\ChineseList.jsp
Warning: (0) ISO-8859-1 character set may not match project compiler setting.
C:\Program Files\Oracle\JDeveloper 3.2.3\myhtml\Chinese_html\ChineseList.java
Error: (0) malformed input character in C:\Program Files\Oracle\JDeveloper 3.2.3\myhtml\Chinese_html\ChineseList.java.
I do appreciate your help on this. Thank you.

Here's some info one of the JSP Developers sent me:
1. HELP.....!!!!! Chinese jsp compilation problem.....
The customer is trying to parse a document generated by
Windows's notepad. When saved in UTF-8, the byte
order mark is saved too. We have a know bug that
JSP parser doesn't recognize Byte Order Mark. The
bug is : 1915285.
2. CHINESE CHARACTER ON JSP
. SQLPLUS depends on NLS_LANG setting. If you
check the windows registry, the default of NLS_LANG
depends on the OS. The user environment is Traditional
Chinese, so does NLS_LANG. If we set NLS_LANG
to .UTF8, SQLPLUS dumps the data in UTF8, however,
the command prompt will have problem displaying them.
. For JSP, as mentioned in a previous mail:
<%@ page contentType="text/html;charset=UTF-8" %> for all languages
<%@ page contentType="text/html;charset=GB2312" %> for simplified Chinese
<%@ page contentType="text/html;charset=Big5" %> for traditional Chinese
. When you enter Chinese characters on a browser,
the data is automatically converted to page encoding
(UTF-8 in your case) before sent back to the server.
But your receiving servlet/JSP needs to have request
encoding set correctly.
    I'm not sure about the JDeveloper environment,
but here is a simple JSP you may try to verify your
OC4J environment:
a.    To set up the schema:
connect scott/tiger
create table tab01(col varchar2(100));
b. Edit the connect string in nls.jsp
c. Run the nls.jsp in oc4j instance.

<%@ page contentType="text/html; charset=UTF-8" %>
<%@ page import="oracle.jdbc.*,java.sql.*,java.io.*"%>
<HTML>
<HEAD>
<TITLE>Hello</TITLE></HEAD>
<BODY>
<%
request.setCharacterEncoding("UTF-8");
String sampledata="\u7D20";
String paramValue = request.getParameter("myparam");
String connStr = "jdbc:oracle:thin:@dlsun478:5521:j2ee01";
String user = "scott";
String passwd = "tiger";
DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
Connection conn = DriverManager.getConnection(connStr, user, passwd);
if (paramValue == null || paramValue.length() == 0) { %>
   <FORM METHOD="GET">
   Please input your name: <INPUT TYPE="TEXT" NAME="myparam"
value="<%=sampledata%>" size=20>
<BR>
   <INPUT TYPE="SUBMIT" value="Insert Data">
   </FORM>
<%
selectData(conn, out);
else
%>
   <H1> Insert Data: <%= paramValue %> </H1>
   <br/>
<%
insertData(conn, paramValue);
%>
<a href="nls.jsp">back</a>
<%
%>
</BODY>
</HTML>
<%!
public void insertData(Connection aConn, String myval)
    try {
      PreparedStatement stmt = aConn.prepareStatement("insert into tab01
values(?)");
      stmt.setString(1, myval);
      stmt.executeUpdate();
      aConn.close();
    catch (SQLException e) {
      e.printStackTrace();
public void selectData (Connection aConn, JspWriter out)
    try {
      Statement stmt = aConn.createStatement( );
      ResultSet r = stmt.executeQuery("SELECT col FROM tab01");
      out.println("<H1>List of Data:</H1>");
      while (r.next()) {
        out.println(r.getString(1)+"<br/>");
      aConn.close();
    catch (SQLException e) {
      e.printStackTrace();
    catch (IOException e) {
      e.printStackTrace();
%>

Re: [iPlanet-JATO] sp3 jsp compiler problem

Weiguo,
First, Matt is correct, the regular expression tool is perfect for general text
substitution situations, and as a completely independent tool its use is not
restricted to migration situations (or file types for that matter).
Second, I sympathize with the unfortunate trouble you are experiencing due to
Jasper's (perhaps more strict) compilation, but in what way did the iMT
automated translation contribute to these inconsistencies that you cited?
1. Changed the case of the tag attribute to be the same as what's
defined in tld.
example: changed OnClick to onClick
The iMT does not generate any OnClick or onClick clauses per se. In a
translation situation, the only way "OnClick" would have been introduced was if
it had been part of the pre-existing project's "extraHTML" (which was written
by the original customer and just passed through unchanged by the iMT) or if it
was added manually by the post-migration developer.
2. Removed attributes which are not defined in tld.
example: escape attribute only defined in three tags
but in some pages, it's used although it's not defined as an
attribute
of certain tags. The jasper compiler doesn't like it.Can you give soem examples? Is there a definite pattern? Again, this might be
similar to the OnClick situation described above?
3. In an end tag, there can't be any space.
example: </content > doesn't work. </content> works.
Again, the content tag would never have been generated by the iMT. There was no
equivalent in the NetDynamics world, so any content tags in your code must have
been introduced by your developers manually. Its a shame that jasper is so
particular, but the iMT could not help you out here even if we wanted to. The
constants that are used by the iMT are defined in
com.iplanet.moko.jsp.convert.JspConversionConstants. From what I can see, the
only situation of a closing tag with any space in it is
public static final String CLOSE_EMPTY_ELEMENT = " />";
But that should not cause the type of problem you are referring to.
Mike
----- Original Message -----
From: Matthew Stevens
Sent: Thursday, September 06, 2001 10:16 AM
Subject: RE: [iPlanet-JATO] sp3 jsp compiler problem
Weiguo,
Others will chime in for sure...I would highly recommend the Regex Tool from
the iMT 1.1.1 for tackling this type of problem. Mike, Todd and myself have
posted to the group (even recently) on directions and advantages of creating
your own RULES (rules file) in XML for arbitary batch processing of source.
matt
-----Original Message-----
From: weiguo.wang@b...
[mailto:<a href="/group/SunONE-JATO/post?protectID=125056020108194190033029175101192165174144234026000079108238073194105057099246073154180137239239223019162">weiguo.wang@b...</a>]
Sent: Thursday, September 06, 2001 12:25 PM
Subject: [iPlanet-JATO] sp3 jsp compiler problem
Matt/Mike/Todd,
We are trying to migrate to sp3 right now, but have had a lot of
issues with the new jasper compiler.
The following workaround has been employed to solve the issues:
1. Changed the case of the tag attribute to be the same as what's
defined in tld.
example: changed OnClick to onClick
2. Removed attributes which are not defined in tld.
example: escape attribute only defined in three tags
but in some pages, it's used although it's not defined as an
attribute
of certain tags. The jasper compiler doesn't like it.
3. In an end tag, there can't be any space.
example: </content > doesn't work. </content> works.
As I see it, we have two options to go about solving this problem:
1. Write a script which will iterate through all the jsp files and
call jspc on them. Fix the errors manually when jspc fails. Jspc will
flag the line number where an error occurs.
2. Write a utility which scans the jsp files and fix the errors when
they are encountered. We should define what's an error and how to
correct it. It's best if we combine this with solution 1 since we
might miss an error condition.
Actually, there might be another option, which is seeking help from
you guys since you have better understanding of JATO and iAS. Can you
do anything to help us?
We would be happy to hear your thoughts.
At last, I would like to suggest modifying the moko tool so that
these rules are enforced and the generated JSPs work with the new
compiler. This is for the benefit of any new migration projects.
Thanks a lot.
Weiguo
[email protected]
Choose from 1000s of job listings!
[email protected]
[Non-text portions of this message have been removed]

Thanks a lot Matt and Mike for your prompt replies.
I agree completely that iMT doesn't introduce the inconsistencies.
About the three cases I mentioned, the third one happens only in
manually created JSPs. So it has nothing to do with iMT. The first
two are mainly due to the existing HTML code, as you rightly pointed
out.
The reason I made the suggestion is since we know that case 1 and 2
won't pass the japser compiler in sp3, we have to do something about
it. The best place to do this, in my mind, is iMT. Of course, there
might be some twists that make it impossible or difficult to do this
kind of case manipulation or attribute discard.
Weiguo
--- In iPlanet-JATO@y..., "Mike Frisino" <Michael.Frisino@S...> wrote:
Weiguo,
First, Matt is correct, the regular expression tool is perfect for general text substitution situations, and as a completely independent
tool its use is not restricted to migration situations (or file types
for that matter).
>
Second, I sympathize with the unfortunate trouble you are experiencing due to Jasper's (perhaps more strict) compilation, but
in what way did the iMT automated translation contribute to these
inconsistencies that you cited?
>
1. Changed the case of the tag attribute to be the same as what's
defined in tld.
example: changed OnClick to onClick
The iMT does not generate any OnClick or onClick clauses per se. In a translation situation, the only way "OnClick" would have been
introduced was if it had been part of the pre-existing
project's "extraHTML" (which was written by the original customer and
just passed through unchanged by the iMT) or if it was added manually
by the post-migration developer.
>
2. Removed attributes which are not defined in tld.
example: escape attribute only defined in three tags
but in some pages, it's used although it's not defined as an
attribute
of certain tags. The jasper compiler doesn't like it.Can you give soem examples? Is there a definite pattern? Again, this might be similar to the OnClick situation described above?
>
>
3. In an end tag, there can't be any space.
example: </content > doesn't work. </content> works.
Again, the content tag would never have been generated by the iMT. There was no equivalent in the NetDynamics world, so any content tags
in your code must have been introduced by your developers manually.
Its a shame that jasper is so particular, but the iMT could not help
you out here even if we wanted to. The constants that are used by the
iMT are defined in
com.iplanet.moko.jsp.convert.JspConversionConstants. From what I can
see, the only situation of a closing tag with any space in it is
public static final String CLOSE_EMPTY_ELEMENT = " />";
But that should not cause the type of problem you are referring to.
Mike
----- Original Message -----
From: Matthew Stevens
Sent: Thursday, September 06, 2001 10:16 AM
Subject: RE: [iPlanet-JATO] sp3 jsp compiler problem
Weiguo,
Others will chime in for sure...I would highly recommend the Regex Tool from
the iMT 1.1.1 for tackling this type of problem. Mike, Todd and myself have
posted to the group (even recently) on directions and advantages of creating
your own RULES (rules file) in XML for arbitary batch processing of source.
>
matt
-----Original Message-----
From: weiguo.wang@b...
[mailto:<a href="/group/SunONE-JATO/post?protectID=125056020108194190033029175101192165174048139046">weiguo.wang@b...</a>]
Sent: Thursday, September 06, 2001 12:25 PM
Subject: [iPlanet-JATO] sp3 jsp compiler problem
Matt/Mike/Todd,
We are trying to migrate to sp3 right now, but have had a lot of
issues with the new jasper compiler.
The following workaround has been employed to solve the issues:
1. Changed the case of the tag attribute to be the same as
what's
defined in tld.
example: changed OnClick to onClick
2. Removed attributes which are not defined in tld.
example: escape attribute only defined in three tags
but in some pages, it's used although it's not defined as an
attribute
of certain tags. The jasper compiler doesn't like it.
3. In an end tag, there can't be any space.
example: </content > doesn't work. </content> works.
As I see it, we have two options to go about solving this problem:
>>
1. Write a script which will iterate through all the jsp files and
call jspc on them. Fix the errors manually when jspc fails. Jspc will
flag the line number where an error occurs.
2. Write a utility which scans the jsp files and fix the errors when
they are encountered. We should define what's an error and how to
correct it. It's best if we combine this with solution 1 since we
might miss an error condition.
Actually, there might be another option, which is seeking help from
you guys since you have better understanding of JATO and iAS. Can you
do anything to help us?
We would be happy to hear your thoughts.
At last, I would like to suggest modifying the moko tool so that
these rules are enforced and the generated JSPs work with the new
compiler. This is for the benefit of any new migration projects.
Thanks a lot.
Weiguo
[email protected]
Choose from 1000s of job listings!
[email protected]
Service.
>
>
>
[Non-text portions of this message have been removed]

Encoding problems in email while on Windows Mail app

Hello.
I have a question concerning email and encoding problems in the Windows Mail App in Windows 8.1. I have encountered a problem with an email I received, while reading, I see strange ASCII characters in one email. I have never encountered it in
my web browsers nor Gmail, just the Mail App.
I was referred to come here when I had asked a similar question there:
http://answers.microsoft.com/en-us/windows/forum/windows8_1-ecoms/strange-foreign-ascii-characters-appearing-in/911f8a44-c302-4fa1-bcaa-3297b32d9120
I don't know which forum to go to so I picked here.
Is there any way that it can be resolved. I tried to troubleshoot, nothing worked; I even synched, to no avail.
I look forward to a response.
JB

Hi JB,
The responder on answers was a bit confused. The MSDN forums are for developers to discuss writing their own apps. We cannot help with problems using Windows or its built-in apps.
If the folks on answers cannot help then you may need to open a support incident. See
http://support.microsoft.com , or the folks on answers may be able to direct you to the specific page for the Windows Mail app.
--Rob

Encoding problem while reading binary data from MQ-series

Dear all,
we are running on 7.0 and we have an encoding problem while reading binary data from MQ-series. Because we are getting flat strings from queue we use module "Plain2ML" (MessageTransformBean) for wrapping xml-elements around the incoming data.
The MQ-Series-Server is using CCSID 850, which we configured in connection parameters in communication channel (both parameters for Queuemanager CCSID and also CCSID of target).If there are special characters in the message (which HEX-values differ from codepage to codepage) we get errors in our adapter while executing, please see stack-trace for further analysis below.
It seems to us that
1. method ByteToCharUTF8.convert() expects UTF-8 in binary data
2. Both CCSID parameters are not used anyway in JMS-adapter
How can we solve this problem without changing anything on MQ-site?
Here is the stack-trace:
Catching com.sap.aii.af.mp.module.ModuleException: Transform: failed to execute the transformation: com.sap.aii.messaging.adapter.trans.TransformException: Error converting Message: 'sun.io.MalformedInputException'; nested exception caused by: sun.io.MalformedInputException caused by: com.sap.aii.messaging.adapter.trans.TransformException: Error converting Message: 'sun.io.MalformedInputException'; nested exception caused by: sun.io.MalformedInputException
    at com.sap.aii.af.modules.trans.MessageTransformBean.throwModuleException(MessageTransformBean.java:453)
    at com.sap.aii.af.modules.trans.MessageTransformBean.process(MessageTransformBean.java:387)
    at com.sap.aii.af.mp.module.ModuleLocalLocalObjectImpl0_0.process(ModuleLocalLocalObjectImpl0_0.java:103)
    at com.sap.aii.af.mp.ejb.ModuleProcessorBean.process(ModuleProcessorBean.java:292)
    at com.sap.aii.af.mp.processor.ModuleProcessorLocalLocalObjectImpl0_0.process(ModuleProcessorLocalLocalObjectImpl0_0.java:103)
    at com.sap.aii.adapter.jms.core.channel.filter.SendToModuleProcessorFilter.filter(SendToModuleProcessorFilter.java:84)
    at com.sap.aii.adapter.jms.core.channel.filter.MessageFilterContextImpl.callNext(MessageFilterContextImpl.java:195)
    at com.sap.aii.adapter.jms.core.channel.filter.ConvertBinaryToXiMessageFilter.filter(ConvertBinaryToXiMessageFilter.java:304)
    at com.sap.aii.adapter.jms.core.channel.filter.MessageFilterContextImpl.callNext(MessageFilterContextImpl.java:195)
    at com.sap.aii.adapter.jms.core.channel.filter.ConvertJmsMessageToBinaryFilter.filter(ConvertJmsMessageToBinaryFilter.java:112)
    at com.sap.aii.adapter.jms.core.channel.filter.MessageFilterContextImpl.callNext(MessageFilterContextImpl.java:195)
    at com.sap.aii.adapter.jms.core.channel.filter.InboundDuplicateCheckFilter.filter(InboundDuplicateCheckFilter.java:87)
    at com.sap.aii.adapter.jms.core.channel.filter.MessageFilterContextImpl.callNext(MessageFilterContextImpl.java:195)
    at com.sap.aii.adapter.jms.core.channel.filter.TxManagerFilter.filterSend(TxManagerFilter.java:123)
    at com.sap.aii.adapter.jms.core.channel.filter.TxManagerFilter.filter(TxManagerFilter.java:59)
    at com.sap.aii.adapter.jms.core.channel.filter.MessageFilterContextImpl.callNext(MessageFilterContextImpl.java:195)
    at com.sap.aii.adapter.jms.core.channel.filter.DynamicConfigurationFilter.filter(DynamicConfigurationFilter.java:72)
    at com.sap.aii.adapter.jms.core.channel.filter.MessageFilterContextImpl.callNext(MessageFilterContextImpl.java:195)
    at com.sap.aii.adapter.jms.core.channel.filter.PmiAgentFilter.filter(PmiAgentFilter.java:66)
    at com.sap.aii.adapter.jms.core.channel.filter.MessageFilterContextImpl.callNext(MessageFilterContextImpl.java:195)
    at com.sap.aii.adapter.jms.core.channel.filter.InboundCorrelationFilter.filter(InboundCorrelationFilter.java:60)
    at com.sap.aii.adapter.jms.core.channel.filter.MessageFilterContextImpl.callNext(MessageFilterContextImpl.java:195)
    at com.sap.aii.adapter.jms.core.channel.filter.JmsHeadersProfileFilter.filter(JmsHeadersProfileFilter.java:59)
    at com.sap.aii.adapter.jms.core.channel.filter.MessageFilterContextImpl.callNext(MessageFilterContextImpl.java:195)
    at com.sap.aii.adapter.jms.core.channel.filter.MessageInvocationsFilter.filter(MessageInvocationsFilter.java:89)
    at com.sap.aii.adapter.jms.core.channel.filter.MessageFilterContextImpl.callNext(MessageFilterContextImpl.java:195)
    at com.sap.aii.adapter.jms.core.channel.filter.JarmMonitorFilter.filter(JarmMonitorFilter.java:57)
    at com.sap.aii.adapter.jms.core.channel.filter.MessageFilterContextImpl.callNext(MessageFilterContextImpl.java:195)
    at com.sap.aii.adapter.jms.core.channel.filter.ThreadNamingFilter.filter(ThreadNamingFilter.java:62)
    at com.sap.aii.adapter.jms.core.channel.filter.MessageFilterContextImpl.callNext(MessageFilterContextImpl.java:195)
    at com.sap.aii.adapter.jms.core.channel.SenderChannelImpl.doReceive(SenderChannelImpl.java:263)
    at com.sap.aii.adapter.jms.core.channel.ChannelImpl.receive(ChannelImpl.java:437)
    at com.sap.aii.adapter.jms.core.connector.MessageListenerImpl.onMessage(MessageListenerImpl.java:36)
    at com.ibm.mq.jms.MQMessageConsumer$FacadeMessageListener.onMessage(MQMessageConsumer.java:399)
    at com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl$JmsProviderMessageListener.onMessage(JmsMessageConsumerImpl.java:904)
    at com.ibm.msg.client.wmq.v6.jms.internal.MQMessageConsumer.receiveAsync(MQMessageConsumer.java:4249)
    at com.ibm.msg.client.wmq.v6.jms.internal.SessionAsyncHelper.run(SessionAsyncHelper.java:537)
    at java.lang.Thread.run(Thread.java:770)
Caused by: com.sap.aii.messaging.adapter.trans.TransformException: Error converting Message: 'sun.io.MalformedInputException'; nested exception caused by: sun.io.MalformedInputException
    at com.sap.aii.messaging.adapter.Conversion.service(Conversion.java:714)
    at com.sap.aii.af.modules.trans.MessageTransformBean.processTransform(MessageTransformBean.java:538)
    at com.sap.aii.af.modules.trans.MessageTransformBean.processTransform(MessageTransformBean.java:528)
    at com.sap.aii.af.modules.trans.MessageTransformBean.processTransform(MessageTransformBean.java:471)
    at com.sap.aii.af.modules.trans.MessageTransformBean.process(MessageTransformBean.java:364)
    ... 36 more
Caused by: sun.io.MalformedInputException
    at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:270)
    at sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:287)
    at sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:337)
    at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:223)
    at java.io.InputStreamReader.read(InputStreamReader.java:208)
    at java.io.BufferedReader.fill(BufferedReader.java:153)
    at java.io.BufferedReader.readLine(BufferedReader.java:316)
    at java.io.LineNumberReader.readLine(LineNumberReader.java:176)
    at com.sap.aii.messaging.adapter.Conversion.convertPlain2XML(Conversion.java:310)
    at com.sap.aii.messaging.adapter.Conversion.service(Conversion.java:709)
    ... 40 more
Any ideas?
Kind regards, Stefan

Hi Stefan,
for the first MTB now we are using only one parameter: Transform.ContentType = text/plain;charset="ISO-8859-1"
The second MTB, which does the XML-Wrapping, is configured like this:
Transform.Class = com.sap.aii.messaging.adapter.Conversion
Transform.ContentType = application/xml
xml.conversionType = SimplePlain2XML
xml.fieldNames = value
xml.fieldSeparator = §%zulu§%
xml.processFieldNames = fromConfiguration
xml.structureTitle = payload
Both CCSID configuration parameters from the "Source"-Tab we've set to 850.
Now, we don't get an error anymore - sun.io.malformedInputException - , but, unfortunately, now special character conversion succeeded (we need an "ß" and we get an ISO-HEX-E1 -> á). E1 is (different from ISO) an "ß" in 850.
Any ideas?

Encoding problem in call-back to hook URL (post parameters)

Hello all,
I'm encountering a character encoding problem while retrieving the content of the shopping basket from one of our provider.
After the POST request is made by the provider to our system using the hook url, when debbuging I can see that some special characters are represented with the sign '#' (after the call the ITS_IMPORT_CONTEXT).
In our case using the parameter http_content_charset with various values, including UTF-8, did not change the result.
Inspecting the HTTP traffic has highlighted the following: the encoding received from the provider is related to UTF-8, but while we are expecting the hexadecimal values, we are receiving the "Unicode code points", which are not recognized by our SAP system. For more details look at the UTF-8 encoding table found here and compare the values under column "Unicode code point" with the one under column "UTF-8 (hex.)".
As an example, for the character 'é', we are receiving the value "%E9" (the code point) instead of receiving the the hexa value : "%C3%A9".
Do you have any idee if this can be corrected on our side or if the provider must addapt the way it's sending the POST parameters?
Many thanks in advance for you help.
Best regards,
Jerome.

Hi Jason,
Indeed I had contacted the provider and informed them about the encoding problem and the fact that passing the parameter http_content_charset had no effect on the sent back encoding.
They have taken into account my request and have changed the encoding used during the request to the HOOK_URL.
Thanks to all of your for your help.
Regards,
Jerome.

C# GWTypeLibrary - AddressBook Entry encoding problem

Hello.
I am using C#(Visual Studio 2005) and GroupWareTypeLibrary to develop for
GroupWise Client 7.0.
Working with AddressBook I have faced some problems.
I am getting display name (AddressBookEntry.DisplayName) for all entries
of AddressBook. Almost all DisplayNames are correct but there are some
problems with two or three of them (there are some illegal char displayed
instead of some char of real user DisplayName). I think it is local
encoding problem bekause I see the same problem with the same users in
GroupWise Client AddressBook.
I thought display name is building not correctly but when I tried to get
these users first and last name I have got the same problem with encoding
in them.
Please advice how to decide this problem.
Regards,
Alex.

Sounds like a GW Client problem and not an API problem if you see it in the client address book. Technical Support should be able to help you.
Glade,
Novell Developer Support

Encoding Problems with WRT300N V2

Hello guys,
i have following problem:
I have a WRT300n Router and it seems to have problems with WPA2 encoding. I have 2 different deviceses (a SMC Ethernet Bridge and a PS3) trying to connect to my Linksys wireless router. No chance in WPA2 mode but when I try in WEP-Mode, both devicec can connect to it.
Are there known encoding problems?
Any idea what i can do?

It is able to use. But my router always drops the connection. WEP is no problem, but ... what about low security and Wirless N is not enabled ??

Encoding problem (via ORB)

Hello,
I posted this problem few months ago, but still havent been able to solve this.
I have a Client Server program which communicates via ORB, i.e. using CORBA, with server running on Solaris OS and Client running on windows.
The server returns string containing chinese characters to the client.
However, my chinese characters dont appear properly on the client side.
If i run the client on the Solaris OS there is no problem with it.
I tried converting the encode of the string by getting its byte and creating
a new string with encoding parameter. None of this seems to work.
I can see the chinese character when the server is writing to OutputStream of CORBA, but on the InputStream of CORBA it does not
show properly.
Any ideas on how i can overcome this encoding problem where the C/S is
communicating via CORBA (ORB)?
Thanks in advance.

Thanks for your reply
Yes, i know the BIG5 is for Traditional Chinese and japansese is using like Shift-JIS or EUC.
So when i try to post japanese in a BIg5 web page, i think it's normal that i can't see it in BIG5 encoding.
But then i change the Safari default decoding to BIG5 HKSCS, the japanese appers! At the same time i can see the traditional chinese too!
And if i use Firefox, i can both see the japanese and chinese at the default BIG5 encoding.
So i simple think maybe safari translate my japanese into BIG5 HKSCS,not Shift-JIS. But if i use Firefox, i can get the same result with only BIG5 encoding, not BIG5 HKSCS. So i am just wondering why it's different between Safari and Firefox with the same BIG5 encoding.
Following is a example URL
It's a MAC discussing froum with BIG5 encoding in Taiwan.
http://ubb.frostyplace.com.tw/viewtopic.php?t=19162
It's a froum topic posted by me. I input some japanese into this topic
If you browse this page with Safari BIG5 encoding, you can see a lot of question mark instead of the original japanese word that i and other people posted.
But if you change the encoding to BIG5 HKSCS, the japanese appears. And if you using Firefox with BIG5 encoding, the japanese appears too.
So is it someing wrong with Safari's BIG5 encoding or some other reason makes this happen?

View Object Encoding problem

I'm using Jdeveloper version 11.1.2.1. I have a encoding problem when creating View Object based on a query. This is my query:
select id, DECODE(id,'11','Индивидуално,'13','Semejno','14','Grupno') naziv
from ins_type
where class_id = '14' and id in ('11', '13', '14')
It is a simple LOV query with cyrilic letters. When I save the ViewObject and re-open it im getting question marks(???????) instead of the cyrilic letters. This only happens in the view object. I dont have other encoding issues when working with cyrilic letters only when im trying to build a View Object based on a query that has cyrilic letters. If i read those values from the database everything is fine
Thanks,

Change the encoding of your application to UTF-8 which appears to be sufficient for cyrilic chars. Here is a quick guide on how to do this http://docs.oracle.com/cd/E17984_01/doc.898/e14693/appa_configuring_jdev.htm
You may also need to update any pages that have encoding explicitly set

Czech characters encoding problem in RTFTemplate with Velocity engine

Hi,
I am trying to use your RTFTemplate project but I have trouble displaying Czech characters in the generated RTF document. Instead of characters like �čř� I get only questionmarks ????. I thought that this could be related to setting a wrong encoding in the velocity.properties file, so I set it to windows-1250 (support for Czech characters) but it didn�t help. Do you have any idea, what could be the problem? If this is not the right place to ask such question, please let me know about a better one.
Thank you for your time,
Ivo Jansky

Hi Jason,
Indeed I had contacted the provider and informed them about the encoding problem and the fact that passing the parameter http_content_charset had no effect on the sent back encoding.
They have taken into account my request and have changed the encoding used during the request to the HOOK_URL.
Thanks to all of your for your help.
Regards,
Jerome.

Urgent , encoding problem

Hi ,
i have received very important msg from ministry , but i cannot read it
its be like this : 爀椀愀氀∀㸀
i want to convert it to arabic chars ,
any ideas ?

Yes, it's an encoding problem. And no, the damagehas
already been done by applying an incorrectencoding.
This cannot be reversed.so there is no solution for this ?Yep you're fucked.
The Ministry of Double Ungood Codings will be coming to collect you shortly so that you might be educated with the double plus good ways.

Jsp Encoding problem

Similar Messages

Maybe you are looking for