Общие сведения о языках томов в Azure NetApp Files

Статья
02/21/2024

Язык томов (а также системные языковые стандарты в клиентских операционных системах) тома Azure NetApp Files управляет поддерживаемыми языками и наборами символов при использовании протоколов NFS и S МБ. Azure NetApp Files использует язык тома по умолчанию C.UTF-8, который предоставляет кодировку UTF-8, соответствующую POSIX для наборов символов. Язык C.UTF-8 изначально поддерживает символы с размером 0-3 байта, который включает большинство языков мира на базовой многоязычной плоскости (BMP) (включая японский, немецкий и большую часть иврита и кириллицы). Дополнительные сведения о BMP см . в Юникоде.

Символы за пределами 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. Дополнительные сведения см. в разделе "Поведение протокола" со специальными наборами символов.

Рекомендации см. в рекомендациях по набору символов.

Кодировка символов в томах Azure NetApp Files NFS и S МБ

В среде общего доступа к файлам Azure NetApp Files имена файлов и папок представлены рядом символов, которые пользователи считывают и интерпретируют. Способ отображения этих символов зависит от того, как клиент отправляет и получает кодировку этих символов. Например, если клиент отправляет устаревшую кодировку ASCII (американский стандартный код для обмена информацией) тому Azure NetApp Files при доступе к нему, то при доступе к нему может отображаться только символы, поддерживаемые в формате ASCII.

Например, японский символ для данных — 資. Так как этот символ не может быть представлен в ASCII, клиент, использующий кодировку ASCII, отображает "?" вместо 資.

ASCII поддерживает только 95 печатных символов, главным образом те, которые находятся на английском языке. Каждый из этих символов использует 1 байт, который учитывается в общей длине пути к файлу в томе Azure NetApp Files. Это ограничивает интернационализацию наборов данных, так как имена файлов могут иметь различные символы, не распознанные ASCII, от японского до кириллицы до эмодзи. Международный стандарт (ISO/IEC 8859) попытался поддержать больше международных символов, но также имел свои ограничения. Большинство современных клиентов отправляют и получают символы с помощью некоторой формы Юникода.

Unicode

В результате ограничений кодировки ASCII и ISO/IEC 8859 был установлен стандарт Юникода, чтобы любой пользователь мог просматривать язык своего домашнего региона на своих устройствах.

Юникод поддерживает более одного миллиона наборов символов, увеличив число разрешенных символов (до 4 байтов) и общее количество байтов, разрешенных в пути к файлу, в отличие от старых кодировок, таких как ASCII.
Юникод поддерживает обратную совместимость путем резервирования первых 128 символов для ASCII, а также обеспечения того, что первые 256 кодовых точек идентичны стандартам ISO/IEC 8859.
В стандарте Юникод наборы символов разбиваются на плоскости. Плоскость — это непрерывная группа из 65 536 точек кода. В общей сложности 17 самолетов (0-16) в стандарте Юникода. Ограничение равно 17 из-за ограничений UTF-16.
Плоскость 0 — базовая многоязычная плоскость (BMP). Эта плоскость содержит наиболее часто используемые символы на нескольких языках.
Из 17 самолетов только пять в настоящее время назначены наборы символов в Юникоде версии 15.1.
Самолеты 1-17 называются дополнительными многоязычными самолетами (SMP) и содержат менее используемые наборы символов, например древние системы письма, такие как клиноформа и иероглифы, а также специальные символы китайского/японского или корейского (CJK).
Методы для просмотра длины символов и размеров пути и управления кодировкой, отправленной в систему, см. в разделе "Преобразование файлов в разные кодировки".

Юникод использует формат преобразования Юникода в качестве стандартного формата, так как UTF-8 и UTF-16 являются двумя основными форматами.

Плоскости Юникода

Юникод использует 17 самолетов из 655 536 символов (256 точек кода, умноженных на 256 прямоугольника в плоскости), с плоскости 0 в качестве основной многоязычной плоскости (BMP). Эта плоскость содержит наиболее часто используемые символы на нескольких языках. Поскольку языки и наборы символов в мире превышают 65536 символов, для поддержки менее часто используемых наборов символов требуется больше плоскостей.

