Простой текст в компьютерных технологиях

Введение

Термин для компьютерных данных, состоящих только из неформатированных символов читаемого материала.

В вычислительной технике простой текст – это общее обозначение для данных (например, содержимого файла), которые представляют собой только символы читаемого материала, но не его графическое представление и не другие объекты (числа с плавающей точкой, изображения и т.п.). Он может также включать ограниченное количество символов "белого пространства", влияющих на простое форматирование текста, таких как пробелы, переносы строк или символы табуляции. Простой текст отличается от форматированного текста, содержащего информацию о стиле; от структурированного текста, в котором идентифицированы структурные части документа, такие как абзацы, разделы и т.д.; и от бинарных файлов, в которых некоторые части должны интерпретироваться как бинарные объекты (кодированные целые числа, вещественные числа, изображения и т.п.). Термин иногда используется в широком смысле для обозначения файлов, содержащих только "читаемый" контент (или просто файлов, не содержащих ничего, что нежелательно для говорящего). Например, это может исключать любые указания на шрифты или макет (например, разметку, Markdown или даже табуляции); символы, такие как умные кавычки, неразрывные пробелы, мягкие переносы, длинные тире и/или лигатуры; или другие элементы. В принципе, простой текст может быть представлен в любой кодировке, но иногда термин подразумевает ASCII. По мере того как кодировки на основе Unicode, такие как UTF-8 и UTF-16, становятся все более распространенными, такое понимание может сокращаться. Простой текст также иногда используется исключительно для исключения "бинарных" файлов: тех, в которых хотя бы некоторые части файла не могут быть правильно интерпретированы с использованием действующей кодировки символов. Например, файл или строка, состоящая из "hello" (в любой кодировке), за которым следуют 4 байта, представляющие собой двоичное целое число, которое не является символом, является бинарным файлом. Преобразование файла простого текста в другую кодировку не изменяет смысл текста, если используется правильная кодировка. Однако преобразование бинарного файла в другой формат может изменить интерпретацию нетекстовых данных.

Использование

Цель использования простого текста сегодня заключается прежде всего в независимости от программ, требующих собственной специальной кодировки, форматирования или формата файла. Простые текстовые файлы можно открывать, читать и редактировать с помощью повсеместно распространенных текстовых редакторов и утилит. Интерфейс командной строки позволяет пользователям вводить команды в виде простого текста и получать ответ, как правило, также в виде простого текста. Многие другие компьютерные программы также способны обрабатывать или создавать простой текст, например, бесчисленные программы для DOS, Windows, классической Mac OS и Unix и его производных; а также веб-браузеры (некоторые браузеры, такие как Lynx и Line Mode Browser, отображают только простой текст) и другие электронные читалки. Простые текстовые файлы практически универсальны в программировании: файл исходного кода, содержащий инструкции на языке программирования, почти всегда является текстовым файлом. Простой текст также часто используется для файлов конфигурации, которые считываются для загрузки сохраненных настроек при запуске программы. Большинство электронных писем используют простой текст. Комментарий, файл с расширением ".txt" или TXT-запись обычно содержат только простой текст (без форматирования), предназначенный для чтения человеком. Лучшим форматом для постоянного хранения информации является простой текст, а не двоичный формат.

Кодировки символов

