Azure NetApp Files의 볼륨 언어 이해

아티클
02/15/2024

Azure NetApp Files 볼륨의 볼륨 언어(클라이언트 운영 체제의 시스템 로캘과 비슷하게)는 NFS 및 SMB 프로토콜을 사용할 때 지원되는 언어 및 문자 집합을 제어합니다. Azure NetApp Files는 문자 집합에 POSIX 규격 UTF-8 인코딩을 제공하는 C.UTF-8의 기본 볼륨 언어를 사용합니다. C.UTF-8 언어는 기본적으로 BMP(Basic Multilingual Plane)(일본어, 독일어 및 대부분의 히브리어 및 키릴 자모 포함)에서 전 세계 언어의 대부분을 포함하는 0-3바이트 크기의 문자를 지원합니다. BMP에 대한 자세한 내용은 유니코드를 참조하세요.

BMP 외부의 문자가 Azure NetApp Files에서 지원하는 3바이트 크기를 초과하는 경우가 있습니다. 따라서 여러 문자 바이트 집합이 결합되어 새 문자를 형성하는 서로게이트 쌍 논리를 사용해야 합니다. 예를 들어 이모지 기호는 이 범주에 속하며 UTF-8이 적용되지 않는 시나리오(예: UTF-16 인코딩을 사용하는 Windows 클라이언트 또는 UTF-8을 적용하지 않는 NFSv3)에서 Azure NetApp Files에서 지원됩니다. NFSv4.x는 UTF-8을 적용합니다. 즉, NFSv4.x를 사용할 때 서로게이트 쌍 문자가 제대로 표시되지 않습니다.

또한 Shift-JIS 및 덜 일반적인 CJK 문자와 같은 비표준 인코딩은 AZURE NetApp Files에서 UTF-8을 적용할 때 제대로 표시되지 않습니다.

팁

문자를 제대로 번역할 수 없어 파일 생성/이름 바꾸기 또는 복사 오류 시나리오가 발생할 수 있는 상황을 방지하려면 UTF-8을 사용하여 텍스트를 보내고 받아야 합니다.

현재 볼륨 언어 설정은 Azure NetApp Files에서 수정할 수 없습니다. 자세한 내용은 특수 문자 집합이 있는 프로토콜 동작을 참조 하세요.

모범 사례는 문자 집합 모범 사례를 참조 하세요.

Azure NetApp Files NFS 및 SMB 볼륨의 문자 인코딩

Azure NetApp Files 파일 공유 환경에서 파일 및 폴더 이름은 최종 사용자가 읽고 해석하는 일련의 문자로 표시됩니다. 이러한 문자가 표시되는 방식은 클라이언트가 해당 문자의 인코딩을 보내고 받는 방법에 따라 달라집니다. 예를 들어 클라이언트가 액세스할 때 레거시 ASCII(American Standard Code for Information Interchange) 인코딩을 Azure NetApp Files 볼륨으로 보내는 경우 ASCII 형식으로 지원되는 문자만 표시하도록 제한됩니다.

예를 들어 데이터의 일본어 문자는 資. 이 문자는 ASCII에서 나타낼 수 없으므로 ASCII 인코딩을 사용하는 클라이언트는 "?"를 표시합니다. 대신 資.

ASCII는 인쇄 가능한 문자 95개만 지원하며, 주로 영어에서 찾을 수 있습니다. 이러한 각 문자는 1 바이트를 사용하며, 이는 Azure NetApp Files 볼륨의 총 파일 경로 길이 에 포함됩니다. 파일 이름에는 일본어에서 키릴 자모, 이모지까지 ASCII에서 인식할 수 없는 다양한 문자가 있을 수 있으므로 데이터 세트의 국제화가 제한됩니다. 국제 표준(ISO/IEC 8859)은 더 많은 국제 문자를 지원하려고 시도했지만 제한 사항도 있었습니다. 대부분의 최신 클라이언트는 어떤 형태의 유니코드를 사용하여 문자를 보내고 받습니다.

Unicode

ASCII 및 ISO/IEC 8859 인코딩 의 제한 사항으로 인해 누구나 디바이스에서 해당 지역의 언어를 볼 수 있도록 유니코드 표준이 설정되었습니다.

