플레인 텍스트

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 정의 및 특징
- 2.1. 플레인 텍스트와 리치 텍스트
- 2.2. 플레인 텍스트의 범위
3. 활용
4. 인코딩
- 4.1. 문자 인코딩
- 4.2. 제어 코드
5. 암호학에서의 플레인 텍스트
참조

1. 개요

플레인 텍스트는 순수한 문자 코드의 시퀀스로, 언어 식별자, 글꼴 크기, 색상 등의 추가 정보를 포함하지 않는 텍스트 표현을 의미한다. 텍스트 편집기나 프로그래밍 언어의 소스 코드 파일 등에서 사용되며, ASCII, 유니코드 등의 다양한 인코딩 방식을 지원한다. 플레인 텍스트는 명령 줄 인터페이스, 프로그래밍, 이메일 등 다양한 분야에서 활용되며, 암호화 알고리즘의 입력으로도 사용된다.

더 읽어볼만한 페이지

오픈 포맷 - HTML
HTML은 웹 페이지 제작을 위한 표준 마크업 언어로서, 팀 버너스리가 제안하고 구현한 후 인터넷 발전과 함께 널리 사용되며, SGML에 기반하여 하이퍼텍스트 기능으로 다양한 콘텐츠를 표현하고 연결하며, W3C와 WHATWG에서 표준화를 진행하고 최신 버전은 HTML Living Standard이다.
오픈 포맷 - 오픈 소스
오픈 소스는 제품 설계 및 재배포를 장려하는 모델로, 소프트웨어 개발에서 시작하여 개방형 협업을 장려하며 다양한 분야에서 활용되고 있고 오픈 소스 이니셔티브와 같은 단체가 운동을 지원한다.
파일 포맷 - 바로 가기
바로 가기는 운영체제에서 파일, 폴더, 프로그램, 웹 페이지에 대한 참조를 제공하는 기능 및 파일로, 사용자들이 원본에 빠르게 접근하도록 GUI 환경의 사용성을 향상시킨다.
파일 포맷 - EXE
EXE 파일 형식은 운영 체제에 따라 다양한 종류가 있는 실행 파일의 한 형태로, DOS MZ 실행 파일에서 PE, PE32+까지 발전해 왔으며, 코드, 데이터, 스택을 별도 관리하고 재배치 항목을 통해 실행 환경에 유연하게 대응하는 특징을 가진다.

플레인 텍스트
개요
다른 이름	텍스트 파일 ASCII 텍스트 파일
정의
설명	컴퓨터 데이터 중 사람이 읽을 수 있는 문자들로만 구성된, 서식이 없는 텍스트를 의미함
특징	서식 정보가 없음 (글꼴, 크기, 스타일 등) 유니코드 또는 특정 문자 인코딩으로 표현됨
사용
예시	소스 코드 구성 파일 로그 파일 이메일 문서
장점	호환성이 높음 편집 및 읽기가 쉬움 저장 공간 효율성이 좋음
단점	서식 정보가 없어 표현에 제한이 있을 수 있음
인코딩
종류	ASCII UTF-8 UTF-16
중요성	인코딩 방식에 따라 문자가 다르게 표시될 수 있음
관련 기술
텍스트 편집기	텍스트 파일을 생성, 편집, 저장하는 데 사용되는 소프트웨어
예시	메모장 vi Emacs Sublime Text Visual Studio Code
암호학
설명	암호화되지 않은 평범한 텍스트
관련 용어	암호문 암호화 복호화

2. 정의 및 특징

플레인 텍스트는 글자의 색상, 크기, 글꼴과 같은 서식 정보나 그림, 표 등의 멀티미디어 정보를 포함하지 않고, 순수하게 문자 코드만으로 이루어진 텍스트 데이터를 의미한다.^[1] 이는 워드 프로세서 문서나 PDF 파일과 같은 리치 텍스트와 구분되는 가장 큰 특징이다.

