당신이 프로그래밍 배경 지식이 없다면 파일이란 게 무엇인지부터 명확하지 않을지 모르겠다.
바이너리 파일은 무엇이고 텍스트 파일은 뭐가 다를까?
이 문제에 대해서 많은 이야기들이 있지만, 나는 유닉스/리눅스, 윈도우, MAC의 파일들에 대해서만 초점을 맞추겠다.
위키백과에는 텍스트파일과 바이너리 파일에 대해 더 많은 이야기가 있다.
이 글이 당신의 호기심을 충족하지 못한다면, 저 문서들도 확인해보기 바란다.
파일이란 무엇인가?
기본적으로 모든 파일은 그저 바이트들, 다시 말해서 0에서 255까지의 숫자들이 연속적으로 이어져 있는 것이다.
파일이 들어 있는 저장장치의 동작을 용이하게 하기 위해서, 하나의 파일이 그 장치의 여러 영역에 나눠져 있을 수 있지만,
우리의 과점에서는 각각의 파일은 그저 일련의 바이트들이다.
일반적으로 모든 파일은 바이너리 파일이다. 그러나 파일 안의 데이터가 오직 텍스트(문자, 숫자, 기호들)만 들어있고,
여러 행들로 구성되어 있다면 우리는 그 파일을 텍스트 파일로 간주한다.
텍스트 파일은 무엇인가?
(여기서는 명료하게 설명하기 위해 파일들이 단지 ASCII 문자들만 사용한다고 가정하겠다.)
당신이 텍스트 파일을 메모장이나 다른 간단한 텍스트 편집기로 열면 여러 행으로 구성된 텍스트를 보게 된다.
반면에 그 파일이 디스크 안에 저장ㄷ죄어 있을 때는 이런 행들로 쪼개져 있지는 않는다. 파일은 일련의 숫자들이 늘어서 있는 것이다.
그 파일을 메모장으로 열면, 메모장은 각 숫자를 시각적 표시로 번역한다.
예를들어 메모장이 숫자 97을 읽게되면, 문자 a를 보여줄 것이다. 이것을 가리켜 ASCII에서 숫자 97은 문자 a를 나타낸다고 말할 수 있다.
편집기에서 여러 행을 보게 되는 이유는 파일의 내용 중 개행(newline)이라고 불리는 어떤 바이트가 실제로는 편집기에게
다음 행의 시작 부분으로 이동하라는 지시를 하기 때문이다. 따라서 파일 안에서 개행 문자 뒤에 오는 문자는 다음 행에 표시되게 된다.
개행문자는 무엇인가?
어느 숫자가 개행 문자를 나타낼까?
실제로는 ASCII 표에 개행이라 불리는 문자는 없다. 우리가 개행이라 부를 때는 보통 컴퓨터에게 다음 행의 시작 지점으로 이동하라고
지시하는 표시를 의미하게 된다.
운영체제에 따라 개행을 나타내는 바이트들 집하이 서로 다르다. 이 글에서 다루는 운영체제들에서는 개행은
ASCII 표에서 LF - 라인 피드(line feed)(16진수 0x0A, 10진수 10)와 CR - 캐리지 리턴(carriage return)(16진수 0x0D, 10진수 13)이라
불리는 두 개의 문자의 조합으로 나타낸다.
당신이 타자기를 본적이 있다면, 다음 줄로 넘어가기 위해서 사용자가 손잡이를 줄의 첫 부분(보통은 용지의 왼쪽부분)으로 당겨야 했던 걸
기억할 것이다. 이 동작은 먼저 "케리지"를 용지의 시작부분으로 밀고, 캐리지가 도착해서 고정되면 그 다음 손잡이를 당겨 용지를 살짝 돌림으로써 캐리지가 다음줄을 가리키게 한다. 이제 타자기는 다음 줄에 입력할 준비가 끝났다.
다시 말해서, 사용자는 두 개의 명령을 이용한다. 캐리지 리턴, 캐리지를 용지의 앞부분으로 밀고, 라인 피드, 다음 줄로 이동한다.
이러한 연유로 MS 윈도우에서는, 개행은 두 개의 문자로 나타낸다.(CRLF, 캐리지 리턴 뒤에 라인피드가 이어진다.)
유닉스/리눅스 시스템과 맥 OSX에서는, 개행은 LF(라인 피드)문자 하나로 나타낸다.
참고로 맥 OS Classic(OSX 이전), Commodore, 코모도어, ZX Spectrum TRS-80은 모두 CR(캐리지 리턴)을 사용하여 개행은 표현했다.
위키백과에는 개행에 대한 더 많은 이야기가 있으니 참고하기 바란다.
그래서 당신이 가진 파일이 ASCII 출력 가능 문자들로 채워져 있고, 사이사이에 "개행"이 조금 흩어져 있다면, 이 파일은 텍스트 파일이다.
인코딩(Encoding)
물론 당신이 ASCII 표를 봤다면 여기 있는 문자들 만으로는 매우 소수의 언어만 작성할 수 있다는 것을 알 수 있을 것이다.
대부분 라틴 계열 언어들이다. 이 문자들을 사용하는 많은 언어들에는 몇 개의 특수한 글자들이 있다.
예를 들어 헝가리어에는 모음이 몇 개 더 있다. :aáeéiíoóöőuúüű. (라틴어에서 온 5개에 추가로 9개) ASCII 표에 있는 것으로는
이 글자들을 나타낼 수 없다.
그래서 사람들은 ASCII 외에 다른 인코딩을 만들었다. 자세한 것은 생략하고, 각 인코딩은 컴퓨터 파일에 저장할 수 있는 숫자들과
스크린에 표시되어야 하는 "그림"간의 맵핑이다.
ASCII에서 조차도, 파일 안의 글자 a가 들어있는 건 아니라는 것을 기억해라.
당신이 저장한 것은 숫자 97이고, 당신의 컴퓨터는 그것을 글자 a로 표시해야 된다는 것을 알고 있다.
그 컴퓨터는 당신의 파일이 ASCII 인코딩이나, Latin1이나, UTF8과 같이 ASCII 기반 인코딩 또는 ASCII-호환 인코딩으로 저장되어 있다고
판단될 경우 a를 표시할 것이다.
어쨋거나 오래 전에는 사람들이 자신들의 고유 언어를 나타내기 위해서 다양한 인코딩을 사용하였다. 그러나 이 인코딩들은 서로 겹치곤 했고, 같은 숫자가 서로 다른 언어에서 서로 다른 문자(그림)를 나타내는데 사용되었다. 그래서 이런 언어들을 하나의 파일 안에 섞어서 쓸 수 없었고, 응용프로그램이 파일의 내용을 표시할 인코딩을 잘못 선택할 경우 당신은 다른 언어에서 사용되는 문자들이 난해하게 섞여 있는 모습만을 보게 되곤 했을 것이다.
여전히 이런 문제를 목격할 수 있다.
어떤 웹페이지가 이런 고대의 인코딩으로 작성되었고, 브라우저 그 페이지를 표시할 때 다른 인코딩을 선택하는 경우메 말이다.
이 문제의 해결책은 HTML 페이지 안에 인코딩에 대한 정보를 포함시키는 것이지만, 사람들은 종종 그것을 잊어버렸다.
다른 좋은 해결책은 UTF--8 인코딩을 사용하는 것인데, 이 인코딩은 이 우주 안에서 알려져 있는 모든 문자를 포함하고 있기 때문이다.
UTF-8은 유니코드(Unicode) 문자들을 숫자에 대응시키는 좋은 방법 중 하나이다.
유니코드에 현재 110,000개 이상의 문자들이 포함되어 있기 때문에, 유니코드는 0에서 255까지만을 담을 수 있는 한 바이트로는
나타낼 수 없다. 따라서 UTF-8에서는 모든 문자를 최소 1바이트에서 최대 4바이트를 사용하여 나타낸다.
만일 당신이 UTF-8 인코딩을 사용하여 작성된 파일을, ASCII 문자만을 다를 수 있는 편집기로 열었다면,
다수의 "쓰레기"들을 보게 될 것이다. UTF-8 내의 어떤 문자들은 ASCII에서 "제어 문자"로 쓰이는 수자로 나타나기 때문이다.
때문에 그러한 편집기에서 이런 파일들은 바이너리 파일과 구별이 되지 않는다.
바이너리 파일
바이너리 파일은 기본적으로 "행 단위"가 아닌 모든 파일들을 다 일컫는다.
표시용 문자와 개행문자 외에 다른 기호가 들어 있는 파일들도 바이너리 파일이다.
따라서 C 프로그래밍 언어로 작성된 프로그램은 텍스트 파일이지만, 이것을 컴파일하여 나온 결과물은 바이너리이다.
Perl 프로그램은 텍스트 파일이지만, 이것을 PAR::Packer를 사용하여 압축한다면 바이너리 파일이 될 것이다.
마이크로소프트 워드 파일은 바이너리 파일이다.
실제 텍스트 외에 글꼴의 크기와 색상을 지정하기 위한 다양한 문자들이 포함되어 있기 때문이다.
Open Office Write 파일은 바이너리 파일이다.
이것은 XML 파일들을 zip으로 압축한 세트이기 때문이다.
그러나 이 안에 압축되어 있는 XML 파일들은 텍스트 파일들이다.
이 안에도 텍스트의 글꼴 크기와 색상을 나타내는 문자들이 포함되어 있지만 말이다.
HTML 파일들도 텍스트 파일이다.
비록 브라우저로 볼 때는 나타나지 않는 수많은 문자들을 포함하고 있지만 말이다.
개행문자를 브라우저로 볼 때, 위에서 설명했던 개행 문자의 뒤에 있는 문자가 다음 줄에 표시되지 않은데도 여전히 텍스트 파일로 간주된다.
HTML 파일이 텍스트 파일로 간주되는 이유는, 모든 "제어 문자"들 자체도 통상의 텍스트 편집기로 볼 수 있는 "출력가능한 문자"들로
이루어져 있기 때문이다.
'Miscellaneous' 카테고리의 다른 글
FAT32, NTFS, exFAT (0) | 2019.11.27 |
---|---|
이명을 치료해보자(TRT Jastreboff와 Hazel 박사의 이론) (1) | 2019.01.10 |
Sublime text3 C Build System (0) | 2018.03.30 |
FIR Filter & IIR Filter의 차이점 (0) | 2018.03.19 |
2차원 배열과 더블포인터 (0) | 2018.02.26 |