了解 Azure NetApp Files 中的路徑長度
檔案和路徑長度是指檔案路徑 (包括目錄) 中的 Unicode 字元數目。 此限制是個別字元長度的一個因素，由以位元組為單位的字元大小來決定。 例如，NFS 和 SMB 允許路徑元件有 255 個位元組。 美國資訊交換標準代碼的檔案編碼格式（ASCII）使用8位編碼，這表示 ASCII 中的檔案路徑元件（例如檔案或資料夾名稱）最多可以有255個字元，因為 ASCII 字元的大小為1位元組。
下表顯示 Azure NetApp Files 磁碟區中支援的元件和路徑長度：
| 元件 | NFS | SMB |
|---|---|---|
| 路徑元件大小 | 255 個位元組 | 255 個位元組 |
| 路徑長度大小 | 不限定 | 預設：255 個位元組 Windows 更新版本中的最大值：32,767 個位元組 |
| 橫向的路徑大小上限 | 4,096 個位元組 | 255 個位元組 |
注意
雙重通訊協定磁碟區會使用最低的最大值。
如果 SMB 共用名稱為 \\SMB-SHARE，則此共用名稱新增 11 個 Unicode 字元至路徑長度，因為每個字元都是 1 個位元組。 如果特定檔案的路徑為 \\SMB-SHARE\apps\archive\file，則為 29 個 Unicode 字元；每個字元 (包括斜線) 都是 1 個位元組。 NFS 裝載適用相同的概念。 裝載路徑 /AzureNetAppFiles 是 17 個 Unicode 字元，每個字元 1 個位元組。
Azure NetApp Files 與新式 Windows 伺服器支援相同的 SMB 共用路徑長度：最多 32,767 個位元組。 不過，視 Windows 用戶端的版本而定，某些應用程式不支援超過 260 個位元組的路徑。 個別路徑元件 (斜線之間的值，例如，檔案或資料夾名稱) 最多支援 255 個位元組。 例如，在 Azure NetApp Files 的檔案路徑中，使用拉丁大寫字母 “A” (每個字元佔用 1 個位元組) 的檔名不能超過 255 個字元。
# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
mkdir: cannot create directory ‘256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’: File name too long
# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
# ls | grep 255
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
辨別字元大小
Linux 公用程式 uniutils 可以用來尋找 Unicode 字元的位元組大小，只要輸入字元執行個體的多個執行個體，然後檢視 [位元組] 欄位即可。
範例 1：對於拉丁大寫字母 A，每次使用時遞增 1 個位元組 (使用單一個十六進位值 41，該值在 ASCII 字元的 0-255 範圍內)。
# printf %b 'AAA' | uniname
character byte UTF-32 encoded as glyph name
0 0 000041 41 A LATIN CAPITAL LETTER A
1 1 000041 41 A LATIN CAPITAL LETTER A
2 2 000041 41 A LATIN CAPITAL LETTER A
結果 1：名稱 AAA 使用 255 個位元組中的 3 個位元組。
範例 2：對於日文字元「字」，每個執行個體遞增 3 個位元組。 這也可以透過 [編碼為] 欄位下 3 個個別的十六進位字碼值 (E5、AD、97) 來計算。 每個十六進位值代表 1 個位元組：
# printf %b '字字字' | uniname
character byte UTF-32 encoded as glyph name
0 0 005B57 E5 AD 97 字 CJK character Nelson 1281
1 3 005B57 E5 AD 97 字 CJK character Nelson 1281
2 6 005B57 E5 AD 97 字 CJK character Nelson 1281
結果 2：名為「字字字」的檔案使用 255 個位元組中的 9 個位元組。
範例 3：對於具有直立符號的字母 Ä，每個執行個體使用 2 個位元組 (C3 + 84)。
# printf %b 'ÄÄÄ' | uniname
character byte UTF-32 encoded as glyph name
0 0 0000C4 C3 84 Ä LATIN CAPITAL LETTER A WITH DIAERESIS
1 2 0000C4 C3 84 Ä LATIN CAPITAL LETTER A WITH DIAERESIS
2 4 0000C4 C3 84 Ä LATIN CAPITAL LETTER A WITH DIAERESIS
結果 3：名為 ÄÄÄÄ 的檔案使用 255 個位元組中的 6 個位元組。
範例 4：😃 表情符號等特殊字元屬於未定義的範圍，超過 Unicode 字元所使用的 0-3 個位元組。 因此，其使用代理字組進行其字元編碼。 在此情況下，字元的每個執行個體都使用 4 個位元組。
# printf %b '😃😃😃' | uniname
character byte UTF-32 encoded as glyph name
0 0 01F603 F0 9F 98 83 😃 Character in undefined range
1 4 01F603 F0 9F 98 83 😃 Character in undefined range
2 8 01F603 F0 9F 98 83 😃 Character in undefined range
結果 4：名為 😃😃😃 的檔案使用 255 個位元組中的 12 個位元組。
大部分的表情符號都屬於 4 個位元組範圍，但最多可以達到 7 個位元組。 在超過一千個標準表情符號中，大約 180 個屬於基本多文種平面 (BMP)，這表示可以根據用戶端對語言類型的支援，在 Azure NetApp Files 中顯示為文字或表情符號。
如需 BMP 和其他 Unicode 平面的詳細資訊，請參閱了解 Azure NetApp Files 中的磁碟區語言。
字元位元組對路徑長度的影響
雖然路徑長度被認為是檔案或資料夾名稱中的字元數，但實際上是路徑中支援的位元組大小。 由於每個字元都會為名稱新增位元組大小，因此不同語言的不同字元集所支援的檔案名稱長度也不盡相同。
請考量下列案例：
檔案或資料夾的檔案名稱重複拉丁字母字元 “A”。 (例如，AAAAAAAA)
由於 “A” 使用 1 個位元組，且 255 個位元組是路徑元件大小限制，因此檔案名稱中允許 255 個 “A” 執行個體。
檔案或資料夾在名稱中重複日文字元「字」。
由於 「字」 的大小為 3 個位元組，因此檔案名稱長度限制為 85 個「字」執行個體 (3 個位元組 * 85 = 255 個位元組)，或者總共 85 個字元。
檔案或資料夾在名稱中重複露齒笑臉表情符號 (😃)。
露齒笑臉表情符號 (😃) 使用 4 個位元組，這表示只包含該表情符號的檔案名稱允許總共 64 個字元 (255 個位元組/4 個位元組)。
- 檔案或資料夾使用不同字元的組合 (亦即，Name字😃)。
若檔案或資料夾名稱使用不同位元組大小的不同字元，每個字元的位元組大小都會影響檔案或資料夾長度。 名為 Name字😃 的檔案或資料夾名稱使用總共 255 個位元組長度中的 1+1+1+1+3+4 個位元組 (11 個位元組)。
特殊表情符號概念
特殊表情符號，例如，旗標表情符號，存在於 BMP 分類之下：表情符號會根據用戶端支援，轉譯為文字或影像。 若用戶端不支援影像指定，會改用區域文字型指定。
例如，美國旗標使用 "us" 字元 (類似於拉丁字元 U+S，但實際上是使用不同編碼的特殊字元)。 Uniname 會顯示字元之間的差異。
# printf %b 'US' | uniname
character byte UTF-32 encoded as glyph name
0 0 000055 55 U LATIN CAPITAL LETTER U
1 1 000053 53 S LATIN CAPITAL LETTER S
# printf %b '🇺🇸' | uniname
character byte UTF-32 encoded as glyph name
0 0 01F1FA F0 9F 87 BA 🇺 Character in undefined range
1 4 01F1F8 F0 9F 87 B8 🇸 Character in undefined range
對於旗標表情符號所指定的字元，在受支援的系統中會轉譯成旗標影像，但在不受支援的系統中則保留為文字值。 若使用旗標表情符號，這些字元中每個字元使用 4 個位元組，總計 8 個位元組。 因此，檔案名稱中總共允許 31 個旗標表情符號 (255 個位元組/8 個位元組)。
SMB 路徑限制
依預設，Windows 伺服器和用戶端支援的路徑長度最多 260 個位元組，但是，因為 <NUL> 值及網域資訊等中繼資料新增至 Windows 路徑，導致實際的檔案路徑長度較短。
在 Windows 中超過路徑限制時，會出現對話方塊：
使用 Windows 10/Windows Server 2016 1607 版或更新版本時，可以透過變更登錄值的方式 (如路徑長度上限中所述) 來擴充 SMB 路徑長度。 若此值變更，路徑長度最多可延伸至 32,767 個位元組 (減去中繼資料值)。
啟用此功能之後，您必須在路徑中使用 \\?\ 來存取 SMB 共用需求，以允許較長的路徑長度。 此方法不支援 UNC 路徑，因此 SMB 共用必須對應至磁碟機代號。
改用 \\?\Z: 便可存取和支援較長的檔案路徑。
注意
Windows CMD 目前不支援使用 \\?\。
無法增加路徑長度上限的因應措施
如果 Windows 環境中無法啟用路徑長度上限，或 Windows 用戶端版本太低，有因應措施可供使用。 您可以將 SMB 共用裝載至目錄結構的更深處，並減少查詢的路徑長度。
例如，對應 \\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 至 Z:，而非對應 \\NAS-SHARE\AzureNetAppFiles 至 Z:。
NFS 路徑限制
對於個別的路徑元件，Azure NetApp Files 磁碟區的 NFS 路徑限制一樣為 255 個位元組限制。 不過，每個元件一次評估一個，每個要求最多可以處理 4,096 個位元組，總路徑長度幾乎無限。 例如，若每個路徑元件為 255 個位元組，則 NFS 用戶端每個要求最多可以評估 15 個元件 (包括 / 字元)。 因此，對超過 4,096 個位元組限制的路徑所提出的 cd 要求，會產生「檔案名稱太長」錯誤訊息。
在大部分情況下，Unicode 字元為 1 個位元組或更少，因此 4,096 個位元組的限制對應至 4,096 個字元。 如果字元的大小大於 1 個位元組，則路徑長度會小於 4,096 個字元。 大小大於 1 個位元組的字元，在總字元數中的計數超過 1 個位元組字元。
您可以使用 getconf PATH_MAX /NFSmountpoint 命令來查詢路徑長度上限。
注意
限制定義在 NFS 用戶端的 limits.h 檔案中。 請勿調整這些限制。
雙重通訊協定磁碟區考量
使用 Azure NetApp Files 進行雙重通訊協定存取時，在 NFS 和 SMB 通訊協定中處理路徑長度的差異，可以在檔案和資料夾之間建立不相容。 例如，Windows SMB 支援路徑最多 32,767 個字元 (前提是 SMB 用戶端上已啟用長路徑功能)，但 NFS 支援可超過該數量。 因此，若在 NFS 中建立的路徑長度超出了 SMB 的支援，則一旦達到路徑長度上限後，用戶端便無法存取資料。 在這些情況下，在建立檔案和資料夾名稱 (以及資料夾路徑深度) 時，請小心考慮跨通訊協定的檔案路徑長度下限，或將 SMB 共用對應至最接近的所需資料夾路徑，以減少路徑長度。
請考慮將 SMB 共用對應至 \\share\folder1\folder2\folder3\folder4 的整個路徑，而非將其對應至磁碟區的頂層以向下導覽至 \\share\folder1\folder2\folder3\folder4 的路徑。 因此，對應至 Z: 的磁碟機代號會進入所需資料夾，並將路徑長度從 Z:\folder1\folder2\folder3\folder4\file 減少到 Z:\file。
特殊字元考量
Azure NetApp Files 磁碟區使用 C.UTF-8 的語言類型，涵蓋許多國家/地區和語言，包括德文、斯拉夫文、希伯來文，以及大部分中文/日文/韓文（CJK）。 Unicode 中最常見的文字字元是 3 個位元組或以下。 特殊字元，例如，表情符號、音樂符號和數學符號，通常大於 3 個位元組。 有些使用 UTF-16 代理字組邏輯。
如果您使用 Azure NetApp Files 不支援的字元，則可能會看到一則警告，要求使用不同的檔案名稱。
該錯誤實際上不是名稱太長，而是因為字元位元組大小太大，無法透過 SMB 使用 Azure NetApp Files 磁碟區。 對於此限制，Azure NetApp Files 沒有因應措施。 如需 Azure NetApp Files 中特殊字元處理方式的詳細資訊，請參閱使用特殊字元集的通訊協定行為。