Обсуждение:Текстовый файл

↓

Пожалуйста, добавляйте новые темы снизу

Текстовый файл vs документ текстового процессора

Начинаю замечать, что всё сложнее объяснять людям отличие «простых» текстовых файлов от документов текстовых процессоров. Начинает казаться, что это какой-то надуманный концепт, с искусственно внесёнными бессмысленными ограничениями.

«Форматирование» в простых текстовых файлах — возможно, хоть и лишь в части отступов горизонтальных и вертикальных (отступы, центрирование и разбивка по ширине колонки пробелами и табуляцией, разбивка на строки и абзацы переносами строк). Графика и таблицы тоже в них доступны, хоть и лишь в виде (ASCII-арт)…

В общем, при попытке объяснить всё в итоге упирается в особенности графической подсистемы старых компьютеров, когда был аппаратный знакогенератор и текстовый режим экрана, самостоятельно отображающий знаки по кодам знакогенератора из видеопамяти. Тогда можно было эти коды знакогенератора, в виде, непосредственно пригодном для видеопамяти, прямо так сохранить в файл, и потом легко просматривать, просто скопировав обратно в видеопамять. И было наглядное различие — вот это видеопамятью отображается читаемо, а вот это выглядит непонятной мешаниной.

И то, уже тогда, вывод на экран практиковали не совсем напрямую, а через подсистему, которая некоторые коды интерпретировала особенным образом — например, табуляцию, перевод строки, возврат каретки, забой (backspace), и даже «символ» номер 7 — который был коротким звуком через системный динамик, и вовсе не рисовался! И уже тогда вид отображаемых символов зависел от картинок знакогенератора, связанных с кодами — ведь уже были разные кодировки, особенно для языков с не латинским алфавитом!

А теперь, когда роль знакогенератора взяли на себя шрифты, в файлах бывают различные кодировки, и знак вовсе не обязан быть в файле одним байтом, знаки даже не обязаны быть все одинакового количества байт (см. UTF-8), и для просмотра простого текстового файла используется одна из множества программ типа notepad, которая прежде чем показать файл всё равно уже делает кучу всякого — как объяснять простым людям разницу, не углубляясь в дебри истории?

Возникает резонный вопрос, зачем такие древние условности сегодня?.. Почему и поныне критерий отображаемости файла блокнотиком так важен? Википедия пока тоже бессильна в ответе на этот вопрос, хотя вот вроде бы должна иметь внятное объяснение! Давайте найдём на него ответ?

--Nashev 07:55, 21 августа 2015 (UTC)

Для простого юзера текстовый файл — это и в самом деле тот же самый вордовый файл, но только с меньшими возможностями. А для программиста текстовый файл — это то, что удобно обрабатывать (в том числе и потому, что существует огромное количество готовых утилит для обработки простого текста). Поэтому вся «внутренняя кухня» компьютера работает с простым текстом — но юзер этого не видит. — Monedula 19:44, 21 августа 2015 (UTC)

• Пожалуй, формулировка «исторически так сложилось, что для этого подхода к данным есть огромное количество опирающихся на него инструментов» — возможно, и впрямь достаточно корректное объяснение первого уровня, спасибо. А дальше желающим можно про древние видеокарты и принтеры рассказывать. --Nashev 09:38, 25 декабря 2015 (UTC)

Не нужно пытаться все объяснять с точки зрения обычного пользователя. Также не нужно путать способ хранения информации и способ её отображения. И блокнот тут совсем ни при чем. --SergV 20:24, 21 августа 2015 (UTC)

• Извините, но ваши утверждения — первое просто ошибочно, вредно и противоречит духу Википедии, второе говорит о несуществующем заблуждении, а третье безосновательно и бесполезно. Зачем Вы их написали? --Nashev 09:38, 25 декабря 2015 (UTC)

Кстати, вспомнил про принтеры и клавиатуры, которые появились раньше текстовых дисплеев и обусловили их возможности. А их собственные возможности были обусловлены телетайпом, дистанционно-электрически-управляемой печатной машинкой, которая родилась из обычной механической печатной машинки и породила кодировку ASCII, являющуюся основой текстовых данных. --Nashev 09:38, 25 декабря 2015 (UTC)

Разделение текстового файла и текстового формата

