link ebcdic
August 14, 1996; Alan Beale
This file is in the public domain.
These procedures assist in use of the ASCII and EBCDIC character sets,
regardless of the native character set of the host:
Ascii128() Returns a 128-byte string of ASCII characters in
numerical order. Ascii128() should be used in
preference to &ascii for applications which might
run on an EBCDIC host.
Ascii256() Returns a 256-byte string representing the 256-
character ASCII character set. On an EBCDIC host,
the order of the second 128 characters is essentially
arbitrary.
Ebcdic() Returns a 256-byte string of EBCDIC characters in
numerical order.
AsciiChar(i) Returns the character whose ASCII representation is i.
AsciiOrd(c) Returns the position of the character c in the ASCII
collating sequence.
EbcdicChar(i) Returns the character whose EBCDIC representation is i.
EbcdicOrd(c) Returns the position of the character c in the EBCDIC
collating sequence.
MapEtoA(s) Maps a string of EBCDIC characters to the equivalent
ASCII string, according to a plausible mapping.
MapAtoE(s) Maps a string of ASCII characters to the equivalent
EBCDIC string, according to a plausible mapping.
Control(c) Returns the "control character" associated with the
character c. On an EBCDIC host, with $ representing
an EBCDIC character with no 7-bit ASCII equivalent,
Control("$") may not be identical to "\^$", as
translated by ICONT (and neither result is particularly
meaningful).
____________________________________________________________
Notes:
There is no universally accepted mapping between ASCII and EBCDIC.
See the SHARE Inc. publication "ASCII and EBCDIC Character Set and
Code Issues in Systems Application Architecture" for more information
than you would ever want to have on this subject.
The mapping of the first 128 characters defined below by Ascii128()
is the most commonly accepted mapping, even though it probably
is not exactly like the mapping used by your favorite PC to mainframe
file transfer utility. The mapping of the second 128 characters
is quite arbitrary, except that where an alternate translation of
ASCII char(n) is popular, this translation is assigned to
Ascii256()[n+129].
The behavior of all functions in this package is controlled solely
by the string literals in the _Eascii() procedure. Therefore you
may modify these strings to taste, and still obtain consistent
results, provided that each character appears exactly once in the
result of _Eascii().
Yes, it's really true that the EBCDIC "\n" (NL, char(16r15)) is not
the same as "\l" (LF, char(16r25)). How can that be? "Don't blame
me, man, I didn't do it."