플레인 텍스트는 특정 소프트웨어에 의존하지 않아 운영 체제나 컴퓨터 기종에 상관없이 호환성이 높으며, 기본적인 텍스트 편집기만으로도 쉽게 내용을 확인하고 수정할 수 있다는 장점이 있다. 이러한 특성 때문에 프로그래밍의 소스 코드 작성이나 간단한 메모, 설정 파일 등 다양한 분야에서 널리 사용된다.

일반적으로 ASCII나 유니코드(UTF-8 등)와 같은 표준 문자 인코딩을 사용하여 작성되며, 문자 정보 외의 다른 데이터(예: 널 문자)는 포함하지 않는 경우가 많다.^[4] HTML이나 XML과 같은 마크업 언어가 포함된 파일도 사람이 읽을 수 있는 형태라면 넓은 의미에서 플레인 텍스트로 간주되기도 한다.^[10]

2. 1. 플레인 텍스트와 리치 텍스트

플레인 텍스트는 순수한 문자 코드의 연속으로 이루어진 텍스트를 의미한다. 유니코드 표준에 따르면, 인코딩되지 않은 플레인 텍스트는 유니코드 문자 코드의 시퀀스이다.^[1] 플레인 텍스트는 글자의 색상, 크기, 글꼴과 같은 서식 정보나 그림, 표, 소리, 영상 같은 멀티미디어 정보를 포함하지 않는다. 오직 텍스트 데이터만으로 구성되어 있어, 최소한의 기능만 갖춘 텍스트 편집기로도 쉽게 다룰 수 있다는 장점이 있다.

반면, '스타일 텍스트' 또는 '리치 텍스트'는 플레인 텍스트에 더해 언어 식별자, 글꼴 크기, 색상, 하이퍼텍스트 링크 등 추가적인 서식 정보를 포함하는 텍스트 표현을 말한다.^[1] 워드 프로세서 프로그램인 Microsoft Word의 문서 형식(.doc/.docx)이나 PDF 형식이 대표적인 예이다. 이러한 형식들은 플레인 텍스트와 달리 다양한 시각적, 구조적 정보를 담을 수 있다.

마크업 언어(HTML, XML 등)를 포함하는 파일의 경우, 플레인 텍스트로 간주될 수 있는지에 대한 두 가지 관점이 있다. 한 관점에서는 마크업 자체가 사람이 직접 읽을 수 있는 형태로 남아 있다면 플레인 텍스트로 본다.^[10] 이 관점에 따르면 SGML, RTF, HTML, XML, 위키 마크업, TeX 및 거의 모든 프로그래밍 언어의 소스 코드 파일은 플레인 텍스트로 간주된다. 파일의 내용이 그림이나 그래픽을 표현하더라도(SVG 파일처럼) 그 형식이 텍스트 기반이라면 플레인 텍스트라는 것이다. 반면, 유니코드 표준에서는 이러한 형식들을 플레인 텍스트 데이터와 추가 데이터 구조를 나타내는 문자 시퀀스가 혼합된 리치 텍스트의 예시로 보기도 한다.^[1]

플레인 텍스트는 바이너리 파일에 비해 특정 컴퓨터 구조에 덜 의존적이어서 호환성이 높고 데이터 보존에 유리하다. 예를 들어, 엔디안 문제와 같은 아키텍처 비호환성 문제를 상당 부분 피할 수 있다. 또한, 운영 체제에 기본적으로 포함된 편집기(Windows의 메모장, 유닉스/리눅스의 vi나 Emacs, macOS의 텍스트 편집기 등)로 쉽게 편집할 수 있다.

과거에는 ASCII(특히 7비트 ASCII)만을 플레인 텍스트로 보는 좁은 의미도 있었으나, 현재는 ISO/IEC 8859-1이나 EUC-JP/Shift_JIS 같은 각국 언어별 문자 코드, 그리고 국제 표준인 유니코드(UTF-8 등)로 작성된 텍스트까지 포함하는 넓은 의미로 주로 사용된다.^[4] 일반적으로 플레인 텍스트 파일은 문자 코드 0으로 표시되는 널 문자를 포함하지 않는다는 특징이 있다.