유니코드는 허용되는 문자당 바이트 수(최대 4바이트)와 ASCII와 같은 이전 인코딩과 달리 파일 경로에서 허용되는 총 바이트 수를 모두 늘려 하나의 백만 문자 집합을 지원합니다.
유니코드는 ASCII에 대해 처음 128자를 예약하는 동시에 처음 256개의 코드 포인트가 ISO/IEC 8859 표준과 동일한지 확인하여 이전 버전과의 호환성을 지원합니다.
유니코드 표준에서 문자 집합은 평면으로 세분화됩니다. 평면은 65,536개의 코드 포인트로 구성된 연속 그룹입니다. 유니코드 표준에는 총 17개의 평면(0-16)이 있습니다. 제한은 UTF-16의 제한으로 인해 17입니다.
평면 0은 기본 BMP(다국어 평면)입니다. 이 평면에는 여러 언어에서 가장 일반적으로 사용되는 문자가 포함되어 있습니다.
17개의 평면 중 현재 유니코드 버전 15.1을 기준으로 문자 집합이 할당된 5개만 있습니다.
평면 1-17은 보조 다국어 평면(SMP)으로 알려져 있으며, cuneiform 및 hieroglyphs와 같은 고대 쓰기 시스템뿐만 아니라 특수 중국어/일본어/한국어(CJK) 문자와 같이 덜 사용되는 문자 집합을 포함합니다.
문자 길이 및 경로 크기를 확인하고 시스템에 전송된 인코딩을 제어하는 메서드는 파일을 다른 인코딩으로 변환을 참조 하세요.

유니코드는 유니코드 변환 형식을 표준으로 사용하며 UTF-8과 UTF-16은 두 가지 기본 형식입니다.

유니코드 평면

유니코드는 65,536자의 17개 평면(256개 코드 포인트에 평면의 상자 256개 곱하기)을 활용하며, 평면 0은 기본 BMP(다국어 평면)입니다. 이 평면에는 여러 언어에서 가장 일반적으로 사용되는 문자가 포함되어 있습니다. 세계의 언어 및 문자 집합이 65536자를 초과하므로 덜 일반적으로 사용되는 문자 집합을 지원하기 위해 더 많은 평면이 필요합니다.

예를 들어 플레인 1(보조 다국어 비행기)에는 cuneiform 및 이집트 상형 문자와 같은 역사적인 스크립트와 일부 오세이지, 와랑 씨티, 아들람, 완초 및 토토가 포함되어 있습니다. 평면 1에는 기호와 이모티콘 문자도 포함되어 있습니다.

평면 2 - 보조 Ideographic Plane(SIP) 에는 중국어/일본어/한국어(CJK) 통합 이드그래프가 포함되어 있습니다. 평면 1과 2의 문자는 일반적으로 크기가 4바이트입니다.

예시:

비행기 1의 "큰 눈을 가진 웃는 얼굴"이모티콘 "😃" 의 크기는 4 바이트입니다.
평면 1의 이집트 상형 문자 "𓀀"의 크기는 4바이트입니다.
평면 1의 오세이지 문자 "𐒸"의 크기는 4바이트입니다.
평면 2의 CJK 문자 "𫝁" 의 크기는 4바이트입니다.

이러한 문자는 모두 >3바이트 크기이므로 서로게이트 쌍을 사용하여 제대로 작동해야 합니다. Azure NetApp Files는 기본적으로 서로게이트 쌍을 지원하지만 문자 표시는 사용 중인 프로토콜, 클라이언트의 로캘 설정 및 원격 클라이언트 액세스 애플리케이션의 설정에 따라 달라집니다.

UTF-8

UTF-8은 8비트 인코딩을 사용하며 최대 1,112,064개의 코드 포인트(또는 문자)를 가질 수 있습니다. 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바이트를 사용합니다.
문자 "ä"는 2바이트를 사용합니다. ("a"의 경우 1바이트 + 움라우트의 경우 1바이트)
데이터에 대한 일본어 간지 기호(資)는 3바이트를 사용합니다.
웃는 얼굴 이모티콘 (😃)은 4 바이트를 사용합니다.

언어 로캘은 컴퓨터 표준 UTF-8(C.UTF-8) 또는 지역별 형식(예: en_US)을 사용할 수 있습니다. UTF-8, ja. UTF-8 등 가능하면 Azure NetApp Files에 액세스할 때 Linux 클라이언트에 UTF-8 인코딩을 사용해야 합니다. OS X를 기준으로 macOS 클라이언트는 기본 인코딩에 UTF-8도 사용하므로 조정하면 안 됩니다.

