Samba ��� ������ ���������

Символы Unicode: о чём должен знать каждый разработчик

Если вы пишете международное приложение, использующее несколько языков, то вам нужно кое-что знать о кодировке. Она отвечает за то, как текст отображается на экране. Я вкратце расскажу об истории кодировки и о её стандартизации, а затем мы поговорим о её использовании. Затронем немного и теорию информатики.

Введение в кодировку

Компьютеры понимают лишь двоичные числа — нули и единицы, это их язык. Больше ничего. Одно число называется байтом, каждый байт состоит из восьми битов. То есть восемь нулей и единиц составляют один байт. Внутри компьютеров всё сводится к двоичности — языки программирования, движений мыши, нажатия клавиш и все слова на экране. Но если статья, которую вы читаете, раньше была набором нулей и единиц, то как двоичные числа превратились в текст? Давайте разберёмся.

Краткая история кодировки

На заре своего развития интернет был исключительно англоязычным. Его авторам и пользователям не нужно было заботиться о символах других языков, и все нужды полностью покрывала кодировка American Standard Code for Information Interchange (ASCII).

ASCII — это таблица сопоставления бинарных обозначений знакам алфавита. Когда компьютер получает такую запись:

то с помощью ASCII он преобразует её во фразу «Hello world».

Один байт (восемь бит) был достаточно велик, чтобы вместить в себя любую англоязычную букву, как и управляющие символы, часть из которых использовалась телепринтерами, так что в те годы они были полезны (сегодня уже не особо). К управляющим символам относился, например 7 (0111 в двоичном представлении), который заставлял компьютер издавать сигнал; 8 (1000 в двоичном представлении) — выводил последний напечатанный символ; или 12 (1100 в двоичном представлении) — стирал весь написанный на видеотерминале текст.

В те времена компьютеры считали 8 бит за один байт (так было не всегда), так что проблем не возникало. Мы могли хранить все управляющие символы, все числа и англоязычные буквы, и даже ещё оставалось место, поскольку один байт может кодировать 255 символов, а для ASCII нужно только 127. То есть неиспользованными оставалось ещё 128 позиций в кодировке.

Вот как выглядит таблица ASCII. Двоичными числами кодируются все строчные и прописные буквы от A до Z и числа от 0 до 9. Первые 32 позиции отведены для непечатаемых управляющих символов.

Проблемы с ASCII

Позиции со 128 по 255 были пустыми. Общественность задумалась, чем их заполнить. Но у всех были разные идеи. Американский национальный институт стандартов (American National Standards Institute, ANSI) формулирует стандарты для разных отраслей. Там утвердили позиции ASCII с 0 по 127. Их никто не оспаривал. Проблема была с остальными позициями.

Вот чем были заполнены позиции 128-255 в первых компьютерах IBM:

Какие-то загогулины, фоновые иконки, математические операторы и символы с диакретическим знаком вроде é. Но разработчики других компьютерных архитектур не поддержали инициативу. Всем хотелось внедрить свою собственную кодировку во второй половине ASCII.

Все эти различные концовки назвали кодовыми страницами.

Что такое кодовые страницы ASCII?

Здесь собрана коллекция из более чем 465 разных кодовых страниц! Существовали разные страницы даже в рамках какого-то одного языка, например, для греческого и китайского. Как можно было стандартизировать этот бардак? Или хотя бы заставить его работать между разными языками? Или между разными кодовыми страницами для одного языка? В языках, отличающихся от английского? У китайцев больше 100 000 иероглифов. ASCII даже не может всех их вместить, даже если бы решили отдать все пустые позиции под китайские символы.

Эта проблема даже получила название Mojibake (бнопня, кракозябры). Так говорят про искажённый текст, который получается при использовании некорректной кодировки. В переводе с японского mojibake означает «преобразование символов».

Пример бнопни (кракозябров).

Безумие какое-то.

Именно! Не было ни единого шанса надёжно преобразовывать данные. Интернет — это лишь монструозное соединение компьютеров по всему миру. Представьте, что все страны решили использовать собственные стандарты. Например, греческие компьютеры принимают только греческий язык, а английские отправляют только английский. Это как кричать в пустой пещере, тебя никто не услышит.