• Только что добавлена правка с комментарием: "Да неужели, мой анонимный критик… во всяком случае это хотя бы не бред про «файлы в формате Unicode»! --Incnis Mrsi". Уважаемый Участник:Incnis Mrsi, поаккуратнее с выражениями. Я вовсе не аноним и не критик. Речь про "переработать" относилась к слову "двоичным" в "двоичным файлам". Если вы пропустили то, как я ставил об этом вопрос, это не моя вина. -- A^VB^talk 00:50, 11 августа 2008 (UTC)

  Не пропустил, сначала обсуждение читал, и даже отреагировал. Вы не заметили? Incnis Mrsi 08:54, 11 августа 2008 (UTC)

• можно ссылочку на вашу реакцию? Вашего ника я что-то не припомню, чтобы он мелькал где-то в ответах или комментариях. -- A^VB^talk 13:12, 11 августа 2008 (UTC)

• Далее, если вам лениво "вытягивать из newline", то хотя бы потрудитесь ознакомиться с текстовый формат, где как раз и рассматривается тема структуры текста. -- A^VB^talk 00:50, 11 августа 2008 (UTC)

  Ознакомился. Англоперевод. IMHO этой статьи в таком виде вообще не должно быть. Incnis Mrsi 08:54, 11 августа 2008 (UTC)

• (1) Точнее, это не перевод, а синхронизация с англовики (я подтянул структуру и некоторые фрагменты оттуда). Немного разные вещи. (2) А в каком виде, по вашему, оно должно быть? PS: я там сделал ошибку: данные и формат тоже разные вещи, а я сделал редирект с "текстового формата" на "текстовые данные". Нужно будет поменять названия местами и перенаправить данные соответственно на данные. -- A^VB^talk 13:12, 11 августа 2008 (UTC)

избыточность текстового формата (низкая энтропия)

• Далее, насчёт "сравнения с машинным кодом" - если вы опять же посмотрите текстовый формат, там показано, откуда берётся избыточность. И, касаясь конкретно машинных кодов, сравните размеры ассемблерных сорсов и размеры того, во что они ассемблируются. -- A^VB^talk 00:50, 11 августа 2008 (UTC)

  Ах, ассемблерных… а если сравнить исходники на C и исполняемый код? Incnis Mrsi 08:54, 11 августа 2008 (UTC)

• Легко. void main(){} компилируется ваткомом в:

0000                          main_:
0000    B8 02 00                  mov         ax,0x0002 
0003    E9 00 00                  jmp         __STK 
0006    C3                        ret

7 байт против 15. Нет, конечно, вы можете начать пытаться искать компиляторы, которые гонят в маш.код ещё какой-то лишний и/или неоптимизированный код, а в компанию затесать объёмы рантайм библиотек или даже объёмы операционной системы, но речь вообще-то всё равно не об этом. Речь, во-первых, о том, что как "хранилище" текстовый формат избыточен за счёт "кодирования" числовых данных (см. пример в текстовом формате) и за счёт избыточности естественных языков, под которые подстраивается "изложение" в текстовых файлах (знаки пунктуации, пробелы, длинные слова и т.п.). Вот, кстати, пример из типовых: при кодировании методом UUENCODE размер данных увеличивается на 30%. К сожалению, я не уверен, если ли источники, в которых эта тривиальность (подобная "2+2=4") явно формулируется, но по крайней мере, вы правы, примеры я добавлю. Во-вторых, машинный код и Си - разные языки, и Си не является текстовым хранилищем машкодов, поскольку между ними нет соответствия и требуется перевод, который в общем случае далеко не однозначен. А вот асм - это как раз и есть маш.код, закодированный с помощью мнемоник (хотя, строго говоря, и тут далеко не всегда есть строгая однозначность - одна и та же инструкция может быть закодирована разными опкодами). -- A^VB^talk 13:12, 11 августа 2008 (UTC)

"направление письма"

• и опять же, какое отношение к текстовым файлам имеет "направление письма"? Да никакого. Абсолютно. Даже к текстовому формату это не имеет отношения. -- A^VB^talk 00:50, 11 августа 2008 (UTC)

  В статье двоичный файл против достаточно подробного описания визуализации никто не возражал, хотя как раз для них это не главное. В чём же радикальное отличие текста от двоичных данных как не в в способе визуализации? Почему такой двойной стандарт? Incnis Mrsi 08:54, 11 августа 2008 (UTC)

