Emacs для начинающих
       

Ввод/вывод в системе UNIX и локализация.


   Когда-нибудь здесь будет небольшая статься о вводе/выводе в системе UNIX. :-) Пока же читатель может посмотреть кучу специальной литературы. Например :

Робачевский А.М.

"Операционная система Unix"

СПб. Издательство BHV

Санкт-Петербург, 1997

ISBN 5-7791-0057-8

 Andrei Robachevsky

Federal Centre RUNNet

e-mail:

phone: +7-812-2388598

fax: +7-812-2327622

    Здесь же кратко коснемся только проблем локализации ввода/вывода UNIX.

    Итак, цитируем :

    В UNIX существуют 6 типов файлов, различающихся по функциональному назначению и действиям операционной системы при выполнении тех или иных операций над файлами :

  • Обычный файл ( regular file )

  • Каталог ( directory )

  • Специальный файл устройства ( special device file )

  • FIFO или именованный канал ( named pipe )

  • Связь ( link )

  • Сокет

    Продолжаем цитировать :

    Обычный файл представляет собой наиболее общий тип файлов, содержащий данные в некотором формате. Для операционной системы такие файлы представляют собой просто последовательность байтов. Вся интерпретация содержимого файла производится прикладной программой, обрабатывающей файл. К этим файлам относятся текстовые файлы, бинарные файлы, исполняемые программы т.п.

    Из этого следует, что в общем случае   не существует никакого способа узнать не только кодировку, но даже тип

