فهم لغات وحدة التخزين في Azure NetApp Files

تتحكم لغة وحدة التخزين (أقرب إلى إعدادات النظام المحلية على أنظمة تشغيل العميل) على وحدة تخزين Azure NetApp Files في اللغات ومجموعات الأحرف المدعومة عند استخدام بروتوكولات NFS وSMB. تستخدم Azure NetApp Files لغة وحدة تخزين افتراضية من C.UTF-8، والتي توفر ترميز UTF-8 متوافقا مع POSIX لمجموعات الأحرف. تدعم لغة C.UTF-8 في الأصل الأحرف بحجم 0-3 بايت، والتي تتضمن غالبية لغات العالم على المستوى الأساسي متعدد اللغات (BMP) (بما في ذلك اليابانية والألمانية ومعظم العبرية والسيريلية). لمزيد من المعلومات حول BMP، راجع Unicode.

تتجاوز الأحرف خارج BMP أحيانا حجم 3 بايت الذي تدعمه Azure NetApp Files. وبالتالي يحتاجون إلى استخدام منطق الزوج البديل، حيث يتم دمج مجموعات بايت متعددة الأحرف لتشكيل أحرف جديدة. رموز المشاعر، على سبيل المثال، تندرج في هذه الفئة ويتم دعمها في Azure NetApp Files في السيناريوهات التي لا يتم فيها فرض UTF-8: مثل عملاء Windows الذين يستخدمون ترميز UTF-16 أو NFSv3 الذي لا يفرض UTF-8. يفرض NFSv4.x UTF-8، مما يعني أن أحرف الزوج البديل لا تظهر بشكل صحيح عند استخدام NFSv4.x.

لا يتم أيضا عرض الترميز غير المتوافق، مثل Shift-JIS وأحرف CJK الأقل شيوعا، بشكل صحيح عند فرض UTF-8 في Azure NetApp Files.

تلميح

يجب إرسال النص وتلقيه باستخدام UTF-8 لتجنب المواقف التي لا يمكن فيها ترجمة الأحرف بشكل صحيح، مما قد يتسبب في إنشاء/إعادة تسمية الملف أو نسخ سيناريوهات الخطأ.

لا يمكن تعديل إعدادات لغة وحدة التخزين حاليا في Azure NetApp Files. لمزيد من المعلومات، راجع سلوكيات البروتوكول مع مجموعات الأحرف الخاصة.

للحصول على أفضل الممارسات، راجع أفضل ممارسات مجموعة الأحرف.

ترميز الأحرف في وحدات تخزين NFS وSMB لملفات Azure NetApp

في بيئة مشاركة ملفات Azure NetApp، يتم تمثيل أسماء الملفات والمجلدات بسلسلة من الأحرف التي يقرأها المستخدمون ويفسرونها. تعتمد طريقة عرض هذه الأحرف على كيفية إرسال العميل وتلقي ترميز هذه الأحرف. على سبيل المثال، إذا كان العميل يرسل ترميز رمز قياسي أمريكي قديم لتبادل المعلومات (ASCII) إلى وحدة تخزين Azure NetApp Files عند الوصول إليه، فإنه يقتصر على عرض الأحرف المدعومة فقط بتنسيق ASCII.

على سبيل المثال، الحرف الياباني للبيانات هو 資. نظرا لأنه لا يمكن تمثيل هذا الحرف في ASCII، يعرض العميل الذي يستخدم ترميز ASCII "؟" بدلا من 資.

يدعم ASCII 95 حرفا قابلا للطباعة فقط، بشكل أساسي تلك الموجودة في اللغة الإنجليزية. يستخدم كل حرف من هذه الأحرف بايت 1، والذي يتم احتسابه في إجمالي طول مسار الملف على وحدة تخزين Azure NetApp Files. وهذا يحد من تدويل مجموعات البيانات، حيث يمكن أن تحتوي أسماء الملفات على مجموعة متنوعة من الأحرف التي لم يتم التعرف عليها من قبل ASCII، من اليابانية إلى السيريلية إلى رموز المشاعر. حاول معيار دولي (ISO/IEC 8859) دعم المزيد من الأحرف الدولية، ولكن كان له أيضا قيوده. يرسل معظم العملاء الحديثين الأحرف ويتلقاها باستخدام شكل من أشكال Unicode.

UNICODE

نتيجة لقيود ترميز ASCII و ISO/IEC 8859، تم إنشاء معيار Unicode حتى يتمكن أي شخص من عرض لغة منطقته الرئيسية من أجهزته.

• يدعم Unicode أكثر من مليون مجموعة أحرف عن طريق زيادة عدد وحدات البايت لكل حرف مسموح به (حتى 4 بايت) وإجمالي عدد وحدات البايت المسموح بها في مسار ملف بدلا من الترميزات القديمة، مثل ASCII.
• يدعم Unicode التوافق مع الإصدارات السابقة من خلال حجز أول 128 حرفا ل ASCII، مع ضمان مطابقة أول 256 نقطة تعليمة برمجية لمعايير ISO/IEC 8859.
• في معيار Unicode، يتم تقسيم مجموعات الأحرف إلى مستويات. الطائرة هي مجموعة مستمرة من 65536 نقطة تعليمة برمجية. في المجموع، هناك 17 طائرة (0-16) في معيار Unicode. الحد هو 17 بسبب قيود UTF-16.
• المستوى 0 هو المستوى الأساسي متعدد اللغات (BMP). تحتوي هذه الطائرة على الأحرف الأكثر استخداما عبر لغات متعددة.
• من بين 17 طائرة، قامت خمس فقط حاليا بتعيين مجموعات أحرف اعتبارا من Unicode الإصدار 15.1.
• تعرف الطائرات من 1 إلى 17 باسم الطائرات التكميلية متعددة اللغات (SMP) وتحتوي على مجموعات أحرف أقل استخداما، على سبيل المثال أنظمة الكتابة القديمة مثل cuneiform وhieroglyphs، بالإضافة إلى الأحرف الصينية/اليابانية/الكورية الخاصة (CJK).
• للحصول على أساليب لمشاهدة أطوال الأحرف وأحجام المسارات والتحكم في الترميز المرسل إلى نظام، راجع تحويل الملفات إلى ترميزات مختلفة.