플레인 텍스트의 단점은 저장할 수 있는 정보가 순수 텍스트로 제한된다는 점과, 텍스트의 인코딩 정보가 파일 자체에 명시적으로 포함되지 않는 경우가 많아 파일을 열 때 인코딩을 추정해야 한다는 점이다. 정보량이 적으면 자동 추정에 실패하여 문자 깨짐 현상이 발생할 수 있다. 이를 방지하기 위해 파일 맨 앞에 바이트 순서 마크(BOM)를 붙이기도 한다. 현대의 개인용 컴퓨터(PC) 운영 체제는 대부분 UTF-8 형식의 플레인 텍스트를 표준으로 지원하므로, 문자 코드 문제만 없다면 이식성과 교환성이 매우 높은 형식이다.

스마트폰의 메모 앱 등에서는 자체적인 리치 텍스트 형식을 사용하는 경우가 많아 기기 간 호환성이 떨어질 수 있지만, 복사하여 붙여넣기 기능을 통해 앱 간에 플레인 텍스트 정보를 주고받는 것은 가능하다.

2. 2. 플레인 텍스트의 범위

유니코드 표준에 따르면, 플레인 텍스트는 순수한 글자들의 연속이며, 글꼴 크기나 색상 같은 추가 정보가 포함된 '스타일 텍스트' 또는 '리치 텍스트'와는 구분된다.^[1] 이 엄격한 정의에 따르면 SGML, RTF, HTML, XML, TeX 등은 마크업 정보를 포함하므로 리치 텍스트의 예시로 본다.^[1]

하지만 일반적으로는 마크업이나 다른 메타데이터가 포함되어 있더라도, 그 마크업 자체가 인간이 읽을 수 있는 형태(예: HTML, XML)라면 플레인 텍스트로 간주하는 경우가 많다. 이런 넓은 의미에서는 SGML, RTF, HTML, XML, 위키 마크업, TeX 표현뿐만 아니라 거의 모든 프로그래밍 언어 소스 코드 파일도 플레인 텍스트에 해당한다. 파일의 내용이 그림인지 글자인지는 중요하지 않다. 예를 들어, SVG 파일은 벡터 그래픽 정보를 담고 있지만, 파일 자체가 사람이 읽을 수 있는 텍스트로 구성되어 있기 때문에 플레인 텍스트로 분류된다.

좁은 의미로는 ASCII, 특히 7비트 ASCII로만 구성된 문서를 플레인 텍스트라고 했지만, 현재는 ISO/IEC 8859-1이나 EUC-JP/Shift_JIS 같은 각국 언어 고유의 문자 인코딩이나 국제 표준인 유니코드로 작성된 문서도 포함하는 넓은 의미로 주로 사용된다.^[4] 일반적으로 플레인 텍스트 파일은 문자 코드 0으로 표현되는 널 문자를 포함하지 않는다는 특징이 있다.

반면, 워드 프로세서 프로그램인 Microsoft Word의 문서 형식(.doc/.docx 등)이나 PDF 형식처럼 글자 색상, 크기, 글꼴 등의 서식 정보나 그림, 표, 동영상 같은 멀티미디어 정보를 포함하는 파일은 플레인 텍스트가 아니다. 이러한 파일들은 해당 정보를 해석할 수 있는 특정 소프트웨어가 필요하다. 플레인 텍스트는 오직 텍스트 데이터만으로 구성되어 있어, 기본적인 텍스트 편집기로도 쉽게 열고 수정할 수 있다는 장점이 있다.

3. 활용

플레인 텍스트는 특정 응용 프로그램이나 운영 체제에 구애받지 않고 다양한 환경에서 쉽게 읽고 수정할 수 있다는 범용성과 독립성 덕분에 여러 분야에서 폭넓게 활용된다. 이는 자체적인 특수 인코딩이나 서식, 파일 형식이 필요한 프로그램으로부터 자유롭기 때문이다. 거의 모든 텍스트 편집기나 기본적인 유틸리티 프로그램을 사용하여 플레인 텍스트 파일을 열고, 읽고, 수정할 수 있다.

