ASCII

아스키 코드는 미국 ANSI에서 표준화한 정보교환용 7비트 부호체계이다. 000(0x00)부터 127(0x7F)까지 총 128개의 부호가 사용된다. 이는 영문 키보드로 입력할 수 있는 모든 기호들이 할당되어 있는 부호 체계이며, 매우 단순하고 간단하기 때문에 어느 시스템에서도 적용가능하다는 장점이 있으나, 2바이트 이상의 코드를 표현할 수 없기 때문에 국제표준의 위상은 유니코드에게 넘어갔다. text only 형태의 게시판에서는 아스키 아트라는 이름으로 자주 사용된다.

1바이트를 구성하는 8비트 중에서 7비트만 쓰도록 제정된 이유는, 나머지 1비트를 통신 에러 검출을 위해 사용하기 때문이었다. Parity Bit라고 해서, 7개의 비트 중 1의 개수가 홀수면 1, 짝수면 0으로 하는 식의 패리티 비트를 붙여서, 전송 도중 신호가 변질된 것을 수신측에서 검출해낼 확률을 높인 것. 원시적인 CRC 체크섬이라고 할 수 있지만 당연히 이런 체크에 검출되지 않는 신호 에러도 얼마든지 생길 수 있고 현재는 더 이상 쓰이지 않는다. 현재는 8비트 문자 인코딩에서는 그냥 맨 앞 비트에 0을 붙이고 이어서 7비트가 이어지는 식의 인코딩이 일반적이다.

아래 표는 아스키 코드 중 제어 문자와 확장 아스키 코드를 제외한 부호(영문 자판에 사용되는 부호)를 정리한 것이다.[2]

IBM CP437 아스키 코드에는 제어 문자 자리에 Null(0x00)을 제외한 32개의 특수문자를 배당해 놓았다. 물론 그렇다고 해서 제어 문자의 기능이 없어지는 것은 아니며, 프로그램이나 글꼴에 따라서는 모양을 출력하지 않거나 아예 무시해버린다. 아래 표에서는 같은 모양의 유니코드 문자들로 대체하였다.

0x0A에 해당되는 ◙자는 유닉스 계열의 OS에서 작성된 텍스트 파일을 Windows 10 RS4 빌드까지의 메모장으로 열면 줄바꿈이 모조리 붙어 나오면서 줄바꿈 자리에 이 문자가 찍혀 나온다. 이것은 두 OS의 줄바꿈 표시 방법이 다르기 때문인데, 유닉스는 Line Feed만으로 줄바꿈을 인식하는 반면 윈도우는 Carriage Return과 Line Feed 두 제어 문자가 같이 붙어 있어야 줄바꿈을 인식하기 때문이다. 그래서 유닉스 계열 OS에서 작성된 텍스트 파일은 윈도우에서 줄바꿈이 되지 않고 저 문자가 대신 출력된다. 반대로 유닉스 계열에서 윈도우에서 작성된 텍스트 파일을 그냥 열면 Line Feed는 인식되어 줄바꿈이 되지만 Carriage Return은 인식 못하여 각 줄 맨 끝에 ♪자가 찍혀 나오게 된다. 이 문제는 Windows 10 RS5 빌드의 메모장에서 줄바꿈 방식을 자동으로 인식하도록 바뀌면서 해결되었다.

한국어 아스키 코드(CP949)에서는 위의 문자들 중 몇 개가 괘선 문자로 대체되어 있다.

Notepad++의 경우에는 제어 문자를 위의 기호로 표시하지 않고, 이니셜을 사용한 자체적인 표시 문자를 사용하기 때문에 어떤 문자가 사용되었는지 쉽게 알 수 있다.

