Compreender linguagens de volume nos Arquivos NetApp do Azure

O idioma do volume (semelhante às localidades do sistema em sistemas operacionais cliente) em um volume de Arquivos NetApp do Azure controla os idiomas e conjuntos de caracteres suportados ao usar protocolos NFS e SMB. Os Arquivos NetApp do Azure usam uma linguagem de volume padrão de C.UTF-8, que fornece codificação UTF-8 compatível com POSIX para conjuntos de caracteres. O idioma C.UTF-8 suporta nativamente caracteres com um tamanho de 0-3 bytes, o que inclui a maioria dos idiomas do mundo no Plano Multilingue Básico (BMP) (incluindo japonês, alemão e a maioria do hebraico e cirílico). Para obter mais informações sobre o BMP, consulte Unicode.

Por vezes, os carateres fora do BMP excedem o tamanho de 3 bytes suportado pelos Ficheiros NetApp do Azure. Assim, eles precisam usar a lógica de par substituto, onde vários conjuntos de bytes de caracteres são combinados para formar novos caracteres. Os símbolos Emoji, por exemplo, se enquadram nessa categoria e são suportados nos Arquivos NetApp do Azure em cenários onde UTF-8 não é imposto: como clientes Windows que usam codificação UTF-16 ou NFSv3 que não impõe UTF-8. O NFSv4.x impõe UTF-8, o que significa que os caracteres de par substituto não são exibidos corretamente ao usar o NFSv4.x.

A codificação não padrão, como Shift-JIS e caracteres CJK menos comuns, também não é exibida corretamente quando UTF-8 é imposta nos Arquivos NetApp do Azure.

Gorjeta

Você deve enviar e receber texto usando UTF-8 para evitar situações em que os caracteres não podem ser traduzidos corretamente, o que pode causar cenários de erro de criação/renomeação ou cópia de arquivos.

As configurações de idioma do volume atualmente não podem ser modificadas nos Arquivos NetApp do Azure. Para obter mais informações, consulte Comportamentos de protocolo com conjuntos de caracteres especiais.

Para obter as práticas recomendadas, consulte Práticas recomendadas do conjunto de caracteres.

Codificação de caracteres nos volumes NFS e SMB dos Arquivos NetApp do Azure

Em um ambiente de compartilhamento de arquivos do Azure NetApp Files, os nomes de arquivos e pastas são representados por uma série de caracteres que os usuários finais leem e interpretam. A maneira como esses caracteres são exibidos depende de como o cliente envia e recebe a codificação desses caracteres. Por exemplo, se um cliente estiver enviando codificação ASCII (American Standard Code for Information Interchange) herdada para o volume Arquivos NetApp do Azure ao acessá-lo, ele estará limitado a exibir apenas caracteres com suporte no formato ASCII.

Por exemplo, o caractere japonês para dados é 資. Como esse caractere não pode ser representado em ASCII, um cliente usando codificação ASCII mostra um "?" em vez de 資.

ASCII suporta apenas 95 caracteres imprimíveis, principalmente aqueles encontrados na língua inglesa. Cada um desses caracteres usa 1 byte, que é fatorado no comprimento total do caminho do arquivo em um volume de Arquivos NetApp do Azure. Isso limita a internacionalização de conjuntos de dados, uma vez que os nomes de arquivo podem ter uma variedade de caracteres não reconhecidos pelo ASCII, do japonês ao cirílico e aos emojis. Uma norma internacional (ISO/IEC 8859) tentou suportar mais caracteres internacionais, mas também tinha suas limitações. A maioria dos clientes modernos envia e recebe caracteres usando alguma forma de Unicode.

Unicode

Como resultado das limitações das codificações ASCII e ISO/IEC 8859, o padrão Unicode foi estabelecido para que qualquer pessoa possa visualizar o idioma de sua região de origem a partir de seus dispositivos.