Windows 클라이언트는 UTF-16을 사용합니다. 대부분의 경우 이 설정은 OS 로캘의 기본값으로 남아 있어야 하지만 최신 클라이언트는 확인란을 통해 UTF-8 문자에 대한 베타 지원을 제공합니다. 필요에 따라 PowerShell 또는 CMD에서 UTF-8을 사용하도록 Windows의 터미널 클라이언트를 조정할 수도 있습니다. 자세한 내용은 특수 문자 집합이 있는 이중 프로토콜 동작을 참조 하세요.

UTF-16

UTF-16은 16비트 인코딩을 사용하며 유니코드의 1,112,064개 코드 요소를 모두 인코딩할 수 있습니다. UTF-16의 인코딩은 크기가 각각 2바이트인 16비트 코드 단위를 하나 또는 두 개 사용할 수 있습니다. UTF-16의 모든 문자는 2 또는 4 바이트 크기를 사용합니다. 4바이트를 사용하는 UTF-16의 문자는 서로게이트 쌍을 활용합니다. 서로게이트 쌍은 서로 다른 두 개의 2바이트 문자를 결합하여 새 문자를 만듭니다. 이러한 보조 문자는 표준 BMP 평면을 벗어나 다른 다국어 평면 중 하나에 속합니다.

UTF-16은 Windows 운영 체제 및 API, Java 및 JavaScript에서 사용됩니다. ASCII 형식과의 이전 버전과의 호환성을 지원하지 않으므로 웹에서 인기를 얻지 못했습니다. UTF-16은 인터넷의 모든 페이지의 약 0.002%만 구성합니다. WHATWG(웹 하이퍼텍스트 애플리케이션 기술 작업 그룹)는 UTF-8을 "모든 텍스트에 대한 필수 인코딩"으로 간주하고 애플리케이션이 브라우저 보안에 UTF-16을 사용하지 않는 것이 좋습니다.

Azure NetApp Files는 서로게이트 쌍을 포함하여 대부분의 UTF-16 문자를 지원합니다. 문자가 지원되지 않는 경우 Windows 클라이언트는 "지정한 파일 이름이 잘못되었거나 너무 길다"는 오류를 보고합니다.

원격 클라이언트를 통해 문자 집합 처리

Azure NetApp Files 볼륨을 탑재하는 클라이언트에 대한 원격 연결(예: NFS 탑재에 액세스하기 위해 Linux 클라이언트에 대한 SSH 연결)은 특정 볼륨 언어 인코딩을 보내고 받도록 구성할 수 있습니다. 원격 연결 유틸리티를 통해 클라이언트로 전송되는 언어 인코딩은 문자 집합을 만들고 보는 방법을 제어합니다. 따라서 다른 원격 연결(예: 두 개의 PuTTY 창)과 다른 언어 인코딩을 사용하는 원격 연결은 Azure NetApp Files 볼륨에 파일 및 폴더 이름을 나열할 때 문자에 대해 다른 결과를 표시할 수 있습니다. 대부분의 경우 이는 라틴 문자/영어 문자와 같이 불일치를 만들지 않지만 이모지와 같은 특수 문자의 경우 결과가 달라질 수 있습니다.

예를 들어 원격 연결에 UTF-8 인코딩을 사용하면 C.UTF-8이 볼륨 언어이므로 Azure NetApp Files 볼륨의 문자에 대한 예측 가능한 결과가 표시됩니다. "data"(資)의 일본어 문자는 터미널에서 보내는 인코딩에 따라 다르게 표시됩니다.

PuTTY의 문자 인코딩

PuTTY 창에서 UTF-8(Windows의 번역 설정에 있음)을 사용하는 경우 문자는 Azure NetApp Files의 NFSv3 탑재 볼륨에 대해 올바르게 표시됩니다.

PuTTY 창에서 ISO-8859-1:1:1998(라틴-1, 서유럽)과 같은 다른 인코딩을 사용하는 경우 파일 이름이 같더라도 동일한 문자가 다르게 표시됩니다.

PuTTY는 기본적으로 CJK 인코딩을 포함하지 않습니다. PuTTY에 해당 언어 집합을 추가하는 데 사용할 수 있는 패치가 있습니다.

Bastion의 문자 인코딩