• разница между текстовыми и нетекстовыми данными не в способе визуализации, а в способе кодирования. Если неформально, то в текстовых форматах кодирование производится не "напрямую", а через "символы", и уже после этого сохраняются коды символов. -- A^VB^talk 13:12, 11 августа 2008 (UTC)

маркер уникода

• Далее, я не понял, зачем было убирать (пусть и не полное) описание, что из себя представляет маркер уникода. Вообще убирать, даже ссылок куда-либо не осталось... -- A^VB^talk 00:50, 11 августа 2008 (UTC)

  Сошлитесь на стандарт, оговаривающий применение \uFEFF в качестве маркера — вернём. По-моему этим маркеры просто чья-то самодеятельность (которую Вы выдаёте за часть UTF-16, не называя его ещё при этом по имени), хотя я могу ошибаться. Incnis Mrsi 08:54, 11 августа 2008 (UTC)

• для того там и был поставлен шаблон {{источник?}}, чтобы потом найти АИ для него. Сам же факт я перенёс из статьи "текстовые форматы" (именно так, во множественном числе) перед тем, как сделать её редиректом. -- A^VB^talk 13:12, 11 августа 2008 (UTC)

• Конечно, вы ошибаетесь. Про FEFF читайте на сайте www.unicode.org. — Monedula 10:47, 11 августа 2008 (UTC)

• Короче, я в шоке. -- A^VB^talk 00:50, 11 августа 2008 (UTC)

  По поводу «файлов в формате Unicode» я тоже посмеялся недурственно ☺ Incnis Mrsi 08:54, 11 августа 2008 (UTC)

• не знаю, про какие "файлы в формате уникода" вы говорите. -- A^VB^talk 13:12, 11 августа 2008 (UTC)

Системы управления версиями, например в MS Word

«Многие распространённые системы управления версиями (например в MS Word) рассчитаны на текстовые файлы…» — распространённые системы управления версиями есть Subversion и git. --217.195.52.165 20:03, 3 января 2011 (UTC)

Преимущества

«Минимальный объём файла (при малом количестве текстовых данных)» - непонятно, что имелось ввиду FeelUs 23:48, 28 января 2011 (UTC)

аналогично .zip'y - при малом объёме данных (скажем 20б - 1 Кб) - сжатие (которое делает .doc) неэффективно и может наоборот привести к разбуханию файла. При бОльших объёмах данных - такое сжатие эффективно. Tpyvvikky 08:30, 29 января 2011 (UTC) ..возможно стоить пояснить в тексте статьи

вот посмотрел: пустой (т.е. без букв) файл Word имеет объём - 10 818 байт (в формате 2007 - .docx), 26 112 байт (в формате 2003 - .doc) Tpyvvikky 08:40, 29 января 2011 (UTC)

• Блин, надо упомянуть и о главном преимуществе - скорости открытия файла (F3, различными просмотрщиками), которое значительно превышает таковое различных проч. файлов при помощи разл. программ. Tpyvvikky 08:33, 29 января 2011 (UTC)

Файл как контейнер

«В отличие от термина „текстовый формат“, характеризующего содержимое данных, термин „текстовый файл“ относится к файлу и характеризует его как контейнер, хранящий такие данные.» — В общем случае это неверно — gnu zip-файл от любого тестового файла будет контейнером хранящим текстовые данные, но не будет текстовым файлом. Отличие как раз в том, что текстовый файл хранит лишь текстовые данные в форме представляющем последовотельность печатаемых символов в какой-либо кодировке, и может быть непосредственно интерпретирован как текстовые данные. Исключение составит лишь формат кодирования UTF16-BOM, и то признак порядка интерпретируется как пробел. — Эта реплика добавлена участником Khenar (о • в)

ну так.. — состоящий только из печатаемых (то есть сабж) или же и из непечатаемых символов, всё верно (zip-файл и будет «текстовый файл»). или я что-то не понял? Tpyvvikky 23:31, 18 января 2013 (UTC) ..что есть «признак порядка интерпретируется как пробел»?

• zip-файл с текстом — это бинарный файл, хранящий запакованные (преобразованные в более компактную форму) данные из текстового файла. --Nashev 09:45, 25 декабря 2015 (UTC)