• O Unicode suporta mais de um milhão de conjuntos de caracteres aumentando o número de bytes por caractere permitido (até 4 bytes) e o número total de bytes permitidos em um caminho de arquivo em oposição a codificações mais antigas, como ASCII.
• O Unicode suporta compatibilidade com versões anteriores, reservando os primeiros 128 caracteres para ASCII, ao mesmo tempo em que garante que os primeiros 256 pontos de código sejam idênticos aos padrões ISO/IEC 8859.
• No padrão Unicode, os conjuntos de caracteres são divididos em planos. Um plano é um grupo contínuo de 65.536 pontos de código. No total, existem 17 aviões (0-16) no padrão Unicode. O limite é de 17 devido às limitações da UTF-16.
• O Plano 0 é o Plano Multilingue Básico (BMP). Este plano contém os caracteres mais comumente usados em vários idiomas.
• Dos 17 planos, apenas cinco atualmente têm conjuntos de caracteres atribuídos a partir da versão 15.1 do Unicode.
• Os planos 1-17 são conhecidos como Planos Multilingues Suplementares (SMP) e contêm conjuntos de caracteres menos utilizados, por exemplo, sistemas de escrita antigos, como cuneiformes e hieróglifos, bem como caracteres especiais chineses/japoneses/coreanos (CJK).
• Para métodos para ver comprimentos de caracteres e tamanhos de caminho e para controlar a codificação enviada para um sistema, consulte Convertendo arquivos em codificações diferentes.

Unicode usa Unicode Transformation Format como seu padrão, com UTF-8 e UTF-16 sendo os dois formatos principais.

Planos Unicode

O Unicode utiliza 17 planos de 65.536 caracteres (256 pontos de código multiplicados por 256 caixas no plano), com o Plano 0 como o Plano Multilingue Básico (BMP). Este plano contém os caracteres mais comumente usados em vários idiomas. Como os idiomas e conjuntos de caracteres do mundo excedem 65536 caracteres, são necessários mais planos para suportar conjuntos de caracteres menos usados.

Por exemplo, o Plano 1 (os Planos Multilingues Suplementares (SMP)) inclui scripts históricos como hieróglifos cuneiformes e egípcios, bem como alguns Osage, Warang Citi, Adlam, Wincho e Toto. O plano 1 também inclui alguns símbolos e caracteres emoticons .

O Plano 2 – o Plano Ideográfico Suplementar (SIP) – contém Ideógrafos Unificados Chineses/Japoneses/Coreanos (CJK). Os caracteres nos planos 1 e 2 geralmente têm 4 bytes de tamanho.

Por exemplo:

• O emoticon😃 "rosto sorridente com olhos grandes" no plano 1 tem 4 bytes de tamanho.
• O hieróglifo egípcio no plano 1 tem 4 bytes de tamanho.
• O caractere Osage "Osage" no plano 1 tem 4 bytes de tamanho.
• O caractere CJK no plano 2 tem 4 bytes de tamanho.

Como esses caracteres têm todos >3 bytes de tamanho, eles exigem o uso de pares substitutos para funcionar corretamente. Os Arquivos NetApp do Azure dão suporte nativo a pares substitutos, mas a exibição dos caracteres varia dependendo do protocolo em uso, das configurações de localidade do cliente e das configurações do aplicativo de acesso para cliente remoto.

UTF-8

UTF-8 usa codificação de 8 bits e pode ter até 1.112.064 pontos de código (ou caracteres). UTF-8 é a codificação padrão em todas as linguagens em sistemas operacionais baseados em Linux. Como UTF-8 usa codificação de 8 bits, o número inteiro não assinado máximo possível é 255 (2^8 – 1), que também é o comprimento máximo do nome do arquivo para essa codificação. UTF-8 é usado em mais de 98% das páginas na Internet, tornando-se de longe o padrão de codificação mais adotado. O Web Hypertext Application Technology Working Group (WHATWG) considera UTF-8 "a codificação obrigatória para todos [texto]" e que, por razões de segurança, os aplicativos de navegador não devem usar UTF-16.

Os caracteres no formato UTF-8 usam de 1 a 4 bytes, mas quase todos os caracteres em todos os idiomas usam entre 1 e 3 bytes. Por exemplo:

• A letra "A" do alfabeto latino usa 1 byte. (Um dos 128 caracteres ASCII reservados)
• Um símbolo de direitos autorais "©" usa 2 bytes.
• O caractere "ä" usa 2 bytes. (1 byte para "a" + 1 byte para o umlaut)
• O símbolo Kanji japonês para dados (資) usa 3 bytes.
• Um emoji de rosto sorridente (😃) usa 4 bytes.

As localidades de idioma podem usar UTF-8 padrão do computador (C.UTF-8) ou um formato mais específico da região, como en_US. UTF-8, ja. UTF-8, etc. Você deve usar a codificação UTF-8 para clientes Linux ao acessar os Arquivos NetApp do Azure sempre que possível. A partir do OS X, os clientes macOS também usam UTF-8 para sua codificação padrão e não devem ser ajustados.

Os clientes Windows usam UTF-16. Na maioria dos casos, essa configuração deve ser deixada como padrão para a localidade do sistema operacional, mas os clientes mais recentes oferecem suporte beta para caracteres UTF-8 por meio de uma caixa de seleção. Os clientes de terminal no Windows também podem ser ajustados para usar UTF-8 no PowerShell ou CMD, conforme necessário. Para obter mais informações, consulte Comportamentos de protocolo duplo com conjuntos de caracteres especiais.

UTF-16

UTF-16 usa codificação de 16 bits e é capaz de codificar todos os 1.112.064 pontos de código de Unicode. A codificação para UTF-16 pode usar uma ou duas unidades de código de 16 bits, cada uma com 2 bytes de tamanho. Todos os caracteres em UTF-16 usam tamanhos de 2 ou 4 bytes. Os caracteres em UTF-16 que usam 4 bytes aproveitam pares substitutos, que combinam dois caracteres separados de 2 bytes para criar um novo caractere. Estes caracteres suplementares situam-se fora do plano BMP padrão e num dos outros planos multilingues.

UTF-16 é usado em sistemas operacionais Windows e APIs, Java e JavaScript. Uma vez que não suporta retrocompatibilidade com formatos ASCII, nunca ganhou popularidade na web. UTF-16 representa apenas cerca de 0,002% de todas as páginas na internet. O Web Hypertext Application Technology Working Group (WHATWG) considera UTF-8 "a codificação obrigatória para todo o texto" e recomenda que os aplicativos não usem UTF-16 para segurança do navegador.

Os Arquivos NetApp do Azure dão suporte à maioria dos caracteres UTF-16, incluindo pares substitutos. Nos casos em que o caractere não é suportado, os clientes Windows relatam um erro de "nome de arquivo especificado não é válido ou muito longo".

Tratamento de conjuntos de caracteres em clientes remotos

As conexões remotas com clientes que montam volumes de Arquivos NetApp do Azure (como conexões SSH com clientes Linux para acessar montagens NFS) podem ser configuradas para enviar e receber codificações de linguagem de volume específicas. A codificação de idioma enviada ao cliente através do utilitário de conexão remota controla como os conjuntos de caracteres são criados e visualizados. Como resultado, uma conexão remota que usa uma codificação de idioma diferente de outra conexão remota (como duas janelas PuTTY diferentes) pode mostrar resultados diferentes para caracteres ao listar nomes de arquivos e pastas no volume Arquivos NetApp do Azure. Na maioria dos casos, isso não criará discrepâncias (como para caracteres latinos/ingleses), mas nos casos de caracteres especiais, como emojis, os resultados podem variar.

Por exemplo, usar uma codificação de UTF-8 para a conexão remota mostra resultados previsíveis para caracteres em volumes de Arquivos NetApp do Azure, já que C.UTF-8 é a linguagem do volume. O caractere japonês para "dados" (資) é exibido de forma diferente dependendo da codificação que está sendo enviada pelo terminal.

Codificação de caracteres em PuTTY

Quando uma janela PuTTY usa UTF-8 (encontrado nas configurações de tradução do Windows), o caractere é representado corretamente para um volume montado NFSv3 nos Arquivos NetApp do Azure:

Se a janela PuTTY usa uma codificação diferente, como ISO-8859-1:1998 (Latin-1, Europa Ocidental), o mesmo caractere é exibido de forma diferente, mesmo que o nome do arquivo seja o mesmo.

PuTTY, por padrão, não contém codificações CJK. Há patches disponíveis para adicionar esses conjuntos de idiomas ao PuTTY.

Codificações de caracteres em Bastion

O Microsoft Azure recomenda o uso do Bastion para conectividade remota com máquinas virtuais (VMs) no Azure. Ao usar Bastion, a codificação de idioma enviada e recebida não é exposta na configuração, mas aproveita a codificação UTF-8 padrão. Como resultado, a maioria dos conjuntos de caracteres vistos no PuTTY usando UTF-8 também devem ser visíveis em Bastion, desde que os conjuntos de caracteres sejam suportados no protocolo que está sendo usado.

Gorjeta

Outros terminais SSH podem ser usados, como o TeraTerm. O TeraTerm fornece uma gama mais ampla de conjuntos de caracteres suportados por padrão, incluindo codificações CJK e codificações não padrão, como Shift-JIS.

Comportamentos de protocolo com conjuntos de caracteres especiais

Os volumes dos Arquivos NetApp do Azure usam codificação UTF-8 e dão suporte nativo a caracteres que não excedem 3 bytes. Todos os caracteres no conjunto ASCII e UTF-8 são exibidos corretamente porque se enquadram no intervalo de 1 a 3 bytes. Por exemplo:

• O caractere do alfabeto latino "A" usa 1 byte (um dos 128 caracteres ASCII reservados).
• Um símbolo © de copyright usa 2 bytes.
• O caractere "ä" usa 2 bytes (1 byte para "a" e 1 byte para o umlaut).
• O símbolo Kanji japonês para dados (資) usa 3 bytes.

Os Arquivos NetApp do Azure também dão suporte a alguns caracteres que excedem 3 bytes por meio da lógica de par substituto (como emoji), desde que a codificação do cliente e a versão do protocolo ofereçam suporte a eles. Para obter mais informações sobre comportamentos de protocolo, consulte:

• Comportamentos SMB
• Comportamentos NFS
• Comportamentos de protocolo duplo

Comportamentos SMB

Em volumes SMB, os Arquivos NetApp do Azure criam e mantêm dois nomes para arquivos ou diretórios em qualquer diretório que tenha acesso de um cliente SMB: o nome longo original e um nome no formato 8.3.

Nomes de arquivo no SMB com Arquivos NetApp do Azure

Quando os nomes de arquivo ou diretório excedem os bytes de caracteres permitidos ou usam caracteres sem suporte, os Arquivos NetApp do Azure geram um nome de formato 8.3 da seguinte maneira:

• Ele trunca o nome do arquivo ou diretório original.
• Ele acrescenta um til (~) e um numeral (1-5) a nomes de arquivo ou diretório que não são mais exclusivos depois de serem truncados. Se houver mais de cinco arquivos com nomes não exclusivos, os Arquivos NetApp do Azure criarão um nome exclusivo sem relação com o nome original. Para arquivos, o Azure NetApp Files trunca a extensão de nome de arquivo para três caracteres.

Por exemplo, se um cliente NFS criar um arquivo chamado specifications.html, Arquivos NetApp do Azure criará o nome specif~1.htm do arquivo seguindo o formato 8.3. Se esse nome já existir, os Arquivos NetApp do Azure usarão um número diferente no final do nome do arquivo. Por exemplo, se um cliente NFS criar outro arquivo chamado specifications\_new.html, o formato 8.3 de specifications\_new.html é specif~2.htm.

Caractere especial no SMB com Arquivos NetApp do Azure

Ao usar o SMB com volumes do Azure NetApp Files, os caracteres que excedem 3 bytes usados em nomes de arquivos e pastas (incluindo emoticons) são permitidos devido ao suporte a pares substitutos. A seguir está o que o Windows Explorer vê para caracteres fora do BMP em uma pasta criada a partir de um cliente Windows ao usar inglês com a codificação UTF-16 padrão.