ASCII уже не удовлетворял жизненным требованиям. Для всемирного интернета нужно было создать что-то другое, либо пришлось бы иметь дело с сотнями кодовых страниц.

��� Если только ������ вы не хотели ��� бы ��� читать подобные параграфы. �֎֏0590֐��׀ׁׂ׃ׅׄ׆ׇ

Так появился Unicode

Unicode расшифровывают как Universal Coded Character Set (UCS), и у него есть официальное обозначение ISO/IEC 10646. Но обычно все используют название Unicode.

Этот стандарт помог решить проблемы, возникавшие из-за кодировки и кодовых страниц. Он содержит множество кодовых пунктов (кодовых точек), присвоенных символам из языков и культур со всего мира. То есть Unicode — это набор символов. С его помощью можно сопоставить некую абстракцию с буквой, на которую мы хотим ссылаться. И так сделано для каждого символа, даже египетских иероглифов.

Кто-то проделал огромную работу, сопоставляя каждый символ во всех языках с уникальными кодами. Вот как это выглядит:

Префикс U+ говорит о том, что это стандарт Unicode, а число — это результат преобразования двоичных чисел. Стандарт использует шестнадцатеричную нотацию, которая является упрощённым представлением двоичных чисел. Здесь вы можете ввести в поле что угодно и посмотреть, как это будет преобразовано в Unicode. А здесь можно полюбоваться на все 143 859 кодовых пунктов.

Уточню на всякий случай: речь идёт о большом словаре кодовых пунктов, присвоенных всевозможным символам. Это очень большой набор символов, не более того.

Осталось добавить последний ингредиент.

Unicode Transform Protocol (UTF)

UTF — протокол кодирования кодовых пунктов в Unicode. Он прописан в стандарте и позволяет кодировать любой кодовый пункт. Однако существуют разные типы UTF. Они различаются количеством байтов, используемых для кодировки одного пункта. В UTF-8 используется один байт на пункт, в UTF-16 — два байта, в UTF-32 — четыре байта.

Но если у нас есть три разные кодировки, то как узнать, какая из них применяется в конкретном файле? Для этого используют маркер последовательности байтов (Byte Order Mark, BOM), который ещё называют сигнатурой кодировки (Encoding Signature). BOM — это двухбайтный маркер в начале файл, который говорит о том, какая именно кодировка тут применена.

В интернете чаще всего используют UTF-8, она также прописана как предпочтительная в стандарте HTML5, так что уделю ей больше всего внимания.

Этот график построен в 2012-м, UTF-8 становилась доминирующей кодировкой. И всё ещё ею является.

Что такое UTF-8 и как она работает?

UTF-8 кодирует с помощью одного байта каждый кодовый пункт Unicode с 0 по 127 (как в ASCII). То есть если вы писали программу с использованием ASCII, а ваши пользователи применяют UTF-8, они не заметят ничего необычного. Всё будет работать как задумано. Обратите внимание, как это важно. Нам нужно было сохранить обратную совместимость с ASCII в ходе массового внедрения UTF-8. И эта кодировка ничего не ломает.

Как следует из названия, кодовый пункт состоит из 8 битов (один байт). В Unicode есть символы, которые занимают несколько байтов (вплоть до 6). Это называют переменной длиной. В разных языках удельное количество байтов разное. В английском — 1, европейские языки (с латинским алфавитом), иврит и арабский представлены с помощью двух байтов на кодовый пункт. Для китайского, японского, корейского и других азиатских языков используют по три байта.

Если нужно, чтобы символ занимал больше одного байта, то применяется битовая комбинация, обозначающая переход — он говорит о том, что символ продолжается в нескольких следующих байтах.

И теперь мы, как по волшебству, пришли к соглашению, как закодировать шумерскую клинопись (Хабр её не отображает), а также значки emoji!

Подытожив сказанное: сначала читаем BOM, чтобы определить версию кодировки, затем преобразуем файл в кодовые пункты Unicode, а потом выводим на экран символы из набора Unicode.

Напоследок про UTF

