«ترکیب یونیکد برای نام‌فایل‌ها (2008)»

اصل ماجرا

در یونیکد برخی حروف می‌توانند به دو شکل NFC یا NFD ذخیره شوند. macOS مسیرها را به NFD تبدیل می‌کند در حالی که ویندوز هر دو شکل را می‌پذیرد. این اختلاف باعث می‌شود فایل‌ها در مخزن به‌درستی شناسایی نشوند و خطاهای نسخه‌بندی رخ دهد. پیشنهاد شده که مسیرها به‌صورت داخلی به NFC نرمال شوند یا توابع مقایسهٔ آگاه به NFC/NFD استفاده شوند.

متن کامل ترجمه‌شده

-- متن -- محتوای ===== * زمینه * شرح موضوع * وضعیت پیش حل - یک پلتفرم - چند پلتفرم: Windows + MacOS X * پیشنهاد پشتیبانی کتابخانه - فرضیه ها - گزینه های * پیشنهاد فرم معمولی * راه حل های ممکن - استاندارد سازی مسیر ورود در MacOS X - استاندارد سازی مسیر ورود در همه جا - روتین مقایسه (برای مشتری) - روتین مقایسه (برای همه جا) * راه حل کوتاه مدت (به عنوان مثال قبل از 2.0) * راه حل طولانی مدت (به عنوان مثال 2.0+) * اطلاعات اضافی * اشاره های زمینه =====در Unicode، برخی از شخصیت ها - با نشانه های دیسکریتیک - می توانند در دو فرم: فرم معمولی تشکیل شده (NFC) یا فرم معمولی حذف شده (NFD) نمایان شوند.لطفا توجه داشته باشید که این مشکل به طور صریح از فرم های معمولی NFKC/NFKD (توازن) خارج می شود، زیرا آنها به عنوان مثال شکل گیری را حذف می کنند (که به این معنی که آنها از دست می یابند)؟ چرا که در Unicode دو فرم برای نشان دادن (همه) شخصیت وجود دارد، ممکن است طیف های مختلف از codepoints تولید شود که به معنای نشان دادن همان طیف از شخصیت ها است [1]. UTF-8, رمزگذاری Unicode داخلی انتخاب شده برای Subversion، codepoints را در ( یک سری از) بیت ها (بیت ها) رمزگذاری می کند. چرا که طیف های codepoints که یک شخصیت را مشخص می کنند ممکن است متفاوت باشد، بنابراین ممکن است UTF-8 حاصل شود. بنابراین، ما در پایان با بیش از یک راه برای نشان دادن همان مسیر است.این موضوع به طور عمده یک مشکل از طرف مشتری است، چیزی که ممکن است در کتابخانه های طرف مشتری (client/subr/wc) حل شود. دوم، همان نام فایل ممکن است در نقاط مختلف رمزگذاری شود. این مشکل بسیار گسترده تر از اولین است، به خصوص با توجه به این که ما در حال حاضر بسیاری از ذخیره سازی های جمعیت شده “در آنجا” داریم. ما نمی توانیم به یک نام فایل از سیستم عامل - حتی اگر متفاوت از آن در ذخیره سازی - برای نام یک فایل متفاوت است. این ذخیره سازی (به عنوان مثال، از سوی سرور) تاثیر دارد. وضعیت پیش از حل =<<<<<<<<<<<< این بخش برای توصیف مشکلات که در ترکیب های مختلف از سیستم های مشتری / سرور انتظار می رود. همانطور که در جدول در زمینه نشان داده شده است، لینوکس و ویندوز انتظار می رود به طور مساویدر این بخش به نظر می رسد که لینوکس به عنوان یک سیستم جداگانه در نظر گرفته می شود. پلتفرم های زیر به طور کامل از طرف مشتری هستند: مشکلات در طرف سرور که در بخش توضیحات مشکل ذکر شده است تنها مربوط به ذخیره ای است که می تواند در هر پلتفرم سرور قرار گیرد. پلتفرم واحد --------------- این می تواند چندین ماشین MacOSX یا چندین ماشین Windows باشد. در این سناریو، هیچ مشکلی با تعاملی انتظار نمی رود. پلتفرم های متعددی: Windows + MacOSX ---------------- یک نام فایل را که شامل یک یا چندین شخصیت پیش ساخته شده (NFC) است که از ویندوز انجام می شود. هنگامی که توسعه دهنده MacOSX به روز رسانی می کند، یک فایل در فرم NFC نوشته می شود، اما همانطور که در زمینه بیان می شود، قسمت Mac آن را به Nهر دو نام فایل به صورت دقیقا یکسان به کسی که نسخه Subversion را در صفحه نمایش می خواند به نظر می رسد. [==> تعارض!] انجام یک فایل در راه دیگر ممکن است کمتر مشکلی باشد، زیرا ویندوز قادر به ذخیره نام های فایل NFD است. پیشنهاد پشتیبانی کتابخانه = <<<<===== فرضیه اصلی این است که ما همچنان APR را برای تبدیل مجموعه حروف استفاده می کنیم، به این معنی که راه حل بازگو برای انتخاب نیازی به ارائه هیچ فعالیت دیگری جز بازگو نیست. گزینه ها ------- دو گزینه وجود دارد (که من از [dionisos] آگاه هستم) برای انتخاب یک کتابخانه که عملکرد مورد نیاز را پشتیبانی می کند: 1) International Component for Unicode (ICU)[3] - یک کتابخانه با طیف گسترده ای از ویژگی های هدفمند، اما با یک انگشت حافظه برای هماهنگی.کتابخانه ای که به طور خاص به تعداد محدود از عملیات برای انجام بر روی سیگنال های رمزگذاری UTF-8 هدف قرار می گیرد. آن را از دو فایل .c و یک فایل .h تشکیل می دهد، با حجم کل منبع 1MB (مجموع کمتر از 0.5MB) است. از این دو، تحت فرض داده شده، این تنها معنای استفاده از utf8proc است. فرم معمولی پیشنهاد شده =.<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<از آنجایی که Mac به نظر می رسد تنها پلتفرم است که واردات PathName خود را به NFD می کند، این به نظر می رسد یک راه حل منطقی (دور کم) است. 2) استاندارد سازی (راه) واردات در تمام پلتفرم ها. از آنجایی که راه ها نمی توانند تنها در رمزنگاری متفاوت باشد اگر ما در رمزنگاری استاندارد سازی کنیم، این به نظر می رسد یک راه حل منطقی (به نسبت پایین) تاثیر است. 3) استاندارد سازی واردات راه در مشتری و سرور. از سوی سرور، راه های غیر استاندارد شده ممکن است بخشی از ذخیره شود. ما می توانیم استاندارد سازی کامل در حافظه را با تبدیل هر راهی از ذخیره و همچنین مشتری به دست آوریم. 4) راه های مقایسه راه های مشتری و سرور. از آنجا که راه های خوانده شده از ذخیره می توانند برای دسترسییک مشتری را در نظر بگیرید که شروع به ارسال راه های رمزگذاری NFC در یک محیط است که در آن زمان تمام راه ها NFD رمزگذاری شده اند - بدون پشتیبانی مناسب در سرور. این باعث می شود که راه های رمزگذاری NFC به فایل هایی که راه در ذخیره NFD رمزگذاری شده است: شکست. راه حل (2) همان مشکل را دارد که راه حل (1) در MacOSX است، اما از طرف دیگر آن را از ورود راه های NFD جدید به ذخیره جلوگیری می کند (برای تعریف های کافی گسترده از ‘مشتری’ [پندارید mod_dav_svn]). همانطور که قبلا گفته شد، راه حل (3) می تواند راه ها را از یافتن جلوگیری کند، اگر مکانیسم جستجوی بر اساس هشدار است. این بدان معنی است که این می تواند هر پشتیبان ذخیره ای از طریق هشدار برای ذخیره اطلاعاتدر عوض، لازم است که تمام مقایسه های مسیر را با استفاده از ویژگی های خاص NFC / NFD برای رمزگذاری انجام دهند. راه حل کوتاه مدت ======= به دلیل تضمینات تعاملات ما، مشتری و سرور باید به جهان های جداگانه در نظر گرفته شوند که هر یک از آنها می تواند از راه حل های خود استفاده کند. با این حال، مشتری باید در هر زمان از راه دقیق که سرور آن را فرستاده است استفاده کند. همان طور که در نظر گرفته شده است، راه حل کوتاه مدت (بعد از 2.0) باید از راه حل های مقایسه مسیر استفاده کند، همانطور که در راه حل (4) بیان شده است. راه حل طولانی مدت ====== راه حل طولانی مدت (2.0+) گزینه استفاده می شود (2), که اطمینان می دهد که همه راه های واردات به شکل معمول (NFC) بازگردانده می شوند.همانطور که قبلا بیان شد، از آنجایی که ما نمی دانیم که آیا طرف دیگری از معادله می تواند یک مشتری یا سرور پیش از استاندارد سازی آگاه باشد تا زمانی که در 2.0 با یکدیگر ارتباط برقرار کنیم، مشتری و سرور باید بتوانند با یک طرف دیگر قبل از NF آگاه با یکدیگر ارتباط برقرار کنند. بنابراین، حل این مشکل به معنای در نظر گرفتن مشتری و سرور جهان های جداگانه است که هر یک از آنها می تواند راه حل داخلی خود را استفاده کند. گزینه اجرا (4) به معنای: A. مقایسه نام های فایل با مسیرهای ورود با استفاده از NFC / NFD ویژگی های مقایسه آگاه. سپس، هنگامی که یک مقایسه وجود دارد، * استفاده از patamehn از ورودی های فایل * برای ارتباط با سرور؛ پس از همه، مسیر ممکن است با یک رمزگذاری متفاوت از آنچه که ما از دیسک دریافت کردیم اضافه شده است. Bاین بدان معنی است که مشتری باید بسیار مراقب رمزنگاری را از سرور حفظ کند و از آن استفاده کند که هنگامی که با سرور صحبت می کند در غیر این صورت سرور ممکن است مسیر را به عنوان یک موجود نسخه ای تشخیص ندهد. با این حال، در محلی، ما نمی توانیم مطمئن شویم که سیستم فایل رمزنگاری را از سرور به مشتری ارسال می کند، به این معنی که موارد (contrived) وجود دارد که یک فایل در یک رمزنگاری متفاوت در محلی وجود دارد، نه در ذخیره سازی. که بدان معنی است که ما باید بسیار مراقب باشیم که چگونه فایل های ما را پیدا کنیم و از رمزنگاری که از سیستم فایل های محلی دریافت کرده ایم استفاده کنیم. جزئیات اجرای: * کلیدهای هش در svn_wc_adm_access_t شامل کلیدهای هش در قسمت های هش است. جدید شامل: * متغیر* متغیر هایی که یک مسیر را به عنوان رمزگذاری شده در ذخیره می کنند، باید (دوره) string ‘repo_path’ را در اختیار داشته باشند. اطلاعات اضافی ============== * “UTF-8 NFC/NFD paths issue” dev@ mailing list thread: http://svn.haxx.se/dev/archive-2010-09/0319.shtml References ========== 1) UAX #15: Unicode normalization forms ›URL_1› 2) Apple Technical Q&A: Path encodings in VFS ›URL_2› 3) ICU - International Component for Unicode ›URL_3› 4) utf8proc - a library aimed at processing UTF-8 encoded unicode strings ›URL_4›

