03-31-2011 11:36 AM
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
03-31-2011 11:41 AM
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!!
03-31-2011 12:46 PM
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
03-31-2011 2:13 PM
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
04-01-2011 5:14 AM
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
04-01-2011 7:57 AM
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
04-01-2011 8:40 AM
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
04-01-2011 8:56 AM
>
> 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
04-01-2011 9:24 AM
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
04-01-2011 10:13 AM
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
04-01-2011 10:14 AM
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
04-01-2011 10:24 AM
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
04-01-2011 10:47 AM