The source data for this proposed application is Line Data from an IBM mainframe,
so it is EBCDIC, Code Page 278 - Finland/Sweden, fixed block with ANSI carriage
control characters in this case.
The idea is to package selected subsets for transmission to workstations,
which of course means Windows platsforms.
I have tried the 'built-in' ASCII transform:
odHit.retrieve(ODConstant.ASCII, "C:\\jj\\OD3\\1hitRGBA.txt");
but we are having some difficulties in reading the .txt file.
1) The record length is honoured and the file has lines ended via 0x0A, Line Feed.
This means that the .txt file is correctly shown by Windows Word Pad but not by
'Notes', which expects 0x0D0A CR+LF
2) The Swedish national characters ÅÄÖ and åäö are correctly translated into two
bytes ASCII characters. C3+..
And the national characters are correctly displayed by 'Notes' while Word Pad displays
each byte individually.
So the file is actually UTF-8 but it does not have the leading indication of 0xEFBBBF.
I made a small experiment of adding these three bytes in front of the data returned and
now it is at least correctly displayed by Word Pad.
I have reread the redbook and others but I am not able to find any parameters which seem to
be meant to influence this translation.
Is this a defect or working as designed?
Is this transfor also being 'phased out' like the AFP-related?
My best idea is to use the interface to a another java class vid ODtransform.XML and
utilize the ICU package to do the translation. This would also allow truncating all
'trailing blanks' which could significantly reduce network load.
Any other suggestion?