Например, плоскость 1 (дополнительные многоязычные самолеты (SMP)) включает в себя исторические сценарии, такие как книформа и египетские иероглифы, а также некоторые Осаж, Warang Citi, Adlam, Wancho и Toto. Плоскость 1 также включает некоторые символы и смайлики .

Плоскость 2 — дополнительный идеографический плоскость (SIP) — содержит китайские/японские и корейские (CJK) унифицированные идеографы. Символы в плоскостях 1 и 2 обычно имеют размер 4 байта.

Например:

"Усыпленное лицо с большими глазами" смайлика "😃" в плоскости 1 составляет 4 байта в размере.
Египетский иероглиф "𓀀" в плоскости 1 составляет 4 байта.
Символ Osage "𐒸" в плоскости 1 составляет 4 байта.
Символ CJK "𫝁" в плоскости 2 составляет 4 байта.

Так как эти символы имеют размер >3 байта, им требуется правильное использование суррогатных пар. Azure NetApp Files изначально поддерживает суррогатные пары, но отображение символов зависит от используемого протокола, параметров языкового стандарта клиента и параметров удаленного клиентского приложения доступа.

UTF-8

UTF-8 использует 8-разрядную кодировку и может содержать до 1112 064 кодовых точек (или символов). UTF-8 — это стандартная кодировка на всех языках в операционных системах под управлением Linux. Так как UTF-8 использует 8-разрядную кодировку, максимально возможное целое число без знака равно 255 (2^8 – 1), что также является максимальной длиной имени файла для этой кодировки. UTF-8 используется на более чем 98% страниц в Интернете, что делает его наиболее принятым стандартом кодирования. Рабочая группа веб-приложений Hypertext (WHATWG) рассматривает UTF-8 "обязательное кодирование для всех [текста]" и что по соображениям безопасности браузерные приложения не должны использовать UTF-16.

Символы в формате UTF-8 используют от 1 до 4 байтов, но почти все символы во всех языках используются от 1 до 3 байт. Например:

Латинская буква "A" использует 1 байт. (Один из 128 зарезервированных символов ASCII)
Символ авторских прав использует © 2 байта.
Символ "ä" использует 2 байта. (1 байт для "a" + 1 байт для umlaut)
Японский символ Kanji для данных (資) использует 3 байта.
Усыпляющее лицо эмодзи (😃) использует 4 байта.

Языковые стандарты языка могут использовать стандартный формат UTF-8 (C.UTF-8) или более конкретный формат региона, например en_US. UTF-8, ja. UTF-8 и т. д. При доступе к Azure NetApp Files при возможности следует использовать кодировку UTF-8 для клиентов Linux. По состоянию на OS X клиенты macOS также используют UTF-8 для кодирования по умолчанию и не должны быть скорректированы.

Клиенты Windows используют UTF-16. В большинстве случаев этот параметр должен оставаться в качестве языкового стандарта ОС по умолчанию, но более новые клиенты предлагают бета-поддержку символов UTF-8 через проверка box. Клиенты терминалов в Windows также можно настроить для использования UTF-8 в PowerShell или CMD по мере необходимости. Дополнительные сведения см. в разделе "Поведение двойного протокола" с специальными наборами символов.

UTF-16

UTF-16 использует 16-разрядную кодировку и может кодировать все 112 064 кодовых точек Юникода. Кодировка для UTF-16 может использовать один или два 16-разрядных единиц кода, каждый 2 байта в размере. Все символы в UTF-16 используют 2 или 4-байтовые размеры. Символы в UTF-16, использующие 4 байта, используют суррогатные пары, которые объединяют два отдельных двухбайтовых символа для создания нового символа. Эти дополнительные символы выходят за пределы стандартной плоскости BMP и в один из других многоязычных самолетов.

