Dorehami · فرهنگ‌های ایران · یادگیری خانوادگی

ذخیره برنامه در تقویم؛ فایل کوچک با اثر واقعی

راهنمای فارسی فایل تقویم ICS؛ رویداد تأییدشده، منطقه زمانی، تاریخ پایان، نشانی خصوصی، به‌روزرسانی، لغو، امنیت و دسترس‌پذیری.

این صفحه رویداد، تاریخ، ساعت، مکان، ظرفیت یا فایل ICS واقعی دورهمی اعلام نمی‌کند و دکمه دانلود فعال ندارد. هر فایل آینده باید فقط از داده تأییدشده و مجاز ساخته شود.

فایل تقویم یادآور است، نه منبع نهایی حقیقت

فایل با پسوند ICS می‌تواند عنوان، آغاز، پایان، توضیح و مکان یک رویداد را میان برنامه‌های تقویم جابه‌جا کند. استاندارد RFC 5545 قالب iCalendar را مستقل از یک سرویس خاص تعریف می‌کند، اما واردکردن فایل به معنی ثبت‌نام، رزرو صندلی، پرداخت یا تضمین برگزاری نیست. صفحه اصلی رویداد باید منبع نهایی وضعیت، تغییر و لغو بماند و فایل تقویم به آن پیوند دهد. فقط برنامه واقعی و تأییدشده باید فایل داشته باشد؛ ساخت نمونه با تاریخ، مکان یا میزبان خیالی می‌تواند کاربر را به حرکت یا هزینه اشتباه بیندازد. عنوان باید روشن و کوتاه باشد و از واژه «تأییدشده» فقط وقتی فرایند واقعی آن را پشتیبانی می‌کند استفاده شود. این صفحه هیچ رویدادی را معرفی نمی‌کند و فایل دانلودی نمی‌سازد. هدف آن تعیین حداقل داده و کنترل‌های لازم پیش از افزودن قابلیت واقعی است. کاربر باید پس از واردکردن نیز اطلاعات را ببیند و بتواند در صورت تردید فایل را حذف کند.

هر فیلد باید از رکورد معتبر و یک مسئول مشخص بیاید

شناسه یکتا، مهر زمان تولید، عنوان، آغاز و پایان، وضعیت، توضیح، پیوند و مکان هرکدام باید منبع و مسئول داشته باشند. شناسه یکتا برای تشخیص نسخه‌های همان رویداد است و نباید ایمیل خصوصی یا شناسه عضو را در خود آشکار کند. توضیح کوتاه باید قواعد اصلی و لینک منبع را بگوید، نه اینکه داده حساس یا متن طولانی HTML در فایل پنهان کند. مکان می‌تواند نام عمومی محل باشد؛ نشانی خانه یا کد ورود نباید در فایل عمومی قرار گیرد. اطلاعات تماس فقط کانال سازمانی و مجاز است. فیلد برگزارکننده یا شرکت‌کننده پیامد حریم و ارسال دارد و برای یک فایل انتشار عمومی غالباً لازم نیست. پیوست، آلارم و تکرار خودکار نیز فقط با ضرورت واقعی اضافه می‌شوند. داده از رکورد رویداد تأییدشده استخراج و با آن مقایسه می‌شود؛ تایپ دوباره دستی منبع خطاست. اگر یک مورد معلوم نیست، حذف یا عبارت روشن بهتر از حدس است. این راهنما هیچ شناسه، نشانی یا تماس واقعی تولید نمی‌کند.

منطقه زمانی و تغییر ساعت تابستانی بخشی از خود رویدادند

ساعت «۱۸» بدون منطقه زمانی برای مخاطب مهاجر یا سفرکننده کافی نیست. زمان باید با منطقه معتبر مانند Europe/Stockholm یا با UTC و تبدیل درست ثبت شود. RFC 5545 برای توصیف منطقه و تغییرهای استاندارد و تابستانی سازوکار VTIMEZONE دارد؛ نوشتن اختلاف ثابت +01:00 برای همه سال می‌تواند در دوره ساعت تابستانی خطا بسازد. تاریخ‌های تمام‌روز نیز با رویداد ساعتی فرق دارند و پایانشان در iCalendar معمولاً حدّ غیرشامل است؛ بنابراین یک جشن یک‌روزه نباید ناخواسته دو روز دیده شود. آغاز و پایان باید منطقی باشند و برنامه عبور از نیمه‌شب تاریخ درست داشته باشد. ساعت نمایش صفحه، فایل و منطقه محل باید با آزمون مرزی پیش و پس از تغییر ساعت مقایسه شوند. تقویم فارسی یا نام ماه فرهنگی می‌تواند در متن توضیح بیاید، اما مقدار فنی باید طبق استاندارد باشد. کاربر باید منطقه را به زبان روشن نیز ببیند. این صفحه هیچ ساعت واقعی دورهمی را تعیین نمی‌کند.

