일반 텍스트
Plain text | 이 글은 검증을 위해 인용구가 추가로 필요하다. 텍스트 – · · · (2012년 8월 (이를 |
컴퓨팅에서 일반 텍스트는 읽을 수 있는 자료의 문자만 나타내며 그래픽 표현이나 다른 객체(플로팅 포인트 번호, 이미지 등)는 나타내지 않는 데이터(예: 파일 내용)의 느슨한 용어다.또한 공백, 줄 바꿈 또는 표와 같은 텍스트의 단순한 배열에 영향을 미치는 제한된 수의 "스페이스" 문자를 포함할 수 있다(탭 문자는 여러 가지 다른 것을 "평균"할 수 있으므로 "일반"은 거의 없다).일반 텍스트는 스타일 정보가 포함되는 형식 텍스트와, 문단, 섹션 등과 같은 문서의 구조적 부분이 식별되는 구조화된 텍스트와, 일부 부분이 이진 객체(인코딩된 정수, 실제 숫자, 이미지 등)로 해석되어야 하는 이진 파일과는 다르다.
이 용어는 때때로 "읽을 수 있는" 내용만 들어 있는 파일(또는 화자가 원하지 않는 내용이 없는 파일만 들어 있는 파일)을 의미하기 위해 상당히 느슨하게 사용된다.예를 들어, 글꼴 또는 레이아웃 표시(예: 마크업, 마크다운 또는 짝수 탭), 구불구불한 따옴표, 공백, 소프트 하이픈, 엠 대시 및/또는 연결 등의 문자를 제외할 수 있다.
원칙적으로 일반 텍스트는 어떤 인코딩에도 있을 수 있지만, 때때로 이 용어는 ASCII를 암시하는 의미로 받아들여지기도 한다.UTF-8이나 UTF-16과 같은 유니코드 기반 인코딩이 보편화되면서 그 사용량이 줄어들고 있을 수 있다.
일반 텍스트도 "이진" 파일, 즉 실제 문자 인코딩을 통해 파일의 일부를 올바르게 해석할 수 없는 파일만 제외하는 데 사용된다.예를 들어, 문자만이 아닌 이진 정수를 표현하는 4바이트를 따라 "hello"(어떤 인코딩이든)로 구성된 파일이나 문자열은 가장 느슨한 일반적인 사용법에 의한 일반 텍스트가 아니라 이진 파일이다.다른 방법으로, 일반 텍스트 파일을 문자를 나타내기 위해 완전히 다른 숫자를 사용하는 문자 인코딩으로 변환해도 의미가 변경되지 않지만(어떤 인코딩이 사용 중인지 알고 있는 한), 이러한 변환과 같은 이진 파일의 경우 최소한 파일의 일부에 대한 의미가 변경된다.
일반 텍스트 및 리치 텍스트
유니코드 표준에 따라:
- 일반 텍스트는 문자 코드의 순서열이며, 따라서 일반 미인코딩 텍스트는 유니코드 문자 코드의 순서가 된다.
- 반대로 리치 텍스트라고도 하는 스타일 텍스트는 일반 텍스트와 언어 식별자, 글꼴 크기, 색상, 하이퍼텍스트 링크 등과 같은 추가 정보를 포함하는 텍스트 표현이다.
SGML, RTF, HTML, XML, TEX는 일반 텍스트 스트림으로 완전히 표현되는 리치 텍스트의 예로서, 일반 텍스트 데이터를 추가 데이터 구조를 나타내는 문자 시퀀스와 교차시킨다."
그러나 다른 정의에 따르면 마크업이나 기타 메타 데이터가 포함된 파일은 일반적으로 일반 텍스트로 간주되며, 마크업 역시 인간이 직접 읽을 수 있는 형태(HTML, XML 등)로 되어 있다.따라서 SGML, RTF, HTML, XML, 위키 마크업, TeX와 같은 표현뿐만 아니라 거의 모든 프로그래밍 언어 소스 코드 파일도 일반 텍스트로 간주된다.특정 내용은 파일이 일반 텍스트인지 여부와 무관하다.예를 들어, SVG 파일은 도면이나 비트맵 그래픽을 표현할 수 있지만, 여전히 일반 텍스트다.
이진 파일이 아닌 일반 텍스트를 사용하면 파일들이 컴퓨터 아키텍처의 비호환성에 대해 크게 영향을 받지 않게 함으로써 파일들이 훨씬 더 잘 "야생적"에서 살아남을 수 있다.예를 들어 Endianness의 모든 문제를 피할 수 있다(UTF-8이 아닌 UCS-2와 같은 인코딩을 사용하면 Endianness가 중요하지만 잠재적으로 알려지지 않은 하위 집합이 아닌 모든 문자에 대해 균일하게).
사용법
오늘날 일반 텍스트를 사용하는 목적은 주로 자체적인 특수 인코딩 또는 포맷이나 파일 형식을 필요로 하는 프로그램으로부터 독립적이다.어디서나 볼 수 있는 텍스트 편집기 및 유틸리티로 일반 텍스트 파일을 열고, 읽고, 편집할 수 있다.
명령줄 인터페이스는 일반 텍스트로 명령을 제공하고 응답(일반적으로 일반 텍스트에서도)을 얻을 수 있도록 한다.
많은 다른 컴퓨터 프로그램들 또한 DOS, 윈도우, 클래식 맥 OS, 유닉스 그리고 그 친척들과 같은 수많은 프로그램과 같이 평범한 텍스트를 처리하거나 만들 수 있다. 뿐만 아니라 웹 브라우저 (Lynx와 Line Mode Browser와 같은 몇몇 브라우저들은 디스플레이를 위한 평범한 텍스트만 생산한다)와 다른 전자 텍스트 리더들.
프로그래밍에서 일반 텍스트 파일은 거의 보편적이다; 프로그래밍 언어로 된 지시사항을 포함하는 소스 코드 파일은 거의 항상 일반 텍스트 파일이다.일반 텍스트는 프로그램 시작 시 저장된 설정을 위해 읽히는 구성 파일에도 일반적으로 사용된다.
일반 텍스트는 많은 전자 메일에 사용된다.
주석, ".txt" 파일 또는 TXT 레코드는 일반적으로 인간이 읽을 수 있도록 고안된 일반 텍스트(형식 없음)만 포함한다.
지식을 집요하게 저장하는 가장 좋은 형식은 어떤 이진 형식이 아니라 일반 텍스트다.[2]
인코딩
캐릭터 인코딩
1960년대 초 이전에는 컴퓨터가 텍스트보다는 숫자 크런치용으로 주로 사용되었고 메모리는 매우 비쌌다.컴퓨터는 종종 각 문자마다 6비트만 할당하고 64자만 허용한다. 즉, A-Z, a-z, 0-9에 코드를 할당하면 2개의 코드만 남는다. 즉, 충분치 않은 코드만 남는다.대부분의 컴퓨터는 소문자를 지원하지 않기로 선택했다.따라서, 로베르토 부사의 지수 토미스틱투스, 브라운 코퍼스 등과 같은 초기 텍스트 프로젝트들은 실제로 대문자로 의도된 선행 서신에 대한 별표를 지정하는 것과 같은 관례에 의존해야 했다.
IBM의 Fred Brooks는 언젠가 사람들이 텍스트를 처리하기를 원할 수도 있기 때문에 8비트 바이트로 가는 것에 대해 강력하게 주장했고 승리했다.IBM은 EBCDIC를 사용했지만, 그 이후 대부분의 텍스트는 (비인쇄) 제어 문자의 경우 0~31의 값, 문자, 숫자, 구두점 등의 그래픽 문자의 경우 32~127의 값을 사용하여 ASCII로 인코딩하게 되었다.대부분의 기계는 나머지 비트를 무시하거나 체크섬으로 사용하면서 7비트가 아닌 8비트에 문자를 저장했다.
ASCII의 거의 고유성이 큰 도움이 되었지만, 국제 및 언어적 우려를 해소하는 데는 실패했다.달러 부호("$")는 영국에서 그렇게 유용하지 않았고, 스페인어, 프랑스어, 독일어, 포르투갈어 및 많은 다른 언어에서 사용되는 악센트 문자는 전적으로 ASCII로 사용할 수 없었다(그리스어, 러시아어 및 대부분의 동양 언어에서 사용되는 문자는 말할 것도 없다).많은 개인, 회사 및 국가는 필요에 따라 추가 문자를 정의했다. 즉, 종종 제어 문자를 재할당하거나 128 ~ 255 범위의 값을 사용한다.128개 이상의 값을 사용하면 8번째 비트를 체크섬으로 사용하는 것과 충돌하지만 체크섬 사용량은 점차 소멸된다.
이러한 추가 문자는 국가마다 다르게 암호화되어 있어 원문의 규칙을 파악하지 않고는 해독이 불가능했다.예를 들어, 브라우저가 한 문자 집합을 다른 문자 집합으로 해석하려고 하면 '이 아닌 ¬A가 표시될 수 있다.국제표준화기구(ISO)는 결국 다양한 언어를 수용하기 위해 ISO 8859에 따라 여러 개의 코드 페이지를 개발했다.이 중 첫 번째(ISO 8859-1)는 "라틴-1"로도 알려져 있으며, 라틴어를 기반으로 한 문자를 사용하는 대부분의 (전부는 아님) 유럽 언어의 니즈를 다루고 있다(모두 포함시킬 수 있는 충분한 공간이 없었다).그 후 ISO 2022는 중간 파일에서 서로 다른 문자 집합 간에 "전환"을 위한 규칙을 제공했다.많은 다른 조직들은 이것들에 대한 변형을 개발했고, 수년 동안 윈도우와 매킨토시 컴퓨터는 양립할 수 없는 변형을 사용했다.
텍스트 인코딩 상황은 점점 더 복잡해졌고, ISO와 유니코드 컨소시엄은 알려진 모든(또는 적어도 현재 알려진 모든) 언어를 포괄할 수 있는 단일 통합 문자 인코딩을 개발하기 위한 노력으로 이어졌다.약간의 갈등 후에, 이러한 노력은 통일되었다.[citation needed]유니코드는 현재 1,114,112개의 코드 값을 허용하고 있으며, 많은 역사적 문자뿐만 아니라 거의 모든 현대적인 텍스트 쓰기 시스템과 프린터의 딩박트, 수학 기호 등과 같은 많은 비언어적 문자들을 포함하는 코드를 할당한다.
텍스트는 인코딩과 상관없이 일반 텍스트로 간주된다.그것을 제대로 이해하거나 처리하려면 수신자가 어떤 인코딩이 사용되었는지 알아야 한다(또는 어떤 인코딩이 사용되었는지 파악할 수 있어야 한다). 그러나, 그들은 사용된 컴퓨터 아키텍처나 데이터를 만든 어떤 프로그램에 의해 정의된 이진 구조에 대해서는 아무것도 알 필요가 없다(있는 경우).
아마도 일반 텍스트의 특정 인코딩을 명시적으로 명시하는 가장 일반적인 방법은 MIME 유형일 것이다.전자 메일 및 HTTP의 경우 기본 MIME 유형은 "텍스트/플레인"이며, 표시하지 않은 일반 텍스트입니다.전자 메일과 HTTP 모두에서 자주 사용되는 또 다른 MIME 유형은 "text/html; charset="이다.UTF-8" - HTML 마크업과 함께 UTF-8 문자 인코딩을 사용하여 표시되는 일반 텍스트.또 다른 일반적인 MIME 유형은 "응용프로그램/json"으로, JSON 마크업과 함께 UTF-8 문자 인코딩을 사용하여 표현되는 일반 텍스트다.
문자 인코딩을 명시적으로 표시하지 않고 문서를 수신할 때, 일부 응용프로그램은 사용된 인코딩을 추측하기 위해 문자 집합 탐지를 사용한다.
제어 코드
ASCII는 "C0 세트"로 알려진 제어 문자에 대해 최초의 32개 코드(숫자 0~31진수)를 보존한다. 즉, 원래 인쇄 가능한 정보를 나타내기 위한 것이 아니라 ASCII를 사용하는 장치(프린터 등)를 제어하거나, 자기 테이프에 저장된 것과 같은 데이터 스트림에 대한 메타 정보를 제공하기 위한 것이다.그것들은 뉴라인과 탭 문자와 같은 일반적인 문자를 포함한다.
라틴어-1과 다른 ISO 8859 세트와 같은 8비트 문자 집합에서 "상부"(128~159개)의 첫 32자 역시 "C1 세트"로 알려진 제어 코드다.그것들은 직접적으로 사용되는 경우가 거의 없다; 표면적으로는 ISO 8859 인코딩으로 되어 있는 문서에서 나타날 때, 그들의 코드 위치는 일반적으로 그 위치의 문자 대신 Windows-1252나 Mac OS Roman과 같은 독점적인 시스템별 인코딩에서 그 위치에 있는 문자들을 가리키며, 그 대신 코드를 사용하여 추가 그래픽 문자를 제공한다.
유니코드는 CJK 문자, 이모지 및 기타 문자의 대체 형식을 선택하기 위해 양방향 텍스트 방향 무시 문자(좌-우-우-우-우-우-우-우-우-우-우-우-우-우-우-우-우-우-우-우-쓰기를 명시적으로 표시하기 위해 사용됨)와 변형 선택기를 포함하여 추가 제어 문자를 정의한다.
