Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with character conversion in the file generated on app server

Former Member
0 Kudos

Hi All,

I have written a report that generates a file on the server but there was some problem with character conversions in that file.So I tried to use


l_v_spras = sy-langu.

* Getting the Codepage value for Bulgerian Language
  CALL FUNCTION 'SCP_CODEPAGE_FOR_LANGUAGE'
    EXPORTING
      language    = l_v_spras
    IMPORTING
      codepage    = l_v_codepage
    EXCEPTIONS
      no_codepage = 1
      OTHERS      = 2.

* open the file in output mode
      OPEN DATASET l_fname FOR OUTPUT IN LEGACY TEXT MODE
    CODE PAGE l_v_codepage.

but it is dumping saying The conversion of texts in code page '4102' to code page '4102' is not

supported here.

How will i resolve the problem of character conversion.

Unicode checks active checkbox is checked for the report

Thanks

Bala Duvvuri

12 REPLIES 12

Former Member
0 Kudos

Hi

Regarding the application server, the value which you are passing into the application server for storing, should be of Char type.

If you pass the Integer or other data type. then it will show you a dump!!

nils_buerckel
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Bala,

OPEN DATASET ... IN LEGACY TEXT MODE ... is supported for Non-Unicode data only.

(Have a look at http://help.sap.com/abapdocu_70/en/ABAPOPEN_DATASET_MODE.htm ).

Now your function results in 4102 (UTF-16 BE) and this is not supported.

I would recommend not to use legacy mode.

Best regards,

Nils Buerckel

SAP AG

MarcinPciak
Active Contributor
0 Kudos

Hi Bala,

I wouldn't play with code pages at all. SAP provides easy way to handle file in UTF-8 which I believe is most convenient encoding type for flat files. So simply use


OPEN DATASET file FOR OUTPUT IN TEXT MODE ENCODING DEFAULT.

Then simply feed the output stream with your text (in Bulgarian). Now the file will be both encoded in UTF-8 and available to be displayed in UTF-8 - so no problem to show it in AL11 correctly. Of course pay attention that same decoding must be used in order to transfer it back to input stream (when accessing it via program).

Regards

Marcin

0 Kudos

Hi Marcin,

I have done exactly what you have mentioned but the problem is when i see the alv output i see some set of characters and when i export those entires to a file on server it has different set of characters.

what might be th problem

Thanks

Bala Duvvuri

0 Kudos

Well, using UNICODE for upload/download files I think is most suitable way. If in AL11 you don't see it being displayed correctly (odd characters appear), that doesn't necessary mean it has wrong encoding set. Maybe AL11 is using different decoding type by default. Normally storage of file on AS is not its final destination, right? You place it there i.e. for customer's job to read it back and send via email. So just make sure that downloading program uses same decoding you used for encoding (UTF-8). Then the characters in the output stream (i.e. frontend file, mail body) should be displayed correctly

What I mean is don't worry how it is dispalyed in AL11, just ensure that after you download it, the characters are correctly decoded.

PS: Make sure that you metion encoding type explicitly both for upload and download programs


OPEN DATASET dset .... IN TEXT MODE ENCODING/DECODING UTF-8.

Regards

Marcin

0 Kudos

Hi Marcin,

We dont have any download program to download the file and read it.Within the report we are just creating the file and users will manually download the file .

any other suggestion

Thanks

Bala Duvvuri

0 Kudos

>

> We dont have any download program to download the file and read it.Within the report we are just creating the file and users will manually download the file .

If i may reply on Marin's behalf. I think what Marcin is trying to put forth is that there should not be any encoding problem if the app server file is written & read in the same code page.

May be AL11 is using some different encoding to display the file which is why we have the junk characters. Did you check the actual file written in the AS? Do you've juck characters there as well?

BR,

Suhas

0 Kudos

You can try another alternative, namely upload it in binary mode (data stream AS-IS)


DATA text TYPE string VALUE 'u0142adowarku0105 siu0119 rozu0142upau0142'.  "some Polish text

DATA file TYPE string VALUE '/tmp/test.txt'.

OPEN DATASET file FOR OUTPUT IN BINARY MODE.

Then in AL11 indeed you will get that displayed as

#B#a#d#o#w#a#r#k### #s#i### #r#o#z#B#u#p#a#B

But now if the user downloads it (manually I guess using CGY3 tcode) only ensure that BIN transfer format is selected and in the PC file the content is as expected

ładowarką się rozłupał

Regards

Marcin

0 Kudos

Suhas,

What do you mean by this

Did you check the actual file written in the AS? Do you've juck characters there as well?

Thanks

Bala Duvvuri

0 Kudos

Hi Marcin,

I forgot to mention we are generating a csv file and I am not sure we can use binary mode in this case.I tried to use it and we are getting only the header and not the data in the csv file when we download it from server with BIN selected

Thanks

Bala Duvvuri

0 Kudos

Hello Bala,

Did you check the actual file written in the AS? Do you've junk characters there as well?

AL11 is a report program displaying the contents of the file. What i meant was to access the actual file, as Marcin has mentioned via trxn. CG3Y or CACS_FILE_COPY.

BR,

Suhas

0 Kudos

Yes Suhas it has junk characters