CONVMV(1) دستورات کاربر CONVMV(1)

convmv - تبدیل نام فایل‌ها از یک کدگذاری به کدگذاری دیگر

convmv [گزینه‌ها] FILE(S) ... DIRECTORY(S)

مشخص کردن کدگذاری فعلی نام فایل(ها) که باید از آن تبدیل شود.
مشخص کردن کدگذاری مقصدی که نام فایل(ها) باید به آن تبدیل شود.
حالت تعاملی (پرسیدن y/n برای هر اقدام).
پیمایش بازگشتی در دایرکتوری‌ها.
فایل‌های هدف در فرم نرمال‌سازی C برای UTF-8 خواهند بود (لینوکس و غیره).
فایل‌های هدف در فرم نرمال‌سازی D برای UTF-8 خواهند بود (OS X و غیره).
نمایش کم‌صداتر بخش‌های "from" یا "to" در تغییر نام (اگر برای نمونه ترمینال شما را به هم می‌ریزد). این گزینه در عمل کاری به جز جایگزینی هر نویسه غیر ASCII (به صورت بایتی) با ? و هر نویسه کنترلی با * در چاپ خروجی انجام نمی‌دهد؛ این کار خود عملیات تغییر نام را تحت تأثیر قرار نمی‌دهد.
اجرای دستور ارائه‌شده. باید دستور را داخل گیومه بگذارید؛ مقدار #1 با نام فایل قدیمی و #2 با نام فایل جدید جایگزین می‌شود. با استفاده از این گزینه مقاصد پیوندهای نمادین دست‌نخورده باقی می‌مانند. به خاطر داشته باشید که #1 و #2 از قبل توسط convmv داخل گیومه قرار می‌گیرند و نباید گیومه اضافی دور آن‌ها بگذارید.

مثال:

convmv -f latin1 -t utf-8 -r --exec "echo #1 should be renamed to #2" path/to/files

فهرست کردن تمام کدگذاری‌های موجود. برای پشتیبانی از کدگذاری‌های بیشتر چینی یا ژاپنی، بسته‌های Perl HanExtra یا JIS2K Encode را نصب کنید. همچنین نصب بسته Perl IMAPUTF7 در صورت نیاز به این کدگذاری می‌تواند مفید باشد.
پایین نگه داشتن ردپای حافظه با عدم ایجاد هش از تمام فایل‌ها. این گزینه بررسی وجود مقاصد پیوندهای نمادین در زیردرخت را غیرفعال می‌کند؛ اشاره‌گرهای مقصد پیوند نمادین در هر صورت تبدیل خواهند شد. اگر صدها هزار یا میلیون‌ها فایل را تبدیل می‌کنید، ممکن است مصرف حافظه convmv بسیار بالا برود. این گزینه در چنین حالتی به کمک شما می‌آید.
به طور پیش‌فرض، convmv تشخیص می‌دهد که آیا نام یک فایل از قبل با فرمت UTF8 کدگذاری شده است یا خیر و در صورت تبدیل از یک مجموعه نویسه دیگر به UTF8، آن فایل را نادیده می‌گیرد. گزینه "--nosmart" تبدیل به UTF-8 را برای چنین فایل‌هایی نیز اجبار می‌کند که ممکن است به "UTF-8 با کدگذاری مضاعف" منجر شود (بخش زیر را ببینید).
با استفاده از گزینه "--fixdouble" دستور convmv تنها فایل‌هایی را تبدیل می‌کند که پس از تبدیل همچنان دارای کدگذاری UTF-8 باشند. این گزینه برای اصلاح فایل‌های با کدگذاری مضاعف UTF-8 مفید است. تمامی فایل‌هایی که UTF-8 نیستند یا پس از تبدیل به UTF-8 ختم نمی‌شوند، دست‌نخورده باقی می‌مانند. همچنین به بخش "نحوه لغو نام فایل‌های با کدگذاری مضاعف UTF-8 ..." در زیر مراجعه کنید.
برای اعمال واقعی تغییر نام فایل‌ها ضروری است. به طور پیش‌فرض convmv صرفاً آنچه را که قصد انجام آن را دارد چاپ می‌کند.
این یک گزینه پیشرفته است که افرادی که قصد نوشتن رابط کاربری گرافیکی (GUI) دارند آن را مفید خواهند یافت. این گزینه باعث می‌شود convmv کارهایی را که انجام می‌دهد به روشی که به آسانی قابل تجزیه باشد چاپ کند. ستون اول شامل عملیات یا نوعی اطلاعات است، ستون دوم اکثراً شامل فایلی است که باید اصلاح شود و در صورت لزوم ستون سوم شامل مقدار اصلاح‌شده است. هر ستون با \0\n (بایت صفر و خط جدید) جدا می‌شود. هر سطر (یک عملیات) با \0\0\n (دو بایت صفر و خط جدید) تفکیک می‌گردد.
این گزینه می‌تواند برای اجرای چشم‌بسته خروجی حاصل از اجرای قبلی --parsable استفاده شود. از این طریق می‌توان حجم عظیمی از فایل‌ها را در حداقل زمان ممکن تغییر نام داد.
اصلاح نام فایل‌ها معمولاً باعث به‌روزرسانی mtime دایرکتوری والد می‌شود. از نسخه ۲ به بعد، convmv به طور پیش‌فرض mtime را به مقدار قدیمی بازمی‌گرداند. اگر سیستم فایل شما از دقت زیر ثانیه پشتیبانی می‌کند، بخش زیر ثانیه atime و mtime از بین می‌رود زیرا پرل هنوز از آن پشتیبانی نمی‌کند. با این گزینه می‌توانید حفظ mtime را غیرفعال کنید.
اگر فایلی که قرار است به آن تغییر نام داده شود از قبل وجود داشته باشد، در صورتی که محتوای فایل برابر باشد رونویسی خواهد شد.
این گزینه توالی‌های هگز % را از نام فایل‌ها حذف کرده و آن‌ها را به نویسه‌های ۸ بیتی تبدیل می‌کند. پس از --unescape ممکن است بخواهید یک تبدیل مجموعه نویسه انجام دهید. این توالی‌ها مانند %20 و غیره گاهی هنگام بارگیری از طریق http یا ftp ایجاد می‌شوند.
تبدیل تمام حروف نام فایل‌ها به بزرگ یا کوچک. هنگامی که فایل با فرمت ASCII کدگذاری نشده باشد، convmv انتظار دارد یک مجموعه نویسه از طریق سوییچ -f وارد شود.
اعمال برخی نگاشت‌های سفارشی نویسه‌ها؛ موارد پشتیبانی‌شده فعلی عبارتند از:

گزینه‌های ntfs-sfm(-undo) و ntfs-sfu(-undo) برای نگاشت نویسه‌های غیرمجاز ntfs برای کلاینت‌های cifs در لینوکس یا مکینتاش (به MS KB 117258 و گزینه سوار کردن mapchars در mount.cifs لینوکس مراجعه کنید).

گزینه ntfs-pretty(-undo) برای نگاشت نویسه‌های غیرمجاز ntfs به نسخه‌های ژاپنی مجاز و مناسب آن‌ها.

برای نحوه افزودن آسان نگاشت‌های اختصاصی در صورت نیاز، به تابع map_get_newname() مراجعه کنید.

مدیریت مسئله i/I بدون نقطه. حرف کوچک "I" نیز بدون نقطه خواهد بود و حرف بزرگ "i" نیز با نقطه خواهد بود. این مسئله در زبان‌های ترکی و آذری وجود دارد.

نکته تاریخی: نقطه بالای حرف i در قرون وسطی اضافه شد تا این حرف (در دست‌نوشته‌ها) از خطوط عمودی مجاور در حروفی مانند u، m و n متمایز شود. حرف J شکلی دگرگون از i است که در این دوره پدیدار شد و متعاقباً تبدیل به یک حرف جداگانه گردید.

تبدیل نشانه ترکیبی sz (U+00DF) به نسخه بزرگ (U+1E9E) و برعکس توسط convmv. از سال ۲۰۱۷ اغلب جدول‌های نگاشت حروف بزرگ/کوچک فایل‌سیستم‌ها این دو نقطه کد را هم‌ارز تلقی نمی‌کنند. بنابراین پیش‌فرض convmv این است که فعلاً آن را بدون در نظر گرفتن بزرگی/کوچکی تلقی کند (مگر اینکه از این گزینه استفاده شود).
چاپ خلاصه کوتاهی از گزینه‌های موجود.
چاپ فهرستی از تمام گزینه‌های در دسترس.

دستور convmv برای کمک به تبدیل نام یک تک‌فایل، یک درخت دایرکتوری و فایل‌های درون آن یا یک فایل‌سیستم کامل به کدگذاری دیگر طراحی شده است. این ابزار فقط نام فایل‌ها را تبدیل می‌کند، نه محتوای فایل‌ها را. یک قابلیت ویژه convmv این است که پیوندهای نمادین را نیز مدیریت می‌کند و در صورتی که مقصد پیوند نمادین نیز در حال تبدیل باشد، اشاره‌گر مقصد را هم تبدیل می‌نماید.