Microsoft Azure는 Azure의 VM(가상 머신)에 대한 원격 연결을 위해 Bastion을 사용하는 것이 좋습니다. Bastion을 사용하는 경우 전송 및 수신된 언어 인코딩은 구성에 노출되지 않지만 표준 UTF-8 인코딩을 활용합니다. 따라서 사용 중인 프로토콜에서 문자 집합이 지원되는 경우 PUTTY에서 UTF-8을 사용하는 대부분의 문자 집합도 Bastion에 표시되어야 합니다.

팁

TeraTerm과 같은 다른 SSH 터미널을 사용할 수 있습니다. TeraTerm은 기본적으로 CJK 인코딩 및 Shift-JIS와 같은 비표준 인코딩을 포함하여 지원되는 다양한 문자 집합을 제공합니다.

특수 문자 집합을 사용하는 프로토콜 동작

Azure NetApp Files 볼륨은 UTF-8 인코딩을 사용하며 기본적으로 3바이트를 초과하지 않는 문자를 지원합니다. ASCII 및 UTF-8 집합의 모든 문자는 1-3바이트 범위에 속하기 때문에 제대로 표시됩니다. 예시:

라틴어 알파벳 문자 "A"는 1 바이트(예약된 ASCII 문자 128개 중 하나)를 사용합니다.
저작권 기호©는 2바이트를 사용합니다.
문자 "ä"는 2바이트("a"의 경우 1바이트, 움라우트의 경우 1바이트)를 사용합니다.
데이터에 대한 일본어 간지 기호(資)는 3바이트를 사용합니다.

또한 Azure NetApp Files는 클라이언트 인코딩 및 프로토콜 버전이 지원하는 경우 서로게이트 쌍 논리(예: 이모지)를 통해 3바이트를 초과하는 일부 문자를 지원합니다. 프로토콜 동작에 대한 자세한 내용은 다음을 참조하세요.

SMB 동작
NFS 동작
이중 프로토콜 동작

SMB 동작

SMB 볼륨에서 Azure NetApp Files는 SMB 클라이언트에서 액세스할 수 있는 디렉터리의 파일 또는 디렉터리에 대해 원래의 긴 이름과 8.3 형식의 이름을 만들고 유지 관리합니다.

Azure NetApp Files를 사용하여 SMB의 파일 이름

파일 또는 디렉터리 이름이 허용되는 문자 바이트를 초과하거나 지원되지 않는 문자를 사용하는 경우 Azure NetApp Files는 다음과 같이 8.3 형식 이름을 생성합니다.

원래 파일 또는 디렉터리 이름을 자립니다.
잘린 후 더 이상 고유하지 않은 파일 또는 디렉터리 이름에 타일(~) 및 숫자(1-5)를 추가합니다. 고유하지 않은 이름을 가진 파일이 5개 이상 있는 경우 Azure NetApp Files는 원래 이름과 관계 없이 고유한 이름을 만듭니다. 파일의 경우 Azure NetApp Files는 파일 이름 확장명을 3자로 자른다.

예를 들어 NFS 클라이언트가 이름이 지정된 specifications.html파일을 만드는 경우 Azure NetApp Files는 8.3 형식에 따라 파일 이름을 specif~1.htm 만듭니다. 이 이름이 이미 있는 경우 Azure NetApp Files는 파일 이름의 끝에 다른 숫자를 사용합니다. 예를 들어 NFS 클라이언트가 이름이 specifications\_new.html다른 파일을 만드는 경우 8.3 형식 specifications\_new.html 은 다음과 같습니다 specif~2.htm.

Azure NetApp Files를 사용한 SMB의 특수 문자

Azure NetApp Files 볼륨에서 SMB를 사용하는 경우 서로게이트 쌍 지원으로 인해 파일 및 폴더 이름(이모티콘 포함)에 사용되는 3바이트를 초과하는 문자가 허용됩니다. 다음은 기본 UTF-16 인코딩과 함께 영어를 사용할 때 Windows 클라이언트에서 만든 폴더에서 BMP 외부의 문자에 대해 Windows 탐색기에서 보는 내용입니다.

참고 항목

Windows 탐색기의 기본 글꼴은 Segoe UI입니다. 글꼴 변경은 일부 문자가 클라이언트에 표시되는 방식에 영향을 줄 수 있습니다.

