MAILCAP(5) File Formats Manual MAILCAP(5)

mailcap - پرونده قابلیت‌های قالب فرامرسوله

پرونده mailcap توسط برنامه metamail خوانده می‌شود تا نحوه نمایش داده‌های غیرمتنی در سامانه محلی مشخص گردد.

نحو پرونده mailcap بسیار ساده است، دست‌کم در مقایسه با پرونده‌های termcap. هر خطی که با «#» آغاز شود یک یادداشت (comment) است. خطوط خالی نادیده گرفته می‌شوند. در غیر این صورت، هر خط یک مدخل مجزای mailcap را برای یک نوع محتوا (content type) مشخص تعریف می‌کند. خطوط طولانی را می‌توان با قرار دادن نویسه اسلش وارو (\) در انتهای آن‌ها ادامه داد.

هر مدخل mailcap شامل مشخصات نوع محتوا (content-type)، دستور اجرایی، و (در صورت نیاز) مجموعه‌ای از مقادیر اختیاری پرچم (flag) است. برای نمونه، یک مدخل mailcap بسیار ساده (که در واقع رفتار پیش‌فرض درونی برای metamail است) بدین صورت خواهد بود:

text/plain; cat %s

پرچم‌های اختیاری می‌توانند برای تعیین اطلاعات اضافی در مورد دستور پردازش نامه استفاده شوند. برای نمونه:

text/plain; cat %s; copiousoutput

می‌تواند برای نشان دادن این موضوع به کار رود که خروجی دستور cat ممکن است پرحجم باشد و نیازمند یک پنجره قابل پیمایش، یک صفحه‌بندی‌کننده (pager)، یا سازوکار مناسب دیگری برای مدیریت آن باشد.