주요 활용 분야는 다음과 같다.

명령 줄 인터페이스(CLI): 사용자가 플레인 텍스트로 명령을 입력하고, 시스템 역시 일반적으로 플레인 텍스트로 응답을 출력하는 방식으로 상호작용이 이루어진다. 도스, 윈도우, 맥 OS, 유닉스 등 다양한 운영체제 환경에서 사용된다.
프로그래밍: 프로그래밍 언어로 작성된 소스 코드 파일은 거의 항상 플레인 텍스트 형식이다. 또한 프로그램 설정을 저장하는 구성 파일에도 자주 사용된다.
데이터 교환 및 저장: 많은 이메일이 플레인 텍스트 형식을 사용하며, 간단한 메모(.txt), 주석, DNS 정보 기록(TXT 레코드) 등에도 널리 쓰인다.
정보 보존: 특정 소프트웨어의 독자적인 이진 파일 형식과 달리, 플레인 텍스트는 형식이 단순하고 호환성이 높아 시간이 지나도 데이터를 비교적 안전하게 보존할 수 있다. 영구적으로 지식을 저장하는 데 가장 적합한 형식으로 여겨지기도 한다.^[11]^[2]

이처럼 플레인 텍스트는 글자의 색상, 크기, 글꼴과 같은 장식 정보나 그림, 표 등의 멀티미디어 정보를 포함하지 않지만, 기본적인 텍스트 편집기만으로도 쉽게 다룰 수 있다는 편리성 때문에 정보의 생성, 공유, 보존에 있어 중요한 역할을 담당한다.

3. 1. 명령 줄 인터페이스 (CLI)

명령 줄 인터페이스(CLI)는 사용자가 플레인 텍스트로 명령을 입력하고, 그 결과를 플레인 텍스트로 돌려받는 방식으로 작동한다. 이러한 방식은 도스, 윈도우, 맥 OS, 유닉스 계열 운영체제 등 다양한 환경에서 널리 사용된다. 또한, 링크스나 라인 모드 브라우저와 같이 텍스트 기반으로 화면을 표시하는 웹 브라우저를 포함한 수많은 컴퓨터 프로그램들이 플레인 텍스트를 처리하거나 생성할 수 있다.

플레인 텍스트는 특정 프로그램의 고유한 인코딩 방식이나 서식, 파일 형식에 얽매이지 않는다는 장점이 있다. 덕분에 거의 모든 텍스트 편집기나 기본적인 유틸리티 프로그램을 사용하여 플레인 텍스트 파일을 열고, 읽고, 수정하는 것이 가능하다. 이러한 독립성과 범용성은 CLI 환경에서 플레인 텍스트가 중요하게 사용되는 이유 중 하나이다. 일부에서는 영구적으로 지식을 저장하는 데 가장 적합한 형식이 특정 이진 형식이 아닌 플레인 텍스트라고 보기도 한다.^[11]

3. 2. 프로그래밍

프로그래밍 언어로 작성된 지시 사항을 담고 있는 소스 코드 파일은 거의 항상 플레인 텍스트 파일이다. 이처럼 플레인 텍스트 파일은 프로그래밍 분야에서 매우 보편적으로 사용된다.

또한, 프로그램이 시작될 때 저장된 설정을 읽어 들이는 구성 파일(설정 파일)에도 플레인 텍스트 형식이 자주 사용된다. 주석, 일반적인 .txt 파일, TXT 레코드 등도 특별한 서식 없이 사람이 읽을 수 있도록 플레인 텍스트로 작성되는 경우가 많다. 많은 이메일 역시 플레인 텍스트 형식을 사용한다.