Nota

A fonte padrão no Windows Explorer é Segoe UI. As alterações de fonte podem afetar a exibição de alguns caracteres nos clientes.

A forma como os caracteres são exibidos no cliente depende da fonte do sistema e das configurações de idioma e localidade. Em geral, os caracteres que se enquadram no BMP são suportados em todos os protocolos, independentemente se a codificação é UTF-8 ou UTF-16.

Ao usar CMD ou PowerShell, a exibição do conjunto de caracteres depende das configurações de fonte. Esses utilitários têm opções de fonte limitadas por padrão. CMD usa Consolas como a fonte padrão.

Os nomes de arquivo podem não ser exibidos como esperado, dependendo da fonte usada, pois alguns consoles não suportam nativamente a interface do usuário Segoe ou outras fontes que processam caracteres especiais corretamente.

Esse problema pode ser resolvido em clientes Windows usando o PowerShell ISE, que fornece suporte a fontes mais robustas. Por exemplo, definir o ISE do PowerShell como Segoe UI exibe os nomes de arquivo com caracteres suportados corretamente.

No entanto, o ISE do PowerShell foi projetado para scripts, em vez de gerenciar compartilhamentos. As versões mais recentes do Windows oferecem o Terminal Windows, que permite o controle sobre as fontes e os valores de codificação.

Nota

Use o chcp comando para visualizar a codificação do terminal. Para obter uma lista completa de páginas de código, consulte Identificadores de página de código.

Se o volume estiver habilitado para protocolo duplo (NFS e SMB), você poderá observar comportamentos diferentes. Para obter mais informações, consulte Comportamentos de protocolo duplo com conjuntos de caracteres especiais.

Comportamentos NFS

Como o NFS exibe caracteres especiais depende da versão do NFS usada, das configurações de localidade do cliente, das fontes instaladas e das configurações do cliente de conexão remota em uso. Por exemplo, usar Bastion para acessar um cliente Ubuntu lida com exibições de caracteres de forma diferente de um cliente PuTTY definido para uma localidade diferente na mesma VM. Os exemplos de NFS subsequentes dependem destas configurações de localidade para a VM do 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=

Comportamento NFSv3

O NFSv3 não impõe a codificação UTF em arquivos e pastas. Na maioria dos casos, conjuntos de caracteres especiais não devem ter problemas. No entanto, o cliente de conexão usado pode afetar como os caracteres são enviados e recebidos. Por exemplo, usar caracteres Unicode fora do BMP para um nome de pasta no cliente de conexão do Azure Bastion pode resultar em algum comportamento inesperado devido ao funcionamento da codificação do cliente.

Na captura de tela a seguir, Bastion não consegue copiar e colar os valores no prompt da CLI de fora do navegador ao nomear um diretório sobre NFSv3. Ao tentar copiar e colar o valor de NFSv3Bastion𓀀𫝁😃𐒸, os caracteres especiais são exibidos como aspas na entrada.

O comando copiar-colar é permitido sobre NFSv3, mas os caracteres são criados como seus valores numéricos, afetando sua exibição:

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

Esta exibição é devido à codificação usada por Bastion para enviar valores de texto ao copiar e colar.

Ao usar o PuTTY para criar uma pasta com os mesmos caracteres sobre NFSv3, o nome da pasta é diferente no Bastion do que quando Bastion foi usado para criá-lo. O emoticon mostra como esperado (devido às fontes instaladas e à configuração de localidade), mas os outros caracteres (como o Osage "Osage") não.

A partir de uma janela PuTTY, os caracteres são exibidos corretamente:

Comportamento NFSv4.x

O NFSv4.x impõe a codificação UTF-8 em nomes de arquivos e pastas de acordo com as especificações de internacionalização RFC-8881.

Como resultado, se um caractere especial for enviado com codificação não-UTF-8, NFSv4.x pode não permitir o valor.