يستخدم Unicode تنسيق تحويل Unicode كمعيار له، مع UTF-8 وUTF-16 هما التنسيقان الرئيسيان.

مستويات Unicode

تستفيد Unicode من 17 طائرة من 65536 حرفا (256 نقطة تعليمة برمجية مضروبة في 256 مربعا في الطائرة)، مع الطائرة 0 كوحدة أساسية متعددة اللغات (BMP). تحتوي هذه الطائرة على الأحرف الأكثر استخداما عبر لغات متعددة. نظرا لأن لغات العالم ومجموعات الأحرف تتجاوز 65536 حرفا، هناك حاجة إلى المزيد من المستويات لدعم مجموعات الأحرف الأقل استخداما.

على سبيل المثال، تتضمن الطائرة 1 (الطائرات التكميلية متعددة اللغات (SMP) نصوصا تاريخية مثل cuneiform والهيروغليفية المصرية بالإضافة إلى بعض أوساج ووارانج سيتي وأدلام وانتشو وتوتو. تتضمن الطائرة 1 أيضا بعض الرموز وأحرف رموز المشاعر .

الطائرة 2 – وحدة Ideographic التكميلية (SIP) – تحتوي على Ideographs الموحدة الصينية/اليابانية/الكورية (CJK). الأحرف في الوحدتين 1 و2 بشكل عام هي 4 بايت في الحجم.

على سبيل المثال:

• رمز مشاعر "وجه مبتسم بعيون كبيرة" في😃 الطائرة 1 هو 4 بايت في الحجم.
• الهيروغليفية المصرية "𓀀" في الطائرة 1 هو 4 بايت في الحجم.
• يبلغ حجم حرف Osage "𐒸" في المستوى 1 4 بايت.
• الحرف CJK "𫝁" في المستوى 2 هو 4 بايت في الحجم.

نظرا لأن كل هذه الأحرف بحجم >3 بايت، فإنها تتطلب استخدام أزواج بديلة للعمل بشكل صحيح. تدعم Azure NetApp Files في الأصل أزواجا بديلة، ولكن يختلف عرض الأحرف اعتمادا على البروتوكول قيد الاستخدام وإعدادات الإعدادات المحلية للعميل وإعدادات تطبيق الوصول إلى العميل عن بعد.

UTF-8

يستخدم UTF-8 ترميز 8 بت ويمكن أن يحتوي على ما يصل إلى 112064 نقطة تعليمة برمجية (أو أحرف). UTF-8 هو الترميز القياسي عبر جميع اللغات في أنظمة التشغيل المستندة إلى Linux. نظرا لأن UTF-8 يستخدم ترميز 8 بت، فإن الحد الأقصى لعدد صحيح غير موقع ممكن هو 255 (2^8 – 1)، وهو أيضا الحد الأقصى لطول اسم الملف لهذا الترميز. يستخدم UTF-8 على أكثر من 98٪ من الصفحات على الإنترنت، مما يجعله حتى الآن معيار الترميز الأكثر اعتمادا. تعتبر مجموعة عمل تقنية تطبيق النص التشعبي على الويب (WHATWG) UTF-8 "الترميز الإلزامي لجميع [النص]" وأنه لأسباب تتعلق بالأمان يجب ألا تستخدم تطبيقات المستعرض UTF-16.

تستخدم كل أحرف بتنسيق UTF-8 من 1 إلى 4 بايت، ولكن تستخدم جميع الأحرف تقريبا في جميع اللغات ما بين 1 و3 بايت. على سبيل المثال،

• يستخدم الحرف الأبجدي اللاتيني "A" 1 بايت. (أحد أحرف ASCII المحجوزة البالغ عددها 128 حرفا)
• يستخدم رمز حقوق النشر "©" بايتين.
• يستخدم الحرف "ä" 2 بايت. (1 بايت ل "a" + 1 بايت ل umlaut)
• يستخدم رمز كانجي الياباني للبيانات (資) 3 بايت.
• يستخدم رمز مشاعر الوجه المبتسم (😃) 4 بايت.

يمكن للغات المحلية استخدام إما UTF-8 القياسي للكمبيوتر (C.UTF-8) أو تنسيق أكثر تحديدا للمنطقة، مثل en_US. UTF-8، ja. UTF-8، إلخ. يجب عليك استخدام ترميز UTF-8 لعملاء Linux عند الوصول إلى Azure NetApp Files كلما أمكن ذلك. اعتبارا من OS X، يستخدم عملاء macOS أيضا UTF-8 لترميزه الافتراضي ولا ينبغي تعديله.

يستخدم عملاء Windows UTF-16. في معظم الحالات، يجب ترك هذا الإعداد كافتراضي للإعدادات المحلية لنظام التشغيل، ولكن العملاء الأحدث يقدمون دعم بيتا لأحرف UTF-8 عبر خانة اختيار. يمكن أيضا تعديل عملاء المحطة الطرفية في Windows لاستخدام UTF-8 في PowerShell أو CMD حسب الحاجة. لمزيد من المعلومات، راجع سلوكيات البروتوكول المزدوج مع مجموعات الأحرف الخاصة.

UTF-16

يستخدم UTF-16 ترميز 16 بت وهو قادر على ترميز جميع نقاط التعليمات البرمجية 1,112,064 من Unicode. يمكن أن يستخدم الترميز ل UTF-16 وحدة تعليمة برمجية واحدة أو وحدتين من وحدات التعليمات البرمجية 16 بت، كل منها بحجم 2 بايت. تستخدم جميع الأحرف في UTF-16 حجمين أو 4 بايت. تستفيد الأحرف في UTF-16 التي تستخدم أزواجا بديلة من 4 بايت، والتي تجمع بين حرفين منفصلين من 2 بايت لإنشاء حرف جديد. تقع هذه الأحرف التكميلية خارج مستوى BMP القياسي وإلى واحدة من الطائرات الأخرى متعددة اللغات.

يتم استخدام UTF-16 في أنظمة تشغيل Windows وواجهات برمجة التطبيقات وJava وJavaScript. نظرا لأنه لا يدعم التوافق مع الإصدارات السابقة مع تنسيقات ASCII، فإنه لم يكتسب شعبية على الويب. يشكل UTF-16 فقط حوالي 0.002٪ من جميع الصفحات على الإنترنت. تعتبر مجموعة عمل تقنية تطبيق النص التشعبي على الويب (WHATWG) UTF-8 "الترميز الإلزامي لجميع النصوص" وتوصي التطبيقات بعدم استخدام UTF-16 لأمان المستعرض.

تدعم Azure NetApp Files معظم أحرف UTF-16، بما في ذلك الأزواج البديلة. في الحالات التي لا يكون فيها الحرف معتمدا، يبلغ عملاء Windows عن خطأ في "اسم الملف الذي حددته غير صالح أو طويل جدا".

معالجة مجموعة الأحرف عبر العملاء البعيدين

يمكن تكوين الاتصالات البعيدة للعملاء الذين يركبون وحدات تخزين Azure NetApp Files (مثل اتصالات SSH بعملاء Linux للوصول إلى عمليات تحميل NFS) لإرسال ترميزات لغة وحدة التخزين المحددة وتلقيها. يتحكم ترميز اللغة المرسل إلى العميل عبر الأداة المساعدة للاتصال عن بعد في كيفية إنشاء مجموعات الأحرف وعرضها. ونتيجة لذلك، يمكن أن يعرض الاتصال البعيد الذي يستخدم ترميز لغة مختلفة عن اتصال بعيد آخر (مثل نافذتين مختلفتين من PuTTY) نتائج مختلفة للأحرف عند سرد أسماء الملفات والمجلدات في وحدة تخزين Azure NetApp Files. في معظم الحالات، لن يؤدي ذلك إلى حدوث تناقضات (مثل الأحرف اللاتينية/الإنجليزية)، ولكن في حالات الأحرف الخاصة، مثل رموز المشاعر، يمكن أن تختلف النتائج.

على سبيل المثال، يظهر استخدام ترميز UTF-8 للاتصال البعيد نتائج يمكن التنبؤ بها للأحرف في وحدات تخزين Azure NetApp Files نظرا لأن C.UTF-8 هي لغة وحدة التخزين. يعرض الحرف الياباني ل "البيانات" (資) بشكل مختلف اعتمادا على الترميز الذي يتم إرساله بواسطة المحطة الطرفية.

ترميز الأحرف في PuTTY

عندما تستخدم نافذة PuTTY UTF-8 (الموجودة في إعدادات ترجمة Windows)، يتم تمثيل الحرف بشكل صحيح لوحدة تخزين NFSv3 مثبتة في Azure NetApp Files:

إذا كانت نافذة PuTTY تستخدم ترميزا مختلفا، مثل ISO-8859-1:1998 (Latin-1، West Europe)، فسيعرض الحرف نفسه بشكل مختلف على الرغم من أن اسم الملف هو نفسه.

لا يحتوي PuTTY، بشكل افتراضي، على ترميزات CJK. هناك تصحيحات متاحة لإضافة مجموعات اللغات هذه إلى PuTTY.

ترميزات الأحرف في Bastion

توصي Microsoft Azure باستخدام Bastion للاتصال عن بعد بالأجهزة الظاهرية (VMs) في Azure. عند استخدام Bastion، لا يتم عرض ترميز اللغة المرسلة والمستلمة في التكوين ولكنه يستفيد من ترميز UTF-8 القياسي. ونتيجة لذلك، يجب أن تكون معظم مجموعات الأحرف التي تظهر في PuTTY باستخدام UTF-8 مرئية أيضا في Bastion، شريطة أن يتم دعم مجموعات الأحرف في البروتوكول المستخدم.

تلميح

يمكن استخدام محطات SSH الأخرى مثل TeraTerm. يوفر TeraTerm مجموعة أوسع من مجموعات الأحرف المدعومة بشكل افتراضي، بما في ذلك ترميزات CJK وترميزات غير قياسية مثل Shift-JIS.

سلوكيات البروتوكول مع مجموعات أحرف خاصة

تستخدم وحدات تخزين Azure NetApp Files ترميز UTF-8 وتدعم الأحرف التي لا تتجاوز 3 بايت في الأصل. يتم عرض جميع الأحرف في مجموعة ASCII وUTF-8 بشكل صحيح لأنها تقع في نطاق 1 إلى 3 بايت. على سبيل المثال:

• يستخدم الحرف الأبجدي اللاتيني "A" بايت واحد (أحد أحرف ASCII المحجوزة البالغ عددها 128 حرفا).
• يستخدم رمز © حقوق النشر 2 بايت.
• يستخدم الحرف "ä" 2 بايت (1 بايت ل "a" و1 بايت للحرف umlaut).
• يستخدم رمز كانجي الياباني للبيانات (資) 3 بايت.

تدعم Azure NetApp Files أيضا بعض الأحرف التي تتجاوز 3 بايت عبر منطق الزوج البديل (مثل رموز المشاعر)، شريطة أن يدعمها ترميز العميل وإصدار البروتوكول. لمزيد من المعلومات حول سلوكيات البروتوكول، راجع:

• سلوكيات SMB
• سلوكيات NFS
• سلوكيات البروتوكول المزدوج

سلوكيات SMB

في وحدات تخزين SMB، تقوم Azure NetApp Files بإنشاء وصيانة اسمين للملفات أو الدلائل في أي دليل لديه حق الوصول من عميل SMB: الاسم الطويل الأصلي والاسم بتنسيق 8.3.

أسماء الملفات في SMB مع Azure NetApp Files

عندما تتجاوز أسماء الملفات أو الدلائل وحدات بايت الأحرف المسموح بها أو تستخدم أحرفا غير معتمدة، تقوم Azure NetApp Files بإنشاء اسم بتنسيق 8.3 كما يلي:

• يتم اقتطاع اسم الملف أو الدليل الأصلي.
• يقوم بإلحاق tilde (~) وأرقام (1-5) بأسماء ملفات أو أدلة لم تعد فريدة بعد اقتطاعها. إذا كان هناك أكثر من خمسة ملفات بأسماء غير أحادية، فإن Azure NetApp Files تنشئ اسما فريدا بدون علاقة بالاسم الأصلي. بالنسبة للملفات، تقوم Azure NetApp Files باقتطاع ملحق اسم الملف إلى ثلاثة أحرف.

على سبيل المثال، إذا أنشأ عميل NFS ملفا باسم specifications.html، فإن Azure NetApp Files ينشئ اسم specif~1.htm الملف باتباع تنسيق 8.3. إذا كان هذا الاسم موجودا بالفعل، فإن Azure NetApp Files تستخدم رقما مختلفا في نهاية اسم الملف. على سبيل المثال، إذا كان عميل NFS ثم يقوم بإنشاء ملف آخر يسمى specifications\_new.html، فإن تنسيق specifications\_new.html 8.3 هو specif~2.htm.

حرف خاص في SMB مع Azure NetApp Files

عند استخدام SMB مع وحدات تخزين Azure NetApp Files، يسمح بالأحرف التي تتجاوز 3 بايت المستخدمة في أسماء الملفات والمجلدات (بما في ذلك رموز المشاعر) بسبب دعم الزوج البديل. فيما يلي ما يراه مستكشف Windows للأحرف خارج BMP على مجلد تم إنشاؤه من عميل Windows عند استخدام اللغة الإنجليزية مع ترميز UTF-16 الافتراضي.

إشعار

الخط الافتراضي في مستكشف Windows هو Segoe UI. يمكن أن تؤثر تغييرات الخط على كيفية عرض بعض الأحرف على العملاء.

تعتمد كيفية عرض الأحرف على العميل على خط النظام وإعدادات اللغة والإعدادات المحلية. بشكل عام، يتم دعم الأحرف التي تقع في BMP عبر جميع البروتوكولات، بغض النظر عما إذا كان الترميز هو UTF-8 أو UTF-16.

عند استخدام CMD أو PowerShell، يعتمد عرض مجموعة الأحرف على إعدادات الخط. تحتوي هذه الأدوات المساعدة على خيارات خطوط محدودة بشكل افتراضي. يستخدم CMD Consolas كخط افتراضي.

قد لا يتم عرض أسماء الملفات كما هو متوقع استنادا إلى الخط المستخدم لأن بعض وحدات التحكم لا تدعم في الأصل Segoe UI أو الخطوط الأخرى التي تعرض الأحرف الخاصة بشكل صحيح.

يمكن معالجة هذه المشكلة على عملاء Windows باستخدام PowerShell ISE، والذي يوفر دعما أكثر قوة للخطوط. على سبيل المثال، يؤدي تعيين PowerShell ISE إلى Segoe UI إلى عرض أسماء الملفات مع الأحرف المدعومة بشكل صحيح.

ومع ذلك، تم تصميم PowerShell ISE للبرمجة النصية، بدلا من إدارة المشاركات. توفر إصدارات Windows الأحدث وحدة طرفية لـ Windows، ما يسمح بالتحكم في الخطوط وقيم الترميز.

إشعار

chcp استخدم الأمر لعرض الترميز للمحطة الطرفية. للحصول على قائمة كاملة بصفحات التعليمات البرمجية، راجع معرفات صفحة التعليمات البرمجية.

إذا تم تمكين وحدة التخزين للبروتوكول المزدوج (كل من NFS وSMB)، فقد تلاحظ سلوكيات مختلفة. لمزيد من المعلومات، راجع سلوكيات البروتوكول المزدوج مع مجموعات الأحرف الخاصة.

سلوكيات NFS

تعتمد كيفية عرض NFS للأحرف الخاصة على إصدار NFS المستخدم وإعدادات الإعدادات المحلية للعميل والخطوط المثبتة وإعدادات عميل الاتصال البعيد قيد الاستخدام. على سبيل المثال، استخدام Bastion للوصول إلى عميل Ubuntu يعالج عرض الحرف بشكل مختلف عن عميل PuTTY الذي تم تعيينه إلى إعدادات محلية مختلفة على نفس الجهاز الظاهري. تعتمد أمثلة NFS التالية على إعدادات الإعدادات المحلية هذه لجهاز Ubuntu الظاهري:

~$ locale
LANG=C.UTF-8
LANGUAGE=
LC\_CTYPE="C.UTF-8"
LC\_NUMERIC="C.UTF-8"
LC\_TIME="C.UTF-8"
LC\_COLLATE="C.UTF-8"
LC\_MONETARY="C.UTF-8"
LC\_MESSAGES="C.UTF-8"
LC\_PAPER="C.UTF-8"
LC\_NAME="C.UTF-8"
LC\_ADDRESS="C.UTF-8"
LC\_TELEPHONE="C.UTF-8"
LC\_MEASUREMENT="C.UTF-8"
LC\_IDENTIFICATION="C.UTF-8"
LC\_ALL=

سلوك NFSv3

لا يفرض NFSv3 ترميز UTF على الملفات والمجلدات. في معظم الحالات، يجب ألا تواجه مجموعات الأحرف الخاصة أي مشكلات. ومع ذلك، يمكن أن يؤثر عميل الاتصال المستخدم على كيفية إرسال الأحرف وتلقيها. على سبيل المثال، يمكن أن يؤدي استخدام أحرف Unicode خارج BMP لاسم مجلد في Bastion عميل اتصال Azure إلى بعض السلوك غير المتوقع بسبب كيفية عمل ترميز العميل.

في لقطة الشاشة التالية، يتعذر على Bastion نسخ القيم ولصقها في موجه CLI من خارج المستعرض عند تسمية دليل عبر NFSv3. عند محاولة نسخ قيمة NFSv3Bastion𓀀𫝁😃𐒸، يتم عرض الأحرف الخاصة كعلامات اقتباس في الإدخال ولصقها.

يسمح بأمر النسخ واللصق عبر NFSv3، ولكن يتم إنشاء الأحرف كقيم رقمية لها، مما يؤثر على عرضها:

NFSv3Bastion'$'\262\270\355\240\214\355\260\200\355\241\255\355\275\201\355\240\275\355\270\203\355\240\201\355

يرجع هذا العرض إلى الترميز المستخدم من قبل Bastion لإرسال قيم نصية عند النسخ واللصق.

عند استخدام PuTTY لإنشاء مجلد بنفس الأحرف عبر NFSv3، فإن اسم المجلد يختلف عن اسم المجلد في Bastion عما كان عليه عند استخدام Bastion لإنشائه. يظهر رمز المشاعر كما هو متوقع (بسبب الخطوط المثبتة وإعداد الإعدادات المحلية)، ولكن الأحرف الأخرى (مثل Osage "𐒸") لا تظهر.

من نافذة PuTTY، يتم عرض الأحرف بشكل صحيح:

سلوك NFSv4.x

يفرض NFSv4.x ترميز UTF-8 في أسماء الملفات والمجلدات لكل مواصفات تدويل RFC-8881.

ونتيجة لذلك، إذا تم إرسال حرف خاص بترميز غير UTF-8، فقد لا يسمح NFSv4.x بالقيمة.

في بعض الحالات، يمكن السماح لأمر باستخدام حرف خارج المستوى الأساسي متعدد اللغات (BMP)، ولكنه قد لا يعرض القيمة بعد إنشائه.

على سبيل المثال، mkdir الإصدار باسم مجلد بما في ذلك الأحرف "𓀀𫝁😃𐒸" (الأحرف في المستويات التكميلية متعددة اللغات (SMP) و Ideographic Plane التكميلية (SIP)) يبدو ناجحا في NFSv4.x. لن يكون المجلد مرئيا عند تشغيل ls الأمر.

root@ubuntu:/NFSv4/NFS$ mkdir "NFSv4 Putty 𓀀𫝁😃𐒸"

root@ubuntu:/NFSv4/NFS$ ls -la

total 8

drwxrwxr-x 3 nobody 4294967294 4096 Jan 10 17:15 .

drwxrwxrwx 4 root root 4096 Jan 10 17:15 ..

root@ubuntu:/NFSv4/NFS$

المجلد موجود في وحدة التخزين. يعمل التغيير إلى اسم الدليل المخفي هذا من عميل PuTTY، ويمكن إنشاء ملف داخل هذا الدليل.

root@ubuntu:/NFSv4/NFS$ cd "NFSv4 Putty 𓀀𫝁😃𐒸"

root@ubuntu:/NFSv4/NFS/NFSv4 Putty 𓀀𫝁😃𐒸$ sudo touch Unicode.txt

root@ubuntu:/NFSv4/NFS/NFSv4 Putty 𓀀𫝁😃𐒸$ ls -la

-rw-r--r-- 1 root root 0 Jan 10 17:31 Unicode.txt

يؤكد أمر إحصائي من PuTTY أيضا وجود المجلد:

root@ubuntu:/NFSv4/NFS$ stat "NFSv4 Putty 𓀀𫝁😃𐒸"

**File: NFSv4 Putty**  **𓀀**** 𫝁 ****😃**** 𐒸**

Size: 4096 Blocks: 8 IO Block: 262144 **directory**

Device: 3ch/60d Inode: 101 Links: 2

Access: (0775/drwxrwxr-x) Uid: ( 0/ root) Gid: ( 0/ root)

Access: 2024-01-10 17:15:44.860775000 +0000

Modify: 2024-01-10 17:31:35.049770000 +0000

Change: 2024-01-10 17:31:35.049770000 +0000

Birth: -

على الرغم من تأكيد وجود المجلد، لا تعمل أوامر أحرف البدل، حيث لا يمكن للعميل "الاطلاع" رسميا على المجلد في العرض.

root@ubuntu:/NFSv4/NFS$ cp \* /NFSv3/

cp: can't stat '\*': No such file or directory

يرسل NFSv4.1 خطأ إلى العميل عندما يواجه حرفا لا يعتمد على ترميز UTF-8.

على سبيل المثال، عند استخدام Bastion لمحاولة الوصول إلى نفس الدليل الذي أنشأناه باستخدام PuTTY عبر NFSv4.1، هذه هي النتيجة:

root@ubuntu:/NFSv4/NFS$ cd "NFSv4 Putty 𓀀𫝁😃�"

-bash: cd: $'NFSv4 Putty \262\270\355\240\214\355\260\200\355\241\255\355\275\201\355\240\275\355\270\203\355\240\201\355': Invalid argument

The "invalid argument" error message doesn't help diagnose the root cause, but a packet capture shines a light on the problem:

78 1.704856 y.y.y.y x.x.x.x NFS 346 V4 Call (Reply In 79) LOOKUP DH: 0x44caa451/NFSv4 Putty ��������

79 1.705058 x.x.x.x y.y.y.y NFS 166 V4 Reply (Call In 25) OPEN Status: NFS4ERR\_INVAL

تتم تغطية NFS4ERR_INVAL في RFC-8881.

نظرا لأنه يمكن الوصول إلى المجلد من PuTTY (بسبب الترميز الذي يتم إرساله وتلقيه)، يمكن نسخه إذا تم تحديد الاسم. بعد نسخ هذا المجلد من وحدة تخزين NFSv4.1 Azure NetApp Files إلى وحدة تخزين NFSv3 Azure NetApp Files، يعرض اسم المجلد:

root@ubuntu:/NFSv4/NFS$ cp -r /NFSv4/NFS/"NFSv4 Putty 𓀀𫝁😃𐒸" /NFSv3/NFSv3/

root@ubuntu:/NFSv4/NFS$ ls -la /NFSv3/NFSv3 | grep v4

drwxrwxr-x 2 root root 4096 Jan 10 17:49 NFSv4 Putty 𓀀𫝁😃𐒸

يمكن رؤية الخطأ نفسه NFS4ERR\_INVAL إذا تمت محاولة تحويل ملف (باستخدام 'iconv') إلى تنسيق غير UTF-8، مثل Shift-JIS.

# echo "Test file with SJIS encoded filename" \> "$(echo 'テストファイル.txt' | iconv -t SJIS)"
 -bash: $(echo 'テストファイル.txt' | iconv -t SJIS): Invalid argument

لمزيد من المعلومات، راجع تحويل الملفات إلى ترميزات مختلفة.

سلوكيات البروتوكول المزدوج

تسمح Azure NetApp Files بالوصول إلى وحدات التخزين بواسطة كل من NFS وSMB عبر الوصول إلى البروتوكول المزدوج. بسبب الاختلافات الشاسعة في ترميز اللغة المستخدمة من قبل NFS (UTF-8) وSMB (UTF-16)، يمكن أن يكون لمجموعات الأحرف وأسماء الملفات والمجلدات وأطوال المسار سلوكيات مختلفة جدا عبر البروتوكولات.

عرض الملفات والمجلدات التي تم إنشاؤها بواسطة NFS من SMB

عند استخدام Azure NetApp Files للوصول إلى البروتوكول المزدوج (SMB وNFS)، قد يتم استخدام مجموعة أحرف غير مدعومة من قبل UTF-16 في اسم ملف تم إنشاؤه باستخدام UTF-8 عبر NFS. في هذه السيناريوهات، عندما يصل SMB إلى ملف بأحرف غير معتمدة، يتم اقتطاع الاسم في SMB باستخدام اصطلاح اسم الملف القصير 8.3.

الملفات التي تم إنشاؤها بواسطة NFSv3 وسلوكيات SMB مع مجموعات الأحرف

لا يفرض NFSv3 ترميز UTF-8. تعمل الأحرف التي تستخدم ترميزات لغة غير قياسية (مثل Shift-JIS) مع Azure NetApp Files عند استخدام NFSv3.

في المثال التالي، تم إنشاء سلسلة من أسماء المجلدات باستخدام مجموعات أحرف مختلفة من مستويات مختلفة في Unicode في وحدة تخزين Azure NetApp Files باستخدام NFSv3. عند عرضها من NFSv3، تظهر هذه بشكل صحيح.

root@ubuntu:/NFSv3/dual$ ls -la

drwxrwxr-x 2 root root 4096 Jan 10 19:43 NFSv3-BMP-English

drwxrwxr-x 2 root root 4096 Jan 10 19:43 NFSv3-BMP-Japanese-German-資ä

drwxrwxr-x 2 root root 4096 Jan 10 19:43 NFSv3-BMP-copyright-©

drwxrwxr-x 2 root root 4096 Jan 10 19:44 NFSv3-CJK-plane2-𫝁

drwxrwxr-x 2 root root 4096 Jan 10 19:44 NFSv3-emoji-plane1-😃

من Windows SMB، يتم عرض المجلدات ذات الأحرف الموجودة في BMP بشكل صحيح، ولكن يتم عرض الأحرف خارج تلك الطائرة بتنسيق الاسم 8.3 بسبب عدم توافق تحويل UTF-8/UTF-16 لتلك الأحرف.

الملفات التي تم إنشاؤها بواسطة NFSv4.1 وسلوكيات SMB مع مجموعات الأحرف

في الأمثلة السابقة، تم إنشاء مجلد باسم NFSv4 Putty 𓀀𫝁😃𐒸 على وحدة تخزين Azure NetApp Files عبر NFSv4.1، ولكن لم يكن قابلا للعرض باستخدام NFSv4.1. ومع ذلك، يمكن رؤيته باستخدام SMB. يتم اقتطاع الاسم بتنسيق SMB إلى تنسيق 8.3 معتمد بسبب مجموعات الأحرف غير المدعومة التي تم إنشاؤها من عميل NFS وتحويل UTF-8/UTF-16 غير المتوافق للأحرف في مستويات Unicode مختلفة.

عندما يستخدم اسم المجلد أحرف UTF-8 القياسية الموجودة في BMP (الإنجليزية أو غير ذلك)، فإن SMB يترجم الأسماء بشكل صحيح.

root@ubuntu:/NFSv4/NFS$ mkdir NFS-created-English

root@ubuntu:/NFSv4/NFS$ mkdir NFS-created-資ä

root@ubuntu:/NFSv4/NFS$ ls -la

total 16

drwxrwxr-x 5 nobody 4294967294 4096 Jan 10 18:26 .

drwxrwxrwx 4 root root 4096 Jan 10 17:15 ..

**drwxrwxr-x 2 root root 4096 Jan 10 18:21 NFS-created-English**

**drwxrwxr-x 2 root root 4096 Jan 10 18:26 NFS-created-**** 資 ****ä**

الملفات والمجلدات التي تم إنشاؤها بواسطة SMB عبر NFS

عملاء Windows هم النوع الأساسي من العملاء الذين يتم استخدامهم للوصول إلى مشاركات SMB. هؤلاء العملاء افتراضيا إلى ترميز UTF-16. من الممكن دعم بعض الأحرف المشفرة UTF-8 في Windows عن طريق تمكينها في إعدادات المنطقة:

عند إنشاء ملف أو مجلد عبر مشاركة SMB في Azure NetApp Files، يتم ترميز مجموعة الأحرف ك UTF-16. ونتيجة لذلك، قد لا يتمكن العملاء الذين يستخدمون ترميز UTF-8 (مثل عملاء NFS المستندين إلى Linux) من ترجمة بعض مجموعات الأحرف بشكل صحيح - خاصة الأحرف التي تقع خارج المستوى الأساسي متعدد اللغات (BMP) .

سلوك حرف غير معتمد

في هذه السيناريوهات، عندما يصل عميل NFS إلى ملف تم إنشاؤه باستخدام SMB بأحرف غير مدعومة، يظهر الاسم كسلسلة من القيم الرقمية التي تمثل قيم Unicode للحرف.

على سبيل المثال، تم إنشاء هذا المجلد في مستكشف Windows باستخدام أحرف خارج BMP.

PS Z:\SMB\> dir

Directory: Z:\SMB

Mode LastWriteTime Length Name

---- ------------- ------ ----

d----- 1/9/2024 9:53 PM SMB𓀀𫝁😃𐒸

عبر NFSv3، يظهر المجلد الذي تم إنشاؤه بواسطة SMB:

$ ls -la

drwxrwxrwx 2 root daemon 4096 Jan 9 21:53 'SMB'$'\355\240\214\355\260\200\355\241\255\355\275\201\355\240\275\355\270\203\355\240\201\355\262\270'

عبر NFSv4.1، يظهر المجلد الذي تم إنشاؤه بواسطة SMB كما يلي:

$ ls -la

drwxrwxrwx 2 root daemon 4096 Jan 4 17:09 'SMB'$'\355\240\214\355\260\200\355\241\255\355\275\201\355\240\275\355\270\203\355\240\201\355\262\270'

سلوك الحرف المعتمد

عندما تكون الأحرف في BMP، لا توجد مشكلات بين بروتوكولات SMB وNFS وإصداراتها.

على سبيل المثال، يظهر اسم المجلد الذي تم إنشاؤه باستخدام SMB على وحدة تخزين Azure NetApp Files مع أحرف موجودة في BMP عبر لغات متعددة (الإنجليزية والألمانية والسيريلية وRunic) بشكل جيد عبر جميع البروتوكولات والإصدارات.

• اللغة اللاتينية الأساسية "SMB"
• اليونانية "ͶΘΩ"
• السيريلية "ЁЄЊ"
• Runic "ᚠᚱᛯ"
• Ideographs توافق CJK "豈滑虜"

هذه هي الطريقة التي يظهر بها الاسم في SMB:

PS Z:\SMB\> mkdir SMBͶΘΩЁЄЊᚠᚱᛯ豈滑虜

Mode LastWriteTime Length Name

---- ------------- ------ ----

d----- 1/11/2024 8:00 PM SMBͶΘΩЁЄЊᚠᚱᛯ豈滑虜

هذه هي الطريقة التي يظهر بها الاسم من NFSv3:

$ ls | grep SMBͶΘΩЁЄЊᚠᚱᛯ豈滑虜

SMBͶΘΩЁЄЊᚠᚱᛯ豈滑虜

هذه هي الطريقة التي يظهر بها الاسم من NFSv4.1:

$ ls /NFSv4/SMB | grep SMBͶΘΩЁЄЊᚠᚱᛯ豈滑虜

SMBͶΘΩЁЄЊᚠᚱᛯ豈滑虜

تحويل الملفات إلى ترميزات مختلفة

أسماء الملفات والمجلدات ليست الأجزاء الوحيدة من كائنات نظام الملفات التي تستخدم ترميزات اللغة. يمكن أن تؤدي محتويات الملف (مثل الأحرف الخاصة داخل ملف نصي) دورا أيضا. على سبيل المثال، إذا تمت محاولة حفظ ملف بأحرف خاصة بتنسيق غير متوافق، فقد تظهر رسالة خطأ. في هذه الحالة، لا يمكن حفظ ملف بأحرف Katagana في ANSI، لأن هذه الأحرف غير موجودة في هذا الترميز.

بمجرد حفظ هذا الملف بهذا التنسيق، يتم تحويل الأحرف إلى علامات استفهام:

يمكن عرض ترميزات الملفات من عملاء NAS. على عملاء Windows، يمكنك استخدام تطبيق مثل المفكرة أو المفكرة++ لعرض ترميز ملف. إذا تم تثبيت نظام Windows الفرعي لـ Linux (WSL) أو Git على العميل، file يمكن استخدام الأمر.

تسمح لك هذه التطبيقات أيضا بتغيير ترميز الملف عن طريق الحفظ لأنواع ترميز مختلفة. بالإضافة إلى ذلك، يمكن استخدام PowerShell لتحويل الترميز على الملفات باستخدام Get-Content cmdlets و Set-Content .

على سبيل المثال، يتم ترميز الملف utf8-text.txt ك UTF-8 ويحتوي على أحرف خارج BMP. نظرا لاستخدام UTF-8، يتم عرض الأحرف بشكل صحيح.

إذا تم تحويل الترميز إلى UTF-32، فلن يتم عرض الأحرف بشكل صحيح.

PS Z:\SMB\> Get-Content .\utf8-text.txt |Set-Content -Encoding UTF32 -Path utf32-text.txt

Get-Content يمكن أيضا استخدام لعرض محتويات الملف. بشكل افتراضي، يستخدم PowerShell ترميز UTF-16 (صفحة التعليمات البرمجية 437) وتكون تحديدات الخطوط لوحدة التحكم محدودة، لذلك لا يمكن عرض الملف المنسق UTF-8 بأحرف خاصة بشكل صحيح:

يمكن لعملاء Linux استخدام file الأمر لعرض ترميز الملف. في بيئات البروتوكول المزدوج، إذا تم إنشاء ملف باستخدام SMB، يمكن لعميل Linux باستخدام NFS التحقق من ترميز الملف.

$ file -i utf8-text.txt

utf8-text.txt: text/plain; charset=utf-8

$ file -i utf32-text.txt

utf32-text.txt: text/plain; charset=utf-32le

يمكن إجراء تحويل ترميز الملف على عملاء Linux باستخدام iconv الأمر . لمشاهدة قائمة تنسيقات الترميز المعتمدة، استخدم iconv -l.

على سبيل المثال، يمكن تحويل الملف المشفرة UTF-8 إلى UTF-16.

$ iconv -t UTF16 utf8-text.txt \> utf16-text.txt

$ file -i utf8-text.txt

utf8-text.txt: text/plain; **charset=utf-8**

$ file -i utf16-text.txt

utf16-text.txt: text/plain; **charset=utf-16le**

إذا كانت الأحرف التي تم تعيينها على اسم الملف أو في محتويات الملف غير معتمدة بواسطة ترميز الوجهة، فلن يسمح بالتحويل. على سبيل المثال، لا يمكن ل Shift-JIS دعم الأحرف في محتويات الملف.

$ iconv -t SJIS utf8-text.txt SJIS-text.txt

iconv: illegal input sequence at position 0

إذا كان الملف يحتوي على أحرف معتمدة بواسطة الترميز، فسينجح التحويل. على سبيل المثال، إذا كان الملف يحتوي على أحرف Katagana テストファイル، فسينجح تحويل Shift-JIS عبر NFS. نظرا لأن عميل NFS المستخدم هنا لا يفهم Shift-JIS بسبب إعدادات الإعدادات المحلية، يظهر الترميز "unknown-8bit".

$ cat SJIS.txt

テストファイル

$ file -i SJIS.txt

SJIS.txt: text/plain; charset=utf-8

$ iconv -t SJIS SJIS.txt \> SJIS2.txt

$ file -i SJIS.txt

SJIS.txt: text/plain; **charset=utf-8**

$ file -i SJIS2.txt

SJIS2.txt: text/plain; **charset=unknown-8bit**

نظرا لأن وحدات تخزين Azure NetApp Files تدعم التنسيق المتوافق مع UTF-8 فقط، يتم تحويل أحرف Katagana إلى تنسيق غير قابل للقراءة.

$ cat SJIS2.txt

▒e▒X▒g▒t▒@▒C▒▒

عند استخدام NFSv4.x، يسمح بالتحويل عندما تكون الأحرف غير المتوافقة موجودة داخل محتويات الملف، على الرغم من أن NFSv4.x يفرض ترميز UTF-8. في هذا المثال، يعرض ملف UTF-8 المشفر بأحرف Katagana الموجودة على وحدة تخزين Azure NetApp Files محتويات الملف بشكل صحيح.

$ file -i SJIS.txt

SJIS.txt: text/plain; charset=utf-8

S$ cat SJIS.txt

テストファイル

ولكن بمجرد تحويله، يتم عرض الأحرف في الملف بشكل غير صحيح بسبب الترميز غير المتوافق.

$ cat SJIS2.txt

▒e▒X▒g▒t▒@▒C▒▒

إذا كان اسم الملف يحتوي على أحرف غير معتمدة ل UTF-8، فسينجح التحويل عبر NFSv3، ولكنه يفشل عبر NFSv4.x بسبب فرض UTF-8 لإصدار البروتوكول.

# echo "Test file with SJIS encoded filename" \> "$(echo 'テストファイル.txt' | iconv -t SJIS)"

-bash: $(echo 'テストファイル.txt' | iconv -t SJIS): Invalid argument

أفضل ممارسات مجموعة الأحرف

عند استخدام أحرف خاصة أو أحرف خارج المستوى الأساسي متعدد اللغات (BMP) القياسي على وحدات تخزين Azure NetApp Files، يجب الاحتفاظ ببعض أفضل الممارسات في الاعتبار.

• نظرا لأن وحدات تخزين Azure NetApp Files تستخدم لغة وحدة التخزين UTF-8، يجب أن يستخدم ترميز الملفات لعملاء NFS أيضا ترميز UTF-8 للحصول على نتائج متسقة.
• يجب أن تكون مجموعات الأحرف في أسماء الملفات أو الموجودة في محتويات الملف متوافقة مع UTF-8 للعرض والوظائف المناسبة.
• نظرا لأن SMB يستخدم ترميز UTF-16 حرفا، فقد لا يتم عرض الأحرف خارج BMP بشكل صحيح عبر NFS في وحدات تخزين البروتوكول المزدوج. قم بتقليص استخدام الأحرف الخاصة في محتويات الملف قدر الإمكان.
• تجنب استخدام أحرف خاصة خارج BMP في أسماء الملفات، خاصة عند استخدام وحدات تخزين NFSv4.1 أو بروتوكول مزدوج.
• بالنسبة لمجموعات الأحرف غير الموجودة في BMP، يجب أن يسمح ترميز UTF-8 بعرض الأحرف في Azure NetApp Files عند استخدام بروتوكول ملف واحد (SMB فقط أو NFS فقط). ومع ذلك، لا تتمكن وحدات تخزين البروتوكول المزدوج من استيعاب مجموعات الأحرف هذه في معظم الحالات.
• الترميز غير المتوافق (مثل Shift-JIS) غير مدعوم على وحدات تخزين Azure NetApp Files.
• يتم دعم أحرف الزوج البديل (مثل رموز المشاعر) على وحدات تخزين Azure NetApp Files.

الخطوات التالية

• فهم أطوال المسار في Azure NetApp Files