瞭解 Azure NetApp Files 中的路徑長度
檔案和路徑長度是指檔案路徑中的 Unicode 字元數目，包括目錄。 如果個別字元長度是由位元組位元的大小所決定，則此限制是一個因素。 例如，NFS 和 SMB 允許 255 個字節的路徑元件。 ASCII 的檔案編碼格式使用 8 位編碼，這表示 ASCII 中的檔案路徑元件（例如檔案或資料夾名稱）最多可以有 255 個字元，因為 ASCII 字元的大小為 1 位元組。
下表顯示 Azure NetApp Files 磁碟區中支援的元件和路徑長度：
| 元件 | NFS | SMB |
|---|---|---|
| 路徑元件大小 | 255 個字節 | 255 個字節 |
| 路徑長度大小 | 不限定 | 默認值：255 個字節 更新 Windows 版本中的最大值：32,767 個字節 |
| Transversal 的路徑大小上限 | 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： Emoji 等 😃 特殊字元落入未定義的範圍，超過 Unicode 字元所使用的 0-3 個字節。 因此，它會使用 Surrogate 配對進行其字元編碼。 在此情況下，字元的每個實例都會使用 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 中顯示為文字或 emoji。
如需 BMP 和其他 Unicode 平面的詳細資訊，請參閱 瞭解 Azure NetApp Files 中的磁碟區語言。
位元位元組對路徑長度的影響
雖然路徑長度被認為是檔案或資料夾名稱中的字元數，但它實際上是 路徑中支援的位元組大小 。 由於每個字元都會將位元組大小新增至名稱，因此不同語言中的不同字元集支援不同的檔名長度。
請考量下列案例：
檔案或資料夾會針對檔名重複拉丁字母字元 「A」。。 （例如，AAAAAAAA）
由於 「A」 使用 1 個字節和 255 個字節是路徑元件大小限制，因此檔名中會允許 255 個 “A” 實例。
檔案或資料夾會在其名稱中重複日文字元字。
由於 「字」 的大小為 3 個字節，檔名長度限制會是 85 個字實例（3 個字節 * 85 = 255 個字節），或總共 85 個字元。
檔案或資料夾會以其名稱重複笑臉表情符號 （😃） 。
笑臉表情符號 （😃） 使用 4 個字節，這表示只有 emoji 的檔名會允許總計 64 個字元（255 個字節/4 個字節）。
- 檔案或資料夾使用不同字元的組合（即名稱字😃）。
當不同位元組大小的不同字元用於檔案或資料夾名稱時，每個字元的位元組大小都會因檔案或資料夾長度而有所不同。 Name 字😃 的檔案或資料夾名稱會使用總計 255 位元組長度的 1+1+1+1+3+4 位元組（11 個字節）。
特殊表情符號概念
特殊表情符號，例如旗標 emoji，存在於 BMP 分類之下：emoji 會根據客戶端支持轉譯為文字或影像。 當用戶端不支援影像指定時，它會改用區域文字型指定。
例如，美國 旗標會使用 「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
為旗標 emoji 指定的字元會轉譯為支持系統中的影像旗標，但在不支持的系統中保留為文字值。 當使用旗標 emoji 時，這些字元會針對總計 8 個字節使用每個字元 4 個字節。 因此，檔名中總共允許 31 個旗標表情符號（255 個字節/8 個字節）。
SMB 路徑限制
根據預設，Windows 伺服器和客戶端支援最多 260 個字節的路徑長度，但實際的檔案路徑長度較短，因為元數據會新增至 Windows 路徑，例如<NUL>值和網域資訊。
在 Windows 中超過路徑限制時，會出現對話框：
使用 Windows 10/Windows Server 2016 1607 版或更新版本時，可以擴充 SMB 路徑長度，方法是變更登錄值，如路徑長度上限限制中所述。 當此值變更時，路徑長度最多可延伸至 32,767 個字節（減去元數據值）。
啟用此功能之後，您必須使用 \\?\ 路徑中的 來存取 SMB 共用需求，以允許較長的路徑長度。 此方法不支援 UNC 路徑，因此 SMB 共用必須對應至驅動器號。
使用 \\?\Z: 可改為允許存取，並支援較長的檔案路徑。
注意
Windows CMD 目前不支援 使用 \\?\。
如果無法增加路徑長度上限，則因應措施
如果 Windows 環境中無法啟用路徑長度上限，或 Windows 用戶端版本太低，則有因應措施。 您可以更深入地掛接SMB共用至目錄結構，並減少查詢的路徑長度。
例如，與其對應 \\NAS-SHARE\AzureNetAppFiles 至 Z:，而是對應 \\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 至 Z:。
NFS 路徑限制
Azure NetApp Files 磁碟區的 NFS 路徑限制對於個別路徑元件具有相同的 255 位元組限制。 不過，每個元件會一次評估一個，而且每個要求最多可以處理 4,096 個字節，且路徑長度幾乎無限。 例如，如果每個路徑元件為 255 個字節，則 NFS 用戶端每個要求最多可以評估 15 個元件（包括 / 字元）。 因此， cd 超過 4,096 位元組限制之路徑的要求會產生「檔名太長」錯誤訊息。
在大部分情況下，Unicode 字元為 1 位元組或更少，因此 4,096 位元組的限制會對應至 4,096 個字元。 如果字元的大小大於1位元組，則路徑長度小於4,096個字元。 大小大於1位元組的位元會根據字元總數計算超過1位元組字元。
您可以使用 命令來查詢 getconf PATH_MAX /NFSmountpoint 路徑長度上限。
注意
限制定義於 limits.h NFS 用戶端的 檔案中。 您不應該調整這些限制。
雙重通訊協定磁碟區考慮
使用 Azure NetApp Files 進行雙重通訊協定存取時，在 NFS 和 SMB 通訊協定中如何處理路徑長度的差異，可以在檔案和資料夾之間建立不相容。 例如，Windows SMB 支援路徑中最多 32,767 個字元（前提是 SMB 用戶端上已啟用長路徑功能），但 NFS 支援可能會超過該數量。 因此，如果在超過SMB支援的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 個字節或更少。 特殊字元，例如 emoji、音樂符號和數學符號，通常大於 3 個字節。 有些使用 UTF-16代理字組邏輯。
如果您使用 Azure NetApp Files 不支援的字元，您可能會看到要求不同檔名的警告。
相較於名稱太長，錯誤實際上會導致字元位元組大小太大，而無法透過SMB使用 Azure NetApp Files 磁碟區。 Azure NetApp Files 中沒有因應措施可進行這項限制。 如需 Azure NetApp Files 中特殊字元處理的詳細資訊，請參閱 使用特殊字元集的通訊協議行為。