플레인 텍스트
암호학 용어에 대해서는 평문 문서를 참고하십시오.
cat로 보여주고 있다.컴퓨팅에서 플레인 텍스트(plain text) 또는 일반 텍스트는 읽을 수 있는 자료의 문자만을 나타내며, 그래픽 표현이나 기타 객체(부동소수점 수, 이미지 등)는 포함하지 않는 데이터(예: 파일 내용)를 뜻하는 느슨한 용어이다. 여기에는 공백, 새줄 문자, 탭 문자와 같이 텍스트의 간단한 배열에 영향을 주는 제한된 수의 "공백" 문자가 포함될 수 있다. 플레인 텍스트는 스타일 정보가 포함된 서식 있는 텍스트, 단락이나 섹션과 같은 문서의 구조적 부분이 식별되는 구조화된 텍스트, 그리고 일부 부분이 이진 객체(인코딩된 정수, 실수, 이미지 등)로 해석되어야 하는 이진 파일과는 다르다.
이 용어는 때때로 매우 느슨하게 사용되어 "읽을 수 있는" 내용만 포함된 파일(또는 화자가 선호하지 않는 것이 없는 파일)을 의미하기도 한다. 예를 들어, 여기에는 글꼴이나 레이아웃 표시(마크업, 마크다운 또는 탭 등), 둥근 따옴표, 줄 바꿈 없는 공백, 소프트 하이픈, em 대시, 합자 등과 같은 문자가 제외될 수 있다.
원칙적으로 플레인 텍스트는 어떤 문자 인코딩으로도 작성될 수 있지만, 가끔 이 용어가 ASCII를 암시하는 것으로 받아들여지기도 한다. UTF-8 및 UTF-16과 같은 유니코드 기반 인코딩이 보편화됨에 따라 그러한 사용법은 줄어들고 있다.
플레인 텍스트는 때때로 "이진" 파일을 제외하는 용도로만 사용되기도 한다. 이진 파일은 파일의 적어도 일부를 유효한 문자 인코딩을 통해 올바르게 해석할 수 없는 파일을 말한다. 예를 들어, (어떤 인코딩으로든) "hello"로 시작하고 그 뒤에 문자가 아닌 이진 정수를 나타내는 4바이트가 이어지는 파일이나 문자열은 이진 파일이다. 플레인 텍스트 파일을 다른 문자 인코딩으로 변환해도 올바른 문자 인코딩을 사용하는 한 텍스트의 의미는 변하지 않는다. 그러나 이진 파일을 다른 형식으로 변환하면 텍스트가 아닌 데이터의 해석이 달라질 수 있다.
플레인 텍스트와 리치 텍스트
[편집]유니코드 표준에 따르면:[1]
- "플레인 텍스트는 문자 코드의 순수한 시퀀스이다. 따라서 인코딩되지 않은 플레인 텍스트는 유니코드 문자 코드의 시퀀스이다.
- 대조적으로, 리치 텍스트(rich text)로도 알려진 스타일이 적용된 텍스트는 플레인 텍스트에 언어 식별자, 글꼴 크기, 색상, 하이퍼텍스트 링크 등과 같은 추가 정보가 포함된 모든 텍스트 표현을 말한다.
- SGML, RTF, HTML, XML, TeX은 플레인 텍스트 데이터와 추가 데이터 구조를 나타내는 문자 시퀀스를 혼합하여 플레인 텍스트 스트림으로 완전히 표현된 리치 텍스트의 예이다."
그러나 다른 정의에 따르면, 마크업이나 기타 메타데이터를 포함하는 파일이라도 마크업 자체가 (HTML, XML 등과 같이) 직접 인간이 읽을 수 있는 형태라면 일반적으로 플레인 텍스트로 간주된다. 따라서 SGML, RTF, HTML, XML, 위키 마크업, TeX와 같은 표현 방식은 물론 거의 모든 프로그래밍 언어 소스 코드 파일도 플레인 텍스트로 간주된다. 특정 내용이 무엇인지는 파일이 플레인 텍스트인지 여부와 무관하다. 예를 들어, SVG 파일은 그림이나 비트맵 그래픽까지 표현할 수 있지만 여전히 플레인 텍스트이다.
이진 파일 대신 플레인 텍스트를 사용하면 파일이 "야생 환경"에서 훨씬 더 잘 살아남을 수 있게 해주는데, 이는 부분적으로 컴퓨터 아키텍처의 비호환성으로부터 상당 부분 면역력을 갖게 해주기 때문이다. 예를 들어, 모든 데이터를 UTF-8 텍스트로 인코딩하면 엔디언 문제를 모두 피할 수 있다.
용도
[편집]오늘날 플레인 텍스트를 사용하는 목적은 주로 고유한 특수 인코딩, 서식 또는 파일 형식을 요구하는 프로그램으로부터의 독립성이다. 플레인 텍스트 파일은 어디에나 있는 문서 편집기와 유틸리티로 열고, 읽고, 편집할 수 있다.
명령줄 인터페이스를 통해 사람들은 플레인 텍스트로 명령을 내리고 대개 플레인 텍스트로 된 응답을 받을 수 있다.
도스, 윈도우, 클래식 맥 OS, 유닉스 및 그 계열의 수많은 프로그램은 물론, 웹 브라우저(링크스나 라인 모드 브라우저와 같은 일부 브라우저는 표시용으로 플레인 텍스트만 생성함) 및 기타 전자 텍스트 리더와 같은 많은 다른 컴퓨터 프로그램도 플레인 텍스트를 처리하거나 생성할 수 있다.
플레인 텍스트 파일은 프로그래밍에서 거의 보편적이다. 프로그래밍 언어의 명령어를 포함하는 소스 코드 파일은 거의 항상 플레인 텍스트 파일이다. 플레인 텍스트는 프로그램 시작 시 저장된 설정을 읽어오는 구성 파일에도 흔히 사용된다.
대부분의 이메일에도 플레인 텍스트가 사용된다.
주석, ".txt" 파일 또는 TXT 레코드는 일반적으로 사람이 읽을 수 있도록 의도된 (서식 없는) 플레인 텍스트만을 포함한다.
지식을 영구적으로 저장하기 위한 최상의 형식은 특정 이진 형식보다는 플레인 텍스트이다.[2]
인코딩
[편집]문자 인코딩
[편집]
이 부분의 본문은 문자 인코딩입니다.1960년대 초반 이전에는 컴퓨터가 텍스트보다는 주로 숫자 계산에 사용되었고 메모리는 매우 비쌌다. 컴퓨터는 종종 각 문자에 6비트만 할당하여 64개의 문자만 허용했다. A-Z, a-z, 0-9에 코드를 할당하면 2개의 코드만 남게 되어 턱없이 부족했다. 대부분의 컴퓨터는 소문자를 지원하지 않기로 했다. 따라서 로베르토 부사의 인덱스 토미스티쿠스, 브라운 코퍼스 등과 같은 초기 텍스트 프로젝트는 대문자로 의도된 글자 앞에 별표를 입력하는 것과 같은 관습에 의존해야 했다.
IBM의 프레더릭 브룩스는 언젠가 사람들이 텍스트를 처리하고 싶어 할 것이라며 8비트 바이트로 갈 것을 강력히 주장했고 승리했다. IBM은 EBCDIC을 사용했지만, 그 이후의 대부분의 텍스트는 ASCII로 인코딩되어 (인쇄되지 않는) 제어 문자에는 0에서 31까지의 값을 사용하고, 문자, 숫자, 문장 부호와 같은 그래픽 문자에는 32에서 127까지의 값을 사용하게 되었다. 대부분의 기계는 문자를 7비트가 아닌 8비트로 저장했으며, 남은 비트는 무시하거나 체크섬으로 사용했다.
ASCII의 보편화는 큰 도움이 되었지만, 국제적이고 언어적인 문제는 해결하지 못했다. 달러 기호("$")는 영국에서 유용하지 않았고, 스페인어, 프랑어, 독일어, 포르투갈어, 이탈리아어 및 기타 많은 언어에서 사용되는 액센트 문자는 ASCII에서 전혀 사용할 수 없었다(그리스어, 러시아어 및 대부분의 동양 언어에서 사용되는 문자는 말할 것도 없다). 많은 개인, 기업 및 국가가 필요에 따라 추가 문자를 정의했으며, 종종 제어 문자를 다시 할당하거나 128에서 255 사이의 값을 사용했다. 128 이상의 값을 사용하는 것은 8번째 비트를 체크섬으로 사용하는 것과 충돌했지만, 체크섬 사용은 점차 사라졌다.
이러한 추가 문자들은 국가마다 다르게 인코딩되어 제작자의 규칙을 파악하지 않고는 텍스트를 디코딩하는 것이 불가능했다. 예를 들어, 브라우저가 한 문자 집합을 다른 문자 집합으로 해석하려고 시도하면 ` 대신 ¬A를 표시할 수 있다. 국제 표준화 기구(ISO)는 결국 다양한 언어를 수용하기 위해 ISO/IEC 8859에 따라 여러 코드 페이지를 개발했다. 이 중 첫 번째인 ISO/IEC 8859-1은 "Latin-1"으로도 알려져 있으며, 라틴 기반 문자를 사용하는 대부분의(전부는 아닌) 유럽 언어의 요구 사항을 충족한다. 그 후 ISO 2022는 파일 중간에 서로 다른 문자 집합 사이를 "전환"하기 위한 관습을 제공했다. 많은 다른 조직에서 이러한 변형을 개발했으며, 수년 동안 윈도우와 매킨토시 컴퓨터는 호환되지 않는 변형을 사용했다.
텍스트 인코딩 상황은 점점 더 복잡해졌고, ISO와 유니코드 컨소시엄은 알려진(또는 적어도 현재 알려진) 모든 언어를 포괄할 수 있는 단일하고 통합된 문자 인코딩을 개발하기 위해 노력했다. 몇 가지 갈등 끝에[3] 이러한 노력은 통합되었다. 유니코드는 현재 1,114,112개의 코드 값을 허용하며, 거의 모든 현대 텍스트 쓰기 시스템은 물론 많은 역사적 체계, 그리고 인쇄용 딩뱃, 수학 기호 등과 같은 많은 비언어적 문자를 포괄하는 코드를 할당하고 있다.
텍스트는 인코딩에 관계없이 플레인 텍스트로 간주된다. 이를 적절하게 이해하거나 처리하기 위해 수신자는 어떤 인코딩이 사용되었는지 알아야(또는 알아낼 수 있어야) 한다. 그러나 사용된 컴퓨터 아키텍처나 데이터를 생성한 프로그램이 정의한 이진 구조에 대해서는 알 필요가 없다.
플레인 텍스트의 특정 인코딩을 명시적으로 밝히는 가장 일반적인 방법은 MIME 유형을 사용하는 것이다. 이메일과 HTTP의 경우, 기본 MIME 유형은 마크업이 없는 플레인 텍스트인 "text/plain"이다. 이메일과 HTTP 모두에서 자주 사용되는 또 다른 MIME 유형은 "text/html; charset=UTF-8"로, 이는 HTML 마크업이 포함된 UTF-8 문자 인코딩으로 표현된 플레인 텍스트이다. 또 다른 일반적인 MIME 유형은 "application/json"으로, 이는 JSON 마크업이 포함된 UTF-8 문자 인코딩으로 표현된 플레인 텍스트이다.
문자 인코딩에 대한 명시적인 표시 없이 문서가 수신되면, 일부 애플리케이션은 문자 집합 감지를 사용하여 어떤 인코딩이 사용되었는지 추측하려고 시도한다.
제어 코드
[편집] 이 부분의 본문은 C0 및 C1 제어 코드입니다.ASCII는 처음 32개 코드(10진수 0–31)를 "C0 세트"로 알려진 제어 문자를 위해 예약해 두었다. 이 코드들은 원래 인쇄 가능한 정보를 나타내기 위한 것이 아니라, ASCII를 사용하는 장치(예: 프린터)를 제어하거나 자기 테이프에 저장된 데이터 스트림에 대한 메타데이터 정보를 제공하기 위해 고안되었다. 여기에는 새줄 문자와 탭 문자와 같은 일반적인 문자가 포함된다.
Latin-1 및 기타 ISO/IEC 8859 세트와 같은 8비트 문자 세트에서 "상위 절반"의 처음 32개 문자(128~159) 또한 제어 코드이며 "C1 세트"로 알려져 있다. 이들은 직접적으로는 거의 사용되지 않는다. 표면적으로 ISO 8859 인코딩으로 되어 있는 문서에서 이들이 나타나면, 해당 코드 위치는 일반적으로 해당 위치에 추가적인 그래픽 문자를 제공하는 Windows-1252 또는 Mac OS Roman과 같은 독점적이고 시스템 특화된 인코딩의 문자를 대신 참조한다.
이 부분의 본문은 유니코드 제어 문자입니다.유니코드는 양방향 텍스트 방향 무시 문자(왼쪽에서 오른쪽 쓰기 내에 오른쪽에서 왼쪽 쓰기를 명시적으로 표시하거나 그 반대의 경우에 사용)와 CJK 통합 한자, 이모지 및 기타 문자의 대체 형태를 선택하기 위한 이형자 선택자를 포함하여 추가적인 제어 문자를 정의한다.
같이 보기
[편집]각주
[편집]- ↑ “The Unicode Standard, version 14.0” (PDF). 18–19쪽.
- ↑ 앤드류 헌트, 데이비드 토머스. "실용주의 프로그래머". 1999. 제14장: "텍스트의 위력". p. 73.
- ↑ “ISO/Unicode Merger: Ed Hart Memo”. 《www.unicode.org》. 2024년 10월 21일에 확인함.