Re: Qshell jar zipped file has strange characters

On 26-Feb-2015 11:51 -0600, Tim Bronski wrote:

<<SNIP>> the file name has to be converted into an ascii ccsid before
it gets inserted into the archive directory. I don't know what TO
ccsid jar is using to do this. The zip archive has no understanding
of ccsids so the codepoint you convert to has to match the one on the
expected destination system.

In tests on v5r3, irrespective the CCSID both of the directory within which the compressed file resided and the [default] CCSID of the job or the QIBM_CCSID EnvVar specification, the file name is converted from EBCDIC into UTF8; no idea what the presumed EBCDIC CCSID is /assumed/ to be for the file name in that conversion. The file extracted on my Mac client, from the file transported in binary\image format, present the names of the files exactly as expected; the same as they appeared, the same glyphs, as the one used [and verified to be proper] when making the following request:
QSH CMD('jar -cfvM /tmp/my_jar dir1208 dir1252 dir819 dir037')

The request to 'jar -tf /tmp/my_jar' works both on the IBM i and elsewhere, to list the [table of] contents of the jar file; showing in each of the directories named dir### where ### is the CCSID of the directory, a file named "char_å_0x47".

FWiW I used the character LA270000 "a Overcircle Small (å)" EBCDIC code point 0x47 instead of the character named as being used in the OP [i.e. "a Grave Small (à)"], merely because the character "å" is conveniently and properly mapped as well as properly displayed as a glyph for me in my emulator. Without any modifications, the file name appears on my 5250 display using DSPF of the jar file tagged with CCSID 819, as the two characters 'Ã¥' for 0xC3A5 because those are the ASCII code points for those single-byte characters. If I first issue the CL request to "CHGATR '/tmp/my_jar' *CCSID 1208", then the expected single glyph will appear showing the file name; the file name is shown with just the multi-byte 0xC3A5 as represented with just the one glyph "å".

The OP did not explain where the '|+' was seen; no mention of the interface used for which that string was presented, but whatever was being used apparently thinks there are two distinct one-byte characters instead of the multibyte like I described above. However for the the character LA130000 "a Grave Small (à)" to appear as 0xC3A0 or "Ã " rather than '|+', however 0xA0 is the (RSP) "required space" character for which I have found almost no non-IBM system [applications] to deal well with that character.