플레인 텍스트는 특정 소프트웨어의 고유한 인코딩 방식이나 서식, 파일 형식에 얽매이지 않는다는 장점이 있다. 덕분에 어떤 환경에서든 기본적인 텍스트 편집기나 유틸리티만 있으면 플레인 텍스트 파일을 열고, 읽고, 수정할 수 있다.^[11] 이러한 독립성과 범용성은 플레인 텍스트가 프로그래밍 및 데이터 저장에 널리 쓰이는 중요한 이유이다. 지식을 영구적으로 저장하는 데 있어서도 특정 이진 형식보다 플레인 텍스트가 더 적합하다는 평가도 있다.^[2]

명령 줄 인터페이스(CLI) 환경에서도 사용자는 플레인 텍스트로 명령을 입력하고, 시스템 역시 일반적으로 플레인 텍스트로 응답을 출력하는 방식으로 상호작용이 이루어진다. 도스, 윈도우, 클래식 맥 OS, 유닉스 계열 운영체제 등 다양한 환경의 수많은 프로그램들이 플레인 텍스트를 처리하거나 생성할 수 있다. 일부 텍스트 기반 웹 브라우저(링크스, 라인 모드 브라우저 등)는 화면 표시를 위해 플레인 텍스트만 사용하기도 한다.

다만, HTML, XML, TeX와 같이 특정 구조나 의미를 나타내는 마크업 언어로 작성된 파일들은 순수한 텍스트로 구성되어 있고 일반 텍스트 편집기로 편집 가능하지만, 단순한 플레인 텍스트와는 구분된다. 이들은 소프트웨어가 해석해야 할 특정 서술(태그 등)을 포함하고 있기 때문이다.^[4]

3. 3. 기타 활용

플레인 텍스트는 특정 프로그램의 고유한 인코딩이나 서식, 파일 형식에 구애받지 않는다는 장점이 있다. 이 덕분에 거의 모든 텍스트 편집기나 유틸리티로 파일을 열고 읽고 편집할 수 있어 편리하다.

이러한 특성 때문에 플레인 텍스트는 다양한 용도로 활용된다. 프로그램 설정을 저장하는 구성 파일에 흔히 쓰이며, 많은 이메일 역시 플레인 텍스트 형식을 사용한다. 특히 주석, 흔히 메모장 파일로 알려진 .txt 파일, DNS 설정에 사용되는 TXT 레코드 등은 사람이 직접 읽고 이해하기 쉽도록 특별한 서식 없이 플레인 텍스트만 담는 경우가 일반적이다.

또한, 특정 이진 형식과 달리 형식이 단순하고 호환성이 높아, 지식이나 정보를 오랫동안 보존하는 데 가장 적합한 형식으로 여겨지기도 한다.^[11]^[2]

4. 인코딩

플레인 텍스트는 다양한 문자 인코딩 방식으로 작성될 수 있다. 좁게는 ASCII, 특히 7비트 ASCII만을 의미하기도 하지만, 넓게는 ISO/IEC 8859-1이나 EUC-JP/Shift_JIS 같은 각국 언어별 문자 코드, 또는 국제 표준인 유니코드로 작성된 텍스트까지 포함하는 것이 일반적이다.^[4] 일반적으로 플레인 텍스트 파일은 문자 코드 0으로 표시되는 널 문자를 포함하지 않는다는 특징이 있으며, 이는 바이너리 파일과의 차이점 중 하나이다.

플레인 텍스트 자체에는 어떤 인코딩이 사용되었는지에 대한 정보가 명시적으로 포함되지 않는 경우가 많다. 이 때문에 파일을 열 때 사용된 인코딩 방식을 자동으로 추측하거나 가정해야 하는데, 파일 내 텍스트 정보가 부족하면 추정에 실패하여 문자 깨짐 현상이 발생할 수 있다. 이러한 문제를 방지하고 인코딩 판별을 돕기 위해 파일 맨 앞에 바이트 순서 마크(BOM)를 붙이기도 한다.