Em alguns casos, um comando pode ser permitido usando um caractere fora do Plano Multilíngüe Básico (BMP), mas pode não exibir o valor depois de criado.

Por exemplo, emitir mkdir com um nome de pasta incluindo os caracteres "Planos😃 Multilingues Suplementares (SMP) e Plano Ideográfico Suplementar (SIP)) parece ter sucesso no NFSv4.x. A pasta não ficará visível ao executar o ls comando.

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$

A pasta existe no volume. Mudar para esse nome de diretório oculto funciona a partir do cliente PuTTY, e um arquivo pode ser criado dentro desse diretório.

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

Um comando stat do PuTTY também confirma que a pasta existe:

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: -

Mesmo que a pasta esteja confirmada como existente, os comandos curinga não funcionam, pois o cliente não pode "ver" oficialmente a pasta na exibição.

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

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

NFSv4.1 envia um erro para o cliente quando ele encontra um caractere que não depende da codificação UTF-8.

Por exemplo, ao usar Bastion para tentar acessar o mesmo diretório que criamos usando PuTTY sobre NFSv4.1, este é o resultado:

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 é abordado no RFC-8881.

Como a pasta pode ser acessada a partir do PuTTY (devido à codificação ser enviada e recebida), ela pode ser copiada se o nome for especificado. Depois de copiar essa pasta do volume NFSv4.1 Azure NetApp Files para o volume NFSv3 Azure NetApp Files, o nome da pasta é exibido:

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 𓀀𫝁😃𐒸