Коды являются ключами. Если я отправлю ошибочную кодировку, вы не сможете ничего прочесть. Не забывайте об этом при отправке и получении данных. В наших повседневных инструментах это часто абстрагировано, но нам, программистам, важно понимать, что происходит под капотом.

Как нам задавать кодировку? Поскольку HTML пишется на английском, и почти все кодировки прекрасно работают с английским, мы можем указать кодировку в начале раздела .

Важно сделать это в самом начале , поскольку парсинг HTML может начаться заново, если в данный момент используется неправильная кодировка. Также узнать версию кодировки можно из заголовка Content-Type HTTP-запроса/ответа.

Если HTML-документ не содержит упоминания кодировки, спецификация HTML5 предлагает такое интересное решение, как BOM-сниффинг. С его помощью мы по маркеру порядка байтов (BOM) можем определить используемую кодировку.

Это всё?

Unicode ещё не завершён. Как и в случае с любым стандартом, мы что-то добавляем, убираем, предлагаем новое. Никакие спецификации нельзя назвать «завершёнными». Обычно в год бывает 1-2 релиза, найти их описание можно здесь.

Если вы дочитали до конца, то вы молодцы. Предлагаю сделать домашнюю работу. Посмотрите, как могут ломаться сайты при использовании неправильной кодировки. Я воспользовался этим расширением для Google Chrome, поменял кодировку и попытался открывать разные страницы. Информация была совершенно нечитаемой. Попробуйте сами, как выглядит бнопня. Это поможет понять, насколько важна кодировка.

Заключение

При написании этой статьи я узнал о Майкле Эверсоне. С 1993 года он предложил больше 200 изменений в Unicode, добавил в стандарт тысячи символов. По состоянию на 2003 год он считался самым продуктивным участником. Он один очень сильно повлиял на облик Unicode. Майкл — один из тех, кто сделал интернет таким, каким мы его сегодня знаем. Очень впечатляет.

Надеюсь, мне удалось показать вам, для чего нужны кодировки, какие проблемы они решают, и что происходит при их сбоях.

Источник

Блог о системном администрировании. Статьи о Linux, Windows, СХД NetApp и виртуализации.

Доброго времени читатели и гости блога www.k-max.name. Сегодняшнюю статью хочу посвятить изучению пакета SAMBA и основ совместного использования разделяемых ресурсов в гетерогенных сетях Linux и Windows. Кроме сетевых протоколов Microsoft, используемых в samba, существуют так же протоколы NFS и NIS, разработанные Sun, которые так же поддерживаются продуктами Microsoft, но не получившие у последних большого распространения и удобны в использовании в сетях Linux и UNIX. Начнем с небольшой теории.

Основы взаимодействия Windows и Linux (протоколы и другие особенности)

В Linux для организации доступа к удаленной системе достаточно знать лишь IP адрес. Вместе с системой DNS, IP адресация представляет собой вполне законченный механизм взаимодействия между системами Linux. В Windows сложилась другая ситуация. Изначально, сети Windows находились в совершенно другом пространстве имен, это было следствием попытки организовать взаимодействие без участия протокола TCP/IP. Для чего был разработан родной для Windows протокол NetBEUI (Network Basic Extended Interface — основной расширенный сетевой пользовательский интерфейс). Не углубляясь в принципы сетевого взаимодействия можно сказать, что NetBEUI состоит из протокола SMB, транспортируемого по протоколу NetBIOS и обернутого в адресуемый протокол LLC, который является подуровнем канального уpовня. Из сказанной каши можно с трудом понять, что NetBEUI не принадлежит какому-либо из уровней модели OSI. В итоге, данный протокол получился не маршрутизируемым и малоэффективным.Через некоторое время, на основе NetBEUI был разработан протокол NetBIOS Frame (NBF) protocol (NetBIOS over IEEE 802.2 LLC). Следующим шагом была реализация NBT (NetBIOS over TCP/IP) .

