LINUX-BG Адрес : http://www.linux-bg.org |
Монтиране на ядро 2.6 с опция utf |
От: Nick Angelow Публикувана на: 24-04-2024 Адрес на статията: http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=365058820 |
МОНТИРАНЕ НА ЯДРО 2.6
С ОПЦИЯ “utf” [1] http://unix.ginras.ru/linux/base004.html Владимир Попов
Преди всичко трябва да кажем, че предлаганият за обсъждане въпрос съвсем не е “подтема” на обсъждане на ядро 2.6. В рамките на последното може да се ограничим с изброяване на опциите за монтиране за различни файлови системи на “нивото” на 2.6, отбелязвайки само разликите с ядро 2.4. Но интерес представлява нещо друго: защо това е нужно и нужно ли въобще [2]? При това, както по отношение на монтирането на “чужди” файлови системи, така и за използването на utf въобще. Моето собствено отношение към този въпрос се формира, преди всичко, в хода на дискусията между разработчиците на movix-продукти (Movix, eMovix и MoviX2), от което следва, че обсъждането се отнася за:
Веднага ще кажа, че никога не съм бил привърженик на използването на native language [3] (в нашия случай – кирилица) в имената на дисковите дялове, директориите и файловете. Смятам това за глупост, подобна на изискването да се наричат лекарствата изключително на руски – на леля Петка така е по-удобно, продавачите и въобще търговците (само нови названия на аспирина измислят) към медицината и фармацевтиката нямат никакво отношение, а лекаря все едно е длъжен да използва стандартното (латинско), а не търговското име на лекарството [4]. Ако той е лекар, разбира се, а не същата тази леля Петка, но вече с диплома [5]. Обаче това са емоции. Реалността се състои в това, че:
Нека да добавим към това и интеграционните процеси в Европа и света. Изводът от това е очевиден за всички и то от доста време. ISO 10646 и Unicode се разработват от края на 80-те години и, за щастие на компютърната общественост, от 1991 г. са съгласувани. Това означава, че и принципите им, и таблиците им са съвместими. Нека го кажем така: толкова са съгласувани и съвместими, че даже и M$, традиционно вървяща по “свои” пътища (не толкова от оригиналност, колкото за търсене на възможност за получаване на патент за тях) съхранява дългите (по-дълги от 8+3) имена на файлове и директории в Unicode. При това на всички съвременни файлови системи fat, ntfs и CD (Joliet) Късите (8+3 – MS DOS формат) имена във файловите системи на M$ използват както преди 8-битови кодировки (cp1250, cp1251 etc), но това не ни вълнува, защото всяко такова име си име свой Unicode-двойник. По този начин, до сега за гореспоменатите файлови системи, опцията за монтиране iocharset=name означаваше, че при четене се декодират имената на монтираната файлова система от Unicode в кодировката name, а при запис се извършваше обратният процес – кодиране от name в Unicode. name може да бъде всяка една произволна кодировка от списъка с възможните в качество на аргумент на iocharset (вижте man mount и съдържанието на директорията Documentation/filesystems на дистрибуцията на ядрото. На последното, между другото, трябва да се обърне особено внимание – възможностите за монтиране се определят от ядрото, поради което документацията за mount традиционно “закъснява”). Този списък6 е доста голям, но само една от кодировките е “многоезична” и това е utf8. Само, че UTF-8 е реализация на ISO 10646-1/2000, който на свой ред, отговаря на Unicode 4.0, Тоест, прекодиране като че ли не е необходимо. И за какво ни трябва тогава iocharset? Правилно – не ни трябва. Което за новото ядро се изрази в появата на нова опция за монтиране – utf8 (за ntfs: nls=utf8). Отсега нататък, разделите vfat и btfs, а също и CD във формат ISO 9660 (ext. Joliet) и udf могат да се монтират еднакво за системи с различни native language. Всичко би било чудесно, ако приложението, което трябва да визуализира тези имена на файлове и директории в кодировка utf се справя добре със задачата. В средата X-Window такива са, трябва да кажем, повечето от приложенията, макар, че за съжаление, не всички. Файловите мениджъри на Gnome и KDE, а също и моят любим ROX се справят лесно, а толкова любимият window-manager Oroborus – не (в случая, когато се иска от него да покаже името на директорията като заглавие на прозорец). Достатъчно е да стартираме xfontsel и да изберем в него rgstry=iso 10646, за да се убедим, че по-голямата част от семействата шрифтове на по-голямата част от производителите в момента могат да използват utf8. Да създаваме само за проверка, файлове и директории с Japanese или Hebrew може би не си струва. А да се възползваме от файла със скучното заглавие quickbrown.txt от пакета на Маркус Кун (Markus Kuhn) ucs-fonts няма да е безинтересно – файлът съдържа фрагменти от текстове във всички възможни кодировки. Впечатляващо! При това използвах Edit от пакета Rox-Desktop и ми се иска да вярвам, че аналогичните средства за преглед и редакция от Gnome и KDE няма да бъдат по-лоши. Също така, нямаме основания да предполагаме, че файловите мениджъри, работещи със същите тези шрифтове, ще възпроизвеждат имената на файловете и директориите по-лошо, отколкото редакторите, възпроизвеждащи части от текст. Ситуацията в конзолата, по принцип е аналогична – само един шрифт за всички приложения. Основната трудност е, че конзолните шрифтове, “по дефиниция” не могат да включват в себе си повече от 256 (512) символа. И се получава парадокс – използваме кодировка utf, тоест една кодировка за множество езици, но реално разполагаме с набор само от 256 (512) символа, което явно не е достатъчно за “покриване” на цялото световно разнообразие. Грубо казано – това, че е необходимо да извадим символ от японската кодировка е очевидно, но то не означава, че в заредения шрифт този символ го има. И ето че се получава, че напълно очевидните предимства, при преход в конзола стават донякъде условни. До подобен извод се стигна и при обсъждането на използването на utf в конзолният клон на movix (MoviX). Ето и още няколко забележки, отнасящи се към обсъжданите въпроси:
Като заключение остава да отбележим двойката опции за монтиране на vfat и ntfs, която се появи след ядро 2.4. Това са опциите dmask и fmask. Лесно може да се сетим, че с тяхна помощ може да се задават отделно маски на флагове за директории и файлове. Преди можеше да маскираме бита executable само едновременно за файлове и директории. За файловете, това беше уместно – наличието на бит за изпълнимост на всеки файл от vfat или ntfs дял видимо дразнеше, а опита на произволен файлов мениджър да пусне файл за изпълнение вместо да изпълни действието според разширението му, както това е прието в M$, изглеждаше неприлично глупав. В същото това време, директориите ставаха “нечетими”. Сега вече, задавайки маска dmask=000 и fmask=0111, може да оставим и директориите дистъпни, и файловете – неизпълними.
превод: Nick Angelow
[1] Може би е по-добре заглавието на български да се чете като “Монтиране на файлови системи в ядро 2.6 с опция “utf””, защото в скромните ми познания не фигурира монтирането на ядро. [2] Явно авторът има предвид използването на опцията “utf” [3] Явно се има предвид родният език на потребителя [4] Явно авторът има предвид практиката в Русия. В България май е точно обратното – на рецептата лекарствата се изписват с тяхното търговско наименование. [5] Перифразирайки думите на академик Крилов, аз бих казал: потребител, даващ руски имена на файловете, заслужава разкъсване на четири на Дворцовия площад – (А.Ф.). [6] На възможните кодировки, които могат да бъдат аргумент на iocharset (н.а) << Инсталиране и настройка на VPN под SuSE 9,1 (9,0) | Настройване на звука и графичната среда при Slackware >> |
Авторите на сайта, както и техните сътрудници запазват авторските права върху собствените си материали публикувани тук,
но те са copyleft т.е. могат свободно да бъдат копирани и разпространявани с изискването изрично да се упоменава името на автора,
както и да се публикува на видно място, че те са взети от оригиналния им URL-адрес на този сървър (http://www.linux-bg.org). Авторските права на преводните материали принадлежат на техните автори. Ако с публикуването тук на някакъв материал неволно са нарушени нечии права - след констатирането на този факт материалът ще бъде свален.
All trademarks, logos and copyrights mentioned on this site are the property of their respective owners.
|