همه این‌ها زمانی که شخصی بخواهد از لوکال‌های قدیمی ۸ بیتی به لوکال‌های UTF-8 مهاجرت کند بسیار کاربردی است. همچنین می‌توان پوشه‌هایی را به UTF-8 تبدیل کرد که بخشی از آن‌ها از قبل به فرمت UTF-8 کدگذاری شده است. دستور convmv قادر به تشخیص فایل‌های دارای کدگذاری UTF-8 است و به طور پیش‌فرض از آن‌ها رد می‌شود. برای خاموش کردن این هوشمندی، از سوییچ "--nosmart" استفاده کنید.

تقریباً تمام فایل‌سیستم‌های استاندارد POSIX اهمیتی به نحوه کدگذاری نام فایل‌ها نمی‌دهند؛ برخی استثناها به شرح زیرند:

HFS+ در OS X / Darwin

لینوکس و بیشتر سیستم‌عامل‌های شبه‌یونیکس دیگر به طور پیش‌فرض از فرم نرمال‌سازی C (NFC) برای کدگذاری UTF-8 استفاده می‌کنند اما آن را اجباری نمی‌نمایند. سیستم‌فایل HFS+ در سیستم‌عامل مکینتاش فرم نرمال‌سازی D (NFD) را اجبار می‌کند که در آن تعداد کمی از نویسه‌ها به روش متفاوتی کدگذاری می‌شوند. در OS X ایجاد نام فایل‌های UTF-8 از نوع NFC امکان‌پذیر نیست زیرا در لایه فایل‌سیستم از آن جلوگیری می‌شود. در HFS+ نام فایل‌ها در درون به صورت UTF-16 ذخیره می‌شوند و هنگامی که به UTF-8 تبدیل می‌شوند، به هر دلیلی NFD تولید می‌شود. برای جزئیات به نشانی زیر مراجعه کنید: http://developer.apple.com/qa/qa2001/qa1173.html در هر جای دیگر، convmv قادر است فایل‌ها را از NFC به NFD یا برعکس تبدیل کند که تعامل‌پذیری با چنین سیستم‌هایی را بسیار آسان‌تر می‌سازد.

APFS در macOS

شرکت اپل با معرفی APFS در macOS 10.3، از تحمیل NFD به فضای کاربری دست کشید. اما پس از اینکه NFD را اجبار کردید، راه بازگشت آسانی بدون شکستن برنامه‌های موجود وجود ندارد؛ بنابراین آن‌ها مجبور شدند APFS را نسبت به نرمال‌سازی حساس نکنند (normalization-insensitive). این بدان معناست که یک فایل می‌تواند در قالب NFC یا NFD در فایل‌سیستم ایجاد شود و با هر دو شکل نیز قابل دسترسی باشد. در پشت صحنه، آن‌ها هش‌های شکل نرمال‌شده نام فایل را ذخیره می‌کنند تا عدم حساسیت به نرمال‌سازی را فراهم نمایند. به نظر ایده خوبی می‌رسد؟ اما: اگر محتویات یک دایرکتوری را بخوانید (readdir)، فایل‌ها را با همان فرم نرمال‌سازی دریافت می‌کنید که هنگام ایجاد آن‌ها استفاده شده بود. اگر یک فایل را در فرم NFC یا NFD بررسی کنید (stat)، همان فرم نرمال‌سازی را دریافت می‌کنید که در فراخوانی stat استفاده کردید. بنابراین برنامه‌های فضای کاربری نمی‌توانند انتظار داشته باشند فایلی که با موفقیت بررسی و قابل دسترسی است لزوماً با همان شکل در فهرست دایرکتوری هم ظاهر شود، زیرا شکل نرمال‌سازی بازگردانده شده طوری جعل شده که با خواسته کاربر مطابقت کند. به صورت تئوری فضای کاربر نیز باید مرتباً رشته‌ها را نرمال‌سازی کند. این همان مشکلی است که قبلاً در مورد عدم حساسیت به بزرگی و کوچکی نام فایل‌ها وجود داشت و هنوز بسیاری از برنامه‌های فضای کاربر را مختل می‌کند.

JFS

اگر پارتیشن‌های JFS با iocharset=utf8 سوار شوند، مشکل مشابهی ایجاد می‌شود زیرا JFS نیز به گونه‌ای طراحی شده که نام فایل‌ها را در درون با فرمت UTF-16 ذخیره کند؛ دلیل آن این است که JFS لینوکس در واقع JFS2 است که بازنویسی JFS برای OS/2 بود. پارتیشن‌های JFS همیشه باید با iocharset=iso8859-1 سوار شوند. اگر این کار انجام نشود، JFS مانند یک فایل‌سیستم POSIX رفتار نخواهد کرد و ممکن است فایل‌های خاصی اصلاً ایجاد نشوند.

NFS4