چرا مهمه؟

تغییر اصلی تبدیل همهٔ مسیرهای ورودی به فرم NFC یا استفاده از توابع مقایسهٔ هوشمند است. این تغییر بر توسعه‌دهندگان Subversion، مدیران مخازن و کاربران نهایی که روی سیستم‌های macOS و ویندوز کار می‌کنند تأثیر می‌گذارد. چون نام‌فایل‌های یکسان ممکن است به‌صورت متفاوتی ذخیره شوند، بدون این اصلاحات مخازن می‌توانند فایل‌های تکراری یا گمشده داشته باشند؛ پس فهم این مسئله برای حفظ صحت نسخه‌بندی ضروری است.

به درد کی می‌خوره؟

• توسعه‌دهندگان Subversion • مدیران مخازن کد منبع • تیم‌های DevOps • کاربران پیشرفتهٔ macOS و ویندوز

تو عمل چی کار کنیم؟

پس از خواندن این خبر می‌توانید بررسی کنید که آیا ابزارهای شما مسیرها را به NFC نرمال می‌کنند یا نه. اگر نه، می‌توانید کتابخانهٔ utf8proc یا ICU را برای نرمال‌سازی اضافه کنید یا توابع مقایسهٔ سفارشی پیاده کنید تا از بروز خطاهای نسخه‌بندی جلوگیری شود.

نظر Blue IT News

پیشنهاد می‌شود پیش از ارتقاء به نسخهٔ ۲٫۰، پروژه‌ها را با توابع مقایسهٔ NFC/NFD سازگار کنید؛ این کار ریسک ناسازگاری را در کوتاه‌مدت کاهش می‌دهد.

<div class=“disclosure”> این صفحه ترجمه و تفسیر کاملی از گزارش اصلی Svn است که توسط تیم تحریریه بلو آی تی نیوز به فارسی ترجمه و تحلیل شده. برای مشاهده نسخه اصلی، به منبع مراجعه کنید. </div>