O mesmo NFS4ERR\_INVAL erro pode ser visto se uma conversão de arquivo (usando 'iconv'') para um formato não-UTF-8 é tentada, como Shift-JIS.

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

Para obter mais informações, consulte Converter arquivos em codificações diferentes.

Comportamentos de protocolo duplo

Os Arquivos NetApp do Azure permitem que os volumes sejam acessados por NFS e SMB por meio de acesso de protocolo duplo. Devido às grandes diferenças na codificação de linguagem usada por NFS (UTF-8) e SMB (UTF-16), conjuntos de caracteres, nomes de arquivos e pastas e comprimentos de caminho podem ter comportamentos muito diferentes entre protocolos.

Visualizando arquivos e pastas criados por NFS a partir do SMB

Quando os Arquivos NetApp do Azure são usados para acesso de protocolo duplo (SMB e NFS), um conjunto de caracteres sem suporte para UTF-16 pode ser usado em um nome de arquivo criado usando UTF-8 via NFS. Nesses cenários, quando o SMB acessa um arquivo com caracteres sem suporte, o nome é truncado no SMB usando a convenção de nome de arquivo curto 8.3.

Arquivos criados por NFSv3 e comportamentos SMB com conjuntos de caracteres

O NFSv3 não impõe a codificação UTF-8. Os caracteres que usam codificações de idioma não padrão (como Shift-JIS) funcionam com os Arquivos NetApp do Azure ao usar NFSv3.

No exemplo a seguir, uma série de nomes de pasta usando conjuntos de caracteres diferentes de vários planos em Unicode foram criados em um volume de Arquivos NetApp do Azure usando NFSv3. Quando visualizados a partir do NFSv3, eles aparecem corretamente.

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-😃

No Windows SMB, as pastas com caracteres encontrados no BMP são exibidas corretamente, mas os caracteres fora desse plano são exibidos com o formato de nome 8.3 devido à conversão UTF-8/UTF-16 ser incompatível para esses caracteres.

Arquivos criados pelo NFSv4.1 e comportamentos SMB com conjuntos de caracteres

Nos exemplos anteriores, uma pasta nomeada NFSv4 Putty 𓀀𫝁😃𐒸 foi criada em um volume de Arquivos NetApp do Azure sobre NFSv4.1, mas não era visível usando NFSv4.1. No entanto, pode ser visto usando SMB. O nome é truncado no SMB para um formato 8.3 suportado devido aos conjuntos de caracteres sem suporte criados a partir do cliente NFS e à conversão UTF-8/UTF-16 incompatível para caracteres em diferentes planos Unicode.

Quando um nome de pasta usa caracteres UTF-8 padrão encontrados no BMP (inglês ou outro), o SMB traduz os nomes corretamente.

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

Arquivos e pastas criados por SMB sobre NFS

Os clientes Windows são o principal tipo de clientes usados para acessar compartilhamentos SMB. Esses clientes usam como padrão a codificação UTF-16. É possível suportar alguns caracteres codificados UTF-8 no Windows, ativando-o nas configurações de região:

Quando um arquivo ou pasta é criado em um compartilhamento SMB nos Arquivos NetApp do Azure, o conjunto de caracteres é codificado como UTF-16. Como resultado, os clientes que usam a codificação UTF-8 (como clientes NFS baseados em Linux) podem não ser capazes de traduzir alguns conjuntos de caracteres corretamente – particularmente caracteres que estão fora do Plano Multilíngüe Básico (BMP).

Comportamento de caracteres não suportado

Nesses cenários, quando um cliente NFS acessa um arquivo criado usando SMB com caracteres sem suporte, o nome é exibido como uma série de valores numéricos que representam os valores Unicode para o caractere.

Por exemplo, essa pasta foi criada no Windows Explorer usando caracteres fora do BMP.

PS Z:\SMB\> dir

Directory: Z:\SMB

Mode LastWriteTime Length Name

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

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

Sobre NFSv3, a pasta criada pelo SMB aparece:

$ 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'

Sobre NFSv4.1, a pasta criada pelo SMB aparece da seguinte maneira:

$ 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'

Comportamento de personagem suportado

Quando os caracteres estão no BMP, não há problemas entre os protocolos SMB e NFS e suas versões.

Por exemplo, um nome de pasta criado usando SMB em um volume de Arquivos NetApp do Azure com caracteres encontrados no BMP em vários idiomas (inglês, alemão, cirílico, rúnico) aparece bem em todos os protocolos e versões.

• Latim básico "SMB"
• Grego "ͶΘΩ"
• Cirílico "ЁЄЊ"
• Rúnica "ᚠᚱᛯ"
• Ideógrafos de compatibilidade CJK "豈滑虜"

É assim que o nome aparece no SMB:

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

Mode LastWriteTime Length Name

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

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

É assim que o nome aparece no NFSv3:

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

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

É assim que o nome aparece no NFSv4.1:

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

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

Convertendo arquivos em codificações diferentes

Os nomes de arquivos e pastas não são as únicas partes de objetos do sistema de arquivos que utilizam codificações de idioma. O conteúdo do arquivo (como caracteres especiais dentro de um arquivo de texto) também pode desempenhar um papel. Por exemplo, se um arquivo é tentado para ser salvo com caracteres especiais em um formato incompatível, então uma mensagem de erro pode ser vista. Nesse caso, um arquivo com caracteres Katagana não pode ser salvo em ANSI, pois esses caracteres não existem nessa codificação.

Uma vez que o arquivo é salvo nesse formato, os caracteres são convertidos em pontos de interrogação:

As codificações de arquivo podem ser visualizadas a partir de clientes NAS. Em clientes Windows, você pode usar um aplicativo como o Bloco de Notas ou o Bloco de Notas ++ para exibir uma codificação de um arquivo. Se o Subsistema Windows para Linux (WSL) ou o Git estiverem instalados no cliente, o file comando poderá ser usado.

Esses aplicativos também permitem que você altere a codificação do arquivo salvando como diferentes tipos de codificação. Além disso, o PowerShell pode ser usado para converter a codificação em arquivos com os Get-Content cmdlets e Set-Content .

Por exemplo, o arquivo utf8-text.txt é codificado como UTF-8 e contém caracteres fora do BMP. Como UTF-8 é usado, os caracteres são exibidos corretamente.

Se a codificação for convertida para UTF-32, os caracteres não serão exibidos corretamente.

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

Get-Content também pode ser usado para exibir o conteúdo do arquivo. Por padrão, o PowerShell usa codificação UTF-16 (página de código 437) e as seleções de fontes para o console são limitadas, portanto, o arquivo formatado UTF-8 com caracteres especiais não pode ser exibido corretamente:

Os clientes Linux podem usar o file comando para visualizar a codificação do arquivo. Em ambientes de protocolo duplo, se um arquivo for criado usando SMB, o cliente Linux usando NFS poderá verificar a codificação do arquivo.

$ 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

A conversão de codificação de arquivos pode ser realizada em clientes Linux usando o iconv comando. Para ver a lista de formatos de codificação suportados, use iconv -l.

Por exemplo, o arquivo codificado UTF-8 pode ser convertido para 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**

Se o conjunto de caracteres no nome do arquivo ou no conteúdo do arquivo não for suportado pela codificação de destino, a conversão não será permitida. Por exemplo, Shift-JIS não pode suportar os caracteres no conteúdo do arquivo.

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

iconv: illegal input sequence at position 0

Se um arquivo tiver caracteres suportados pela codificação, a conversão será bem-sucedida. Por exemplo, se o arquivo contiver os caracteres Katagana テストファイル, a conversão Shift-JIS terá êxito sobre NFS. Como o cliente NFS que está sendo usado aqui não entende o Shift-JIS devido às configurações de localidade, a codificação mostra "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**

Como os volumes de Arquivos NetApp do Azure oferecem suporte apenas à formatação compatível com UTF-8, os caracteres Katagana são convertidos em um formato ilegível.

$ cat SJIS2.txt

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

Ao usar NFSv4.x, a conversão é permitida quando caracteres não compatíveis estão presentes dentro do conteúdo do arquivo, mesmo que o NFSv4.x imponha a codificação UTF-8. Neste exemplo, um arquivo codificado UTF-8 com caracteres Katagana localizados em um volume de Arquivos NetApp do Azure mostra o conteúdo de um arquivo corretamente.

$ file -i SJIS.txt

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

S$ cat SJIS.txt

テストファイル

Mas uma vez convertido, os caracteres no arquivo são exibidos incorretamente devido à codificação incompatível.

$ cat SJIS2.txt

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

Se o nome do arquivo contiver caracteres não suportados para UTF-8, a conversão será bem-sucedida sobre NFSv3, mas falhará sobre NFSv4.x devido à imposição UTF-8 da versão do protocolo.

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

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

Práticas recomendadas do conjunto de caracteres

Ao usar caracteres especiais ou caracteres fora do BMP (Basic Multilingual Plane) padrão nos volumes do Azure NetApp Files, algumas práticas recomendadas devem ser levadas em consideração.

• Como os volumes dos Arquivos NetApp do Azure usam a linguagem de volume UTF-8, a codificação de arquivos para clientes NFS também deve usar a codificação UTF-8 para obter resultados consistentes.
• Os conjuntos de caracteres em nomes de arquivo ou contidos no conteúdo do arquivo devem ser compatíveis com UTF-8 para exibição e funcionalidade adequadas.
• Como o SMB usa codificação de caracteres UTF-16, os caracteres fora do BMP podem não ser exibidos corretamente sobre NFS em volumes de protocolo duplo. Na medida do possível, minimize o uso de caracteres especiais no conteúdo do arquivo.
• Evite usar caracteres especiais fora do BMP em nomes de arquivo, especialmente ao usar NFSv4.1 ou volumes de protocolo duplo.
• Para conjuntos de caracteres que não estão no BMP, a codificação UTF-8 deve permitir a exibição dos caracteres nos Arquivos NetApp do Azure ao usar um único protocolo de arquivo (somente SMB ou NFS). No entanto, os volumes de protocolo duplo não são capazes de acomodar esses conjuntos de caracteres na maioria dos casos.
• A codificação não padrão (como Shift-JIS) não é suportada nos volumes dos Arquivos NetApp do Azure.
• Caracteres de par substituto (como emojis) são suportados em volumes de Arquivos NetApp do Azure.

Próximos passos

• Compreender os comprimentos de caminho nos Arquivos NetApp do Azure