클라이언트에 문자가 표시되는 방법은 시스템 글꼴과 언어 및 로캘 설정에 따라 달라집니다. 일반적으로 인코딩이 UTF-8 또는 UTF-16인지에 관계없이 BMP에 속하는 문자는 모든 프로토콜에서 지원됩니다.

CMD 또는 PowerShell을 사용하는 경우 문자 집합 표시는 글꼴 설정에 따라 달라집니다. 이러한 유틸리티에는 기본적으로 제한된 글꼴 선택 항목이 있습니다. CMD는 Consolas를 기본 글꼴로 사용합니다.

명령 프롬프트 글꼴 옵션의 스크린샷.

일부 콘솔은 기본적으로 Segoe UI 또는 특수 문자를 제대로 렌더링하는 다른 글꼴을 지원하지 않으므로 사용되는 글꼴에 따라 파일 이름이 예상대로 표시되지 않을 수 있습니다.

dir 출력의 스크린샷.

이 문제는 더 강력한 글꼴 지원을 제공하는 PowerShell ISE를 사용하여 Windows 클라이언트에서 해결할 수 있습니다. 예를 들어 PowerShell ISE를 Segoe UI로 설정하면 지원되는 문자가 있는 파일 이름이 제대로 표시됩니다.

그러나 PowerShell ISE는 공유를 관리하는 대신 스크립팅을 위해 설계되었습니다. 최신 Windows 버전은 글꼴 및 인코딩 값을 제어할 수 있는 Windows 터미널 제공합니다.

참고 항목

명령을 chcp 사용하여 터미널의 인코딩을 봅니다. 코드 페이지의 전체 목록은 코드 페이지 식별자를 참조 하세요.

명령 출력의 스크린샷

볼륨이 이중 프로토콜(NFS 및 SMB 모두)에 사용하도록 설정된 경우 다른 동작을 관찰할 수 있습니다. 자세한 내용은 특수 문자 집합이 있는 이중 프로토콜 동작을 참조 하세요.

NFS 동작

NFS에서 특수 문자를 표시하는 방법은 사용되는 NFS 버전, 클라이언트의 로캘 설정, 설치된 글꼴 및 사용 중인 원격 연결 클라이언트의 설정에 따라 달라집니다. 예를 들어 Bastion을 사용하여 Ubuntu 클라이언트에 액세스하면 동일한 VM의 다른 로캘로 설정된 PuTTY 클라이언트와 다르게 문자가 표시됩니다. 이어지는 NFS 예제는 Ubuntu VM에 대한 다음 로캘 설정을 사용합니다.

~$ 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 인코딩을 적용하지 않습니다. 대부분의 경우 특수 문자 집합에는 문제가 없어야 합니다. 그러나 사용되는 연결 클라이언트는 문자를 보내고 받는 방법에 영향을 줄 수 있습니다. 예를 들어 Azure 연결 클라이언트 Bastion의 폴더 이름에 BMP 외부의 유니코드 문자를 사용하면 클라이언트 인코딩이 작동하는 방식으로 인해 예기치 않은 동작이 발생할 수 있습니다.

다음 스크린샷에서 Bastion은 NFSv3을 통해 디렉터리의 이름을 지정할 때 브라우저 외부에서 값을 복사하여 CLI 프롬프트에 붙여넣을 수 없습니다. 값을 NFSv3Bastion𓀀𫝁😃𐒸복사하여 붙여넣으려고 하면 특수 문자가 입력에 따옴표로 표시됩니다.

Bastion의 mkdir 명령 스크린샷

복사-붙여넣기 명령은 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는 RFC-8881 국제화 사양에 따라 파일 및 폴더 이름에 UTF-8 인코딩을 적용합니다.

따라서 특수 문자가 UTF-8이 아닌 인코딩으로 전송되는 경우 NFSv4.x는 이 값을 허용하지 않을 수 있습니다.

경우에 따라 BMP(기본 다국어 평면) 외부의 문자를 사용하여 명령을 사용할 수 있지만 만든 후에는 값이 표시되지 않을 수 있습니다.

예를 들어 NFSv4.x에서는 "𓀀𫝁𐒸😃"(SMP(보조 다국어 평면) 및 보조 Ideographic Plane(SIP)의 문자)가 포함된 폴더 이름을 발급 mkdir 하는 것이 성공하는 것처럼 보입니다. 명령을 실행할 때 폴더가 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을 사용하여 NFSv4.1을 통해 PuTTY를 사용하여 만든 동일한 디렉터리에 대한 액세스를 시도할 때 결과는 다음과 같습니다.

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

