CP500 EBCDIC encoding bug?

[Tin Gherdanarra]

This is probably a fringe programme...

In the past I used a C-program to convert from EBCDIC (CP500)
to ASCII/Unicode. As you might guess, this is simply a 256-byte
lookup table. I lifted it from Larry Wall's perl source, to
be found here:

http://www.nntp.perl.org/group/perl.mvs/735

This worked very well. For some reason, the C# codec for
CP500 does not convert CR/LF (0x15 in EBCDIC) to 0x0A in
ASCII. Instead, it converts to 0x85. The other character
translations look okay. I figured that I might have picked
the wrong encoding, but picking /500/ as code-page for
the ISO standard CP (codepage) 500 is pretty much a
no-brainer. Other EBCDIC encodings from C#'s library
give gross results. So... what gives?

Any experiences from the fringe? Post-processing the
CP500-decoded string by translating the 0x85s to 0x0As
is SLOW in C#.

 

[Mark Rae]

Any experiences from the fringe? Post-processing the
CP500-decoded string by translating the 0x85s to 0x0As
is SLOW in C#.

Have a look at this: http://www.yoda.arachsys.com/csharp/ebcdic/

When Mr Skeet logs in a little later, I'm sure he'll have the solution...

 

[Jon Skeet [C# MVP]]

This is probably a fringe programme...

In the past I used a C-program to convert from EBCDIC (CP500)
to ASCII/Unicode. As you might guess, this is simply a 256-byte
lookup table. I lifted it from Larry Wall's perl source, to
be found here:

http://www.nntp.perl.org/group/perl.mvs/735

This worked very well. For some reason, the C# codec for
CP500 does not convert CR/LF (0x15 in EBCDIC) to 0x0A in
ASCII. Instead, it converts to 0x85.

That's the correct encoding according to a source I've used for EBCDIC
before:

http://std.dkuug.dk/i18n/charmaps/500

Note that Unicode U+0085 is "next line" which fits with the description
on the above page.

Jon

 

[Jon Skeet [C# MVP]]

Have a look at this: http://www.yoda.arachsys.com/csharp/ebcdic/

When Mr Skeet logs in a little later, I'm sure he'll have the solution...

I posted a while ago on Google in fact, but it doesn't seem to have
come through yet.

Basically, according to the code charts I've got, the encoding is doing
the right thing - 0x15 is meant to translate to U+0085 (next line), not
U+000A.

 

[Mark Rae]

Basically, according to the code charts I've got

Yes, but it's still a bit of a "black art", is it not...?

 

[Jon Skeet [C# MVP]]

Yes, but it's still a bit of a "black art", is it not...?

Absolutely. I'd love to see some official specifications, but when I
looked at this a few years ago, the charts at dkuug.org were the only
good references I could find