تقویم می‌تواند اطلاعات خصوصی را بی‌صدا همگام و پشتیبان‌گیری کند

وقتی فایل وارد تقویم ابری می‌شود، عنوان، توضیح و مکان ممکن است روی چند دستگاه، اعلان صفحه قفل، ساعت هوشمند، پشتیبان و تقویم مشترک ظاهر شوند. بنابراین نشانی خانه، کد در، نام کودک، فهرست مهمان، آلرژی یا توضیح امنیتی در فایل عمومی قرار نمی‌گیرند. برای برنامه خصوصی، فایل می‌تواند فقط نام خنثی و زمان داشته باشد و جزئیات حساس از کانال محدود و نزدیک زمان برنامه برسد. پیوند دارای توکن نیز ممکن است از تاریخچه یا اشتراک تقویم نشت کند و باید عمر، دامنه و امکان لغو داشته باشد. افزودن دعوت‌شونده به ATTENDEE یا ارسال ایمیل تقویمی پردازش داده جداست؛ فایل دانلود عمومی به آن نیاز ندارد. کاربر باید بداند فایل چه داده‌ای دارد پیش از واردکردن آن. حذف از سایت، نسخه ذخیره‌شده در تقویم کاربر را خودکار پاک نمی‌کند. این صفحه هیچ نام، ایمیل، نشانی یا شناسه خصوصی دریافت نمی‌کند و تصاویرش دعوت واقعی نیستند.

محتوای ICS متن ساختاریافته است و باید در برابر تزریق و لینک ناسالم مقاوم باشد

عنوان یا توضیح کاربرنباید بدون پاک‌سازی وارد خطوط تقویم شود. خط جدید، جداکننده، کاراکتر کنترلی و طول غیرعادی ممکن است ساختار فایل را تغییر دهد یا فیلد ناخواسته بسازد. مقادیر باید طبق RFC escape و خطوط بلند درست تا شوند؛ خروجی با MIME مناسب text/calendar و نام فایل ایمن ارائه شود. لینک فقط به دامنه مورد انتظار و HTTPS می‌رود و هیچ اسکریپت یا HTML اجرایی داخل توضیح لازم نیست. فایل از ورودی تأییدشده سمت سرور تولید می‌شود، نه پارامتر خام نشانی. شناسه و نسخه نباید کلید یا مسیر داخلی را افشا کنند. آزمون باید نویسه فارسی، ویرگول، نقطه‌ویرگول، بک‌اسلش، خط جدید و نام بسیار بلند را پوشش دهد. دریافت‌کننده نیز باید منبع فایل را بشناسد و واردکردن فایل ناشناس را مانند بازکردن پیوست بررسی کند. قابلیت فعلی پروژه فقط پس از آزمون میزبان و بازبینی امنیتی می‌تواند عمومی شود. این صفحه فایل یا پیوند دانلود واقعی ارائه نمی‌کند.

نسخه تازه باید همان رویداد را اصلاح کند، نه نسخه‌ای مبهم بسازد

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

لغو باید در صفحه، فایل و کانال مجاز هماهنگ شود