현대의 개인용 컴퓨터 운영 체제(OS)는 대부분 UTF-8 형식의 플레인 텍스트 표시와 편집을 표준으로 지원하므로, 문자 코드를 올바르게 인식하기만 하면 플랫폼 간 호환성이 높은 데이터 형식이 될 수 있다. 예를 들어, Windows에서는 메모장, UNIX와 Linux에서는 vi나 Emacs, macOS에서는 텍스트 편집기와 같은 기본 편집기로 UTF-8 텍스트를 다룰 수 있다. 과거 MS-DOS의 EDLIN이나 MS-DOS Editor, Classic Mac OS의 SimpleText 등은 유니코드 보급 이전 환경에서 Microsoft 코드 페이지 932나 MacJapanese와 같은 독자적인 확장 문자 코드를 사용하기도 했다.

한편, 프로그래밍 언어의 소스 코드나 HTML, XML, TeX와 같은 마크업 언어 파일들은 순수한 텍스트로 구성되어 있지만, 특정 태그나 주석을 통해 사용된 인코딩 방식을 명시하기도 한다. 예를 들어, HTML/XML에서는 특정 태그나 속성으로 언어와 문자 인코딩을 지정하며^[5], Python 소스 코드는 기본적으로 UTF-8로 간주되지만, 파일 맨 앞의 특별한 주석(시뱅)으로 인코딩을 지정할 수도 있다.^[6]

4. 1. 문자 인코딩

문자 인코딩은 컴퓨터에서 문자를 표현하고 저장하는 방식을 정하는 규칙이다. 1960년대 초반까지 컴퓨터는 주로 숫자 계산에 사용되었고 메모리가 비쌌기 때문에, 각 문자에 6비트(64개 문자)만 할당하는 경우가 많았다. 이는 알파벳 대소문자와 숫자를 모두 담기에는 턱없이 부족하여, 대부분의 초기 컴퓨터 시스템에서는 소문자를 지원하지 않았다.^[4] 로베르토 부사의 토미즘 색인이나 브라운 코퍼스 같은 초기 텍스트 프로젝트들은 대문자로 의도된 문자를 표시하기 위해 별표(*) 같은 별도의 규칙을 사용해야 했다.

IBM의 프레드 브룩스는 텍스트 처리의 중요성을 예견하고 8비트 바이트 사용을 강력히 주장하여 관철시켰다. IBM은 EBCDIC이라는 인코딩 방식을 사용했지만, 이후 대부분의 시스템에서는 ASCII가 표준처럼 사용되었다. ASCII는 0부터 31까지의 값을 비인쇄 제어 문자에, 32부터 127까지의 값을 문자, 숫자, 구두점 등 그래픽 문자에 할당했다. 초기에는 7비트만 사용하고 남은 1비트는 체크섬 등으로 활용하기도 했지만, 점차 8비트 전체를 문자 표현에 사용하게 되었다.

ASCII는 널리 쓰였지만, 영어 중심적이었기 때문에 다른 언어의 문자를 표현하는 데 한계가 있었다. 예를 들어 영국에서는 달러 기호(`$`)가 불필요했고, 유럽의 여러 언어(스페인어, 프랑스어, 독일어 등)에서 사용되는 악센트 부호나 그리스어, 러시아어, 동아시아 언어의 문자들은 ASCII로 표현할 수 없었다. 이 문제를 해결하기 위해 여러 개인, 기업, 국가에서 ASCII의 남는 공간(128~255)을 활용하거나 제어 문자를 재할당하여 필요한 문자를 추가하는 비표준적인 확장 방식을 사용했다. 하지만 이는 국가나 시스템마다 인코딩 방식이 달라 호환성 문제를 일으켰다. 예를 들어, 문자 인코딩이 일치하지 않으면 웹 브라우저에서 '¬A' 대신 '`'와 같이 엉뚱한 문자가 표시될 수 있었다.

이러한 혼란을 줄이기 위해 ISO는 다양한 언어를 지원하는 여러 코드 페이지를 ISO 8859 표준으로 제정했다. 그중 첫 번째인 ISO 8859-1("Latin-1")은 서유럽 언어 대부분을 지원했지만, 모든 유럽 언어를 포괄하지는 못했다. 또한 ISO 2022 표준을 통해 하나의 문서 안에서 여러 문자 집합을 바꿔가며 사용할 수 있는 방법을 제시하기도 했다. 하지만 여전히 Windows와 매킨토시 환경에서는 서로 호환되지 않는 독자적인 확장 인코딩 방식들이 사용되었다. 한국어 환경에서는 주로 EUC-KR 인코딩이 사용되었으나, 표현할 수 있는 한글 문자의 수가 제한적이라는 단점이 있었다.

