EBCDIC 382

IBM code page 382 is an EBCDIC code page used used in IBM mainframes. It is called Publishing: Austria, Germany, Switzerland.[1][2] This code page is supported by IBM.[3] It is a modification of EBCDIC 361.

Codepage layout

EBCDIC 382[4][5]
_0 _1 _2 _3 _4 _5 _6 _7 _8 _9 _A _B _C _D _E _F
4_ SP
0020

 
â
00E2
{
007B
à
00E0
á
00E1
ã
00E3
å
00E5
ç
00E7
ñ
00F1
Ä
00C4
.
002E
<
003C
(
0028
+
002B
!
0021
5_ &
0026
é
00E9
ê
00EA
ë
00EB
è
00E8
í
00ED
î
00EE
ï
00EF
ì
00EC

 
Ü
00DC
$
0024
*
002A
)
0029
;
003B
¬
00AC
6_ -
002D
/
002F
Â
00C2
[
005B
À
00C0
Á
00C1
Ã
00C3
Å
00C5
Ç
00C7
Ñ
00D1
ö
00F6
,
002C
%
0025
_
005F
>
003E
?
003F
7_ ø
00F8
É
00C9
Ê
00CA
Ë
00CB
È
00C8
Í
00CD
Î
00CE
Ï
00CF
Ì
00CC

 
:
003A
#
0023
§
00A7
'
0027
=
003D
"
0022
8_ Ø
00D8
a
0061
b
0062
c
0063
d
0064
e
0065
f
0066
g
0067
h
0068
i
0069
«
00AB
»
00BB

2030

2212
ij
0133

FB03
9_ °
00B0
j
006A
k
006B
l
006C
m
006D
n
006E
o
006F
p
0070
q
0071
r
0072

2014
Œ
0152
æ
00E6
Ÿ
0178
Æ
00C6

25CF
A_
FB00
ß
00DF
s
0073
t
0074
u
0075
v
0076
w
0077
x
0078
y
0079
z
007A
¡
00A1
¿
00BF
œ
0153

FB04

2021

201E
B_ ¢
00A2
£
00A3
¥
00A5

FB01

FB02
@
0040

00B6
¼
00BC
½
00BD
¾
00BE

215B

2018

2019

201C

201D

2020
C_ ä
00E4
A
0041
B
0042
C
0043
D
0044
E
0045
F
0046
G
0047
H
0048
I
0049

 
ô
00F4
|
007C
ò
00F2
ó
00F3
õ
00F5
D_ ü
00FC
J
004A
K
004B
L
004C
M
004D
N
004E
O
004F
P
0050
Q
0051
R
0052

215C
û
00FB
}
007D
ù
00F9
ú
00FA
ÿ
00FF
E_ Ö
00D6

 
S
0053
T
0054
U
0055
V
0056
W
0057
X
0058
Y
0059
Z
005A

215D
Ô
00D4
\
005C
Ò
00D2
Ó
00D3
Õ
00D5
F_ 0
0030
1
0031
2
0032
3
0033
4
0034
5
0035
6
0036
7
0037
8
0038
9
0039

215E
Û
00DB
]
005D
Ù
00D9
Ú
00DA

 

  Letter  Number  Punctuation  Symbol  Other  Undefined

gollark: ... no.
gollark: Thus bad.
gollark: It does NOT allow random access.
gollark: Hmm, so, designoidal idea:- files have the following metadata: filename, last modified time, maybe permissions (I may not actually need this), size, checksum, flags (in case I need this later; probably just compression format?)- each version of a file in an archive has this metadata in front of it- when all the files in some set of data are archived, a header gets written to the end with all the file metadata plus positions- when backup is rerun, the system™️ just checks the last modified time of everything and sees if its local copies are newer, and if so appends them to the end; when it is done a new header is added containing all the files- when a backup needs to be extracted, it just reads the end, finds the latest versions and decompresses stuff at the right offsetThere are some important considerations here: it should be able to deal with damaged/partial files, encryption would be nice to have (it would probably work to just run it through authenticated AES-whatever when writing), adding new files shouldn't require tons of seeking, and it might be necessary to store backups on FAT32 disks so maybe it needs to be able of using multiple files somehow.
gollark: I have been pondering an osmarksarchiveformat™ because I dislike the existing ones somewhat. Specifically for backups and append-only-ish access. Thusly, thoughts on the design (crossposted from old esolangs)?

References

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.