|There's more than one way to do things|
Re^20: Native newline encodingby sauoq (Abbot)
|on May 29, 2012 at 14:14 UTC||Need Help??|
You do the transfer in binary mode and what do you end up with? Utter garbage!
Incorrect. Again. What you end up with is an XML file encoded in UTF-EBCDIC.
Your supposition that your transfer tools should be able to handle all necessary conversions for you is just wrong-headed.
Let's change this assumption...
The only access available is ftp.
... and assume instead that the only available access is via a webserver.
Since it isn't going to do any conversions for you, what are you going to do? Pull out iconv, of course. Or an equivalent tool. Or do nothing so long as your tool set handles the encoding without problems.
Consider unpacking (on z/OS, if you like) an archive file containing thousands of different XML files with different encodings, created on different platforms. Then someone gives you the filename of one of those and tells you they need you to transfer it to a totally different platform. Whatchagonnado?
I'll gift you a hint. Under ASCII mode [. . . snip . . .]
And I've already gifted you the hint: don't use ASCII mode.
The point of ASCII mode, is that the source encodes the data into a known format: "8-bit NVT-ASCII". At the destination, that format is then converted to whatever local format is required. The point of this is that each system only needs to know how to convert from its local format and the "well-known format".
You know, that whole paragraph explains a lot. Are you perhaps just so steeped in the old ways of doing things that you completely fail to recognize what advantages a universal cod(e)ing imparts and the problems it solves?
"My two cents aren't worth a dime.";