你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
文件和路径长度是指文件路径中允许的 Unicode 字符数,包括目录。 在 Azure NetApp 文件中,NFS 和 SMB 协议在处理文件和文件夹名称中的字符的方式有些不同。
- 在 NFS 中,字符字节大小是路径长度的重要因素。
- 在 SMB 中,字符字节大小不太重要,但路径长度可能会受到客户端配置方式和 SMB 共享连接方式的影响。
下表显示了“Azure NetApp 文件”服务的卷中支持的组成部分和路径长度:
| Component | NFS | SMB |
|---|---|---|
| 路径组成部分大小 | 255 bytes | 最多 255 个字符 |
| 路径长度大小 | Unlimited | 最多 255 个字符(默认值) 更高版本中的最大值:32,767 个字符 |
| 横向路径的最大路径大小 | 4,096 bytes | 255 characters |
Note
双协议卷使用最低的最大值。
Azure NetApp 文件中的 NFS 路径长度注意事项
在 Azure NetApp 文件 NFS 卷中,字符字节大小是单个路径长度的一个因素。 例如,NFS 允许最大大小为 255 字节的路径组件。 American Standard Code for Information Interchange (ASCII) 的文件编码格式使用 8 位编码,这意味着 ASCII 中的文件路径组件(如文件或文件夹名称)最多可以包含 255 个字符,因为 ASCII 字符的大小为 1 字节。 有关详细信息,请参阅 字符字节对路径长度的影响。
Azure NetApp 文件中的 SMB 路径长度注意事项
Azure NetApp 文件中的 SMB 路径长度默认为最多 255 个字符,而不考虑字符的字节大小。 Windows 服务器和客户端支持最大 260 字节的路径长度,但由于将元数据添加到 Windows 路径(如<NUL>值和域信息)中,实际文件路径长度较短。
在 Windows 中,当超出路径限制时,将显示一个对话框:
与 NFS 不同,字符的较大字节大小由存储系统存储在单独的区域中,所有字符都被视为大小为 1 字节。 但是,整个路径的长度默认为 255 个字符,这意味着路径的每个段都会计入总长度。 因此,SMB 共享的入口点可能会影响文件或文件夹路径名称的总可用字符数。 例如,如果 SMB 服务器的 UNC 路径名称为 \\SMB-SHARE\,UNC 名称会将 12 个 Unicode 字符添加到路径长度(包括 \)。 如果特定文件路径是\\SMB-SHARE\apps\archive\,那么它包含了最大255个字符中的25个Unicode字符。 如果 SMB 共享映射到驱动器号(例如, Z:/),则仅使用 255 个字符中的 3 个字符。
这意味着,在上述每个方案中,文件或文件夹的最大名称长度可能有所不同。
-
\\SMB-SHARE\(12 个字符)允许长度为 243 个字符的文件夹或文件名 -
\\SMB-SHARE\apps\archive\(25 个字符)允许长度为 230 个字符的文件夹或文件名 -
Z:\(三个字符;映射到\\SMB-SHARE\apps\archive\)将允许长度为 252 个字符的文件夹或文件名
虽然 255 个字符是 SMB 共享(Windows 限制)的最大默认路径长度,但 Azure NetApp 文件还支持新式 Windows 服务器支持的 SMB 共享的相同允许路径长度: 最多 32,767 字节。 但是,根据 Windows 客户端的版本,某些应用程序无法 支持超过 260 个字节的路径。 单个路径组件(斜杠(如文件或文件夹名称)之间的值最多支持 255 个字符。
如果文件或文件夹名称超过允许的最大字符数,则会显示以下错误:
# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
mkdir: cannot create directory ‘256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’: File name too long
# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
# ls | grep 255
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
在 Windows 中扩展 SMB 路径限制
使用 Windows 10/Windows Server 2016 版本 1607 或更高版本时,可以通过更改注册表值(如最大路径长度限制中所述)来扩展 SMB 路径长度。 更改此值后,路径长度可以扩展到最多 32,767 个字节(减去元数据值)。
启用此功能后,必须在路径中使用 \\?\ 来访问 SMB 共享,以允许更长的路径长度。 此方法不支持 UNC 路径,因此 SMB 共享需要映射到驱动器号。
改用 \\?\Z: 将允许访问并支持更长的文件路径。
Note
Windows CMD 目前不支持使用 \\?\。
如果无法增加最大 SMB 路径长度,请考虑使用以下替代方案
如果无法在 Windows 环境中启用最大路径长度或 Windows 客户端版本太低,有一种解决方法。 你可以将 SMB 共享更深入地装载到目录结构中,并减小查询的路径长度。
例如,请将 \\NAS-SHARE\AzureNetAppFiles 映射到 Z:,而不是将 \\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 映射到 Z:。
NFS 路径限制
“Azure NetApp 文件”服务卷的 NFS 路径限制对单个路径组成部分同样具有 255 个字节的限制。 但是,每个组成部分一次评估一个,每个请求最多可以处理 4,096 个字节,总路径长度几乎是无限的。 例如,如果每个路径组成部分为 255 个字节,则 NFS 客户端可以每个请求最多评估 15 个组成部分(包括 / 字符)。 因此,对超过 4,096 个字节限制的路径发出的 cd 请求会导致“文件名太长”错误消息。
在大多数情况下,Unicode 字符为 1 个字节或更少,因此 4,096 个字节的限制对应于 4,096 个字符。 如果字符的大小大于 1 个字节,则路径长度小于 4,096 个字符。 与单字节字符相比,大小大于 1 个字节的字符将会在总字符计数中产生更高的计数。
可以使用 getconf PATH_MAX /NFSmountpoint 命令查询路径长度最大值。
Note
该限制在 NFS 客户端的 limits.h 文件中定义。 请勿调整这些限制。
识别字符大小
Linux 实用工具 uniutils 可以通过键入字符实例的多个实例并查看“bytes”字段来查找 Unicode 字符的字节大小。
示例 1:拉丁文大写字母 A 每次使用都会递增 1 个字节(使用单个十六进制值 41,在 0-255 的 ASCII 字符范围内)。
# 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 使用了 3 个字节(最多 255 个字节)。
示例 2:日语字符“字”每个实例会递增 3 个字节。 这也可以通过“encoded as”字段下的 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:命名为“字字字”的文件使用了 9 个字节(最多 255 个字节)。
示例 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:命名为“ÄÄÄ”的文件使用了 6 个字节(最多 255 个字节)。
示例 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 文件”服务中显示为文本或表情符号(具体取决于客户端支持的语言类型)。
有关 BMP 和其他 Unicode 平面的详细信息,请参阅了解“Azure NetApp 文件”服务中的卷语言。
字符字节对路径长度的影响
尽管路径长度被认为是文件名或文件夹名称中的字符数,但它实际上是路径中支持的字节大小。 由于每个字符都会使名称的字节大小增大,因此不同语言的不同字符集支持不同的文件名长度。
请考虑下列情形:
文件或文件夹以重复的拉丁字母字符“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 个字节)。
特殊字符注意事项
“Azure NetApp 文件”服务卷使用语言类型 C.UTF-8,其中涵盖了许多国家/地区和语言,包括德语、西里尔文、希伯来语和大多数中文/日语/朝鲜语 (CJK)。 Unicode 中的最常见文本字符为 3 个字节或更少。 特殊字符(如表情符号、音乐符号和数学符号)通常大于 3 个字节。 有些使用 UTF-16 代理项对逻辑。
如果使用了“Azure NetApp 文件”服务不支持的字符,可能会看到要求请求其他文件名的警告。
该错误实际上是因字符字节大小过大导致“Azure NetApp 文件”服务卷无法通过 SMB 使用而导致的,而不是由于名称过长。 “Azure NetApp 文件”服务中没有针对此限制的解决方法。 有关“Azure NetApp 文件”服务中的特殊字符处理的详细信息,请参阅有关特殊字符集的协议行为。
双协议卷注意事项
使用 Azure NetApp 文件进行双重协议访问时,NFS 和 SMB 协议中路径长度处理方式的差异可能会导致文件和文件夹之间的不兼容。 例如,Windows SMB 在路径中最多支持 32,767 个字符(前提是在 SMB 客户端上启用了长路径功能),但 NFS 支持可能会超过该数量。 因此,如果在 NFS 中创建了超过 SMB 支持范围的路径长度,那么一旦达到最大路径长度,客户端将无法访问数据。 在这些情况下,请在创建文件名和文件夹名称(以及文件夹路径深度)时,考虑不同协议的文件路径长度限制(使用较小的限制值),或者将 SMB 共享映射到更接近所需文件夹路径的位置以减小路径长度。
请考虑将 SMB 共享映射到整个路径 \\share\folder1\folder2\folder3\folder4,而不是将 SMB 共享映射到卷的顶层以导航到路径 \\share\folder1\folder2\folder3\folder4。 因此,映射到 Z: 的驱动器号将会进入所需文件夹中,将路径长度从 Z:\folder1\folder2\folder3\folder4\file 缩短为 Z:\file。