Problem with charset  ISO-8859 with dinamic action

Hello
I migrated my application that was Apex 3.2, and now Apex is 4.2.3, but a have a problem when I'm use Dynamic Action with ISO-8859.
When I used a filter "ação" in dinamic action filter mounted by the apex presents 'aà § à £ o.'
If I force use of PlsqlNLSLanguage = BRAZILIAN PORTUGUESE_BRAZIL.UTF8 in Dads, works correct.
Please, Help me! I need to keep ISO-8859!
Thanks

Using another example to illustrate the problem… I
found an apparent solution using "encodeURI".
It sees:
quote:
BEFORE:
function SaveMsg()
if (document.sender.message == "" )
return false;
var mensagem=document.sender.message.value;
ds2.setURL('responsexml.asp?action=add'&msg='+mensagem);
ds2.loadData();
document.sender.message.value="";
document.sender.message.focus();
When the entrance of the changeable "mensagem" was
“João” was recorded in archive XML as
“Joo” ...
input: "João"
output: "Joo"
quote:
AFTER:
function SaveMsg()
if (document.sender.message == "" )
return false;
var mensagem=encodeURI(document.sender.message.value);
ds2.setURL('responsexml.asp?action=add'&msg='+mensagem);
ds2.loadData();
document.sender.message.value="";
document.sender.message.focus();
Now ...
input: "João"
output: "João"
This would be a good solution? I will not have problems,
right? Some opinion/suggestion on this solution?

Similar Messages

  • [svn:fx-trunk] 7661: Change from charset=iso-8859-1" to charset=utf-8" and save file with utf-8 encoding.

    Revision: 7661
    Author:   [email protected]
    Date:     2009-06-08 17:50:12 -0700 (Mon, 08 Jun 2009)
    Log Message:
    Change from charset=iso-8859-1" to charset=utf-8" and save file with utf-8 encoding.
    QA Notes:
    Doc Notes:
    Bugs: SDK-21636
    Reviewers: Corey
    Ticket Links:
        http://bugs.adobe.com/jira/browse/iso-8859
        http://bugs.adobe.com/jira/browse/utf-8
        http://bugs.adobe.com/jira/browse/utf-8
        http://bugs.adobe.com/jira/browse/SDK-21636
    Modified Paths:
        flex/sdk/trunk/templates/swfobject/index.template.html

    same problem here with wl8.1
    have you sold it and if yes, how?
    thanks

  • Cant mount usb sticks with fat32 ISO-8859-1 2.6.31-ARCH

    when trying to mount my usb sticks from xfce4 desktop(halmount).
    Following error occurs (as told by dmesg).
    FAT: IO charset ISO-8859-1 not found
    First i suspected hal being the culprit but now im not so sure anymore.
    im using stock 2.6.31-ARCH.
    when i checked the .config for the stock kernel CONFIG_NLS_ISO8859_1=y is enabled in the kernelconfig, and also everything below to support fat32.
    CONFIG_FAT_FS=m
    CONFIG_MSDOS_FS=m
    CONFIG_VFAT_FS=m
    CONFIG_FAT_DEFAULT_CODEPAGE=437
    CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
    CONFIG_NTFS_FS=m
    but when i list the modules nls_iso8859-1.ko is missing.
    #~ls -a /lib/modules/2.6.31-ARCH/kernel/fs/nls/nls_iso*
    /lib/modules/2.6.31-ARCH/kernel/fs/nls/nls_iso8859-13.ko
    /lib/modules/2.6.31-ARCH/kernel/fs/nls/nls_iso8859-14.ko
    /lib/modules/2.6.31-ARCH/kernel/fs/nls/nls_iso8859-15.ko
    /lib/modules/2.6.31-ARCH/kernel/fs/nls/nls_iso8859-2.ko
    /lib/modules/2.6.31-ARCH/kernel/fs/nls/nls_iso8859-3.ko
    /lib/modules/2.6.31-ARCH/kernel/fs/nls/nls_iso8859-4.ko
    /lib/modules/2.6.31-ARCH/kernel/fs/nls/nls_iso8859-5.ko
    /lib/modules/2.6.31-ARCH/kernel/fs/nls/nls_iso8859-6.ko
    /lib/modules/2.6.31-ARCH/kernel/fs/nls/nls_iso8859-7.ko
    /lib/modules/2.6.31-ARCH/kernel/fs/nls/nls_iso8859-9.ko
    So i suspect the newest kernel broke mounting with hal.
    Last edited by nichlas.johansson (2009-10-17 14:25:56)

    Based on the information given in http://bbs.archlinux.org/viewtopic.php?id=82176, I changed in /etc/rc.conf from LOCALE=en_GB.iso88591 to LOCALE=en_GB.utf8, uncommented en_GB.UTF-8 UTF-8  in /etc/locale.gen, issued # locale-gen and after a reboot, I was able to mount my usb sticks again.
    However, now I get "FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!" in dmesg. Is this something, I need to worry about...?
    Last edited by smurf (2009-10-19 08:29:15)

  • Unsupported Content-Type: text/html; charset=iso-8859-1

    Originally posted on JBI forum -
    It was helpfully suggested there that I check on JAX-WS forum whether this was an issue with utf-8/16 encodings...
    I have been experimenting with the openESB composite application described here
    http://jlorenzen.blogspot.com/2007/08/using-jbi-javaee-serviceengine.html
    This works fine as it appears on this webpage.
    I have tried to adapt it to act as a proxy to a secure version of Hello EJB that runs on the SSL port of glassfish AS.
    To do this I edited the EJB to set up the security properties. Edited the BPEL wsdl file and created a new composite application using the updated BPEL project.
    This leads to an Unsupported Content-Type exception when a test case is run on the composite application from SOAP-UI
    Does anyone know how I can explicitly set the content type of the proxied request to the secure WS?
    Thanks
    Joss Armstrong
    HTTPBC-E00720: Provider for service [{http://j2ee.netbeans.org/wsdl/HelloBPEL}HelloBPELService] endpoint [HelloBPELPort] responded with an error status. Error detail is: BPCOR-6135:A fault was not handled in the process scope; Fault Name is {http://www.sun.com/wsbpel/2.0/process/executable/SUNExtension/ErrorHandling}systemFault; Fault Data is <?xml version="1.0" encoding="UTF-8"?><jbi:message xmlns:sxeh="http://www.sun.com/wsbpel/2.0/process/executable/SUNExtension/ErrorHandling" type="sxeh:faultMessage" version="1.0" xmlns:jbi="http://java.sun.com/xml/ns/jbi/wsdl-11-wrapper"><jbi:part>Unsupported Content-Type: text/html; charset=iso-8859-1 Supported ones are: [text/xml]</jbi:part></jbi:message>. Sending errors for the pending requests in the process scope before terminating the process instance
    BPCOR-6151:The process instance has been terminated because a fault was not handled; Fault Name is {http://www.sun.com/wsbpel/2.0/process/executable/SUNExtension/ErrorHandling}systemFault; Fault Data is <?xml version="1.0" encoding="UTF-8"?><jbi:message xmlns:sxeh="http://www.sun.com/wsbpel/2.0/process/executable/SUNExtension/ErrorHandling" type="sxeh:faultMessage" version="1.0" xmlns:jbi="http://java.sun.com/xml/ns/jbi/wsdl-11-wrapper"><jbi:part>Unsupported Content-Type: text/html; charset=iso-8859-1 Supported ones are: [text/xml]</jbi:part></jbi:message>
    com.sun.jbi.engine.bpel.core.bpel.exception.SystemException: BPCOR-6131:An Error status was received while doing an invoke (partnerLink=EJBPartnerLink, portType={http://hellopack/}Hello, operation=sayHello)
    BPCOR-6129:Line Number is 29
    BPCOR-6130:Activity Name is Invoke1
    at com.sun.jbi.engine.bpel.core.bpel.model.runtime.impl.InvokeUnitImpl.processStatus(InvokeUnitImpl.java:968)
    at com.sun.jbi.engine.bpel.core.bpel.model.runtime.impl.InvokeUnitImpl.process(InvokeUnitImpl.java:538)
    at com.sun.jbi.engine.bpel.core.bpel.model.runtime.impl.InvokeUnitImpl.doAction(InvokeUnitImpl.java:181)
    at com.sun.jbi.engine.bpel.core.bpel.engine.impl.BPELInterpreter.execute(BPELInterpreter.java:148)
    at com.sun.jbi.engine.bpel.core.bpel.engine.BusinessProcessInstanceThread.execute(BusinessProcessInstanceThread.java:98)
    at com.sun.jbi.engine.bpel.core.bpel.engine.impl.BPELProcessManagerImpl.process(BPELProcessManagerImpl.java:1001)
    at com.sun.jbi.engine.bpel.core.bpel.engine.impl.EngineImpl.process(EngineImpl.java:258)
    at com.sun.jbi.engine.bpel.core.bpel.engine.impl.EngineImpl.process(EngineImpl.java:1229)
    at com.sun.jbi.engine.bpel.BPELSEInOutThread.processStatus(BPELSEInOutThread.java:407)
    at com.sun.jbi.engine.bpel.BPELSEInOutThread.processMsgEx(BPELSEInOutThread.java:239)
    at com.sun.jbi.engine.bpel.BPELSEInOutThread.run(BPELSEInOutThread.java:191)
    *Caused by: com.sun.xml.ws.server.UnsupportedMediaException: Unsupported Content-Type: text/html; charset=iso-8859-1 Supported ones are: [text/xml]*
    at com.sun.xml.ws.encoding.StreamSOAPCodec.decode(StreamSOAPCodec.java:291)
    at com.sun.xml.ws.encoding.StreamSOAPCodec.decode(StreamSOAPCodec.java:128)
    at com.sun.xml.ws.encoding.SOAPBindingCodec.decode(SOAPBindingCodec.java:287)
    at com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:171)
    at com.sun.xml.ws.tx.client.TxClientPipe.process(TxClientPipe.java:177)
    at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
    at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
    at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
    at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
    at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
    at com.sun.xml.ws.client.Stub.process(Stub.java:248)
    at com.sun.xml.ws.client.dispatch.DispatchImpl.doInvoke(DispatchImpl.java:180)
    at com.sun.xml.ws.client.dispatch.DispatchImpl.invoke(DispatchImpl.java:206)
    at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.outboundCall(OutboundMessageProcessor.java:986)
    at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.dispatch(OutboundMessageProcessor.java:1016)
    at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.processRequestReplyOutbound(OutboundMessageProcessor.java:661)
    at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.processMessage(OutboundMessageProcessor.java:243)
    at com.sun.jbi.httpsoapbc.OutboundAction.run(OutboundAction.java:63)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
    at java.lang.Thread.run(Thread.java:619)
    Request doesnt have a Content-Type
    com.sun.xml.ws.server.UnsupportedMediaException: Request doesnt have a Content-Type
    at com.sun.xml.ws.encoding.SOAPBindingCodec.decode(SOAPBindingCodec.java:267)
    at com.sun.xml.ws.transport.http.HttpAdapter.decodePacket(HttpAdapter.java:276)
    at com.sun.xml.ws.transport.http.HttpAdapter.invokeAsync(HttpAdapter.java:341)
    at com.sun.jbi.httpsoapbc.embedded.JAXWSGrizzlyRequestProcessor.processAsynchRequest(JAXWSGrizzlyRequestProcessor.java:372)
    at com.sun.jbi.httpsoapbc.embedded.JAXWSGrizzlyRequestProcessor.service(JAXWSGrizzlyRequestProcessor.java:228)
    at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
    at com.sun.jbi.httpsoapbc.embedded.JBIGrizzlyAsyncFilter.doFilter(JBIGrizzlyAsyncFilter.java:95)
    at com.sun.enterprise.web.connector.grizzly.async.DefaultAsyncExecutor.invokeFilters(DefaultAsyncExecutor.java:175)
    at com.sun.enterprise.web.connector.grizzly.async.DefaultAsyncExecutor.interrupt(DefaultAsyncExecutor.java:153)
    at com.sun.enterprise.web.connector.grizzly.async.AsyncProcessorTask.doTask(AsyncProcessorTask.java:92)
    at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
    at com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:116)

    Jossarm/Jeff,
    The Cryptography forum is not the right forum for this question; have you tried posting to the Glassfish forum on java.net?
    But, here is what I think the problem might be:
    SOAP-based web-service security uses XML Signature and XML Encryption to secure the message - not SSL; as a result it uses text/xml at the start of its message (which is what SOAP messages are). SSL assumes that the secure session has been established and all messages thereafter, are expected to begin with text/html (as expected in HTTP). You cannot mix-and match this - unless the service is an HTTP-based service that expects a SOAP-based message embedded in the HTTPRequest.

  • Client found response content type of 'text/html;charset=iso-8859-1', but expected 'text/xml'.

    Hello All,
    I am on BI 4.0 SP6.
    I am login to Advance Analysis Office using sso with Authentication : Windows AD, but when i login errors occurs:
    Client found response content type of 'text/html;charset=iso-8859-1', but expected 'text/xml'.
    The request failed with the error message:
    I have done all settings and configuration for SSO as per following notes:
    http://service.sap.com/sap/support/notes/1631734
    http://service.sap.com/sap/support/notes/1646920
    http://service.sap.com/sap/support/notes/1794675
    Earlier i was getting Login Exception Error WSE : 99999, i did some changes, after that the above error is coming
    Does anybody knows the solution?
    KR,
    MD

    refer the below note
    1785270 - How to configure AD SSO for Advance Analysis for MS Office with Business Objects BI 4.0

  • Creating XML-files in ABAP with format ISO-8859-1 after the use of unicode

    Hello,
    We have a problem with XML-files created in z_abap-programma.
    Before the use of unicode the XML-file was of the format: ISO-8859-1.
    After the introducting of unicode the format is UTF-16.
    In the abap-program we are using:
            CALL TRANSFORMATION xls-program
             SOURCE t_vbak = it_vbak
             RESULT XML xmlstring.
            CALL FUNCTION 'SCMS_STRING_TO_XSTRING'
              EXPORTING
                text     = xmlstring
              IMPORTING
                buffer   = lx_xml_as_string.
            CALL FUNCTION 'SCMS_XSTRING_TO_BINARY'
              EXPORTING
                buffer        = lx_xml_as_string
              IMPORTING
                output_length = li_xml_size
              TABLES
                binary_tab    = ltb_xml_table.
            CALL METHOD cl_gui_frontend_services=>gui_download
              EXPORTING
                bin_filesize = li_xml_size
                filename     = lc_filename
                filetype     = 'BIN'
              CHANGING
                data_tab     = ltb_xml_table
              EXCEPTIONS
                OTHERS       = 24.
    Is it prossible to create the XML-file with the format ISO-8859-1 after the unicode, please can you explane how to solve this problem.
    Regards,
    Theo Pijlman

    hi theo,
    did you read my thread i wrote some days before ? have a look in my sample coding find   " if_ixml_encoding ..... " there you can set the encoding of character .
    greetz
    tony
    thread:
    Re: abap to xml
    SAP Explanation for Interface if_ixml_encoding :
    http://help.sap.com/saphelp_nw04/helpdata/de/bb/5766a6dca511d4990b00508b6b8b11/content.htm

  • Problems reading Latin2 (ISO 8859-2) characters

    Hello!
    I want to read the content of an MS Access table (in an MDB file) using the JDBC:ODBC driver.
    The program works well but there is a character conversion problem when I read text fields from the table.
    The Latin2 (ISO 8859-2) characters like áéíóőűüöÁÉÍÓÜÖŰŐ are replaced by the "?" character.
    I use the ResultSet object's getString() method.
    Any idea about how to solve this problem?

    Try to change session encoding from defaut to iso-8559-2
    This probably would help:
    http://download.oracle.com/javase/1.4.2/docs/guide/jdbc/bridge.html
    >
    What's New with the JDBC-ODBC Bridge?
    * A jdbc:odbc: connection can now have a charSet property, to specify a Character Encoding Scheme other than the client default.
    For possible values, see the Internationalization specification on the Web Site.
    The following code fragment shows how to set 'Big5' as the character set for all character data.
    // Load the JDBC-ODBC bridge driver
    Class.forName(sun.jdbc.odbc.JdbcOdbcDriver) ;
    // setup the properties
    java.util.Properties prop = new java.util.Properties();
    prop.put("charSet", "Big5");
    prop.put("user", username);
    prop.put("password", password);
    // Connect to the database
    con = DriverManager.getConnection(url, prop);

  • Not a valid SOAP Content-Type: text/html; charset=iso-8859-1

    Friends
    JDEV and SOA suite 10134
    I have multiple domains on my BPEL Server. In one of the domain since I deployed the new process, all the processes of that domain are now failing on execution with following error in opmn/soa_instance/*.err log files. No errors in domain.log
    +"Caused by: java.security.PrivilegedActionException: oracle.j2ee.ws.saaj.ContentTypeException: Not a valid SOAP Content-Type: text/html; cha+
    +rset=iso-8859-1"+
    At the same time we get Internal Server Error on BPEL Console.
    I have sync processes with 1 or two invokes, so I am generally losing the instances, cannot provide the details in the process execution. All BPEL processes are invoking Siebel Web Services, that is the common part.
    When I restart my system, it may or may not work; even if it works then within few instances execution again starts giving the same error. I can see that after the errors the instance are going through and getting completed successfully few times. All these processes were working successfully earlier.
    Any idea about this !!!!
    Thanks

    Thanks Anirudh,
    I don't use compensation handlers. Moreover I have properly defined the scopes and sequences throughout the bpel process. My processes are sync in nature and I'm not able say at what step exactly the processes are failing and throwing the SOAP content Type error though the instances are getting completed with delay soemtimes.

  • Charset ISO-8859-5

    I am trying to convert ASCII to ISO-8859-5.
    For it I should add new Charset to CharsetProvider.
    What I do:
    1. create file java.nio.charser.spi.CharsetProvider in META-INF\services ( in \jre\lib\rt.jar file );
    2. there:
    sun.io.ByteToCharISO8859_5
    sun.io.CharToByteISO8859_5
    3. I try simple converting:
    String str = new String( b, "ISO-8859-5" );
    error:
    java.lang.ClassCastExeption: sun.io.ByteToCharISO8859_5
    BTW, I try that too:
    Charset charset = Charset.forName("ISO-8859-5");
    CharsetDecoder decoder = charset.newDecoder();
    same error.
    Any ideas, tips, or help would be greatly appreciated.
    Thanks very much!
    Hill

    Hi,
    Why do u want to add it to the CharsetProvider.
    I feel there is no need for that.
    You can just achieve this by following lines of code:
    String ascii = "hsgfjg";
    byte[] byt = null;
    byt = ascii.getBytes("iso-8859-5");
    String strISO-8859-5 = new String(byt);
    I guess this shoulf answer your problem
    Thanks & regards
    Paritosh Wechalekar
    Software Engineer
    L&T Infotech Ltd
    & Chief Controller
    International Mathematics Consortium

  • Problem to burn iso image with disk utility

    hi,
    i burnt an iso image file on a cd using disk utility.
    I checked the md5 of the burn, and found it is different than the original iso file.
    how do i create an EXACT iso image burn?
    more details:
    i downloaded file.iso from the web, inserted a blank CD, opened disk utility, chose "burn", then located the image, and confirmed.
    after the disk utility announced "success", i wanted to check that the md5 of the burnt cd matches the original. so i used "dd if=/dev/disk1 of=~/file.dd" but i got a completely different file than the original file.iso...
    not only that the md5 not match (which could be due to some extra 0 bytes), but i even compared the two files using xxd, and they look similar, but every now and then file.dd (=copy of the brunt CD) has a extra chunk of garbage bytes (and then the files are again the same, and then another chunk of garbage, etc.)
    so how do i create a 1:1 burn of file.iso?

    The problem here is that most Mac disc utilities, including the built-in Disk Utility, take a different approach when it comes to image burning. Instead of telling the program you want to burn an image, then choosing the file, you're supposed to do the reverse: You choose the file, then tell the program you want to burn it. So, to burn an ISO image to disc, here's what to do:
    1.Insert a blank disc.
    2.Start Disk Utility.
    3.From the File menu, choose Open Disk Image and select the ISO to be burned.
    4.In the list of volumes, you will now see an item representing the ISO file.
    5.Select it.
    6.Click the Burn button and follow the instructions.

  • Nerving Problem with UTF-8 and ISO-8859-1

    Hi,
    I´m looking for a solution to serve this problem for many hours now, maybe someone can help me:
    1.) We need to send our Mails with the ISO-8859-1-Charset because otherwise Windows-Users get the text in the message twice: once as plain, and after a question mark formated. So I changed the NSPreferredMailCharset in the com.apple.mail.plist to ISO-8859-1:
    defaults write com.apple.mail NSPreferredMailCharset "ISO-8859-1"
    2.) So far so good. It works until I add an attachment to a message. Adding an attachment forces the sending of the mail again as Unicode (UTF-8). I could change the encoding manual, but thats not the way we can work in our company.
    My question is: is there any way to force mail to encode as ISO-8859-1? It can´t be that we have to change the encoding for every message.
    Thanks a lot
    florian
    PS: I´m not sure if this is important: we use the osx in German.

    I was thinking that since he is from Austria & references a company, there is a very strong possibility that the character "€" (the Euro currency symbol, Unicode 20AC, UTF-8 E2 82 AC) would frequently appear in messages.
    Even if he sets a preference for ISO-8859-1 as the default with Terminal, or manually changes messages to ISO-8859-1, it would not be possible to include this symbol in such messages, since there is no "€" in ISO-8859-1.
    Similar problems would occur with other symbols sometimes used in business (for example "™"), in engineering ("Ω"), in mathematics ("∑"), or even with some general punctuation marks such as the dagger ("†").
    Other possible problems are the use of other currency symbols the Euro replaced (the franc's "₣" or the lira's "₤") or others still in use (the Israeli new sheqel's "₪ or rupee's "₨"). Ligatures in an international environment would really complicate things as well, as this Wikipedia article about the Œthel illustrates.
    Note that in none of these cases would the presence or absence of an attachment matter -- ISO-8859-1 simply isn't up to the task.
    I suspect that in some cases, if it is possible, setting the default to Windows-1252 (Windows Latin 1 in Mail's list?) would help, since it does include at least the Euro & dagger. I haven't played around with this much, but I do note that in a new message window containing "€" in the body, if I set the text encoding to Windows Latin 1, Automatic, or UTF-8, Mail doesn't complain, but if I set it to ISO Latin 1, I get an error saying the message can't be saved & an "Invalid Text Encoding" alert if I try to send it.
    As for how messages are received at the other end, Windows apps (not just Outlook) are notorious for continuing to use non-Unicode API's even after the OS itself has long since moved to Unicode as its internal standard. Some of them employ bass-ackwards fixes like deciding ISO-8859-1 declarations are supposed to be Windows-1252 ones. Worse, Windows itself sometimes seems to interpret a few Windows-1252 code positions as their ISO-8859-1 control equivalents!
    All this makes life that much more complicated for people trying to avoid problems like the above.

  • British Pound Sterling with UTF-8 and ISO-8859-15

    Please excuse my long-windedness ... I'm simply trying to answer all possible questions up front and give the most possible information. I've searched through tons of forums and all over various sites and references and am not able to come up with a concrete solution to this. I'd appreciate any help anyone has.
    I'm having some trouble with character sets and international currencies.
    Our server was recently upgraded from Red Hat 7.3 to Red Hat 8.0. I understand that the default system encoding thus changed from ISO-8859-15 to UTF-8. I have verified this by executing the following:
    public class WhichEncoding {
      public static void main(String args[])
        String p = System.getProperty("file.encoding");
        System.out.println(p);
    }I have two machines, one which represents the old system (7.3) and one representing the new (8.0), which I will call machine73 and machine80 respectively.
    [machine73:~]# java WhichEncoding
    ISO-8859-15
    [machine80:~]# java WhichEncoding
    UTF-8I have also verified that the JVM is using the correct default character set by executing the following:
    import java.io.ByteArrayOutputStream;
    import java.io.OutputStreamWriter;
    public class WhichCharset {
        public static void main (String[] args) {
            String foo = (String)(new OutputStreamWriter(new ByteArrayOutputStream())).getEncoding();
            System.out.println(foo);
    }which yields:
    [machine73:~]# java WhichCharset
    ISO-8859-15
    [machine80:~]# java WhichCharset
    UTF8Here comes the problem. I have the following piece of code:
    import java.text.NumberFormat;
    import java.util.Locale;
    public class TestPoundSterling
        public static void main (String[] args)
            NumberFormat nf = NumberFormat.getCurrencyInstance(new Locale("en", "GB"));
            System.out.println(nf.format(1.23));
    }When I compile and execute this, I see mixed results. On machine73, I see what I would expect to see, the British Pound Sterling followed by 1.23. To be sure, I outputted the results to a file which I viewed in a hex editor, and observed [A3 31 2E 32 33 0A], which seems to be correct.
    However, when I execute it on machine80, I see a capital A with a circumflex (carat) preceding the British Pound Sterling and the 1.23. The hex editor shows [C2 A3 31 2E 32 33 0A].
    I looked up these hexadecimal values:
    Extended ASCII
    0xC2 = "T symbol"
    0xA3 = lowercase "u" with grave
    ISO-8859-1
    0xC2 = Capital "A" with circumflex (carat)
    0xA3 = British Pound Sterling
    Unicode Latin-1
    0x00C2 = Capital "A" with circumflex (carat)
    0x00A3 = British Pound Sterling
    (This explains why, when I remove /bin/unicode_start and reboot, I see a "T symbol" and "u" with a grave in place of what I saw before ... probably an irrelevant sidenote).
    I found a possible answer on http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8 under the Examples section. Apparently, a conversion between Unicode and UTF-8 acts differently based on the original Unicode value. Since the Pound Sterling falls between U-00000080 � U-000007FF (using the chart on the mentioned site), the conversion would be (as far as I can tell):
    U-000000A3 = 11000010 10101001 = 0xC2 0xA3
    This appears to be where the extra 0xC2 pops up.
    Finally, to the whole point of this: How can I fix this so that things work as they should on machine80 like they did on machine73. All I want to see at the command line is the Pound Sterling. Getting the 0xC2 preceding the Pound Sterling causes some parts of my applications to fail.
    Here's some additional information that might be of use:
    [machine73:~]# cat /etc/sysconfig/i18n
    LANG="en_US.iso885915"
    SUPPORTED="en_US.iso885915:en_US:en"
    SYSFONT="lat0-sun16"
    SYSFONTACM="iso15"
    [machine73:~]# echo $LANG
    en_US.iso885915
    [machine80:~]# cat /etc/sysconfig/i18n
    LANG="en_US.UTF-8"
    SUPPORTED="en_US.UTF-8:en_US:en"
    SYSFONT="latarcyrheb-sun16"
    [machine80:~]# echo $LANG
    en_US.UTF-8Any help is very, very much appreciated. Thanks.

    you didn't look hard enough, this is a faq...
    there three options:
    1) change the system encoding by setting LANG or LC_CTYPE environment variables... assuming you use bash:bash$ export LC_CTYPE=en_GB.iso88591 you can check the available locales with locale -a ... pipe it to grep en_GB to filter out the non-british english locales
    -OR-
    2) change the java default encoding from the command line with -Dfile.encoding... run with$ java -Dfile.encoding=ISO-8859-1 yourclass-OR-
    3) set the encoding from within the program with OutputStreamWriter, or use a PrintStream that has the encoding set..PrintStream out = new PrintStream(new FileOutputStream(FileDescriptor.out), true, "ISO-8859-1");
    System.setOut(out);see also the internationalization tutorial & the javadoc of the related classes....

  • Flat file transformation to xml with encoding in iso-8859-1

    We have a BPEL process that picks up a flat fle (fixed length), transforms it to xml and emails it. The flat file is in iso-8859-1 (when I look at special characters like e-accent's in hex).
    The basic transformation that you get from (the wizards) of BPEL don't do the trick, the special characters are corrupted and unreadable.
    After that I changed all the encoding's (in xsd's and xsl's) from utf-8 into iso-8859-1 but doesn't help either. I also added an xsl:output section to my xsl (with "encoding="iso-8859-1") but that also fails...
    Does anyone have a clue? We're using SOA Suite 10.1.3.1.
    greetings,
    Jan

    just tried that but the problem is still there
    I suspect that the output of the file adapter (reading the flat file) is already corrupted, you should be able to tell the file adapter what encoding the input file is...

  • HTTP Test Tool Umlaut (Special Character) Problem iso-8859-1 utf-8

    Hi folks,
    I habe a Problem in an HTTP to IDOC Scenario. The configuration works and when I test it, by using the Test Message Tool from the Runtime Workbench i get the following problem:
    I post an IDOC XML Charset iso-8859-1 when it arrive as IDoc in business system german umlauts would be displayd very cryptic
    ä = ä
    ü = ü
    and so on ....
    When I post the XML with UTF-8 charset it works, what can i do to handle this ?
    Thank you

    Hi,
    maybe this document is helpful:
    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/502991a2-45d9-2910-d99f-8aba5d79fb42
    and also this thread:
    Character translation error in Mapping Lookup API (RFC)
    Regards
    Patrick

  • Problem with HttpHeader Accept-Language with InternetExplorer

    I'm building an web application using Flash at the front side and Jetty at the back side.
    This application has to care of the language settings of the browser.
    Normally the browser sends with each request the Http-header accept-language in wich the language settings of the browser are reflected.
    To check this I wrote a servlet wich echos the request with its headers.
    Here is the output for FF:
    <code>
    >>>TestServlet0<<<
    HttpServletRequest.getRequestURI
    /Era09Web/TestServlet0
    HttpServletRequest.getHeader
    Host : localhost:8080
    User-Agent : Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9
    Accept : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language : en-gb,de-at;q=0.5
    Accept-Encoding : gzip,deflate
    Accept-Charset : ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive : 300
    Connection : keep-alive
    Cache-Control : max-age=0
    HttpServletRequest.getLocale: Englisch (Vereinigtes Königreich)
    </code>
    Here is the output for IE:
    <code>
    >>>TestServlet0<<<
    HttpServletRequest.getRequestURI
    /Era09Web/TestServlet0
    HttpServletRequest.getHeader
    Accept : */*
    Accept-Language : en-GB,de-AT;q=0.5
    User-Agent : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; MSN OptimizedIE8;DEDE)
    Accept-Encoding : gzip, deflate
    Host : localhost:8080
    Connection : Keep-Alive
    HttpServletRequest.getLocale: Englisch (Vereinigtes Königreich)
    </code>
    That looks ok, but it was without Flash jet.
    Now the same info requested by mx.rpc.http.HTTPService.
    First for FF:
    <code>
    RequestURL : http://localhost:8080/Era09Web/DownServlet
    HttpHeader:
    Host : localhost:8080
    User-Agent : Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9
    Accept : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language : en-gb,de-at;q=0.5
    Accept-Encoding : gzip,deflate
    Accept-Charset : ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive : 300
    Connection : keep-alive
    RequestLocale : Englisch (Vereinigtes Königreich)
    </code>
    Second for IE:
    <code>
    RequestURL : http://localhost:8080/Era09Web/DownServlet
    HttpHeader:
    Accept : */*
    Referer : http://localhost:8080/Diagramm1.swf
    Accept-Language : de-DE
    User-Agent : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; MSN OptimizedIE8;DEDE)
    Accept-Encoding : gzip, deflate
    Host : localhost:8080
    Connection : Keep-Alive
    x-flash-version : 9,0,124,0
    RequestLocale : Deutsch (Deutschland)
    </code>
    Question: Why with IE it shows me de-DE and not en-GB ?

    I'm sending the files zipped yes. I thinks it's better like that. Isn't it?
    Yes.
    They are not necessarly using the same version. I will ask them to get the last one so we will have all the same.
    Perhaps that will help. You should also make sure they have the same Arabic fonts on their machines that you used for your file.

Maybe you are looking for