문자 인코딩 상황이 점점 더 복잡해지자, 전 세계의 모든 문자를 하나의 표준으로 통합하려는 노력이 시작되었다. ISO와 유니코드 컨소시엄은 협력을 통해 유니코드라는 통합 문자 인코딩 표준을 개발했다.^[3] 유니코드는 현재 1,114,112개의 코드 포인트를 제공하며, 현대 언어의 문자뿐만 아니라 고대 문자, 수학 기호, 이모티콘 등 다양한 문자를 포괄한다.

어떤 인코딩 방식을 사용하든, 문자로만 이루어진 데이터는 플레인 텍스트로 간주된다. 텍스트를 올바르게 해석하려면 수신 측에서 해당 텍스트가 어떤 인코딩(예: UTF-8, EUC-KR)으로 작성되었는지 알아야 한다. 인코딩 정보가 명시되지 않은 경우, 일부 프로그램은 문자 집합 감지 기능을 통해 인코딩을 추측하기도 한다. 웹에서는 MIME 유형을 통해 인코딩 정보를 명시하는 것이 일반적이다. 예를 들어, `text/plain`은 마크업 없는 일반 텍스트를, `text/html; charset=UTF-8`은 UTF-8로 인코딩된 HTML 문서를 의미한다.

과거에는 서로 다른 운영체제(예: UNIX/Linux의 EUC-KR과 Windows/Mac OS의 CP949 계열) 간에 파일을 주고받을 때 인코딩 방식의 차이로 인해 문자 깨짐 현상이 빈번하게 발생했다. 현대에는 유니코드, 특히 UTF-8 인코딩이 널리 사용되면서 이러한 문제가 많이 줄어들었지만, 여전히 송신 측과 수신 측이 사용하는 인코딩 방식이 다르면 문자 깨짐이 발생할 수 있다.^[4] Windows NT 계열 운영체제는 내부적으로 유니코드를 사용하지만, 하위 호환성을 위해 시스템 로케일 설정에 따른 과거의 멀티바이트 인코딩 방식(예: 한국어 Windows의 CP949)을 사용하는 경우가 있어 주의가 필요하다. 예를 들어, cmd.exe의 출력 결과를 파일로 저장할 때 기본적으로 시스템 로케일 인코딩이 사용될 수 있다.

4. 2. 제어 코드

플레인 텍스트는 화면에 표시되는 일반적인 문자(인쇄 가능한 문자, 공백 포함) 외에도, 문자로는 표시되지 않지만 문자 표시를 제어하는 '''제어 코드'''를 포함한다^[4].

ASCII는 처음 32개의 코드(10진수 0–31)를 'C0 세트'라는 제어 문자 그룹으로 할당했다. 이 코드들은 원래 인쇄 가능한 정보가 아니라, 프린터 같은 장치를 제어하거나 데이터 스트림에 대한 메타 정보를 제공하기 위해 만들어졌다. 여기에는 줄 바꿈이나 탭 문자 같은 일반적인 제어 문자가 포함된다.

Latin-1 및 기타 ISO/IEC 8859 세트와 같은 8비트 문자 세트에서는 '상위 절반'(128~159)의 처음 32개 문자 역시 'C1 세트'라는 제어 코드이다. 이 C1 제어 코드들은 직접 사용되는 경우는 드물다. 명목상 ISO 8859 인코딩을 사용하는 문서에서 이 코드 위치에 문자가 나타난다면, 이는 보통 Windows-1252나 Mac OS Roman 같은 특정 시스템 전용 인코딩에서 해당 위치의 문자를 참조하여 추가적인 그래픽 문자를 제공하려는 목적이다.