данных, содержащихся в файле.

    В принципе, существуют два основных способа определения содержимого файла (набора/потока данных) :

  • In-band - свединия о кодировке содержатся внутри

    файла

  • Out-band - сведения о кодироке содержатся снаружи, где-то в другом месте.

    •     Самый известный In-band способ - . Здесь кодировки и вид содержимого описываются явно, в полях Content-Type: text/plain; charset=koi8-r и Content-Transfer-Encoding: base64. Концепции MIME (описание типа) используются также в HTTP ().

        Также In-band сведения о содержимом и кодировках содержатся, например, в файлах Microsoft Word .DOC(с включенными OLE объектами), Windows .EXE и .DLL (ресурсы), e.t.c. К In-band методам можно отнести и разнообразные языки разметки (MARK-UP


    Languages), например тэг <LANG=> языка HTML 4.0 и XML или спецификацию языка в файлах .RTF.

        Теперь об Out-band (внешних) способах. К сожалению, в UNIX

    поддерживается простая однопотоковая концепция организации файла. Нет никаких ресурсных вилок, как в MacOS HFS, нет Meta Info как в OS/2 HPFS. Файл - это просто набор данных, имеющий имя (ну, еще даты создания/изменения/доступа, ну еще права доступа : rwxr-xr-x ). Без всяких "расширенных атрибутов".

        Проблема зашла так далеко, что в UNIX

    появилась специальная утилита file, которая "эвристическими методами" пытается определить тип содержимого.

        Единственный более-менее распространенным способом определения типа файла является расширение, то есть несколько конечных символов в имени

    файла после точки : ".txt". На самом деле, никакого стандарта на "расширения" в UNIX нет, так как точка : "." является допустимым символом имени. Так что вполне могут встретится имена типа "file.doc.tar.gz", "file............txt" или ".profile".

        Тем не менее, многие программы ориентируются именно на "расширения", особенно при переводе в MIME, например для простановки типа в HTTP ():



  • (/usr/local/etc/http/mime.types)


    • (sqiud-1.1.2x/include/mime.table)

  • (/usr/local/etc/lynx.cfg [SUFFIX])


    •     Насколько ненадежен этот метод, можно судить например по тому, что текстовый (!) файл "ls-lR.ftp.anu.edu.au" упорно интерпретируется как "audio/basic" и некоторые программы пытаются его "сыграть" ;-))

        Тем не менее, иногда этим можно пользоваться, например задавая определения типов (и многие другие атрибуты) для файлов текущего

    каталога, в файле ./.htaccess от apache

    ( модуль mod_mime ):

    AddType text/plain text

    AddEncoding    x-compress    Z

    AddIconByType        (TXT, icons/text.gif)         text/plain

    AddIconByEncoding  (COMP, icons/comp.gif) application/x-compress

    e.t.c.
    <


        Ну чем не Out-band метод ? Правда доступ к файлу в таком каталоге осуществлять придется только через HTTP от apache. ;-)

        Но продолжаем цитировать :

        Каталог: С помощью каталогов формируется логическое дерево файловой системы. Каталог - это файл, содержащий имена находящихся в нем файлов, а также указатели на дополнительную информацию - метаданные, позволяющие операционной системе производить операции над этими файлами. Каталоги определяют положение файла в дереве файловой системы, поскольку сам файл не содержит информации о своем местонахождении.
        Файл в файловой системе имеет некоторое имя - последовательность символов. Когда-то считалось, что имя файла может состоять только из 7-bit ASCII символов. В случае же использования национальных символов для имени файла возникают проблемы. И в стандарте POSIX решения нет.

    Существующие способы определения кодировки символов в имени файла :

  • Файловая система поддерживает UNICODE, например в UTF-8 или UCS-2 :


    • JOLIET


    • NTFS


    • EXT2FS (Linux)


    • Кодировка явно указывается (не POSIX

      ! ) :


      • При монтировании файловой системы :


        • Linux mount :

          $ mount -t vfat -o umask=002,noexec,gid=100,codepage=866,iocharset=koi8-r /dev/hdb1 /mnt


        • FreeBSD mount : /etc/fstab

          /dev/sd0s1        /dos/c   msdos    rw,-W=koi2dos,-L=ru_RU.KOI8-R  0  0

          детальное описание опций -W и -L смотрите в mount_msdos (8)


        • SAMBA :

          client code page = 866

          character set = koi8-r


        • ??


          •     Все операции, оперирующие с именами файлов должны быть как минимум прозрачны в отношении 8 бит.

              Специальный файл устройства обеспечивает доступ к физическому устройству. В UNIX различают символьные

          (character) и блочные (block) файлы устройств. Доступ к устройствам осуществляется путем открытия, чтения и записи в специальный файл устройства.
              Блочные файлы устройств позволяют организовать доступ к физическому устройству точно также, как доступ к обычному файлу. И точно также, как при работе с обычным файлом, интерпретация содержимого остается задачей программы. Никакой информации о кодировках содержимого не поддерживается.



              Более неприятна ситуация с симольными

          (character) устройствами, где также совершенно не существует определения character set. Другими словами, стандартными

          средствами UNIX (POSIX) невозможно ни определить

          текущую, ни установить необходимую кодироку символьного устройства (например, терминала).

              Стандартных средств изменения и определения кодировки нет ни для "настоящих" (подключенных через ASYNC-port) терминалов , ни для эмуляторов консоли (SCO, BSD или LINUX console), ни для окна xterm в X-Windows (работающих через псевдотерминалы /dev/pty). Понятий "кодировка"

          или "набор символов" нет ни в процедурах управления терминалом : termios (POSIX), ни в базах описания терминалов termcap и terminfo, ни даже в "высокоуровневых" библиотеках управления терминалом curses и ncurses. (TODO: посмотреть slang  ).

              Точно также, нет указателя Charset

          у потоков STDIN, STDOUT, STDERR.

          * ПРИМЕЧАНИЕ: В настоящее время наметилось несколько путей решения этой проблемы:

        • login class расширения BSD ( не POSIX

          ! )

             part 2.13

             (или то же самое, через Linux PAM)


        • CHARSET-параметр протокола telnet. .


        • Новые переменные termacp/terminfo,

          определяющие charset.


        • "Последовательности переключения" ISO-2022 у xterm


        • Реализация консоли с поддержкой UNICODE (в виде UTF-7, UTF-8). .


          •    FIFO или именованый канал - это файл, используемый для связи между процессами. FIFO впервые появились в System V UNIX, но большинство современных систем поддерживают этот механизм.
              Не вдаваясь в тонкости отличий System V и BSD, скажем о FIFO следующее :

        • Именованный канал имеет имя. Информацию о именах смотри в пункте .


        • Функционально FIFO весьма близок к .


          •    Связь. Особым типом файла является символическая связь, позволяющая косвенно адресовать файл. В отличии от жесткой связи, символическая связь адресует файл, который в свою очередь, ссылается на другой файл. В результате, последний файл адресуется символической связью косвенно. Данные файла, являющегося символической связью, содержат только имя целевого файла.
          <


              Собственно, на имя связи

          и на ее содержимое распространяются те же правила, что и на имя в .

            Сокет. Сокет представляет собой двусторонний канал обмена данными между процессами и является одним из механизмов IPC (Inter-Process Communication).
              Механизм сокетов был разработан для унификации межпроцессорного взаимодействия и должен был работать независимо от :

        • Реального механизма передачи информации (IP, IPX, X.25, e.t.c. )


        • Формата и схемы адресации (формата адресов) объектов


        • Сетевого или локального характера взаимодействия


          •     Для описания характеристик взаимодействия было введено понятие коммуникационный домен (communication domain). Сокеты создаются в рамках определенного коммуникационного домена, и, кроме прочих характеристик, имеют соответствующее имя

          (связываемое с сокетом при помощи вызова bind()

          ).

        • В коммуникационном домене AF_UNIX сокет связывается с определенным именем файла

          в файловой системе. Соответственно, на имя этого файла распространяются все правила именования в .


        • В коммуникационном домене AF_INET имена являются именами хостов Internet, на которые распространяются правила "Domain names - concepts and facilities".


        • В коммуникационном домене AF_NS (куда входят IPX/SPX) - ???.


          •     Не вдаваясь в подробности функционирования Socket API, рассмотрим лишь отношение сокетов и методов кодирования передаваемой информации.

              Сокеты (stream socket), после установления соединения предоставляют процессам чистый 8-ми битный канал обмена информацией (Out-Of-Band данные не рассматриваются). В принципе, пользователь может передавать данные в совершенно произвольном формате. Однако, существуют некоторые "устоявшиеся правила" организации протоколов обмена данными (IPC).

             1. Разделять управляющую информацию и пользовательские данные. Как сказано в "Srtings for humans, Protocols for computers".

              2. Текстовый



          управляющий протокол - это "правильная вещь". (c) Eric S. Raymond, разработчик . Для облегчения разработки и сопровождения протокола, управляющие команды и ответы сервера лучше сделать в виде текстовых строк.

             3. Хорошо разработанный протокол содержит в себе созможности Handshake

          (или Negotiation)

        • Language Negotiation, например, поля

              Accept-Language:

                  Content-Language:


        • Type & Charset Negotiation, например, поля

              Accept:

              Accept-Charset:

                  Content-Type: text/plain; charset=

                  Content-Type: text/html; charset=


        • Transfer Encoding Negotiation

                        Accept-Encoding:

                  Content-Transfer-Encoding:


          • См. например проекта .

          Если у вас имеются каие-либо дополнения или исправления, пишите

          --

          -=AV=-

          Содержание

          Last change : 11-01-2000



          Содержание раздела