I was playing around with GUI_DOWNLOAD the other day, trying to make a decent extract from SAP for uploading into Excel. Of course, there are other ways of doing this, but many solutions still rely on the proven CSV format. The problem is, older applications may not be that good handling non-standard data, such as when your company expands to regions with specific character sets.
GUI_DOWNLOAD defaults to the code page used by the windows front-end, like 1160 (windows-1252). This may be good enough for general purposes, but what if you need to download specific characters and find your resulting CSV file “simplified” to your own local code page?
The solution is to populate the CODEPAGE parameter of the function with something more sensible, like UTF-8. Table TCP00A shows the code pages available; 4110 is nice for UTF-8.
Here is a sample excerpt from a CSV file downloaded using code page 1100. The names in this file are in the Czech language, thus contains (or should contain) lots of specific characters:
We see the ubiquitous # symbols popping up everywhere, replacing a lot of the specific CZ-style characters.
Let’s try something else…
Running the function using code page 4110, however, remedies this:
The curse of Excel
Now, what about Excel? Excel seems to have a certain preference for CSV files, to the degree it has become something of a native format to the application. Unfortunately, this also means Excel is pretty good at cannibalizing any CSV files thrown at it, deleting leading zeroes and spaces, and generally doing whatever it thinks is right (which is not always what we think is OK). The second download from above will actually show up like this in Excel:
Funny thing is, if you rename the file to .TXT format, it parses correctly into Excel:
Maybe the MS/Excel gurus out there can provide some further hints on how to avoid the “Excel ate my CSV” syndrome!