발음 구별 기호와 출판물에서 사용하는 여닫는 따옴표(“” ‘’)와 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에서는 이 영역에 가타카나를 넣어서 사용하기도 했다. 그래서 8비트 초기 시절에는 한자나 히라가나 없이 올 가타카나로만 이루어진 문장을 일본에서 만들어진 BASIC 언어 교본 등에서 볼 수 있었다. 현재 일본어 입력기에서 지원하는 반각 가타카나도 이 시절의 잔재인데, Windows 9x 시절까지만 해도 한자와 히라가나만 전각으로 처리하고 가타카나는 반각으로 처리하는 경우가 흔했다. 여담으로 한글 또한 이 시기에 모아쓰기를 하지 말고 풀어쓰기로 하자는 움직임이 있었는데, 큰 반향은 없었다. 풀어쓰기를 하면 128자 안에서 해결이 되지만, 가독성이 반각 가타카나보다도 훨씬 나빠지기 때문이다.

한국어나 중국어처럼 문자가 굉장히 많은 경우, 확장 영역에 해당하는 바이트를 두 개 붙여 놓으면 한 글자로 표시되는 방식을 사용했다. 이는 현재의 유니코드와 거의 동일한 형식이다. 그래서 한국어 환경에선 확장 영역에 있는 괘선 문자를 쓰기가 곤란했던 까닭에 저 앞의 섹션에 나온 것처럼 제어 문자 영역에 있는 특수문자 중 일부분에 괘선 문자를 때려박았다. 한글 바이오스 모드가 비활성화됐을 때 텍스트 모드에서 돌아가는 한글 프로그램을 돌리면 괘선 문자가 들어갈 자리에 웃는 얼굴 그림과 ♥♦♣♠ 등이 나오는 것을 볼 수 있었다.

반대로 한글 바이오스 모드가 활성화 된 상태에서 텍스트 모드에서 돌아가는 영문 프로그램을 돌리면 괘선 문자가 한글이나 한자로 깨지는 것을 볼 수 있었다. 예를 들면 "────────"라고 반각 수평선 괘선문자가 나와야 할 곳에 "컴컴컴컴"이라는 한글이 연속으로 나오는 경우인데, 수평선 괘선문자 코드인 0xC4를 "컴"자에 해당하는 완성형 코드인 0xC4C4로 인식하기 때문에 발생하는 문제이다. 이것 때문에 영문 프로그램을 돌릴 때는 한글 바이오스를 꺼줘야 했다.

UTF-8의 경우 ASCII 영역은 그대로 1바이트를 사용하기 때문에 호환이 된다. 반대로 말하자면 UTF-8 문서라도 ASCII 영역에 해당하는 문자만 적혀 있고 BOM까지 없다면 그냥 ASCII 문서와 다를 게 없다.

하지만 UTF-16은 2바이트[13]와 4바이트[14]만 사용하기 때문에 서로 호환이 되지 않는다. 이 때문에 UTF-16에서 ASCII 문자를 나타낼 때는 앞에 0x00이 붙는다. 예를 들어 A라는 글자를 표현하려면, ASCII나 UTF-8에서는 0x41이라고만 표현하면 되지만, UTF-16에서는 0x0041로 표현해야 한다. 이를 무시하고 1바이트로만 표현하면 앞뒤의 바이트가 묶여서 전혀 다른 문자가 튀어나온다. 반대로 UTF-16으로 작성된 문서를 고정폭 글꼴을 사용하는 텍스트 편집기에서 ASCII로 읽으면 ASCII 영역의 문자열들이 한글자 한글자 띄어쓰기를 해놓은 것처럼 띄엄띄엄 표시되는 것을 알 수 있는데, 이 역시 앞뒤에 붙은 Null(0x00)이 따로 해석돼서 발생하는 현상이다.[15]

유니코드의 첫 256글자(U+0000 ~ U+00FF)는 확장 ASCII 코드 중 하나인 ISO/IEC 8859-1을 그대로 차용한 것이다.

Windows 10 19H1 빌드부터는 메모장의 기본 인코딩이 ANSI에서 UTF-8로 바뀌었다.