Shift-JIS와 같이 UTF-8이 아닌 형식으로의 파일 변환('iconv'사용)을 시도하는 경우에도 동일한 NFS4ERR\_INVAL 오류를 확인할 수 있습니다.

# 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)에서 사용하는 언어 인코딩의 큰 차이로 인해 문자 집합, 파일 및 폴더 이름 및 경로 길이는 프로토콜 간에 매우 다른 동작을 가질 수 있습니다.

SMB에서 NFS에서 만든 파일 및 폴더 보기

Azure NetApp Files를 이중 프로토콜 액세스(SMB 및 NFS)에 사용하는 경우 UTF-16에서 지원하지 않는 문자 집합을 NFS를 통해 UTF-8을 사용하여 만든 파일 이름에 사용할 수 있습니다. 이러한 시나리오에서 SMB가 지원되지 않는 문자가 있는 파일에 액세스하면 8.3 짧은 파일 이름 규칙을 사용하여 이름이 SMB에서 잘립니다.

NFSv3에서 만든 파일 및 문자 집합이 있는 SMB 동작

NFSv3은 UTF-8 인코딩을 적용하지 않습니다. 표준이 아닌 언어 인코딩(예: Shift-JIS)을 사용하는 문자는 NFSv3을 사용할 때 Azure NetApp Files에서 작동합니다.

다음 예제에서는 NFSv3을 사용하여 Azure NetApp Files 볼륨에서 유니코드의 다양한 평면에서 다양한 문자 집합을 사용하는 일련의 폴더 이름을 만들었습니다. 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에 문자가 있는 폴더는 제대로 표시되지만, UTF-8/UTF-16 변환이 해당 문자와 호환되지 않아 해당 평면 외부의 문자는 8.3 이름 형식으로 표시됩니다.

특수 문자를 사용하는 디렉터리 이름이 있는 Windows 탐색기의 스크린샷

NFSv4.1에서 만든 파일 및 문자 집합이 있는 SMB 동작

이전 예제에서 이름이 지정된 NFSv4 Putty 𓀀𫝁😃𐒸 폴더는 NFSv4.1을 통해 Azure NetApp Files 볼륨에 만들어졌지만 NFSv4.1을 사용하여 볼 수 없었습니다. 그러나 SMB를 사용하여 볼 수 있습니다. NFS 클라이언트에서 만든 지원되지 않는 문자 집합과 다른 유니코드 평면의 문자에 대해 호환되지 않는 UTF-8/UTF-16 변환으로 인해 이름이 지원되는 8.3 형식으로 SMB로 잘립니다.

Windows 탐색기의 NFSv4.x 디렉터리 스크린샷

폴더 이름이 BMP에 있는 표준 UTF-8 문자(영어 또는 그 외)를 사용하는 경우 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-**** 資 ****ä**

성공적으로 표시된 이중 프로토콜 디렉터리의 스크린샷

NFS를 통해 SMB에서 만든 파일 및 폴더

Windows 클라이언트는 SMB 공유에 액세스하는 데 사용되는 기본 유형의 클라이언트입니다. 이러한 클라이언트는 기본적으로 UTF-16 인코딩으로 설정됩니다. 지역 설정에서 사용하도록 설정하여 Windows에서 일부 UTF-8로 인코딩된 문자를 지원할 수 있습니다.

지역 설정 창의 스크린샷.

Azure NetApp Files의 SMB 공유를 통해 파일 또는 폴더를 만들면 문자 집합이 UTF-16으로 인코딩됩니다. 따라서 UTF-8 인코딩(예: Linux 기반 NFS 클라이언트)을 사용하는 클라이언트는 일부 문자 집합, 특히 BMP(기본 다국어 평면) 외부에 있는 문자를 제대로 번역하지 못할 수 있습니다.

지원되지 않는 문자 동작

이러한 시나리오에서 NFS 클라이언트가 지원되지 않는 문자가 있는 SMB를 사용하여 만든 파일에 액세스할 때 이름은 문자의 유니코드 값을 나타내는 일련의 숫자 값으로 표시됩니다.

예를 들어 이 폴더는 BMP 외부의 문자를 사용하여 Windows 탐색기에서 만들어졌습니다.

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 프로토콜과 해당 버전 간에 문제가 없습니다.

