Could anone explain this for me? Codepage issue - Forum - OpenEdge General - Progress Community
Home » Community Groups » OpenEdge General » Forum » Could anone explain this for me? Codepage issue

Could anone explain this for me? Codepage issue

 Forum

Could anone explain this for me? Codepage issue

This question is not answered
goo
Posted by
on 8 Aug 2018 5:25

A webservice runs a procedure that has an inputparameter ipMylongchar as longchar no-undo.

I believe that the ipMylongchar has codepage fixed as -cpInternal ? So if a customer sends filecontent that is converted as UTF-8, it will be wrong?

So if different customer uses the webservice and sends different codepageformat, it would be pretty messy. 

Is the solution to start several services, with different -cpinternal ? or could it be done in another way?
All Replies
  • marian.edu
    Posted by
    on 8 Aug 2018 8:08
    The encoding of the input longchar should match the one set in the SOAP request which most probably is 'UTF-8' (<?xml version="1.0" encoding="UTF-8"?>) but you can check that using GET-CODEPAGE function on that longchar and the act accordingly... if the client send UTF-8 you might not be able to correctly store it in the database using ISO-8859-1 codepage but that doesn't mean the customer request is wrong. All characters should pass the web using an 'unicode encoding form' which translates to UTF-8, UTF-16 or UTF-32.

     
    Marian Edu

    Acorn IT 
    +40 740 036 212
  • goo
    Posted by
    on 8 Aug 2018 8:40
    So if the database is of ISO8859, and I have not done any changes to -dbinternal, I may assume that the input parameter will be codepage ISO8859 ?
     
    If the SOAP request is UTF-8, I should startup the webservice/appserver using -dbinternal UTF-8? Or am I missing something importenl understanding?
     
    Are you saying that a longchar with codepage ISO8859 should be able to hold codepage UTF-8?
     
    I am not saying that the customer is wrong, I am trying to understand the transfer of filecontent using longchar. Since I am not able to use fix-codepage(iplongcha) = ‘UTF-8’ on a input parameter, I would need to understand the float of my filecontent that is added to the input parameter.
     
    //Geir Otto
     
     
     
  • Peter Judge
    Posted by
    on 8 Aug 2018 9:34
    There’s also a CODEPAGE-CONVERT function that lets you convert (long)character data from one codepage to another. Obviously the target needs to support the characters in the source too.
     
    If you’re working with longchars, use the SET-CODEPAGE(‘utf-8’) before you assign values into the longchar. As Marian says, you should use something like UTF-8 .
     
  • frank.meulblok
    Posted by
    on 8 Aug 2018 9:44

    When passing longchars as parameters, the receiving end (callee for input, caller for output) will always use the same codepage the passing end used.

    In this case:

    I would assume the SOAP adapter/transport is smart enough to fix the codepage to the encoding used in the request.

    So the ipMylongchar would match the encoding from the request.

    And any conversion to your -cpinternal is something you need to take care of yourself.

    If my assumption is wrong and the adapter/transport doesn't fix the codepage, then indeed you'd get an unfixed longchar which the AVM will then assume is in your -cpinternal codepage.
  • gus bjorklund
    Posted by
    on 8 Aug 2018 10:42

    > On Aug 8, 2018, at 9:41 AM, goo wrote:

    >

    > Are you saying that a longchar with codepage ISO8859 should be able to hold codepage UTF-8?

    You probably know this already, but:

    ISO 8859 is a single byte code page with 8-bit characters. there are several (minor) variants for different part of europe. details here: en.wikipedia.org/.../IEC_8859 with character maps. 8859-15 is frequently used in Windows systems and elsewhere.

    UTF-8 is a multi-byte code page with characters that are 1, 2, 3, or 4 bytes long, depending on the character being represented.

    UTF-8 has my characters that cannot be converted to a single byte of ISO-8859.

    BTW: 7-bit ASCII is a proper subset of UTF-8.=
  • goo
    Posted by
    on 8 Aug 2018 12:38
    Thanks Gus, I was just not able to understand how the codepage interact with the longchar variable. I understand that UTF-8 is different than iso8859, but thanks for clarify it &#128522; I am only into this now and then, so it slips of my mind…
     
    //Geir Otto
     
  • goo
    Posted by
    on 8 Aug 2018 12:43

    hmmm I sent a smily, but it does not look like one Smile
  • goo
    Posted by
    on 8 Aug 2018 12:53

    Peter, I did not find SET-CODEPAGE(... did you mean FIX-CODEPAGE(longchar) = 'UTF-8'  ?

    but you can you use that for an input parameter ?

    My problem is that we have a Method that reads files from an FTP site, and using an appserver procedure (or a SOAP webservice) With an input parameter as longchar. Since I am not able to change the longchar With a fix-codepage, I am stucked With the codepage that is started With -cpinternal (or that is what my knowledge is telling me, am I wrong ? )

  • marian.edu
    Posted by
    on 8 Aug 2018 13:01

    Could you just use GET-CODEPAGE on that input parameter and see what it gives you? If the SOAP request uses an UTF-8 encoding and the longchar doesn't match that then I would say you should raise that with TS but you might be suprised to find out that this is not the same as 'cpinternal' as you expect ;)