Протокол NetBIOS (точнее SMB) обладает своим собственным пространством имен. Все имена могут иметь длину до 16 алфавитно-цифровых символов. При этом, использовать имена, начинающиеся с цифры не приемлемо для реализации протокола NetBIOS over TCP/IP, т.к. данное имя будет интерпретироваться как IP-адрес. В NetBIOS существует понятие Рабочая группа (в последствии замененное понятием домен). Компьютеры, имеющие одинаковое имя рабочей группы принадлежат одной группе.

NetBIOS over TCP/IP использует два основных протокола и два порта 139/tcp (порт службы сеанса NetBIOS) и 137/udp (порт сервера имен NetBIOS). Порт UDP используется для разрешения имен на основе широковещательных рассылок, что в большой сети порождает большой трафик. Чтобы уменьшить большой широковещательный трафик, необходимо использовать сервер имен NetBIOS (в Microsoft данный сервер получил название WINS — Windows Internet Naming Service). WINS для NetBIOS over TCP/IP это как DNS для TCP/IP.

С появлением Win2k и Active Directory, Microsoft полностью отказалась от NetBIOS. Вместо NetBIOS стал использоваться SMB через TCP/IP (без использования протокола NetBIOS, его же называют NetBIOS-less). Данный протокол позволял отказаться от WINS и резолвить имена с помощью DNS, используя связку системы безопасности Kerberos и службу каталогов Active Directory. Active Directory — это LDAP каталог (аналог OpenLDAP), которому я обязательно посвящу статью.

Чтобы SAMBA работала без поддкржки NetBIOS, необходимо, чтобы система была членом домена Active Directory. Если система НЕ член домена, то отключать поддержку NetBIOS не стоит!

Собственно, протокол SMB и дал начало названия проекта Samba. Через некоторое время SMB был переименован в CIFS (Common Internet File System). Samba версии 2 может использоваться только совместно с протоколом NetBT (NetBIOS over TCP/IP). Версия Samba 3 способна обеспечивать совместимость по протоколу SMB через TCP/IP (NetBIOS-less TCP/IP) и совместима с Active Directory. При использовании SMB через TCP/IP используется порт 445/tcp, а так же 135/tcp для обеспечения взаимодействия по протоколу DCE RPC (удаленные вызовы процедур).

При установке и настройке Samba (без членства в домене Active Directory) желательно использовать демон Samba как сервер WINS или как член сервера WINS для снижения нагрузки мультикаст трафика в сети.

Исходные данные (подготовка хостов для осуществления общего доступа)

Сначала я опишу возможность организации доступа к ресурсам на Windows (Сервер) со стороны Linux (Клиент). Для организации данного взаимодействия нам необходимо наличие соединения по протоколу TCP/IP между хостами (то есть присвоен корректный IP, заданы правильные маски, в каждой системе должен быть корректный файл hosts и правильно настроена служба ДНС, если таковая используется), а так же наличие расшаренного ресурса в системе Windows. В примере, машина Windows будет иметь IP 192.168.2.1 и имя host, Linux — 192.168.2.2 и имя samba. Рабочую группу будем использовать WORKGROUP. Ресурс в общем доступе будет называться share.

Пакет Samba для своей работы требует наличия модулей ядра и инструментов для доступа к удаленной системе. Прежде всего, должна быть поддержка файловых систем smbfs и cifs ядром Linux. Старые версии ядра — ниже 2.6.х может не поддерживать cifs в начальной комплектации компиляции. Хотя, по поводу поддержки smbfs в современных дистрибутивах можно поспорить, т.к. данный модуль устарел и не поддерживает символы кириллицы и . ну в общем я его рассматривать не буду ввиду устаревания. Для включения поддержки cifs в старые ядра 2.4 необходимо ознакомиться с документацией на сайте: http://linux-cifs.samba.org/. Новые версии ядра Linux 2.6 в большинстве дистрибутивов имеют встроенную поддержу cifs (если, конечно, ядро не самосборное). Убедиться в поддержке ядром — cifs можно, выполнив команду grep над файлом текущей конфигурации ядра:

Посмотрев на вышеприведенный код, хорошо видно, что текущее ядро не поддерживает SMB_FS (нам оно в принципе и не нужно), а вот cifs поддерживается в виде модуля (что, собственно, нас так же устраивает). Если в Вашем ядре нет поддержки CIFS, то необходимо будет его пересобрать с необходимым параметром. О том как это сделать, я описывал в статьях Ядро Linux (получение информации и управление) и Управление ядром Linux (сборка, компилирование, конфигурирование). Итак, мы убедились, что наше ядро поддерживает нужную файловую систему. Теперь нам необходимо установить саму SAMBA и кое-какие инструменты. Выбор того, каким способом устанавливать ПО в Linux оставляю Вам. Скажу лишь, что при установке из исходных текстов, получив их (исходники) с samba.org можно получить более новую версию, нежели при установке в бинарном виде из репозитория, в котором скорее всего будет более старая и проверенная версия. Я пошел по пути наименьшего сопротивления и установил SAMBA через пакетный менеджер (apt-get install samba). Так же, необходимо установить пакет smb-fs (без данного пакета я столкнулся с ошибкой CIFS VFS: cifs_mount failed w/return code = -22).

Мы начнем с самого простого примера и предположим, что DNS для разрешения имен не используется и машины имеют статичные IP-адреса. Поэтому нам необходимо в /etc/hosts добавить следующую строку:

Утилитой ping мы проверили возможность разрешения имени и связь с удаленным хостом Windows. И как можно понять — все работает.

Организация доступа к Windows с помощью клиента smbclient

В первую очередь, нам необходимо убедиться в том, может ли наш Linux взаимодействовать с Windows с помощью Samba. Самый простой способ, это воспользоваться FTP-подобным клиентом smbclient . C помощью которого, можно отправить запрос системе Windows и получить информацию о том, какие ресурсы Windows являются доступными.

Из листинга видно, как мы с помощью smbclient и параметра -L запросили список доступных ресурсов на машине host от имени анонимного пользователя (параметр -U%). В ответ Windows нам сказал, что Error returning browse list: NT_STATUS_ACCESS_DENIED, то есть анонимный доступ запрещен. Далее, мы попробовали подключиться к машине от имени пользователя Администратор с паролем 12345, который зарегистрирован в системе. Мы получили ответ со списком расшаренных ресурсов. Это не может не радовать. Давайте попробуем подключиться к шаре share:

Итак, в приведенном листинге нам удалось подключиться к шаре \\host\share от пользователя Администратор с паролем 12345. Мы получили содержимое каталога (причем русские символы прекрасно отображаются), перешли в подкаталог ime, получили его содержимое и получили на локальную машину файл SPTIP.dll, командой get (команда как и у FTP клиента). Вы, наверно, заметили, что в утилите smbclient путь к шаре указывается с прямым слешем, хотя в Windows принято задавать путь с обратным слешем. Утилита smbclient довольно гибка и используется как часть утилиты smbprint, для передачи потока данных, отправленных на принтер.

Организация доступа к Windows с помощью модулей ядра smbfs и cifsfs

Драйвер файловой системы smbfs по своему поведению напоминает утилиту smbclient. Он выполняет аутентификацию на основе предоставленного имени и пароля и устанавливает соединение с сервером SMB/CIFS, после этого подключает соединение с сервером SMB/CIFS к точке монтирования файловой системы. Права владения точкой монтирования устанавливаются в соответствии с пользователем и группой Linux, установившей соединение, а права доступа к файлам в точке монтирования устанавливаются на основании umask пользователя, установившего соединение.

Фактически, управление доступом ко всем файлам и каталогам переходит под управление Linux, а на сервере SMB/CIFS все обращения будут рассматриваться как операции, выполненные единственным пользователем. То есть все пользователи, работающие с файлами сервера в точке монтирования будут рассматриваться сервером SMB как единственный пользователь.

Драйвер SMBFS имеет существенное ограничение — не поддерживает Unicode, что может приводить к проблемам, если имена файлов или каталогов содержат символы НЕ английского алфавита. Данный драйвер стоит использовать только в крайних случаях, например когда не удалось завести cifs. Давайте проведем несколько практических действий с расшаренным каталогом:

