ASCII(American Standard Code for Information Interchange)
7비트로 표현되는 128개의 알파벳대소문자/숫자/특수문자들의 인코딩 표준이다.
유니코드보다 귀에 익지만 영문밖에 안되는 문자제국주의적 성질을 갖는다.
기술자 도구의 대다수는 이를 채택한다.
ASCII code
Symbol
ASCII code
Symbol
ASCII code
Symbol
0-31
제어문자
48-57
0-9
91-96
특수문자3
0000000-0011111
0110000-0111001
1011010-1100000
32
(space)
58-64
특수문자2
97-122
a-z
0100000
0111010-1000000
1100001-1111010
33-47
특수문자1
65-90
A-Z
123-127
특수문자4
0100001-0101111
1000001-1011001
1111011-1111111
UTF(Unicode Transformation Format)
전세계 문자 집합 표준인 Unicode를 기반으로 하는 인코딩 표준으로, ASCII 확장형이라 할 수 있다.
많은 어플리케이션은 이를 채택한다.
Unicode는 전 세계 문자를 32비트 값에 매핑하는데, 문자를 매핑하고도 코드가 남아 돌아 이모지도 매핑하는 추세인데도 남아 돈다. 이걸 전부다 쓰려 하는 것은 ASCII의 문자제국주의를 피해 Unicode의 다양성 카르텔에 몸을 내던지는 꼴이다. 영문만 표현되는 게 문제인 거지, 이 세상에 알려진 모든 문자를 다 표현할 수 있어야만 하는 걸 바라는 것은 탈현실적이기 때문이다.
이에 보통은 그 호환성을 유연하게 한정하는 UTF-8 이나 UTF-16을 쓰며, UTF-32는 비효율적이라 잘 쓰이지 않는다. 8, 16, 32는 인코딩하는 바이트 단위를 의미하고, Unicode를 기반으로 하기에 매핑테이블 자체는 동일하다.
그럼에도 문자제국주의의 잔상이 남아 있는데, UTF-8의 2바이트 부분이 그렇다. 256개를 구별할 수 있는 1바이트 글자에 128개의 ASCII만 넣어놓은 건 뭐 그렇다 치자. 이건 나라도 그렇게 했지 싶다. 그런데 2바이트 글자의 경우는 무려 65536개를 구별할 수 있는 16비트에 고작 2048개의 라틴/아랍/그리스어 등 자신들과 광의의 동류 언어만 2바이트로 매핑하고 나머지 63000개는 과감히 버린다. 나머지 문자는 3~4바이트로 밀어넣은 모습을 볼 수 있다.
참고로 모든 한글과 히라가나 카타가나, 기본 한자는 65519 안에서 해결된다. 한자는 외래어/신조어도 기본 한자의 조합으로 새로운 한자를 만들어내는 놀라운 문자체계라 확장한자까지 하면 십만대를 초과하기에 2바이트에 모든 문자를 담을 수 없다는 것인데, 정작 바로 뒤이어 나온 UTF-16에서는 기본한자까지만 담아 2바이트로 표현한다.
이게 특히 거슬리는 이유는, 과거 기술자들은 다양한 어플리케이션 제작보다 리소스 최적화에 포커싱하는 것이 일반적이었다. 그런데 자기들이 늘상 하던 최적화 및 리소스 효율을 도모하는 것이 아니라, 이와 반대되는 방향으로 "서방 제외 글자당 1바이트 핸디캡"을 굳이 제공한 셈이기 때문이다.
분류
내용
예시 / 특징
코드포인트
글자당 바이트
UTF-8
8비트 단위로 인코딩하기에 글자당 1 ~ 4바이트값을 갖는다.
한글이 3바이트 ASCII와 호환(영문 1바이트)
0-127
1바이트
128-2047
2바이트
2048-65535
3바이트
65536-1114111
4바이트
UTF-16
16비트 단위로 인코딩하기에 글자당 2 또는 4바이트값을 갖는다.
한글이 2바이트 ASCII 비호환(영문 2바이트)
0-65535
2바이트
65535-
4바이트
UTF-32
32비트 단위로 인코딩하기에 글자당 4바이트 값을 갖는다.
한글이 4바이트 영문도 4바이트
0-
4바이트
Base64는 대표적인 파일 포맷 변환 인코딩 표준이다. 이는 형식적으로는 데이터를 문자로 치환한다는 점에서 ASCII/Unicode와 비슷한 부분이 있긴 하다. 그러나 문자인코딩은 사람이 읽기 위한 인코딩이지만, base64는 시스템 호환을 위해 형식에 끼워 넣는 인코딩이지 사람이 읽기 위한 인코딩은 아니기에 따로 분류한다.
Base64
바이너리데이터(실행파일/이미지파일 등)을 문자로 변환하는 인코딩 표준.
일반적인 텍스트기반 시스템에서는 바이너리 데이터를 처리하지 못하기 때문에, 일단 그 시스템에서 처리는 할 수 있는 문자열로 형식만 바꾸는 인코딩 표준이다.
ASCII/Unicode가 저장 인코딩이라면, Base64는 전송 인코딩이라고 할 수 있다.
png파일의 헤더부분 Hex값은 "89504E470D0A1A0A"과 같다. 이는 "10001001 01010000 01001110 01000111 00001101 00001010 00011010 00001010"라는 바이너리데이터의 16진수 표현이다. 이들은 인코딩된 문자열, 즉 코드값의 상징적 표식이 아니라 그 자체로 컴퓨터 리소스의 처리대상으로서 데이터라는 것이 중요하다. 텍스트기반 시스템에서는 혼동을 빚을 수밖에 없는 것이다. 만약에 ASCII기반 시스템에서 이를 처리한다고 하면, "10001001" 부분은 "1011011 1011010 101101010110101011011 101101010110101011011"로 ASCII에 따라 다시 디코딩되는 대환장파티가 열린다.
도착한 데이터에 대해서 자신의 표준에 따라 언박싱을 하게 되어 있는 텍스트기반 시스템을 생각해보자. 정상적인 작동을 원한다면 그 시스템에 정보를 전송하기 전에 박싱을(그 시스템에서 수행하는 언박싱의 역순) 거친 뒤 보내야 할 것이다. 그런데 박싱 없이 바로 보낸다 생각해보자. 이를 받은 시스템은 그 박싱 여부는 알 바가 아니고 일단 왔으면 언박싱하는 게 당연한 수순이기에, 박싱도 없는 로우데이터를 대상으로 언박싱 과정을 거치는 문제가 발생한다. 유실, 오작동 등 다양한 문제가 발생한다.
어쨋든 호환성을 위해 바이너리데이터를 "문자열로" 인코딩하는 것이 Base64의 골자인데, 형식만 놓고 보면 "문자열과의" 매핑을 담당하는 ASCII/Unicode를 써도 되는 것 아닌가 싶다. 그러나 base64는 의도하지 않은 동작의 우려가 있는 제어 심볼을 배제하고 안전한 6비트 64개 문자들로만 인코딩되기에 더 적합하다. 다만 인코딩 과정에서 데이터 크기가 33%+@ 증가하는 단점이 있다.
문자열로 저장된 데이터를 송신하기 위해서는 ASCII 디코딩 > Base64 인코딩의 과정을 거쳐야 한다. OSP를 예로 들어보면 아래와 같다. 데이터 크기가 33% 증가하는 이유를 한 눈에 알 수 있다. 6비트데이터를 1바이트 문자에 담아버리기 때문(8/6 = 1.333)
Code
Symbol
Code
Symbol
Code
Symbol
0-25
A-Z
52-61
0-9
63
/
26-51
a-z
62
+
ASCII symbol
O
S
P
ASCII code
79
83
80
Bit
0
1
0
0
1
1
1
1
0
1
0
1
0
0
1
1
0
1
0
1
0
0
0
0
Base64 code
19
53
13
16
Base64 symbol
T
1
N
Q
흔히 볼 수 있는 위와 같은 표 양식에서는 base64 symbol이 6비트 크기를 가진다는 착각를 빚지만 사실은 문자 하나당 1바이트 값을 가진다. 33%만큼의 데이터 팽창은 여기서 발생하고, 이에 더해 글자 수에 따라 생기는 비트 부족분을 처리하는 수단이 padding인데, 이 padding 때문에 +@ 만큼의 데이터 팽창이 추가적으로 발생한다. paddoing은 쉽게 표현하면 2비트 "00"을 상징하는 "="라고 요약할 수 있다. 아래 예시를 보면 이해가 빠르다.
padding문자도 1바이트 값을 가지기에, 아래의 예시에 따라 산술적으로 계산하면 (1+2+3+4+5) = 15바이트의 데이터 전송을 위해 인코딩 된 데이터는 (4+4+4+8+8) = 28바이트로 데이터 크기가 2배 가까이 팽창된 모습을 볼 수 있다. 배꼽이 아주 풍년이다.
이러한 문제를 해결하기 위해 base64는 패딩이 필요 없는 3바이트 단위로 인코딩한다. 패딩으로 인한 데이터 팽창을 막기 위함이다. 때문에 패딩은 데이터의 끄트머리에서나 볼 수 있다. 만약 패딩이 중간에 위치한다면 일상적이지 않은 눈초리로 살펴야 한다.
ASCII symbol
A
ASCII code
65
Bit
0
1
0
0
0
0
0
1
0
0
0
0
Base64 code
16
16
Base64 symbol
Q
Q==
ASCII symbol
A
B
ASCII code
65
66
Bit
0
1
0
0
0
0
0
1
0
1
0
0
0
0
1
0
0
0
Base64 code
16
20
8
Base64 symbol
Q
U
I=
ASCII symbol
A
B
C
ASCII code
65
66
67
Bit
0
1
0
0
0
0
0
1
0
1
0
0
0
0
1
0
0
1
0
0
0
0
1
1
Base64 code
16
20
9
3
Base64 symbol
Q
U
J
D
A
B
C
D
65
66
67
68
0
1
0
0
0
0
0
1
0
1
0
0
0
0
1
0
0
1
0
0
0
0
1
1
0
1
0
0
0
1
0
0
0
0
0
0
16
20
9
3
17
0
Q
U
J
D
R
A==
ASCII symbol
A
B
C
D
E
ASCII code
65
66
67
68
69
Bit
01000001
01000010
01000011
01000100
01000101
Bit
01000
010100
001001
000011
010001
000100
010100
Base64 code
16
20
9
3
17
4
20
Base64 symbol
Q
U
J
D
R
E
U=
2. Encryption
방어적 목적의 데이터 변조 행위를 암호화(encryption)이라 하며, 그 이렇게 변조된 데이터를 다시 원상태로 복구하는 행위를 복호화(decryption)라 한다. 그리고 그러한 매핑 논리를 암호화 알고리즘이라 한다.
XOR은 암호화 데이터와 키를 비교하여 같으면 0, 다르면 1으로 변조하는 암호화 알고리즘이다.
아래는 ASCII의 XOR 암/복호화 예시이다. 예시일 뿐 실제로 이런 암호화를 짜는 이는 없다. 주목해야 하는 특징은 암호화 키와 복호화 키가 동일하다는 것, 그리고 이로 인해 그 키의 안전한 분배 방법이 문제된다는 것이다.
암호화
ASCII symbol
O
S
P
ASCII code
79
83
80
Bit
0
1
0
0
1
1
1
1
0
1
0
1
0
0
1
1
0
1
0
1
0
0
0
0
XOR key
0
1
0
1
0
1
1
1
0
1
1
0
1
0
0
0
0
1
0
1
0
1
0
1
encrypted bit
0
0
0
1
1
0
0
0
0
0
1
1
1
0
1
1
0
0
0
0
0
1
0
1
Encrypted code
24
59
5
Encrypted symbol
CAN
;
ENQ
복호화
Encrypted code
24
59
5
XOR key
0
1
0
1
0
1
1
1
0
1
1
0
1
0
0
0
0
1
0
1
0
1
0
1
Decrypted bit
0
1
0
0
1
1
1
1
0
1
0
1
0
0
1
1
0
1
0
1
0
0
0
0
ASCII code
79
83
80
ASCII symbol
O
S
P
비대칭형 암호화(Aasymmetric Encryption)
암호화 키와 복호화 키를 서로 달리 두는 유형이다. 연산이 무겁고 느리다.
수신자측에서 공개키(암호화키)와 개인키(복호화키)를 준비한다. 공개키는 말 그대로 공개하여 누구나 암호화할 수 있도록 하는 반면, 개인키는 공개하지 않아 자기만 복호화할 수 있게 한다. 즉 암호화 키와 복호화 키를 분리하여 대칭형 암호화의 키 분배 문제를 해결한다.
비대칭 암호화 알고리즘에는 RSA, ECC가 대표적이다.
암호화 알고리즘을 은닉하는 방향보다 암호화 알고리즘을 알아도 현실적인 시간 내에 해결할 수 없도록 하는(개인키를 획득하기 어려운) 방향으로 암호학이 발전했기에 연산이 무겁다.
해시 함수(Hash function)
임의의 데이터를 고정된 길이의 고정된 길이의 데이터로 매핑하는 함수이다.
위는 일반론적 설명이고, 실증적인 설명은 "암호화인데 복호화할 수는 없는 단방향 함수"이다.
클라이언트들의 중요 정보는 암호화하여 저장하거나 처리하는 것이 근래의 표준이다. 여기에서 문제가 발생한다. "대칭이던 비대칭이던 어쨋든 복호화키로 내 중요 정보를 마음대로 볼 수도 있다는 거 아니야?" 서버사이드에서 볼 마음은 당연히 없겠지만, 불순한 마음이 없어도 이를 가능하게 하는 수단이 있다는 것 자체가 문제된다. 이런 문제의식에서 출발한 접목이 해시암호화이다.
암호화는 복호화와 쌍으로 묶이는 개념이기도 하고, 해시암호화는 이런 묶음을 분리해야 한다는 문제의식에서 출발했기에 해시암호화라는 지칭에 대한 반발도 있다.
대표적인 해시알고리즘에는 SHA시리즈, MD5가 있다.
비대칭 암호화는 어쨋든 복호화 해야 함을 전제로 복호화 키는 있어야 하고, 대신 복호화 키를 획득하기 어렵게 만든 암호화 방식이라면, 해시암호화는 복호화키가 없는(정확히는 없는 것을 목적으로 하는) 암호화 방식이다. 활용할 수는 있어야 하기에 여러 입력값이 동일한 출력값을 갖는 경우가 없어야 한다.(해시충돌)
3. Compression
데이터는 용량은 보조메모리/통신부하 등 컴퓨터 리소스 소모량의 지표가 된다. 컴퓨터 리소스를 효율적으로 활용하기 위해 데이터 용량을 줄이는 행위, 즉 압축을 의미한다. 압축풀기는 Decompression.
