Skip to Content
avatar image
Former Member

JCo encoding problem

Hi,

I have a problem where a login over JCo fails when I have the character u20AC in the password.

This is a bit strange, because the JCo Client itself has the UTF-16 encoding, and the password is UTF-8. The password is UTF-8 because it also contains Ä which works.

I set up a test password with umlauts, and all umlauts seem to work. Everytime I have a u20AC or even &, the login fails.

I tried setting "jco.client.unicode" to 1, but this didn't seem to work. I am not even sure the property "jco.client.unicode" even exists, although there is a "jco.server.unicode" which in my case is not helpful - I'm creating a client, not a server.

The remote SAP System is a Unicode system by the way.

Any ideas? Oh, I am using JCo 2.1.8.

T00th

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • avatar image
    Former Member
    Mar 23, 2010 at 11:54 PM

    This is a bit strange, because the JCo Client itself has the UTF-16 encoding, and the password is UTF-8.

    Ok, so I'm assuming this means that your passwords are stored as UTF-8 hashes on the application server (i.e. profile parameter login/password_charset=2). Note that default value is pointing to Latin-1 encoding, which contains Ä, but no u20AC (so per your comment it's not 100% clear if you're really using UTF-8 on the server).

    First of all, are you sure that your password string is correct? I.e. the Euro symbol is Unicode code point U20AC+, so when debugging your Java application you should be able to validate that. This way you ensure that you don't read the password from some other location (e.g. database, file) with a possibly wrong encoding (e.g. system code page) and thus ending up with a different character.

    You're right, there's no Unicode boolean/flag for JCo client programs. However, you do have an attribute for the code page used by the client, i.e. jco.client.codepage. It's a bit confusing to me, because the Java Strings are anyhow UTF-16 (see also OSS note 794411), but when tracing I can clearly see that it's set to my system code page. When I change the code page to UTF-16LE, i.e. 4103 I can see that reflected in the trace (logon succeeds), but later my RFC fails. So maybe you can experiment with setting the client codepage.

    Maybe somebody else could explain if and if so why the client code page matters. Java is using UTF-16 strings, so I really wonder why the client code page would have any impact?!

    Cheers, harald

    p.s.: Tracing can be enabled via the following JCo parameters that can be passed directly to Java: Trace level is controlled via -Djco.trace_level=<n>, where 0<=n<=10 and trace directory via -Djco.trace_path=<path>.

    If all of this doesn't help, I'd personally do the following: Try testing the character passing by using a user with a working password and pass the special characters (like Euro sign) as a parameter (ideally you have some coding with an appropriate function for that, otherwise you could quickly create a test class). Debug your example and see if the characters ending up in SAP are correct.

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      ad 1. Yes, that's why I said: the note explains some basic codepage functionality. But the classic RFC library has been

      modified for exclusive usage by the SAP connectors. So not all the information within this note is valid for JCo (for example the

      usage of code pages 4102/4103). And no, you cannot substitute the classic RFC library with the NetWeaver version. But you

      may use the classic RFC library of newer releases for JCo 2.1 (classic RFC Library version 7.00, 7.01, 7.10, 7.11, etc.).

      ad 2. Yes, as a developer you always would like to design from scratch and don't care about compatibility and legacy stuff.

      But unfortunately business works different 😊 Maybe the next JCo version would do this step forward.

      Regarding code page 4110 I will do some more testing. I think it will work back to release 4.6 with most characters (I think the

      codepage converter did not offer full support for code page 4110 in this release; try chinese or japanese for example). 4.7 should work though.

      ad 3. With non-Unicode I meant all application servers not running on an UTF-16 code page.

      ad 4. Yes, you are right. But as the old R/3 releases are already shipped for a long time, it works as it is: the initiating RFC

      partner has to choose some code page that the other RFC partner is capable to handle. Please see ad 2. again.

  • avatar image
    Former Member
    Mar 24, 2010 at 11:34 AM

    Hi Sameer,

    Harald almost gave the complete solution and you already did some testing and found out the most.

    The missing part is the following:

    JCo uses by default the codepage 1100 for doing the logon itself because it does not know which codepage the communcation partner is running on and this is the lowest common denominator of all systems.

    After the logon and therefore knowing the partner's codepage JCo then automatically switches to the appropriate communication codepage.

    So you may get in trouble if some of your logon parameters are not part of codepage 1100.

    Usually it works for all characters being in the range up to character code U00FF as these codes are not converted with codepage 1100. That's the reason why it works with the "umlauts" but does not work with the Euro sign as this is character code U20AC and definitely must be converted.

    So the solution to your problem is to specify the additional logon parameter "jco.client.codepage" which is really only used for the logon and not for the following real RFC communication.

    You must define a codepage fitting to the used characters within your UserID and password. If your partner is a unicode system you may define 4102 or 4103 and it will always work with all characters - BUT only with unicode systems, of course.

    By the way, it doesn't matter if you specify 4102 or 4103 - both will work even if the endianity doesn't fit.

    Add comment
    10|10000 characters needed characters exceeded