예를 들어 여러 언어(영어, 독일어, 키릴 자모, Runic)에서 BMP에서 찾은 문자가 있는 Azure NetApp Files 볼륨에서 SMB를 사용하여 만든 폴더 이름은 모든 프로토콜 및 버전에서 잘 표시됩니다.

이름이 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 클라이언트에서는 메모장 또는 메모장++와 같은 애플리케이션을 사용하여 파일 인코딩을 볼 수 있습니다. Linux용 Windows 하위 시스템(WSL) 또는 Git이 클라이언트 file 에 설치된 경우 이 명령을 사용할 수 있습니다.

ANSI 인코딩 옵션의 스크린샷.

또한 이러한 애플리케이션을 사용하면 다른 인코딩 형식으로 저장하여 파일의 인코딩을 변경할 수 있습니다. 또한 PowerShell을 사용하여 및 Set-Content cmdlet이 있는 파일의 인코딩을 Get-Content 변환할 수 있습니다.

예를 들어 파일 utf8-text.txt 은 UTF-8로 인코딩되고 BMP 외부의 문자를 포함합니다. UTF-8이 사용되므로 문자가 제대로 표시됩니다.

올바르게 렌더링된 UTF-8 문자의 스크린샷

인코딩이 UTF-32로 변환되면 문자가 제대로 표시되지 않습니다.

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

잘못 렌더링된 UTF-32 문자의 스크린샷

Get-Content 을 사용하여 파일 내용을 표시할 수도 있습니다. 기본적으로 PowerShell은 UTF-16 인코딩(코드 페이지 437)을 사용하며 콘솔의 글꼴 선택 항목이 제한되므로 특수 문자가 있는 UTF-8 형식의 파일을 제대로 표시할 수 없습니다.

Get-Content 명령 출력의 스크린샷.

Linux 클라이언트는 이 file 명령을 사용하여 파일의 인코딩을 볼 수 있습니다. 이중 프로토콜 환경에서 SMB를 사용하여 파일을 만드는 경우 NFS를 사용하는 Linux 클라이언트는 파일 인코딩을 확인할 수 있습니다.

$ 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 인코딩을 적용하더라도 호환되지 않는 문자가 파일 내용 내에 있는 경우 변환이 허용됩니다. 이 예제에서는 Azure NetApp Files 볼륨에 Katagana 문자가 있는 UTF-8로 인코딩된 파일에 파일의 내용이 제대로 표시됩니다.

$ 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을 통해 성공하지만 프로토콜 버전의 UTF-8 적용으로 인해 NFSv4.x를 장애 조치합니다.

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

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

문자 집합 모범 사례

Azure NetApp Files 볼륨에서 표준 BMP(기본 다국어 평면) 외부에서 특수 문자 또는 문자를 사용하는 경우 몇 가지 모범 사례를 고려해야 합니다.

Azure NetApp Files 볼륨은 UTF-8 볼륨 언어를 사용하므로 NFS 클라이언트의 파일 인코딩도 일관된 결과를 위해 UTF-8 인코딩을 사용해야 합니다.
파일 이름 또는 파일 내용에 포함된 문자 집합은 적절한 표시 및 기능을 위해 UTF-8과 호환되어야 합니다.
SMB는 UTF-16 문자 인코딩을 사용하므로 BMP 외부의 문자가 이중 프로토콜 볼륨의 NFS에 제대로 표시되지 않을 수 있습니다. 가능한 한 파일 내용에 특수 문자 사용을 최소화합니다.
특히 NFSv4.1 또는 이중 프로토콜 볼륨을 사용하는 경우 파일 이름에서 BMP 외부의 특수 문자를 사용하지 마세요.
BMP에 없는 문자 집합의 경우 UTF-8 인코딩은 단일 파일 프로토콜을 사용할 때 Azure NetApp Files의 문자 표시를 허용해야 합니다(SMB 전용 또는 NFS만 해당). 그러나 이중 프로토콜 볼륨은 대부분의 경우 이러한 문자 집합을 수용할 수 없습니다.
비표준 인코딩(예: Shift-JIS)은 Azure NetApp Files 볼륨에서 지원되지 않습니다.
서로게이트 쌍 문자(예: 이모지)는 Azure NetApp Files 볼륨에서 지원됩니다.

다음 단계

Azure NetApp Files의 경로 길이 이해

다음을 통해 공유