On Mon, Mar 2, 2015 at 2:52 PM, <craigs@xxxxxxxxx> wrote:
IBM said, "This problem is not specific to the IBM i or the QSH
environment. You can recreate exactly the same problem using the "jar"
command from a Windows or Linux PC.
This is an issue with jar command (no matter the OS), although, I am not
sure it is a "problem" with jar since jar is able to extract the contents
without problem. More, an interaction between jar and the utility you are
using to view the contents of the "jar-ed" file."
So, it seems, IBM is saying, use something else and ARP-ZIP is a free
alternative to the Java jar and has further features such as encryption
type, compression level, etc.
That's not how I read it. I believe IBM is saying that the symptoms
you're seeing are actually (1) harmless, and (2) an issue with the way
the jar contents are being displayed, rather than an issue with the
actual jar contents.
In other words, everything about the jar itself is absolutely fine.
IBM's recommendation is actually more akin to: Keep using the jar
program, and don't be fazed by the weird display.
You never addressed Chuck's comment:
"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."
I didn't fully understand how Chuck was getting the results he was
getting in his own testing, but I think I followed the gist of his
comment. I did a little rudimentary testing of my own on a Windows 7
PC and found that the jar command (which came with Java version 1.7.0
for Windows) archived files with accented characters in their names
just fine, though with somewhat weird reporting of those names.
I made a couple of files:
tëst.txt
fóobár.txt
(In case the characters are not showing up in your e-mail client, the
'e' has a diaeresis (which I'd call an umlaut), the first 'o' and the
'a' each have an acute accent.)
I ran the following command from the command line:
jar cvf test.jar tëst.txt fóobár.txt
As it was working, jar reported this at the command line session:
added manifest
adding: tδst.txt(in = 5) (out= 7)(deflated -40%)
adding: f≤obßr.txt(in = 5) (out= 7)(deflated -40%)
And when I renamed the archive to .zip so that Windows Explorer could
open it with its built-in compressed folder facility, the names of the
files *appeared* as
t+½st.txt
f+¦ob+ír.txt
However, when I opened the same archive with 7-Zip, the names of the
files were exactly as I originally entered them.
So the way the Windows ZIP-reader is rendering the names of the jar
contents is different than the way 7-Zip is rendering those same names
in the very same jar archive.
Which is why I believe IBM is telling you there's nothing *materially*
wrong with jar; it's quirky and *depending on how you look at them*
the names in the jar archives may show up wonky. But it amounts to a
cosmetic issue, and everything is still fine.
Incidentally, inspecting the names within test.jar using Python's
standard library returns the Unicode code points, with
e-with-diaeresis as 0xEB, o-with-acute as 0xF3, and a-with-acute as
0xE1. Which is further support for the notion that the names are
getting into the archive as intended; they are just not always
interpreted as intended when displayed.
John Y.
midrange.com
