, ASCI에 대한 내용은
아시아 스타 챌린저스 인비테이셔널
문서
참고하십시오.1. 개요
|
|
| 2열 이후의 코드들은 위키에서 사용할 수 없는 특수 문자 항목의 링크를 걸 때 사용하는 코드들이다.[1] |
1963년 미국 ANSI에서 표준화한 정보 교환용 7비트 부호 체계. 인쇄 전신기(teleprinter)[2]를 통한 전신(통신)에서 사용되기 시작했고, 8비트 컴퓨터에서도 활용되어 오늘날 문자 인코딩의 근간을 이루게 된다.
000(0x00)부터 127(0x7F)[3]까지 총 128개의 부호가 사용된다. 1바이트를 구성하는 8비트 중에서 7비트만 쓰도록 제정된 이유는 나머지 1비트를 통신 에러 검출을 위한 용도로 비워두었기 때문이다. parity bit라고 해서 7개의 비트 중 1의 개수가 홀수면 1, 짝수면 0으로 하는 식의 패리티 비트를 붙여 전송 도중 신호가 변질된 것을 수신 측에서 검출해 낼 수 있도록 하였다. 일종의 원시적인 CRC 체크섬이라고 할 수 있다.
영문 키보드로 입력할 수 있는 모든 기호들이 할당되어 있는 가장 기본적인 부호 체계이다. 매우 단순하고 간단하기 때문에 어느 시스템에서도 적용 가능하다는 장점이 있다. 8비트 컴퓨터에서는 아스키 코드에 1비트를 더해 더 많은 문자를 표현할 수 있는 여지가 생겼고, 아스키 코드에 없는 문자를 추가해 "코드페이지"를 제정하였다. IBM PC에서는 "Codepage 437"(라틴어, 음성 기호, 수학 기호, 괘선, 특수 문자 등 추가)을 사용했고, 확장된 아스키 코드의 사실상 표준이 되었다. 이 외 각국의 언어에 따라 다양한 코드페이지가 존재하는데, 대부분 아스키 코드에 기반하여(가급적 훼손하지 않고) 제작된다.
한글 인코딩은 2바이트 이상을 써야 가능했기 때문에 아스키 코드를 건드릴 수밖에 없었고 초창기에는 글자 깨짐 문제가 종종 발생하였다. 코드페이지( CP949 등)를 맞춰주지 못하면 역시 글자 깨짐이 발생했고, 해외 게임을 할 때 특히 그러했다. 유니코드가 제정되면서 글자 깨짐은 끝날 줄 알았지만 멀티 바이트의 엔디안 문제로 글자는 또 깨졌고, ASCII가 호환되는 UTF-8이 널리 사용되면서 글자 깨짐은 막을 내리게 된다.
ASCII와 CP437에는 CLI 인터페이스에서도 그림을 그릴 수 있게 각종 특수 문자가 존재하는데 이를 적극적으로 활용하여 예술로 승화시킨 것을 아스키 아트라고 부른다. Text only 형태의 게시판에서 자주 보였다.
2. 목록
아래 표는 아스키 코드 중 제어 문자와 확장 아스키 코드를 제외한 부호(영문 자판에 사용되는 부호)를 정리한 것이다.| 10진수 | 부호 | <colbgcolor=#eaeaea,#43474c> 10진수 | <colbgcolor=#eaeaea,#43474c> 부호 | 10진수 | 부호 | <colbgcolor=#eaeaea,#43474c> 10진수 | <colbgcolor=#eaeaea,#43474c> 부호 |
| 032 | [4] | 056 | 8 | 080 | P | 104 | h |
| 033 | ! | 057 | 9 | 081 | Q | 105 | i |
| 034 | " | 058 | : | 082 | R | 106 | j |
| 035 | # | 059 | ; | 083 | S | 107 | k |
| 036 | $ | 060 | < | 084 | T | 108 | l |
| 037 | % | 061 | = | 085 | U | 109 | m |
| 038 | & | 062 | > | 086 | V | 110 | n |
| 039 | ' | 063 | ? | 087 | W | 111 | o |
| 040 | ( | 064 | @ | 088 | X | 112 | p |
| 041 | ) | 065 | A | 089 | Y | 113 | q |
| 042 | * | 066 | B | 090 | Z | 114 | r |
| 043 | + | 067 | C | 091 | [ | 115 | s |
| 044 | , | 068 | D | 092 | \\ | 116 | t |
| 045 | - | 069 | E | 093 | ] | 117 | u |
| 046 | . | 070 | F | 094 | ^ | 118 | v |
| 047 | / | 071 | G | 095 | _ | 119 | w |
| 048 | 0 | 072 | H | 096 | ` | 120 | x |
| 049 | 1 | 073 | I | 097 | a | 121 | y |
| 050 | 2 | 074 | J | 098 | b | 122 | z |
| 051 | 3 | 075 | K | 099 | c | 123 | { |
| 052 | 4 | 076 | L | 100 | d | 124 | | |
| 053 | 5 | 077 | M | 101 | e | 125 | } |
| 054 | 6 | 078 | N | 102 | f | 126 | ~ |
| 055 | 7 | 079 | O | 103 | g |
- 흔히 이 목록에 있는 문자들을 영숫자라고 부른다. 좁은 의미로는 숫자 10개(0~9, 0x30 ~ 0x39), 대문자 26개(A~Z, 0x41 ~ 0x5A), 소문자 26개(a~z, 0x61 ~ 0x7A) 해서 총 62개의 문자를 영숫자라고 부르고, 넓은 의미로는 이 목록의 문자들을 모두 포괄한다.
- 한편, 92번은 EUC-KR에서는 ₩, Shift-JIS에서는 ¥로 표시된다. 자세한 사항은 백슬래시 문서 참조.
-
참조:
Codepage 437 (IBM PC) ASCII Table
2.1. 특수 문자화 된 제어 문자
IBM CP437 아스키 코드에는 제어 문자 자리에 Null(0x00)을 제외한 32개의 특수 문자를 배당해 놓았다. 물론 그렇다고 해서 제어 문자의 기능이 없어지는 것은 아니며 프로그램이나 글꼴에 따라서는 모양을 출력하지 않거나 아예 무시해 버린다. 아래 표에서는 같은 모양의 유니코드 문자들로 대체하였다.| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D | E | F | |
| 0x | NUL | ☺ | ☻ | ♥ | ♦ | ♣ | ♠ | •[A] | ◘[B] | ○[C] | ◙[D] | ♂ | ♀ | ♪[E] | ♫ | ☼ |
| 1x | ► | ◄ | ↕ | ‼ | ¶ | § | ▬ | ↨ | ↑ | ↓ | → | ← | ∟ | ↔ | ▲ | ▼ |
| 7x | ⌂ | |||||||||||||||
0x0A에 해당되는 ◙ 자는 유닉스 계열의 OS에서 작성된 텍스트 파일을 Windows 10 1803까지의 메모장으로 열면 줄 바꿈이 모조리 붙어 나오면서 줄 바꿈 자리에 이 문자가 찍혀 나온다. 이것은 두 OS의 줄 바꿈 표시 방법이 다르기 때문인데 유닉스는 Line Feed만으로 줄 바꿈을 인식하는 반면 윈도우는 Carriage Return과 Line Feed 두 제어 문자가 같이 붙어 있어야 줄 바꿈을 인식한다. 그래서 유닉스 계열 OS에서 작성된 텍스트 파일은 윈도우에서 줄 바꿈이 되지 않고 저 문자가 대신 출력된다. 반대로 유닉스 계열에서 윈도우에서 작성된 텍스트 파일을 그냥 열면 Line Feed는 인식되어 줄 바꿈이 되지만 Carriage Return은 인식 못 하여 각 줄 맨 끝에 ♪ 자가 찍혀 나오게 된다.[10] 이 문제는 Windows 10 1809의 메모장에서 줄바꿈 방식을 자동으로 인식하도록 바뀌면서 해결되었다.
한국어 아스키 코드(CP949)에서는 위의 문자들 중 몇 개가 괘선 문자로 대체되어 있다.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D | E | F | |
| 0x | NUL | ┌ | ┐ | └ | ┘ | │ | ─ | •[A] | ◘[B] | ○[C] | ◙[D] | ♂ | ♀ | ♪[E] | ♫ | ☼ |
| 1x | ┼ | ◄ | ↕ | ‼ | ¶ | ┴ | ┬ | ┤ | ↑ | ├ | → | ← | ∟ | ↔ | ▲ | ▼ |
| 7x | ⌂ | |||||||||||||||
Notepad++에서는 제어 문자를 위의 기호로 표시하지 않고, 이니셜을 사용한 자체적인 표시 문자를 사용하기 때문에 어떤 문자가 사용되었는지 쉽게 알 수 있다
언제부턴가 macOS의 기본 한글 입력기에서 Backspace 문자를 제멋대로 입력하는 현상이 발생하고 있다. #
3. 언어 표기용으로
발음 구별 기호와 출판물에서 사용하는 여닫는 따옴표(“” ‘’)와 en dash(–), em dash(—) 등으로 인해 영어를 제대로 표기하려면 아스키 문자만으로는 부족하다. 이런 문제 때문에 나온 것이 8비트로 확장한 아스키 코드이다. 128(0x80)~255(0xFF) 영역에 diacritic을 붙인 문자와 그리스 문자, 수학 기호, 괘선 문자 등을 포함하고 있다. 그러나 이걸로도 여닫는 따옴표나 dash는 해결이 안 되어서, en dash는 HYPHEN-MINUS(-)로, em dash는 수평 괘선 문자(─)로 대체해야 했다. 이 확장된 코드를 ANSI 코드라 부르기도 한다.이 확장 영역은 국가마다 달랐는데 표음 문자를 쓰는 국가 중 128자 이내에서 자국의 문자를 넣을 수 있는 국가가 이 확장 영역을 많이 사용했다(특히 ISO/IEC 8859 시리즈). 주로 알파벳 기반의 문자를 사용하는 국가가 이렇게 사용했지만 아랍어나 태국어, 히브리어에서 사용하는 문자도 글자 수가 128자 내에서 해결이 가능했기 때문에 이 영역을 사용했다. 덕분에 다른 국가에 이메일을 보내면 글자가 와장창 깨졌다(...).
8비트 초기 일본의 PC에서는 이 영역에 가타카나를 넣어서 사용하기도 했다.[16] 그래서 8비트 초기에는 한자나 히라가나 없이 올 가타카나로만 이루어진 문장을 일본에서 만들어진 BASIC 언어 교본 등에서 볼 수 있었다. 현재 일본어 입력기에서 지원하는 반각 가타카나도 이 시절의 잔재인데 Windows 9x/NT4 시절까지만 해도 한자와 히라가나만 전각으로 처리하고 가타카나는 반각으로 처리하는 경우가 흔했다. 여담으로 한글도 이 시기에 모아쓰기를 하지 말고 풀어쓰기를 하자는 움직임이 있었는데 큰 반향은 없었다. 풀어쓰기를 하면 128자 안에서 해결되지만 가독성이 반각 가타카나보다도 훨씬 나빠지기 때문이다.[17]
한국어나 중국어처럼 문자가 굉장히 많은 경우 확장 영역에 해당하는 바이트를 두 개 붙여 놓으면 한 글자로 표시되는 방식을 사용했다. 이는 현재의 유니코드와 거의 동일한 형식이다. 그래서 한국어 환경에선 확장 영역에 있는 괘선 문자를 쓰기가 곤란했던 까닭에 저 앞의 섹션에 나온 것처럼 제어 문자 영역에 있는 특수 문자 중 일부분에 괘선 문자를 때려 박았다. 한글 바이오스 모드가 비활성화됐을 때 텍스트 모드에서 돌아가는 한글 프로그램[18]을 돌리면 괘선 문자가 들어갈 자리에 웃는 얼굴 그림(🙂[19])과 ♥♦♣♠ 등이 나오는 것을 볼 수 있다.
반대로 한글 바이오스 모드가 활성화된 상태에서 텍스트 모드에서 돌아가는 영문 프로그램을 돌리면 괘선 문자가 한글이나 한자로 깨지는 것을 볼 수 있었다. 예를 들면 "────────"라고 반각 수평선 괘선 문자가 나와야 할 곳에 "컴컴컴컴"이라는 한글이 연속으로 나오는 경우가 있는데 수평선 괘선 문자 코드인 0xC4를 "컴" 자에 해당하는 완성형 코드인 0xC4C4로 인식하기 때문에 발생하는 문제이다. 이것 때문에 영문 프로그램을 돌릴 때는 한글 바이오스를 꺼줘야 했다.
4. 유니코드와의 호환성
UTF-8의 경우 ASCII 영역은 그대로 1바이트를 사용하기 때문에 호환이 된다. 반대로 말하자면 UTF-8 문서라도 ASCII 영역에 해당하는 문자만 적혀 있고 BOM까지 없다면 그냥 ASCII 문서와 다를 게 없다.하지만 UTF-16은 2바이트[20]와 4바이트[21]만 사용하기 때문에 서로 호환이 되지 않는다. 이 때문에 UTF-16에서 ASCII 문자를 나타낼 때는 앞에
0x00이 붙는다. 예를 들어 A라는 글자를 표현하려면, ASCII나 UTF-8에서는 0x41이라고만 표현하면 되지만 UTF-16에서는 0x0041로 표현해야 한다. 이를 무시하고 1바이트로만 표현하면 앞뒤의 바이트가 묶여서 전혀 다른 문자가 튀어나온다. 반대로 UTF-16으로 작성된 문서를 고정 폭 글꼴을 사용하는 텍스트 편집기에서 ASCII로 읽으면 ASCII 영역의 문자열들이 한 글자 한 글자 띄어쓰기를 해놓은 것처럼 띄엄띄엄 표시되는 것을 알 수 있는데, 이 역시 앞뒤에 붙은
Null(0x00)이 따로 해석돼서 발생하는 현상이다.[22]- 예시: ABCD
-
ASCII:
41 42 43 44 -
UTF-16LE:
41-00 42-00 43-00 44-00 -
UTF-16BE:
00-41 00-42 00-43 00-44 -
ASCII→UTF-16LE:
42-41 44-43/ 䉁䑃 -
ASCII→UTF-16BE:
41-42 43-44/ 䅂䍄 -
UTF-16LE→ASCII:
41 00 42 00 43 00 44 00/ A(Null)B(Null)C(Null)D(Null)[23]
유니코드의 첫 256글자(U+0000 ~ U+00FF)는 확장 ASCII 코드 중 하나인 ISO/IEC 8859-1을 그대로 차용한 것이다.
Windows 10 1903부터는 메모장의 기본 인코딩이 ANSI에서 UTF-8로 바뀌었다.
5. 기타
프로그래밍 언어에서 10진수(%d / Decimal)로 문자(Char)를 출력 시 아스키 코드의 10진수가 출력된다. 당연히 8진수(%o) 또는 16진수(%x)로도 가능하다. 일반적으로 해당 경우를 거의 사용하지는 않으나 65부터 A가 시작된다는 사실을 알고 있으면 코딩 시 꽤 도움이 된다.6. 관련 문서
[1]
기호가 들어갈 곳에 코드를 넣어 주면 된다. (
URL escape code는 아스키 문자의 hex(16진수)값을 이용한다. 항목 참조)
[2]
모스 부호(1844)를 전달하는
전신기를 대체하는 1900년 즈음부터 발명·개량된 기계이며
타자기 사용하듯
키보드로 손쉽게 입력하는 기계.
[3]
16진법
[4]
공백 한 칸
[A]
Bell 문자이다.
DOS 계열 및 Windows의 명령 프롬프트에서 이 문자를 출력할 경우 화면에 표시되지 않고 Beep음이 울린다.(입력하는 경우에는 출력된다.)
[B]
Backspace 문자이다.
DOS 계열에서 이 문자를 입력할 경우 Backspace 키를 누른 것과 같은 효과를 낸다.
[C]
Tab 문자이다.
DOS 계열에서 이 문자를 입력할 경우 Tab 키를 누른 것과 같은 효과를 낸다.
[D]
Line Feed 문자이다. 이 문자는
UNIX 계열에서 줄 바꿈으로 사용된다.
[E]
Carriage Return 문자이다. 이 문자는
Mac OS 클래식에서 줄 바꿈으로 사용되며,
DOS 계열에서는 Line Feed와 같이 사용해야 줄 바꿈이 된다.
[10]
맥 OS 클래식에서 윈도우에서 작성된 텍스트파일을 그냥 열면 CarriageReturn은 인식되어 줄바꿈이 되지만 Line Feed는 인식 못 하여 각 줄 맨 앞에 ◙자가 찍혀 나오게 된다.
[A]
[B]
[C]
[D]
[E]
[16]
가타카나의 위치는 JIS 규격으로 정해 놨지만 그 외에 빈 공간들이 더 있었다. 이 부분에 日, 月, 年 같은 간단한 한자 몇 개를 더 넣어 128비트를 꽉 채웠는데 어디에 어떤 문자를 채웠는지는 PC 제조 회사마다 조금씩 차이가 있었다. 보통은
NEC의 PC-8001 시리즈의 그것을 기본으로 한 경우가 많았다.
MSX는 이 영역에 히라가나까지 채워넣은 근성을 보였다. 8x8 도트 매트릭스로 문자의 가독성은 심히 떨어지지만 단어 단위가 되면 대충 문맥으로 알아볼 수는 있다.
##
[17]
오죽하면 이 가독성 때문에 기울여 풀어쓰기 같은 기상천외한 아이디어도 나올 정도. 45도 기울이면 얼추 모아쓰기와 비슷해 지긴 한다.
[18]
한글 MS-DOS에서 hcode /e를 쓰고 기본적으로 설치되어 있는 텍스트 편집기인 edit를 실행해도 된다.
[19]
비슷한 이모지로 표기함. 실제로는 이모지와 다르다.
[20]
U+0000부터 U+FFFF까지.
[21]
U+10000부터.
[22]
고정 폭 글꼴이 아닌 가변 폭 글꼴을 사용하면 Null 문자가 표시되지 않으며, 텍스트 편집기가 아닌 일반 프로그램에서 불러오면 Null 문자가 아예 무시된다.
[23]
Null 문자의 경우 실제로는 화면에 표시되지 않는다.