До начала 1960-х годов компьютеры в основном использовались для вычислений, а не для работы с текстом, и память была чрезвычайно дорогой. Компьютеры часто выделяли всего 6 бит на каждый символ, что позволяло использовать лишь 64 символа. Назначение кодов для A–Z, a–z и 0–9 оставляло всего 2 кода, чего было явно недостаточно. Большинство компьютеров отказались от поддержки строчных букв. Таким образом, ранние текстовые проекты, такие как Index Thomisticus Роберто Бусы, Brown Corpus и другие, вынуждены были прибегать к условности, например, ставить звездочку перед буквами, которые должны были быть заглавными. Фред Брукс из IBM настоятельно выступал за переход к 8-битным байтам, поскольку когда-нибудь людям может понадобиться обрабатывать текст, и ему удалось убедить руководство. Хотя IBM использовала EBCDIC, с тех пор большая часть текста стала кодироваться в ASCII, используя значения от 0 до 31 для (непечатаемых) управляющих символов и значения от 32 до 127 для графических символов, таких как буквы, цифры и знаки препинания. Большинство машин хранили символы в 8 битах, а не в 7, игнорируя оставшийся бит или используя его для контрольной суммы. Широкое распространение ASCII было большой помощью, но не решило проблемы, связанные с международными языками и различными лингвистическими особенностями. Знак доллара ("$") был не так полезен в Англии, а диакритические знаки, используемые в испанском, французском, немецком, португальском и многих других языках, полностью отсутствовали в ASCII (не говоря уже о символах, используемых в греческом, русском и большинстве восточных языков). Многие частные лица, компании и страны определяли дополнительные символы по мере необходимости, часто переназначая управляющие символы или используя значения в диапазоне от 128 до 255. Использование значений выше 128 противоречило использованию 8-го бита для контрольной суммы, но использование контрольной суммы постепенно прекратилось. Эти дополнительные символы кодировались по-разному в разных странах, что делало декодирование текстов невозможным без понимания правил, принятых автором. Например, браузер мог отображать ¬A вместо ` , если бы пытался интерпретировать один набор символов как другой. Международная организация по стандартизации (ISO) в конечном итоге разработала несколько кодовых страниц в рамках стандарта ISO 8859, чтобы учесть различные языки. Первая из них (ISO 8859-1) также известна как "Latin 1" и охватывает потребности большинства (но не всех) европейских языков, использующих символы латинского алфавита (места для всех не хватало). ISO 2022 затем предоставил соглашения для "переключения" между различными наборами символов внутри файла. Многие другие организации разработали собственные варианты, и в течение многих лет компьютеры Windows и Macintosh использовали несовместимые варианты. Ситуация с кодировкой текста становилась все более сложной, что привело к усилиям ISO и Консорциума Unicode по разработке единой, унифицированной кодировки символов, которая могла бы охватить все известные (или, по крайней мере, все известные на данный момент) языки. После некоторого противостояния эти усилия были объединены. Unicode в настоящее время позволяет использовать 1 114 112 кодовых значений и присваивает коды, охватывающие почти все современные системы письменности, а также многие исторические, и множество нелингвистических символов, таких как типографские символы, математические символы и т. д. Текст считается обычным текстом независимо от его кодировки. Чтобы правильно понять или обработать его, получателю необходимо знать (или иметь возможность определить), какая кодировка была использована; однако ему не нужно знать ничего об архитектуре компьютера, который использовался, или о двоичных структурах, определенных любой программой (если таковая имеется), создавшей данные. Наиболее распространенным способом явного указания конкретной кодировки обычного текста является тип MIME. Для электронной почты и HTTP тип MIME по умолчанию — "text/plain" — обычный текст без разметки. Другой тип MIME, часто используемый как в электронной почте, так и в HTTP, — это "text/html; charset=UTF-8" — обычный текст, представленный с использованием кодировки символов UTF-8 с разметкой HTML. Другой распространенный тип MIME — "application/json" — обычный текст, представленный с использованием кодировки символов UTF-8 с разметкой JSON. Когда документ получен без явного указания кодировки символов, некоторые приложения используют определение кодировки, чтобы попытаться угадать, какая кодировка была использована.

Before the early 1960s, computers were mainly used for number crunching rather than for text, and memory was extremely expensive. Computers often allocated only 6 bits for each character, permitting only 64 characters—assigning codes for A Z, a z, and 0 9 would leave only 2 codes: nowhere near enough. Most computers opted not to support lower case letters. Thus, early text projects such as Roberto Busa's Index Thomisticus, the Brown Corpus, and others had to resort to conventions such as keying an asterisk preceding letters actually intended to be upper case. Fred Brooks of IBM argued strongly for going to 8 bit bytes, because someday people might want to process text, and won. Although IBM used EBCDIC, most text from then on came to be encoded in ASCII, using values from 0 to 31 for (non printing) control characters, and values from 32 to 127 for graphic characters such as letters, digits, and punctuation. Most machines stored characters in 8 bits rather than 7, ignoring the remaining bit or using it as a checksum. The near ubiquity of ASCII was a great help, but failed to address international and linguistic concerns. The dollar sign ("$") was not as useful in England, and the accented characters used in Spanish, French, German, Portuguese, and many other languages were entirely unavailable in ASCII (not to mention characters used in Greek, Russian, and most Eastern languages). Many individuals, companies, and countries defined extra characters as needed—often reassigning control characters, or using values in the range from 128 to 255. Using values above 128 conflicts with using the 8th bit as a checksum, but the checksum usage gradually died out. These additional characters were encoded differently in different countries, making texts impossible to decode without figuring out the originator's rules. For instance, a browser might display ¬A rather than ` if it tried to interpret one character set as another. The International Organization for Standardization (ISO) eventually developed several code pages under ISO 8859, to accommodate various languages. The first of these (ISO 8859 1) is also known as "Latin 1", and covers the needs of most (not all) European languages that use Latin based characters (there was not quite enough room to cover them all). ISO 2022 then provided conventions for "switching" between different character sets in mid file. Many other organisations developed variations on these, and for many years Windows and Macintosh computers used incompatible variations. The text encoding situation became more and more complex, leading to efforts by ISO and by the Unicode Consortium to develop a single, unified character encoding that could cover all known (or at least all currently known) languages. After some conflict, these efforts were unified. Unicode currently allows for 1,114,112 code values, and assigns codes covering nearly all modern text writing systems, as well as many historical ones, and for many non linguistic characters such as printer's dingbats, mathematical symbols, etc. Text is considered plain text regardless of its encoding. To properly understand or process it the recipient must know (or be able to figure out) what encoding was used; however, they need not know anything about the computer architecture that was used, or about the binary structures defined by whatever program (if any) created the data. Perhaps the most common way of explicitly stating the specific encoding of plain text is with a MIME type. For email and HTTP, the default MIME type is "text/plain" plain text without markup. Another MIME type often used in both email and HTTP is "text/html; charset=UTF 8" plain text represented using the UTF 8 character encoding with HTML markup. Another common MIME type is "application/json" plain text represented using the UTF 8 character encoding with JSON markup. When a document is received without any explicit indication of the character encoding, some applications use charset detection to attempt to guess what encoding was used.

Коды контроля

ASCII зарезервировал первые 32 кода (числа от 0 до 31 в десятичной системе) для управляющих символов, известных как "набор C0": коды, изначально предназначенные не для представления печатной информации, а для управления устройствами (например, принтерами), использующими ASCII, или для предоставления метаинформации о потоках данных, таких как данные, хранящиеся на магнитной ленте. Они включают в себя распространенные символы, такие как символ новой строки и символ табуляции. В 8-битовых кодировках, таких как Latin 1 и другие наборы ISO 8859, первые 32 символа "верхней половины" (от 128 до 159) также являются управляющими кодами, известными как "набор C1". Они редко используются напрямую; когда они встречаются в документах, которые предположительно имеют кодировку ISO 8859, их позиции кода обычно соответствуют символам в этой позиции в проприетарной, системно-зависимой кодировке, такой как Windows 1252 или Mac OS Roman, которые используют эти коды для предоставления дополнительных графических символов. Unicode определяет дополнительные управляющие символы, включая символы переопределения направления текста (используемые для явного указания направления письма справа налево внутри текста, написанного слева направо, и наоборот) и селекторы вариантов для выбора альтернативных форм иероглифов CJK, эмодзи и других символов.