| Предыдущая глава |
↓ Содержание ↓
↑ Свернуть ↑
| Следующая глава |
хотя бы переставить можно...
Этот самый файл типа .html или лучше всётаки .xml это тоже если хотите
поток потоков... Или пакетов... Но вообще-то он — типа текстовый.
Текстовый файл можно считать потоком не байтов а строк. Тоже, как и пакет,
переменной длины. В разных ФС это организуется по-разному. Например в начале
каждой строки — её длина... Но чаще всего конец строки (и начало следущей)
указывается символом-разделителем строк. Который внутри строки не встречается.
(Вернее как встретился — значит это и есть конец строки.) В кодировках на
основе ASCII это команда ПС (перевод строки, он же 'n') или пара ВК ПС. И еще
текстовый файл по-возможности не содержит "слепых" (непечатных) символов — не
имеющих изображений. (Раньше не имевших — сейчас то картинки сопоставили всем.)
Но вот сейчас в винде вишь взяли моду делать строку размером с целый
абзац — что де программное обеспечение само разобьёт это на строки — по
размеру окна, который может запросто измениться в любой момент по прихоти
пользователя... Запустившие эту моду мелкомягкие недоумки вишь не знали, что
для этих целей на нулевой странице ASCII среди управляющих символов есть
специально для этого предназначенный символ-разделитель групп записей, ну или
абзацев текста. Или и знать не хотели, а хотели воспользоваться тем, что уже
есть — создали всем остальным проблему на ровном месте...
Файлы типа .html и .xml впринципе тоже текстовые, но только в том смысле,
что состоят из печатных символов. (А к разбиению на строчки там относятся
примерно так же, если не хуже.) Разбиение на что-то (вот на такие же "пакеты")
там с помощью своего рода скобок — "тегов". (Тег — "ярлык".) Именованных.
Открывающая и закрывающая скобки выглядит как <имя> и и между ними -
тело пакета, где может быть как текст, так среди него и такие-же вот скобочки.
Скобочки впринципе должны быть сбалансированы, но в .html с этим — бардак.
Потому что по исходному замыслу это команды форматирования текста. При чем в
виде скобок — только некоторые из них: типа выводить вот таким шрифтом не всё
нижеследующее (пока на другой шрифт не переключат), а только заключенное в оные
скобочки. За сим в .xml сделали: <имя/> — пакет без тела; скобка разом
открывающая и закрывающая. И придумали .xhtml — где бардака поменьше.
Внутри открывающей скобки (заголовка пакета) могут быть дополнительные
поля — тоже именованные. Вида: имя="значение".
У .xml все эти имена — какие сами выдумаем. И смысл у них такой, о котором
сами с собою договоримся. А вот у других файлов этого семейства — типа уже
договорились. В частности у .fb2 это элементы оформления книги: автор,
название, разные виды заголовков, деление на главы и абзацы... У .html это
команды управления просмотрщиком. Который сперва был совсем простеньким — умел
выводить текст разного вида, размера и цвета (например курсив: текст
(i потому что "итальянский")), но главное — умел переходить по ссылке:
текст_изображающий_ссылку (если конечно ткнуть в эту
ссылку мышкою) в результате чего и получается "гипертекст": несколько
связанных вот такими ссылками файлов. Лежащих как на одной машине, так и на
разных. И тогда этот не просто имя файла, а сетевой адрес. (Который тоже
"путь", но сначала по сети, а потом уже по тамошней файловой системе.)
А вот форматирование текста как изначально было дурацкое, так и осталось:
штатных средств сделать по-человечески — чтобы абзац начинался с красной
строки, а не отделялся пустой строкой от предыдущего, как небыло предусмотрено,
так нет и не предвидится. И приходится по-всякому выёживаться...
Ну и весь такой файл это один пакет: .... внутри которого
еще два — заголовок и тело. Оформленные вот таким же образом. В начале правда
еще иногда встречаются рудименты другого языка (известного как SGML, вот это:
— его скобочки, и коментарий вида: тоже его
наследство) куда более замудрённого и громоздкого, нигде и никогда так всерьёз
и не применявшегося. Однако с упорством, достойным лучшего применения, это таки
суют якобы для обратной совместимости...
Вопрос: а еще что-то типа вот таких ссылок у нас есть? А как же! Вон
каталоги, вернее файлы в них. Правда штука это — закрытая. Операционная
система работает с ними только сама — по заявкам "заинтересованных лиц"...
Доступ только по именам, а позиционирование — фиг! (Хотя это где как.) Но тем
не менее...
В общем не будем тянуть кота за хвост. Была вот такая идея: ввести еще
один канал ввода/вывода (типа для поиска файлов) направленный по умолчанию на
устройство "Д", изображающее собою текущий каталог. И ежели открыть что-то под
этим псевдонимом, то это и будет эквивалент команды !CD, каковая в ДОС`е
работает (потому что процесс — один общий для всех) а в UNIX`е не должна.
(Потому что для каждой выполняющейся программы процесс — свой. И есть места,
куда даже король ходит пешком.) Но открыть можно будет только файл с признаком
"d". (В точности так же, как на запись можно открыть только файл с признаком
"w", то есть разрешенный для записи. А переключить канал вывода, тоже
получится только на что-то открытое для записи...) Так что к R и W в
псевдониме открытого файла надо добавить еще буковку D.
Пользоваться этим каналом будут оператор Oper и функция FTEll("имя_файла")
Вернее — уже. В смысле, оказывается так оно и было всегда, изначально. Только
мы вот как-то внимания на это не обращали. А вот устройство Д... Да, таки надо
сделать — а то и в самом деле: как же с "cd" под UNIX`ом? (Но гром не грянет,
мужик не перекрестится! Пока вот как то и так обходились...)
((И, кстати, а вот открываем мы файл под псевдонимом Х, а на него как раз
УЖЕ направлен один из каналов, ну например вывода... И что-то я не припомню,
чтобы проверялось что файл открывается именно для вывода и что он вообще
разрешен на запись — чтобы иначе была ошибка...))
Вспомним, что в том же UNIX`е у каждого файла аттрибуты: -rwx (что их три
комплекта — пока несущественно) где вместо прочерка может быть a b c d... при
чем "а" (самый обычный файл) никогда не пишут, так и оставляют прочерк. Вот "d"
как раз и означает, что это каталог... А вот многие аналоги Нортон-Командера
позволяют "заходить" например в архивы типа .rar .zip ... как в каталоги...
Нечто типа каталога имеют в себе и файлы других типов (библиотеки подпрограмм
например). Тот же самый файл .wav содержащий внутри себя именованные потоки,
тоже бы подошел в этом качестве... И вообще любой файл, содержащий в себе
записи, имеющие два обязательных "выделенных" поля: "имя" — текстовое и
"поток" — либо встроенный поток, как у пакета, так и указатель на что-то
подобное.
Но это чисто на будущее...))
...Но таки надо отличать средства "разукрашивания" текста (ну ладно,
пусть "форматирования"), как тот же .html, где выкинь все эти урашательства и
останется чистый текст, который и есть главное содержимое... Отличать от
средств формирования структуры (как тот же .xml) — самоопределяющейся. Где
текст это всего лишь значения её полей. А главное — сама структура.
Хотя грамматика у них — вроде как практически одинаковая. И даже не
"вроде как" и не "практически" а один в один! Имена и смысл тегов разные...
Для форматирования текста есть еще масса других средств, начиная с
UNIX`овского roff (а так же производных от него nroff, troff...), изначально
сделанного чтобы управлять некоторой фотонаборной машиной. Про который я
смутно помню только что к уже имеющемуся форматированию он относился бережно,
и что каждая команда там занимала отдельную строку и начиналась с точки в
первой позиции. (Такая вот UNIX`овская заморочка, что мол ничего осмысленного
начинаться с точки не может. Там у них и в главном текстовом редакторе ed
(стареньком, маленьком и неудобном, за то работающем всегда — в том числе в
самых-самых тяжелых условиях, потому что с интерфейсом командной строки!)
поставить одинокую точку в начале строки — это выйти из режима набора текста в
командный.)
Это и дурацкий и-би-эм`овский формат .rtf — крайне примитивный (как и сам
аглицкий язык, что всегда вызывает непомерную сложность на следующем уровне),
отличающийся тем, что скобки там уже есть — фигурные. Типа для сохранения
контекста: всё что установлено в скобках, при выходе из них — отменяется.
И восстанавливается то, что было до. И еще там есть команды: слова,
начинающиеся с (обратной косой черты), и состоящие только из букв, потому что
дальше впритык идёт числовой аргумент (в том числе, говорят, что и
отрицательный, но я не видел), хотя может и отсутствовать. Еще эта самая
обратная косая черта служит там экранирующим символом (для себя и для скобок).
А вот всё остальное, что не скобки и не команды — сам текст.
Это и макрогенератор ТеХ (где букву Е традиционно пишут смещенной вниз на
пол строчки) и производные от него (типа LaTeX), который изначально придумал
лично Дональд Кнутт, когда захотел пристойно изображать в своих статьях
математические формулы. И там команды — тоже с символа
Это и уже упоминавшийся ПостСкрипт — вполне себе полноценный
алгоритмический язык, вернее его интерпретатор, каковой нынче встроен во все
лазёрные и струйные принтеры. (Мелкопроцессоры, ими управляющие, вишь стали
нынче весьма мощные.) А формат .pdf — суть программа на этом языке (немножко
урезанном).
Раньше-то всё было просто: разом и терминалом и принтером был телетайп
(разновидность электрической пишущей машинки), украденный на почте — там еще
на моей памяти с их помощью телеграммы передавали по четыре копейки за слово.
(А у одного мужика в командировке деньги кончились, так он послал жене
телеграмму из одного слова: "сторублируй"!)
В электрической пишущей машинке электрического только электромотор,
вращающий резиновый валик, около которого для каждого рычага-литероносителя
пристроилась такая полукруглая деталька... Которую, лёгким нажатием кнопки на
клавиатуре, слегка прижимает к этому валику. Дальше он её проворачивает, а она
тащит за собою этот рычаг. Который и ударяя по бумаге через красящую ленту,
оставляет на ней отпечаток литеры. (А то, боюсь, многие живую пишущую машинку
уже и не видели...) В механической пишущей машинке надо было колотить по
кнопкам со всей дури. При чем по разным — еще и с разной силою! Потому что
это усилие распределяется по площади литеры. И если А или Т напечатаются
нормально, Ж или Ш — бледно, то точка или запятая пробьют в бумаге дырочки!
(Ну бумага-то всё стерпит, но перед ней — красящая лента...)
Телетайп — это такая электрическая пишущая машинка, где на печатающий
механизм воздействуют не клавиши напрямую, а электромагнитики. А клавиатура
выдаёт им для этого коды нажатых кнопок. Которые можно пробить на перфоленту и
потом быстренько передать по линии связи (так обычно на почте и делали) или
посылать в линию связи сразу — чтобы их и удалённый телетайп отрабатывал...
А он либо печатает буковку, либо что-то делает — что умеет. Немногое: ПС, ВК,
ВШ, ГТ ЗВ (перевод строки — прокрутка на одну строку бумагоопорного валика,
возврат каретки, возврат на шаг, горизонтальная табуляция, звонок — реально
звякающий специательным колокольчиком)... Еще в нулевой странице ASCII (помним
еще, откуда она?) была пара команд то ли для установки и сброса табулостопа в
текущей позиции, то ли для переключения цвета (красящая лента нужна была
двухцветная!), которые потом приспособили для переключения регистров... А всё
остальное там — для оформления пакетов и управления коммутацией в телетайпетной
сети.
Далее, когда появились отдельно дисплеи (где маркер можно поставить в
любую точку экрана), и отдельно — принтеры, в том числе игольчатые, где можно
было изобразить что-то графическое, напрямую управляя отдельными иголками,
вспомнили про "эскейп-последовательности". На нулевой странице ASCII есть две
команды: АР1 и АР2 (она же ЕСЦ) — "авторегистр" 1 и 2 с кодами 10 и 27, первая
из которых — "экранирующая": отбирает "командный" смысл у следующего после
него кода, а вторая — наоборот: придаёт следующему после него коду специальный
смысл, позволяя учинять дополнительные команды. Сначала такие команды были
просты и немногочисленны. (Например как у VT-52 и его аналогов: в дополнение к
вышеперечисленным ПС, ВК, ВШ, ГТ, ЗВ, еще несколько штук: после EСЦ одна
буковка: A, B, C, D — перемещение маркера вверх, вниз, вправо, влево на одну
позицию; H, I, J, K — маркер в начало экрана; обратный перевод строки (как и
ПС, только на предыдущую строку, и если она крайняя — тоже с прокруткой
изображения); стереть от маркера до конца строки и экрана. Сложная — одна:
прямая адресация маркера: ЕСЦ Y и еще два байта — координаты, куда его
поставить. И последняя: ЕСЦ Z, на которую дисплей, если он есть, должен был
отозваться тремя байтами: ЕСЦ / Z.) Потом команды стали многочисленными,
сложными и навороченными. (Как у VT-100 и его аналогов.) У принтеров — тоже.
При чем кто-то придерживался неких стандартов де-факто, заимствуя систему
команд, например, у принтера фирмы Эпсон; кто-то придумывал свои собственные...
Но для более серьёзного полиграфического оборудования... А лазерный или
струйный принтер тоже уже можно причислить к этой категории... В общем, в
конце концов догадались, что чем передавать изображение по точкам, проще и
быстрее построить его на месте по куда более компактному описанию...
Уже упоминавшийся ПостСкрипт не спешит, как некоторые, рисовать указанные
ему графические примитивы... Сперва он строит абстрактный "путь" — траекторию,
добавляя эти самые примитивы к её концу. Возможно, замкнутую: там есть
специальная команда для её замыкания — соединения конца с началом. (Возможно,
это будут контуры буковки.) Которую, вместе с "листом", на коем она рисуется,
можно как хошь перенести, повернуть или отмасштабировать. И вот только потом
либо этот контур заливается указанным цветом, либо прорисовывается указанными
линиями (некоторой толщины, а то и пунктирности)...
Сам этот ПостСкрипт — вполне себе универсальный интерпретируемый язык
общего назначения. (Который, если что, как и Фокал, можно например использовать
в роли калькулятора.) Построен он на тех же принципах, что и язык Форт:
"стэкового" типа. (У нас так сделаны %r и %R в форматном выражении оператора
Write.) Всё с чем работаем — берётся со стека и что получилось — туда же
| Предыдущая глава |
↓ Содержание ↓
↑ Свернуть ↑
| Следующая глава |