Из примера можно увидеть, что мы зашли под пользователем mc-sim и посмотрели на его umask, который равен 0022, что соответствует правам доступа 755, то есть rwxr-xr-x, что мы далее и увидим. Далее, закрываем сессию пользователя и оказываемся в оболочке текущего пользователя и пытаемся подключить подмонтировать сетевой каталог от имени пользователя, umask которого узнали выше (т.е. — mc-sim). Думаю, что формат команды mount вам ясен из моей статьи о основных командах Linux, но все же опишу указанные параметры: -t smbfs указывает нам использовать тип файловой системы — SMBFS, далее указываем путь к шаре в виде: //хост/шара, далее точка монтирования в формате /точка/монтирования, далее параметры монтирования (после ключа -o) — имя пользователя и пароль на удаленной системе (username и password соответственно) с правами которого будет происходить обращение к удаленным каталогам, далее UID и GID локальных пользователей, права которых будут учитываться при чтении/записи в примонтированный каталог. После монтирования удаленного каталога, мы можем спокойно обращаться к файлам на удаленном хосте, как к локальным и производить все доступные операции с файлами, как с локальной файловой системой. В том числе, копирование/удаление/перемещение, естественно, учитывая права локального и удаленного пользователей.

Хочется так же отметить, что запуская mount -t smbfs, фактически мы запускаем команду /usr/bin/smbmount, которая является символьной ссылкой на /sbin/mount.smbfs. smbmount считывает параметры из конфигурационного файла smb.conf (обычно находится или в /etc/smb.conf или /etc/samba/smb.conf). Формат выполнения команды smbmount совпадает с mount -t smbfs. Для корректной работы SAMBA в виде подключающегося клиента, минимально достаточно файла со следующим содержимым:

Давайте рассмотрим более сложный пример монтирования расшаренного каталога:

В данном примере команда очень похожа на приведенную чуть выше, за исключением, нескольких дополнительных передаваемых параметров. Первое — это credentials=/etc/samba/pw — позволяет указать файл с идентификационными данными для подключения к удаленному ресурсу. Содержимое данного файла так же указано в примере. Другие два новых параметра — это указание маски прав доступа для файлов и директорий, соответственно, которые складываются с системной umask и применяются к содержимому в директории.

Давайте теперь поговорим о cifs. Формат команды с применением модуля cifsfs точно такой же, как и smbfs, за исключением того, что параметр smbfs заменяется на cifs, а имя пользователя указывается не username, а просто user. Итого, команда выглядит как: mount -t cifs //host/share /mnt -o user=User,password=,uid=mc-sim,gid=mc-sim. Так же стоит обратить внимание, что fmask и dmask считается устаревшим параметром и заменен на file_mode и dir_mode соответственно. Ну и команда, при использовании модуля cifsfs запускается не /sbin/mount.smbfs, а /sbin/mount.cifs

Чтобы монтировать SMB/CIFS — ресурсы автоматически при загрузке, необходимо проверить работоспособность монтирования с помощью вышеуказанных команд с необходимыми параметрами. Если тесты прошли удачно, то необходимо добавить строку в файл /etc/fstab примерно следующего содержания:

, где //хост/расшаренный_ресурс — UNC-путь к расшаренному ресурсу, /каталог/монтирования — точка монтирования (естественно, она должна существовать), файловая_система — указание файловой системы (на текущий момент, считаю, что актуальна только cifs), опции_монтирования — строка опций, которая передавалась команде mount -t cifs, после ключа -o.

Резюме

На этом, на сегодня закончу. В следующей части повествования о SAMBA расскажу о взаимодействии Windows как клиента и Linux в виде файлового сервера SAMBA. Подведу маленький итог всему вышенаписанному. В сегодняшней статье я постарался рассказать об основах взаимодействия гетерогенных сетей Linux и Windows, немного рассказал об истории появления протоколов NetBIOS и взаимодействие хостов в сети TCP/IP по данному протоколу. Постарался изложить принципы взаимодействия между Linux и Windows и показал на практике, как взаимодействуют указанные системы. А так же описал, каким образом подключиться к расшаренным ресурсам Windows из Linux и заставить ОС Linux монтировать сетевые каталоги Windows при загрузке. Всем спасибо за внимание. Жду комментариев и дополнений!

Источник