برخلاف سایر فایل‌سیستم‌های پوزیکس، استاندارد RFC3530 (NFS 4) استفاده از UTF-8 را الزامی کرده اما می‌گوید: "پروفایل nfs4_cs_prep یک فرم نرمال‌سازی مشخص نمی‌کند." به عبارت دیگر، اگر می‌خواهید از NFS4 استفاده کنید ممکن است قابلیت‌های تبدیل و نرمال‌سازی convmv را کاملاً کاربردی بیابید.

FAT/VFAT و NTFS

سیستم‌فایل‌های NTFS و VFAT (برای نام‌های بلند فایل) در درون از UTF-16 برای ذخیره نام فایل‌ها استفاده می‌کنند. هنگام سوار کردن این سیستم‌فایل‌ها نیازی به تبدیل نام فایل‌ها ندارید؛ به جای آن از گزینه‌های مناسب دستور mount استفاده کنید!

گاهی ممکن است برخی نام فایل‌ها به صورت مضاعف کدگذاری شوند (double-encoded)؛ برای مثال نام فایل‌ها از قبل دارای کدگذاری UTF-8 بوده‌اند و شما تصادفاً تبدیل دیگری از یک مجموعه نویسه به UTF-8 انجام داده‌اید. به سادگی می‌توانید با انجام تبدیل در جهت معکوس این کار را لغو کنید: مجموعه نویسه مبدأ باید UTF-8 باشد و مجموعه نویسه مقصد باید همان مبدئی باشد که قبلاً اشتباهاً استفاده کرده‌اید. اگر از گزینه "--fixdouble" استفاده کنید، convmv تضمین می‌کند که فقط فایل‌هایی پردازش شوند که پس از تبدیل همچنان دارای کدگذاری UTF-8 باشند و فایل‌های غیر UTF-8 را دست‌نخورده باقی می‌گذارد. پیشنهاد می‌شود پیش از آن تبدیل را بدون "--notest" اجرا کنید تا نتایج را بررسی نمایید؛ همچنین گزینه "--qfrom" می‌تواند سودمند باشد، زیرا نام فایل‌های دابل UTF-8 در صورت چاپ در ترمینال ممکن است نمایش را به هم بریزند.

اگر در فایل smb.conf (مربوط به Samba 2.x) متغیر "character set" به درستی تنظیم نشده باشد، فایل‌هایی که توسط کلاینت‌های ویندوز ایجاد می‌شوند با کدپیج کلاینت (مانند cp850) ذخیره می‌گردند. در نتیجه فایل‌هایی که حاوی نویسه‌های غیر ASCII هستند هنگام مشاهده با ls روی سرور یونیکس نامعتبر دیده می‌شوند. اگر بعداً متغیر "character set" را به iso8859-1 تغییر دهید، فایل‌های تازه‌ایجادشده درست هستند اما فایل‌های قدیمی همچنان با کدگذاری ویندوز خرابند. در این حالت convmv می‌تواند برای تبدیل فایل‌های اشتراکی قدیمی سامبا از cp850 به iso8859-1 استفاده شود.

نکته: Samba 3.x به طور پیش‌فرض به نام فایل‌های UTF-8 نگاشت می‌شود، بنابراین هنگام مهاجرت از Samba 2 به Samba 3 نیز ممکن است نیاز به تبدیل نام فایل‌ها داشته باشید.

هنگامی که Netatalk به UTF-8 تغییر می‌یابد (که در نسخه ۲ پشتیبانی می‌شود)، صرفاً تغییر نام فایل‌ها کافی نیست. باید کارهای بیشتری انجام شود. برای جزئیات به آدرس زیر و ابزار uniconv در Netatalk مراجعه کنید: http://netatalk.sourceforge.net/2.0/htmldocs/upgrade.html#volumes-and-filenames

برخی نسخه‌های Dovecot برای پوشه‌های Maildir از UTF-8 استفاده می‌کنند و برخی از IMAP-UTF-7 (معروف به mUTF7). در سناریوهای خاص مهاجرت، مدیران سیستم ممکن است نیاز به تبدیل نام پوشه‌ها داشته باشند که با convmv قابل انجام است. اطمینان حاصل کنید بسته Perl IMAPUTF7 را نصب کرده‌اید تا بتوانید از این کدگذاری در convmv استفاده کنید.

locale(1) utf-8(7) charsets(7)

هیچ باگ شناخته‌شده‌ای وجود ندارد.

می‌توانید با اهدای کمک مالی از convmv حمایت کنید؛ ببینید: https://www.j3e.de/donate.html

Bjoern JACKE

برای ارسال گزارش‌های باگ و پیشنهادات به bjoern [at] j3e.de ایمیل بفرستید.

2025-03-01 perl v5.40.1