本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
Package 组定义语法和匹配行为
本主题包含有关定义包组、模式匹配行为、包关联强度和包组层次结构的信息。
Package 组定义语法和示例
定义包组的模式语法严格遵循软件包路径的格式。包路径是根据包的坐标组件（格式、命名空间和名称）创建的，方法是在开头添加正斜杠，然后用正斜杠分隔每个组件。例如，命名空间中命名anycompany-ui-components的 npm 包的包路径是 /npm/sp ac e/ anycompany-ui-components。
包组模式遵循与包路径相同的结构，唯一的不同是省略了未指定为组定义一部分的组件，并且该模式以后缀结尾。包含的后缀决定了模式的匹配行为，如下所示：
后
$缀将与完整的包裹坐标相匹配。后
~缀将与前缀匹配。后
*缀将匹配先前定义的组件的所有值。
以下是每种允许组合的示例模式：
所有包裹格式：
/*特定的包裹格式：
/npm/*Package 格式和命名空间前缀：
/maven/com.anycompany~Package 格式和命名空间：
/npm/space/*Package 格式、命名空间和名称前缀：
/npm/space/anycompany-ui~Package 格式、命名空间和名称：
/maven/org.apache.logging.log4j/log4j-core$
如上面的示例所示，~后缀被添加到命名空间或名称的末尾以表示前缀匹配，当用于匹配路径中下一个组件的所有值（所有格式、所有命名空间或所有名称）时，后缀位于正斜杠之后。*
Package 组定义和标准化
CodeArtifact 对 NuGet Python 和 Swift 包名进行标准化，并在存储 Swift 包命名空间之前对其进行标准化。 CodeArtifact 将包与包组定义进行匹配时使用这些标准化名称。因此，包含这些格式的命名空间或名称的软件包组必须使用标准化的命名空间和名称。有关如何规范包名称和命名空间的更多信息，请参阅、P NuGetyth on 和 Swift 名称标准化文档。
软件包组定义中的命名空间
对于没有命名空间的包或包格式（Python 和 NuGet），包组不得包含命名空间。这些包组的包组定义包含一个空白的命名空间部分。例如，名为 requests 的 Python 包的路径是 /python//request s。
对于带有命名空间的软件包或包格式（Maven、generic 和 Swift），如果包含软件包名称，则必须包含命名空间。对于 Swift 包格式，将使用标准化的包命名空间。有关如何规范化 Swift 包命名空间的更多信息，请参阅。Swift 程序包名称和命名空间规范化
Package 组层次结构和模式特异性
“在” 或 “与包组相关联” 的软件包是指其包路径与该组的模式相匹配但与更具体的组的模式不匹配的软件包。例如，给定包组/npm/*和，包路径 /npm//react 与第一组 () 关联/npm/space/*，而 /npm/spac e/ aui.components 和 /npm/space/ 与第二组 (/npm/*) 关联。amplify-ui-core /npm/space/*尽管一个包可能匹配多个组，但每个包仅与一个组相关联，即最具体的匹配项，并且只有该组的配置适用于该软件包。
当一个包路径与多个模式匹配时，可以将 “更具体” 的模式视为最长的匹配模式。或者，更具体的模式是与不太具体的模式匹配的适当软件包子集的模式。在我们之前的示例中，每个匹配的包/npm/space/*也都匹配/npm/*，但反之亦然，这使得/npm/space/*模式更具体，因为它是一个适当的子集/npm/*。由于一个组是另一个组的子集，因此它会创建一个层次结构，/npm/space/*即父组的子组。/npm/*
尽管只有最具体的软件包组的配置适用于软件包，但可以将该组配置为继承其父组的配置。
单词、单词边界和前缀匹配
在讨论前缀匹配之前，让我们定义一些关键术语：
一个单词：一个字母或数字，后跟零个或多个字母、数字或标记字符（例如重音符号、变音符号等）。
当到达非单词字符时，单词边界位于单词的末尾。非单词字符是标点符号
.，例如-、和。_
具体而言，单词的正则表达式模式是[\p{L}\p{N}][\p{L}\p{N}\p{M}]*，可以分解如下：
\p{L}代表任何字母。\p{N}代表任意数字。\p{M}代表任何标记字符，例如重音符号、变音符号等。
因此，[\p{L}\p{N}]代表一个数字或字母，[\p{L}\p{N}\p{M}]*代表零个或多个字母、数字或标记字符，并且单词边界位于此正则表达式模式的每个匹配项的末尾。
注意
单词边界匹配基于 “单词” 的定义。它不是基于字典中定义的单词，或 CameCase。例如，oneword或中没有单词边界OneWord。
现在定义了单词和单词边界，我们可以用它们来描述中的前缀匹配 CodeArtifact。为了表示单词边界上的前缀匹配，在单词字符后面使用匹配字符 (~)。例如，模式与包路径/npm/space/foo和/npm/space/foo~匹配/npm/space/foo-bar，但不匹配/npm/space/food或/npm/space/foot。
需要使用通配符 (*)，而不是跟随非单词字符，例如在模式中。~ /npm/*
区分大小写
Package group 定义区分大小写，这意味着只有大小写不同的模式可以作为单独的包组存在。例如，用户可以使用 npm Public Registry 上存在的三个单独的软件包创建单独的软件包组：AsyncStorage、、、、、、，它们仅/npm//asyncstorage$因大小写而异。/npm//AsyncStorage$ /npm//asyncStorage$
尽管大小写很重要， CodeArtifact 但如果包裹的模式变体因大小写而异，则仍会将包裹与包裹组关联起来。如果用户在创建/npm//AsyncStorage$软件包组时没有创建上面显示的其他两个组，则名称AsyncStorage的所有大小写变体，包括 AsyncStorage 和 as yncStorag e，都将与该软件包组相关联。但是，如下一节所述强弱匹配，这些变体的处理方式将与模式完全匹配。AsyncStorage
强弱匹配
上一节中的信息说明包组区分大小写，然后解释它们不区分大小写。区分大小写这是因为中的软件包组定义 CodeArtifact 具有强匹配（或完全匹配）和弱匹配（或变体匹配）的概念。强匹配是指包装与图案完全匹配，没有任何变化。弱匹配是指包装与图案的变体（例如不同的字母大小写）相匹配。弱匹配行为可防止包组模式变体的软件包汇总到更通用的包组。当软件包是最具体的匹配组模式的变体（弱匹配）时，该包与该组关联，但该包会被屏蔽，而不是应用该组的源控制配置，从而阻止该包的任何新版本从上游拉出或发布。这种行为降低了由于名称几乎相同的包裹的依赖关系混淆而导致的供应链攻击的风险。
为了说明弱匹配行为，假设包组/npm/*允许摄取并阻止发布。更具体的软件包组被配置为阻止摄取并允许发布。/npm//anycompany-spicy-client$名anycompany-spicy-client为的软件包与软件包组非常匹配，该组允许发布软件包版本并阻止获取软件包版本。允许发布的软件包名称的唯一大小写是 anycompany-spicy-client，因为它与软件包定义模式非常匹配。不同的大小写变体（例如 AnyCompany-spicy-client）被禁止发布，因为匹配度较弱。更重要的是，软件包组会阻止提取所有大小写变体，而不仅仅是模式中使用的小写名称，从而降低了依赖混淆攻击的风险。
其他变体
除了大小写差异外，弱匹配还会忽略破折号-、点号._、下划线和可混淆字符序列中的差异（例如来自不同字母表的外观相似的字符）。在用于弱匹配的标准化过程中， CodeArtifact 执行大小写折叠（类似于转换为小写字母），用单个点替换短划线、点和下划线字符序列，并对可混淆的字符进行标准化。
弱匹配将破折号、点和下划线视为等效，但不会完全忽略它们。这意味着 foo -bar、f oo.bar、foo... bar 和 f oo_bar 都是弱匹配等效物，但是 foobar 不是。尽管一些公共存储库实施了防止此类变化的措施，但公共存储库提供的保护并没有使软件包组的这一功能变得不必要。例如，诸如 npm Public Registry 注册表之类的公共存储库只有在 my-package 已经发布到名为 my-package 的包时才会阻止其出现新的变体。如果 my- package 是一个内部软件包，并且创建了允许发布和阻止摄取的包组/npm//my-package$，那么你可能不想为了防止诸如 my.package 之类的变体被允许而将 my- package 发布到 npm Public Registry。
虽然某些包格式（例如 Maven）对这些字符的处理方式不同（Maven . 将其视为命名空间层次结构分隔符但不是 -_），但像 com.act-on 这样的软件包仍然可能与 com.act.on 混淆。
注意
请注意，每当多个变体与一个包裹组关联时，管理员都可以为特定变体创建一个新的包裹组，为该变体配置不同的行为。