حذف آرام فایل باعث نمی‌شود رویداد از تقویم واردشده ناپدید شود. رکورد لغو باید وضعیت روشن داشته باشد و صفحه مقصد در بالای محتوا، تاریخ و زمان لغو را بیان کند. اگر روش به‌روزرسانی تقویم از STATUS:CANCELLED پشتیبانی می‌کند، باید با همان شناسه و قواعد استاندارد آزموده شود؛ در غیر این صورت پیام مستقیم و روشن لازم است. علت خصوصی، بیماری فرد یا جزئیات خانوادگی نباید برای توجیه لغو منتشر شود. بازپرداخت یا رزرو، اگر وجود داشته باشد، فرایند جدا و واقعی است و فایل تقویم آن را انجام نمی‌دهد. کاربر باید تشویق شود پیش از حرکت منبع نهایی را بررسی کند. فایل لغوشده نباید دوباره از کش یا لینک قدیمی به‌عنوان فعال عرضه شود. زمان ارسال اصلاح و گیرندگان ثبت می‌شوند، اما آمار خیالی ساخته نمی‌شود. این صفحه هیچ لغو یا برنامه‌ای اعلام نمی‌کند و تنها طراحی مسئولانه برای آینده را توضیح می‌دهد.

دکمه و اطلاعات تقویم باید بدون وابستگی به یک برنامه قابل فهم باشند

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

پیش از انتشار، فایل در مرزهای واقعی آزموده می‌شود

چک‌لیست شامل اعتبار نحوی RFC، نویسه فارسی، آغاز و پایان، رویداد تمام‌روز، عبور از نیمه‌شب، ساعت تابستانی، لغو، به‌روزرسانی، تکرار، لینک، متن طولانی و escape است. فایل در چند برنامه رایج بدون ورود به حساب واقعی آزمایش و خروجی پس از واردکردن با رکورد منبع مقایسه می‌شود. آزمون حریم بررسی می‌کند هیچ ایمیل، نشانی خصوصی، توکن پایدار یا داده کودک وارد نشده باشد. آزمون دسترس‌پذیری صفحه و مسیر افزودن دستی انجام می‌شود. خطای 404، MIME، نام فایل و cache نیز بررسی می‌شوند. رفتار موبایل و دسکتاپ ممکن است متفاوت باشد و باید با دستگاه واقعی کنترل شود. نتیجه آزمون تاریخ، نسخه و محدودیت دارد؛ «در یک برنامه باز شد» معادل سازگاری کامل نیست. انتشار فقط پس از وجود رویداد تأییدشده و مجوز نیما ممکن است. این صفحه نمونه فنی دانلودشدنی تولید نمی‌کند و هیچ رویداد یا زمان ساختگی را برای عبور صوری از آزمون وارد نمی‌سازد.

کارگاه کاغذیِ ممیزی یک فایل تقویم خیالی

  1. یک رویداد کاملاً خیالی و بی‌نام بسازید و منبع نهایی اطلاعات را مشخص کنید.
  2. عنوان، آغاز، پایان، منطقه زمانی و پیوند عمومی را روی کارت جدا بنویسید.
  3. هر نشانی، ایمیل، نام کودک یا داده غیرضروری را از کارت حذف کنید.
  4. سناریوی تغییر ساعت، تغییر مکان عمومی و لغو را با همان شناسه تمرین کنید.
  5. متن فارسی، نویسه ویژه، رویداد تمام‌روز و تغییر ساعت تابستانی را در چک‌لیست بگذارید.
  6. مسیر HTML قابل دسترس و روش افزودن دستی را کنار دانلود فرضی طراحی کنید.
  7. نمونه خیالی بماند؛ رویداد، نشانی، ایمیل یا فایل واقعی را برای سایت نفرستید.

این تمرین فایل ICS واقعی یا دعوت تقویمی نیست. دورهمی از این صفحه رویداد، زمان، مکان، ایمیل یا تقویم شخصی دریافت نمی‌کند.

منابع

  1. RFC Editor — استاندارد iCalendar، RFC 5545
  2. IETF Datatracker — متن RFC 5545
  3. IANA — پایگاه مناطق زمانی
  4. IMY — اصول بنیادی GDPR
  5. IMY — پردازش داده در انجمن‌ها
  6. MFD — محتوای دسترس‌پذیر برای وب
  7. Digg — پیوندهای قابل فهم
  8. Dorehami — حضور و لغو
  9. Dorehami — حریم نشانی
  10. Dorehami — خبرنامه و رضایت

بازبینی محتوا: ۲۷ اکتبر ۲۰۲۶. پیوندها برای پژوهش و کنترل ادعاها ثبت شده‌اند؛ دسترسی بیرونی ممکن است تغییر کند.