UTF-16 используется в операционных системах Windows и API, Java и JavaScript. Так как он не поддерживает обратную совместимость с форматами ASCII, он никогда не получил популярность в Интернете. UTF-16 составляет только около 0,002% всех страниц в Интернете. Рабочая группа технологий веб-приложений Hypertext (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 является языком тома. Японский символ для "data" (資) отображается по-разному в зависимости от кодировки, отправляемой терминалом.

Кодировка символов в PuTTY

Если окно PuTTY использует UTF-8 (найдено в параметрах перевода Windows), символ представлен правильно для подключенного тома NFSv3 в Azure NetApp Files:

Если в окне PuTTY используется другая кодировка, например ISO-8859-1:1998 (Latin-1, Западная Европа), то тот же символ отображается по-разному, даже если имя файла совпадает.

PuTTY по умолчанию не содержит кодировки CJK. Для добавления этих языковых наборов в PuTTY доступны исправления.

Кодировки символов в Бастионе

Microsoft Azure рекомендует использовать Бастион для удаленного подключения к виртуальным машинам в Azure. При использовании Бастиона кодирование языка отправляется и получено не предоставляется в конфигурации, но использует стандартную кодировку UTF-8. В результате большинство наборов символов, отображаемых в PuTTY с помощью UTF-8, также должны быть видимы в Бастионе, если наборы символов поддерживаются в используемом протоколе.

Совет

Другие терминалы SSH можно использовать, например TeraTerm. TeraTerm предоставляет более широкий диапазон поддерживаемых наборов символов по умолчанию, включая кодировки CJK и нестандартные кодировки, такие как SHIFT-JIS.

Поведение протокола со специальными наборами символов

Тома Azure NetApp Files используют кодировку UTF-8 и изначально поддерживают символы, не превышающие 3 байта. Все символы в наборе ASCII и UTF-8 отображаются правильно, так как они попадают в диапазон от 1 до 3 байтов. Например:

Латинский алфавит символ "A" использует 1 байт (один из 128 зарезервированных символов ASCII).
Символ авторского права © использует 2 байта.
Символ "ä" использует 2 байта (1 байт для "a" и 1 байта для umlaut).
Японский символ Kanji для данных (資) использует 3 байта.

Azure NetApp Files также поддерживает некоторые символы, превышающие 3 байта с помощью логики суррогатной пары (например, эмодзи), если поддерживается кодирование клиента и версия протокола. Дополнительные сведения о поведении протокола см. в следующей статье:

Поведение S МБ
Поведение NFS
Поведение двух протоколов

Поведение S МБ

В томах S МБ Azure NetApp Files создает и сохраняет два имени для файлов или каталогов в любом каталоге, который имеет доступ из клиента S МБ: исходное длинное имя и имя в формате 8.3.

Имена файлов в S МБ с помощью Azure NetApp Files

Если имена файлов или каталогов превышают допустимые байты символов или используют неподдерживаемые символы, Azure NetApp Files создает имя формата 8.3 следующим образом:

Он усечение исходного файла или имени каталога.
Он добавляет тильду (~) и числовой (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, формат 8.3 имеет значение specifications\_new.htmlspecif~2.htm.

Специальный символ в S МБ с помощью Azure NetApp Files

При использовании S МБ с томами Azure NetApp Files символы, превышающие 3 байта, используемые в именах файлов и папок (включая смайлики), допускаются из-за поддержки суррогатной пары. Ниже приведено, что windows Обозреватель видит символы за пределами BMP в папке, созданной из клиента Windows, при использовании английского языка с кодировкой UTF-16 по умолчанию.

Примечание.

Шрифт по умолчанию в Windows Обозреватель — segoe UI. Изменения шрифта могут повлиять на отображение некоторых символов на клиентах.

Отображение символов на клиенте зависит от системного шрифта и языковых параметров. Как правило, символы, которые попадают в BMP, поддерживаются во всех протоколах, независимо от того, является ли кодировка UTF-8 или UTF-16.

При использовании CMD или PowerShell представление набора символов может зависеть от параметров шрифта. Эти служебные программы имеют ограниченный выбор шрифта по умолчанию. CMD использует Consolas в качестве шрифта по умолчанию.

Screenshot of command prompt font options.

Имена файлов могут не отображаться должным образом в зависимости от шрифта, используемого в некоторых консоли, не поддерживают пользовательский интерфейс Segoe или другие шрифты, которые правильно отображают специальные символы.

Screenshot of dir output.

Эта проблема может быть устранена на клиентах Windows с помощью среды сценариев PowerShell, которая обеспечивает более надежную поддержку шрифтов. Например, при настройке isE PowerShell в пользовательский интерфейс Segoe отображаются имена файлов с поддерживаемыми символами правильно.

Однако среда сценариев PowerShell предназначена для сценариев, а не для управления общими ресурсами. Новые версии Windows предлагают Терминал Windows, что позволяет управлять шрифтами и значениями кодирования.

Примечание.

chcp Используйте команду для просмотра кодирования для терминала. Полный список кодовых страниц см. в разделе "Кодовые идентификаторы".

Screenshot of command output.

Если том включен для двойного протокола (как NFS, так и S МБ), может наблюдаться различные действия. Дополнительные сведения см. в статье о поведении двух протоколов с специальными наборами символов.

Поведение NFS

Отображение специальных символов NFS зависит от используемой версии NFS, параметров языкового стандарта клиента, установленных шрифтов и параметров используемого клиента удаленного подключения. Например, использование Бастиона для доступа к клиенту 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 для файлов и папок. В большинстве случаев специальные наборы символов не должны иметь проблем. Однако используемый клиент подключения может повлиять на способ отправки и получения символов. Например, использование символов Юникода за пределами BMP для имени папки в бастионе подключения Azure может привести к неожиданному поведению из-за того, как работает кодировка клиента.

На следующем снимке экрана Бастион не может скопировать и вставить значения в запрос CLI извне браузера при именовании каталога по протоколу NFSv3. При попытке копирования и вставки значения NFSv3Bastion𓀀𫝁😃𐒸специальные символы отображаются как кавычки во входных данных.

Screenshot mkdir command in Bastion.

Команда копирования вставить разрешена через 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

Это отображение связано с кодировкой, используемой Бастионом для отправки текстовых значений при копировании и вставки.

При использовании PuTTY для создания папки с теми же символами через NFSv3 имя папки отличается от имени в Бастионе, чем при создании бастиона. Смайлик отображается должным образом (из-за установленных шрифтов и параметров языкового стандарта), но другие символы (например, Osage "𐒸") не делают.

Screenshot of incorrect file name output.

В окне PuTTY символы отображаются правильно:

Screenshot of correct file name output.

Поведение NFSv4.x

NFSv4.x применяет кодировку UTF-8 в именах файлов и папок для спецификаций интернационализации RFC-8881.

В результате, если специальный символ отправляется с кодировкой, отличной от UTF-8, NFSv4.x может не разрешить значение.

В некоторых случаях команда может быть разрешена с помощью символа за пределами базовой многоязычной плоскости (BMP), но она может не отображать значение после его создания.

Например, выдача mkdir с именем папки, включая символы "𓀀𫝁𐒸😃" (символы в дополнительных многоязычных плоскостях (SMP) и дополнительный идеографический плоскость (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

Команда stat из 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: -

Несмотря на то что папка подтверждена, команды wild карта не работают, так как клиент официально не может "просмотреть" папку в отображении.

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

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

NFSv4.1 отправляет клиенту ошибку при обнаружении символа, который не зависит от кодировки UTF-8.

Например, при использовании Бастиона для попытки доступа к тому же каталогу, который мы создали с помощью 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, так и S МБ через двойной протокол. Из-за огромных различий в кодировке языка, используемой NFS (UTF-8) и S МБ (UTF-16), наборы символов, имена файлов и папок и длины пути могут иметь очень разные поведение между протоколами.

Просмотр созданных NFS-файлов и папок из S МБ

Если Azure NetApp Files используется для доступа с двумя протоколами (S МБ и NFS), в имени файла, созданном с помощью UTF-16, может использоваться символьный набор, неподдерживаемый UTF-8 через NFS. В таких случаях, когда S МБ обращается к файлу с неподдерживаемых символов, имя усечено в S МБ с помощью соглашения о имени короткого файла 8.3.

Созданные NFSv3 файлы и S МБ поведения с наборами символов

NFSv3 не применяет кодировку UTF-8. Символы, использующие нестандартные кодировки языка (например shift-JIS), работают с Azure NetApp Files при использовании NFSv3.

В следующем примере в томе 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 S МБ папки с символами, найденными в BMP, отображаются правильно, но символы за пределами этого плоскости отображаются с форматом имени 8.3 из-за преобразования UTF-8/UTF-16, несовместимого для этих символов.

Screenshot of Windows Explorer with directory names using special characters.

Созданные файлы NFSv4.1 и S МБ с наборами символов

В предыдущих примерах в томе Azure NetApp Files по сравнению с NFSv4.1 была создана папка с именем NFSv4 Putty 𓀀𫝁😃𐒸 NFSv4.1, но не была просмотрен с помощью NFSv4.1. Однако его можно увидеть с помощью S МБ. Имя усечено в S МБ в поддерживаемый формат 8.3 из-за неподдерживаемых наборов символов, созданных из клиента NFS, и несовместимого преобразования символов UTF-8/UTF-16 для символов в разных плоскостях Юникода.

Screenshot of NFSv4.x directory in Windows Explorer.

Если имя папки использует стандартные символы UTF-8, найденные в BMP (английский или в противном случае), то S МБ правильно переводит имена.

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-**** 資 ****ä**

Screenshot of successfully displayed dual-protocol directory.

Файлы и папки, созданные по протоколу S МБ через NFS

Клиенты Windows — это основной тип клиентов, которые используются для доступа к общим папкам S МБ. Эти клиенты по умолчанию используют кодировку UTF-16. Можно поддерживать некоторые символы в кодировке UTF-8 в Windows, включив его в параметрах региона:

Screenshot of region settings window.

При создании файла или папки через общую папку S МБ в Azure NetApp Files символьный набор используется в кодировке UTF-16. В результате клиенты, использующие кодировку UTF-8 (например, клиенты NFS под управлением Linux), не могут правильно переводить некоторые наборы символов , особенно символы, которые выходят за пределы базового многоязычного уровня (BMP).

Неподдерживаемое поведение символов

В этих сценариях, когда клиент NFS обращается к файлу, созданному с помощью S МБ с неподдерживаемых символов, имя отображается в виде ряда числовых значений, представляющих значения Юникода для символа.

Например, эта папка была создана в Windows Обозреватель с помощью символов за пределами BMP.

PS Z:\SMB\> dir

Directory: Z:\SMB

Mode LastWriteTime Length Name

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

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

Поверх NFSv3 создается папка S МБ:

$ 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 созданная папка S МБ отображается следующим образом:

$ 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, между протоколами S МБ и NFS и их версиями нет проблем.

Например, имя папки, созданное с помощью S МБ в томе Azure NetApp Files с символами, найденными в BMP на нескольких языках (английский, немецкий, кириллический, runic) отображается точно во всех протоколах и версиях.

Базовая латиница "S МБ"
Греческий "Ͷ±±±
Кириллица "ЁЁЩ"
Runic "ᚠᚱᛯ"
Идеографы совместимости CJK "豈滑虜"

Вот как имя отображается в S МБ:


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, так как эти символы не существуют в этой кодировке.

Screenshot of warning about unsupported characters.

После сохранения этого файла в этом формате символы преобразуются в вопросительные знаки:

Screenshot of characters converted to question marks.

Кодировки файлов можно просматривать с клиентов NAS. В клиентах Windows можно использовать приложение, например Блокнот или Блокнот++ для просмотра кодировки файла. Если на клиенте установлены подсистема Windows для Linux (WSL) или Git, file можно использовать команду.

Screenshot of the ANSI encoding option.

Эти приложения также позволяют изменять кодировку файла, сохраняя их в виде разных типов кодирования. Кроме того, PowerShell можно использовать для преобразования кодировки в файлах с Get-Content помощью командлетов и Set-Content командлетов.

Например, файл utf8-text.txt закодирован как UTF-8 и содержит символы за пределами BMP. Так как используется UTF-8, символы отображаются правильно.

Screenshot of correctly rendered UTF-8 characters.

Если кодировка преобразуется в UTF-32, символы не отображаются должным образом.

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

Screenshot of incorrectly rendered UTF-32 characters.

Get-Content также можно использовать для отображения содержимого файла. По умолчанию PowerShell использует кодировку UTF-16 (кодовая страница 437) и выбор шрифта для консоли ограничен, поэтому форматированный файл UTF-8 с специальными символами не может отображаться правильно:

Screenshot of Get-Content command output.

Клиенты Linux могут использовать file команду для просмотра кодирования файла. В средах с двумя протоколами, если файл создается с помощью S МБ, клиент 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 из-за параметров языкового стандарта, кодировка отображает "неизвестно-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

Следующие шаги

Общие сведения о длине пути в Azure NetApp Files

Поделиться через