Владимир Попов

Преди всичко трябва да кажем, че предлаганият за обсъждане въпрос съвсем не е “подтема” на обсъждане на ядро 2.6. В рамките на последното може да се ограничим с изброяване на опциите за монтиране за различни файлови системи на “нивото” на 2.6, отбелязвайки само разликите с ядро 2.4. Но интерес представлява нещо друго: защо това е нужно и нужно ли въобще [2]? При това, както по отношение на монтирането на “чужди” файлови системи, така и за използването на utf въобще.

Моето собствено отношение към този въпрос се формира, преди всичко, в хода на дискусията между разработчиците на movix-продукти (Movix, eMovix и MoviX2), от което следва, че обсъждането се отнася за:

• преди всичко за video- и mp3-CD;

• както за възпроизвеждането, така и за записа на мултимедийни дискове (eMovix);

• както за конзолни, така и за графични приложения (MoviX2).

Веднага ще кажа, че никога не съм бил привърженик на използването на native language [3] (в нашия случай – кирилица) в имената на дисковите дялове, директориите и файловете. Смятам това за глупост, подобна на изискването да се наричат лекарствата изключително на руски – на леля Петка така е по-удобно, продавачите и въобще търговците (само нови названия на аспирина измислят) към медицината и фармацевтиката нямат никакво отношение, а лекаря все едно е длъжен да използва стандартното (латинско), а не търговското име на лекарството [4]. Ако той е лекар, разбира се, а не същата тази леля Петка, но вече с диплома [5].

Обаче това са емоции. Реалността се състои в това, че:

• мултимедийните дискове са стока с голямо търсене и родният език (native language) присъства върху тях с такава неизбежност, както и в названията на лекарствата;

• Усилията на M$, насочени към потребителите на IBM PC, така са засегнали повечето потребители, че в крайна сметка, за част от тях никакъв друг език, освен родният не е достъпен. За да бъда честен трябва да добавя, че тази част от населението не е наясно и с родният си език, но това вече не е наша работа.

Нека да добавим към това и интеграционните процеси в Европа и света. Изводът от това е очевиден за всички и то от доста време. 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).

Ето и още няколко забележки, отнасящи се към обсъжданите въпроси:

• опцията за монтиране codepage=name всъщност е необходима само за правилното изобразяване на имената във формат 8+3. Често е необходима, тъй като все още често се срещат дялове, създадени изключително под MS DOS;

• досадно обстоятелство за CD е ограничаването на дължината на имената на файловете до 64 символа, известно като Microsoft Joliet Specification. mkisofs наистина има опция -joliet-long, повдигаща летвата до 103 символа, но това за съжаление си остава “вътрешна работа” на mkisofs;

• Интересно, че отбелязаното по-горе ограничение се преодолява лесно при използване на ISO 9660 RockRidge разширение. Жалко само, че преобладаващите в света Windows-компютри не могат да четат таблицата на файловете на RockRidge.

Като заключение остава да отбележим двойката опции за монтиране на 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 >>