فیلد «type» (در مثال بالا text/plain) هر نام نوع محتوای معتبر تعریف‌شده بر اساس RFC 822 است. در عمل، این فیلد تقریباً می‌تواند هر رشته‌ای باشد. این رشته با سرآیند «Content-type» (یا مقدار ارائه‌شده با -c) تطبیق داده می‌شود تا مشخص شود آیا این مدخل mailcap با پیام فعلی همخوانی دارد یا خیر. افزون بر این، فیلد type می‌تواند یک زیرنوع (مانند «text/ISO-8859-1») یا یک نویسه عام (wildcard) برای تطبیق تمام زیرنوع‌ها (مانند «image/*») تعیین کند.

فیلد «command» هر دستور یونیکس است («cat %s» در مثال بالا) و برای تعیین مفسر نوع داده پیام به کار می‌رود. این دستور از طریق فراخوانی (3)system به شل ارسال خواهد شد. نقطه‌ویرگول‌ها (semicolons) و اسلش‌های وارو (backslashes) درون دستور باید با نویسه اسلش وارو کوت (quote) شوند. اگر دستور حاوی «%s» باشد، این دو نویسه با نام پرونده‌ای که بدنه پیام در آن قرار دارد جایگزین می‌شوند. اگر حاوی «%t» باشد، با فیلد content-type شامل زیرنوع (در صورت وجود) جایگزین خواهد شد. (یعنی اگر content-type برابر «image/pbm; opt1=something-else» باشد، «%t» با «image/pbm» جایگزین می‌شود). اگر فیلد دستور حاوی «%{» و به دنبال آن یک نام پارامتر و «}» باشد، تمام آن نویسه‌ها با مقدار پارامتر نام‌برده از سرآیند Content-type جایگزین خواهند شد. بنابراین، در مثال قبلی، «%{opt1}» با «something-else» جایگزین می‌شود. در نهایت، اگر دستور حاوی «\%» باشد، این دو نویسه با یک نویسه % تنها جایگزین خواهند شد. (در واقع، اسلش وارو می‌تواند برای کوت کردن هر نویسه‌ای، از جمله خود آن، استفاده شود).

اگر هیچ «%s» در فیلد دستور ظاهر نشود، metamail به جای قرار دادن بدنه پیام در یک پرونده موقت، بدنه را از طریق ورودی استاندارد (standard input) به دستور ارسال می‌کند. این کار به صرفه‌جویی در فضای پرونده‌های /tmp کمک می‌کند، اما ممکن است برای برنامه‌های مبتنی بر پنجره در برخی محیط‌های گرافیکی مانند MGR مشکل‌ساز شود.

دو کد ویژه می‌توانند در دستور مشاهده برای اشیایی از نوع multipart (با هر زیرنوعی) ظاهر شوند: «%n» و «%F». کد %n با تعداد بخش‌های درون شیء multipart جایگزین می‌شود. کد %F با مجموعه‌ای از آرگومان‌ها جایگزین می‌شود (دو آرگومان برای هر بخش) که اولی نوع محتوا (content-type) و دومی نام پرونده موقتی را مشخص می‌کند که بخش رمزگشایی‌شده در آن ذخیره شده است. علاوه بر این، به ازای هر پرونده ایجادشده توسط %F، پرونده دومی نیز با همان نام و به دنبال آن حرف «H» ایجاد می‌شود که حاوی اطلاعات سرآیند آن بخش از بدنه پیام است. این ویژگی برای بیشتر پردازنده‌های multipart لازم نخواهد بود، اما در صورت نیاز در دسترس است.

فیلد «notes=xxx» یک رشته تفسیرنشده است که برای تعیین نام شخصی که این مدخل را در پرونده mailcap نصب کرده به کار می‌رود. (می‌توان «xxx» را با هر رشته متنی جایگزین کرد).

فیلد «test=xxx» دستوری است که اجرا می‌شود تا مشخص کند آیا خط mailcap مربوطه اعمال می‌شود یا خیر. یعنی اگر فیلد content-type با نوع محتوای پیام مطابقت داشته باشد، اما فیلد «=test» وجود داشته باشد، این آزمون باید با موفقیت به پایان برسد تا خط mailcap با پیام مورد مشاهده مطابقت داده شود. این دستور می‌تواند هر دستور یونیکس با همان نحو و همان گریزهای % (مانند دستور مشاهده که در بالا شرح داده شد) باشد. اگر دستور با وضعیت خروج صفر پایان یابد موفقیت‌آمیز در نظر گرفته می‌شود و در غیر این صورت ناموفق تلقی می‌گردد.

فیلد «print=xxx» دستوری است که به جای نمایش تعاملی داده‌ها، برای چاپ آن‌ها اجرا می‌شود. این رفتار معمولاً نتیجه فراخوانی metamail با سوییچ «-h» است.

فیلد «textualnewlines» می‌تواند در موارد خاصی به کار رود که قواعد پیش‌فرض metamail برای پردازش خطوط جدید در داده‌های کدگذاری‌شده با base64 رضایت‌بخش نیست. به‌طور پیش‌فرض، اگر نوع محتوا «text» (با هر زیرنوعی) باشد، metamail نویسه‌های CRLF را در خروجی رمزگشایی‌شده base64 به نویسه خط جدید محلی تبدیل می‌کند، اما در غیر این صورت این کار را انجام نمی‌دهد. مدخل mailcap با فیلد «textualnewlines=1» این تبدیل را برای نوع محتوای مشخص‌شده اجباری می‌کند، در حالی که «textualnewlines=0» تضمین می‌کند که این تبدیل حتی برای انواع محتوای متنی نیز انجام نشود.

فیلد «compose» ممکن است برای تعیین برنامه‌ای استفاده شود که قادر به ایجاد یک بدنه جدید یا بخشی از بدنه در قالب مشخص‌شده باشد. هدف از آن پشتیبانی از برنامه‌های ایجاد نامه است که از ساخت انواع گوناگون پیام با استفاده از برنامه‌های بیرونی پشتیبانی می‌کنند. مانند دستور مشاهده، دستور compose نیز پس از جایگزینی دنباله‌های گریز خاصی که با «%» آغاز می‌شوند اجرا خواهد شد. به‌ویژه، %s باید با نام پرونده‌ای که داده‌های ایجادشده توسط برنامه تعیین‌شده باید در آن نوشته شوند جایگزین شود؛ این امر به برنامه فراخوان (مانند metamail) اجازه می‌دهد به برنامه فراخوانده‌شده اطلاع دهد که داده‌های ایجادشده را در کجا ذخیره کند. اگر %s ظاهر نشود، فرض می‌شود که داده‌های ایجادشده توسط برنامه‌های ایجادکننده در خروجی استاندارد نوشته می‌شوند. نتیجه برنامه سازنده ممکن است داده‌هایی باشد که هنوز برای انتقال نامه مناسب نیستند؛ به این معنی که ممکن است همچنان نیاز باشد Content-Transfer-Encoding روی داده‌ها اعمال شود.

فیلد «composetyped» مشابه فیلد «compose» است، اما زمانی استفاده می‌شود که برنامه سازنده نیاز دارد فیلد سرآیند Content-type را برای اعمال روی داده‌های ایجادشده مشخص کند. فیلد «compose» ساده‌تر است و برای استفاده در برنامه‌های موجود (غیرمرتبط با ایمیل) جهت ساخت داده در یک قالب مشخص ترجیح داده می‌شود. فیلد «composetyped» زمانی ضروری است که اطلاعات Content-type باید شامل پارامترهای کمکی باشد، و برنامه ایجادکننده باید به اندازه کافی از قالب‌های ایمیل آگاهی داشته باشد تا خروجی حاوی اطلاعات نوع پیام تولید کند و هرگونه Content-Transfer-Encoding لازم را اعمال نماید. از نظر مفهومی، «compose» برنامه‌ای را مشخص می‌کند که صرفاً داده‌های نوع مشخص‌شده را به شکل خام خارج می‌کند، در حالی که «composetyped» برنامه‌ای را تعیین می‌کند که داده‌ها را به عنوان یک شیء MIME، همراه با تمام سرآیندهای لازم Content-* در جای خود تولید می‌کند.

اگر این پرچم داده شود، مفسر نام‌برده باید از طریق ترمینال با کاربر تعامل داشته باشد. در برخی محیط‌ها (مانند یک برنامه‌خوان نامه پنجره‌ای تحت X11) این کار نیازمند ایجاد یک پنجره شبیه‌ساز ترمینال جدید است، در حالی که در بیشتر محیط‌ها چنین نیازی نیست. اگر مدخل mailcap پرچم «needsterminal» را مشخص کند و metamail در یک ترمینال در حال اجرا نباشد (همان‌طور که توسط (3)isatty، گزینه -x و متغیر محیطی MM_NOTTTY تعیین می‌شود)، metamail تلاش خواهد کرد تا دستور را در یک پنجره شبیه‌ساز ترمینال جدید اجرا کند. در حال حاضر، metamail نحوه ایجاد پنجره‌های جدید را در سیستم‌های پنجره X11، SunTools و WM می‌داند.
این پرچم باید هر زمان که مفسر قادر به تولید بیش از چند خط خروجی در stdout باشد و هیچ تعاملی با کاربر نداشته باشد مشخص شود. اگر مدخل mailcap پرچم copiousoutput را تعیین کرده باشد و صفحه‌بندی از طریق دستور «-p» درخواست شده باشد، خروجی دستور در حال اجرا از طریق یک برنامه صفحه‌بندی (پیش‌فرض «more»، اما قابل بازنویسی با متغیر محیطی METAMAIL_PAGER) هدایت خواهد شد.

برنامه metamail از چند نوع محتوای کلیدی به‌صورت درونی پشتیبانی می‌کند. به‌طور خاص، از نوع text، نوع multipart و multipart/alternative، و انواع message/rfc822 پشتیبانی می‌کند. این پشتیبانی برای بسیاری از زیرنوع‌ها ناقص است؛ برای نمونه، به‌طور کلی تنها از متن US-ASCII پشتیبانی می‌کند. این نوع پشتیبانی درونی می‌تواند توسط مدخلی در هر پرونده mailcap موجود در مسیر جستجوی کاربر لغو (OVERRIDDEN) شود. همچنین metamail پشتیبانی ابتدایی درونی برای انواعی که کاملاً ناشناخته هستند (یعنی هیچ مدخل mailcap یا گرداننده درونی برای آن‌ها وجود ندارد) ارائه می‌دهد. برای چنین انواع ناشناخته‌ای، metamail پرونده‌ای با نسخه‌ای «پاک» از داده‌ها می‌نویسد؛ یعنی نسخه‌ای که تمام سرآیندهای ایمیل در آن حذف شده‌اند و هرگونه کدگذاری انتقال 7 بیتی در آن رمزگشایی شده است.

$HOME/.mailcap:/etc/mailcap:/usr/etc/mailcap:/usr/local/etc/mailcap

- مسیر پیش‌فرض برای پرونده‌های mailcap.

metamail(1)

Copyright (c) 1991 Bell Communications Research, Inc. (Bellcore)

مجوز استفاده، کپی، تغییر و توزیع این مطالب برای هر مقصودی و بدون پرداخت هزینه بدین‌وسیله اعطا می‌شود، مشروط بر این‌که اعلان حق نشر فوق و این مجوز در تمامی نسخه‌ها درج شود و نام Bellcore در تبلیغات یا آگهی‌های مرتبط با این مطالب بدون مجوز کتبی، قبلی و خاص نماینده مجاز Bellcore استفاده نشود. BELLCORE هیچ‌گونه مسئولیتی در مورد دقت یا مناسب بودن این مطالب برای هر مقصودی بر عهده نمی‌گیرد. این مطالب «همان‌طور که هست» و بدون هیچ‌گونه ضمانت صریح یا ضمنی ارائه می‌شود.

Nathaniel S. Borenstein

Release 2 Bellcore Prototype