-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
James,
On 10/12/12 11:48 AM, James Lampert wrote:
> Christopher Schultz wrote:
>
>> This is what I get from my own web.xml:
>>
>> 0000000 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d
>> 22 31 < ? x m l sp v e r s i o n = "
>> 1 0000020 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d
>> 22 49 53 . 0 " sp e n c o d i n g = "
>> I S 0000040 4f 2d 38 38 35 39 2d 31 22 3f 3e 0a O
>> - 8 8 5 9 - 1 " ? > nl 0000054
>
> Well THAT's weird:
>
> Aside from the file's pathname having one directory level you
> didn't mention (WEB-INF), . . .
>
> The CCSID on the file says 819 ("ISO 8859-1: Latin Alphabet Number
> 1"). If do a "head" on the file, without piping it into "od," I get
> the expected text.
>
> If I download it to a WinDoze box via FTP, in binary mode, and open
> it in Hex Editor, everything matches.
>
> But if I pipe a "head" into an "od" as you described, the hex
> values come up as if the file were EBCDIC.
>
> And what's even weirder is that Tomcat, and the webapp, come up
> just fine, after the exceptions are logged.
Your posts to this list have convinced me that using AS/400 should be
on my "to-NOT-do list". ;)
Doing a binary FTP to another box should have given you complete
garbage (aka EBCDIC). The only thing I can think of is that 'head' is
reading the file and converting it into EBCDIC before handing it off
to 'od'. The 'head' program is supposed to be text-oriented, so it's
possible that 'head' opens the file as "text" (e.g. fopen() without
using the "b" modifier to open as binary).
You could try flipping things around to use 'od' first. 'od' surely
uses a binary read:
$ od -t x1a webapps/yourwebapp/WEB-INF/web.xml | head -n 5
My output:
0000000 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31
< ? x m l sp v e r s i o n = " 1
0000020 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 49 53
. 0 " sp e n c o d i n g = " I S
0000040 4f 2d 38 38 35 39 2d 31 22 3f 3e 0a 0a 3c 77 65
I dunno if that gets you anywhere.
Actually, it might.
No, I changed my mind.
At first, I was thinking that perhaps Tomcat was using a FileReader to
read web.xml. Java might implement that using fopen("r") - that is,
without a 'b' modifier and therefore get magic (and *totally
"helpful"*) "text translation" into EBCDIC). But there are two reasons
why that is wrong: 1) Tomcat uses ServletContext.getResourceAsStream
(not text) and 2) a Reader should convert from whatever wacky encoding
is being used on the bare metal into Java-friendly characters.
Again, it sounds like using AS/400 really sucks.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlB4Pl4ACgkQ9CaO5/Lv0PAqpgCbBpGW4ac4eLet5UfqvOrBxeUx
tSkAoJy8/jQprpcPAmmV8QPbTTdw/bQU
=1X+M
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