유니코드는 양방향 텍스트 방향 재정의 문자(왼쪽에서 오른쪽으로 쓰는 글 중간에 오른쪽에서 왼쪽으로 쓰는 글을 명시적으로 표시하는 데 사용)나 변형 선택기(CJK 표의 문자, 이모지 등의 대체 형태 선택)와 같은 추가적인 제어 문자를 정의한다.

플레인 텍스트에 포함될 수 있는 제어 코드의 예로는, 문자의 시작 위치를 맞추는 수평 탭(0x09), 수직 탭(0x0B), 줄 바꿈, 페이지 넘김(0x0C), EOF(End Of File, 파일 종단 표시: 0x1A), BOM(Byte Order Mark: 유니코드처럼 2바이트 이상으로 한 문자를 구성하는 문자 코드에서 엔디안을 판별하기 위한 정보) 등이 있다.

특히 줄 바꿈 문자는 운영 체제(OS) 간 호환성 문제를 일으키기도 한다. MS-DOS·Windows, UNIX 계열, 그리고 클래식 Mac OS는 서로 다른 줄 바꿈 문자를 표준으로 사용해왔다.

OS	줄 바꿈 문자
MS-DOS・Windows	CR+LF
UNIX	LF
클래식 Mac OS	CR

위 표에서 CR은 캐리지 리턴(Carriage Return, 0x0D), LF는 라인 피드(Line Feed, 0x0A)를 나타내는 ASCII 제어 코드이다. MS-DOS는 CP/M과의 호환성을 위해 CR+LF를 채택했고, Windows도 이를 따랐다^[7]. 이는 타자기에서 인쇄 헤드를 줄의 시작 위치로 되돌리고(캐리지 리턴), 종이를 한 줄 위로 올려(라인 피드) 다음 줄을 쓸 준비를 하는 동작을 모방한 것이다^[8]. UNIX 계열 OS는 LF만을 사용하며, 클래식 Mac OS는 CR만을 사용했지만, 이후 UNIX 기반으로 재설계된 macOS에서는 LF를 표준 줄 바꿈 문자로 채택했다.

유니코드에서는 줄 바꿈을 나타내는 별도의 문자(U+2028 LINE SEPARATOR)와 단락 구분을 나타내는 문자(U+2029 PARAGRAPH SEPARATOR)를 정의하고 있다. 또한 유니코드 표준에서는 수직 탭(VT, 0x0B)과 페이지 넘김(FF, 0x0C)도 줄 바꿈 문자로 취급한다.

5. 암호학에서의 플레인 텍스트

암호화 알고리즘에 대한 입력을 플레인 텍스트(평문)라고 부른다.^[9] 영어에서는 plaintext|플레인텍스트^eng와 같이 표기한다.

참조

_[1] 웹사이트 The Unicode Standard, version 14.0 https://www.unicode.[...]
_[2] 서적 The Pragmatic Programmer https://books.google[...] 1999
_[3] 웹사이트 ISO/Unicode Merger: Ed Hart Memo https://www.unicode.[...] 2024-10-21
_[4] 웹사이트 プレーンテキストとは - IT用語辞典 e-Words https://e-words.jp/w[...]
_[5] 웹사이트 HTMLで文字エンコーディングを指定する https://www.w3.org/I[...]
_[6] 웹사이트 2. Python インタプリタを使う — Python 3.13.0 ドキュメント https://docs.python.[...]
_[7] 웹사이트 ASCII.jp：Windowsにおける改行文字の扱い (1/2) https://ascii.jp/ele[...]
_[8] 웹사이트 CRLF (しーあーるえるえふ) とは? | 計測関連用語集 | TechEyesOnline https://www.techeyes[...]
_[9] 웹사이트 plaintext - Internet Security Glossary - IPA https://www.ipa.go.j[...]
_[10] 저널 Markup systems and the future of scholarly text processing http://xml.coverpage[...] Association for Computing Machinery 1987-11
_[11] 서적 The Pragmatic Programmer https://books.google[...] 1999

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com