本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
Package 群組定義語法和相符行為
本主題包含有關定義封裝群組、模式比對行為、封裝關聯強度和套件群組階層的資訊。
Package 群組定義語法與範例
定義套裝軟體群組的模式語法會緊跟套件路徑的格式。套件路徑是從套件的座標元件 (格式、命名空間和名稱) 建立的，方法是在開頭加上正斜線，並以正斜線分隔每個元件。例如，在命名空間anycompany-ui-components中命名的 npm 套件的套件路徑是 /npm/ space/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 將套件與套件群組定義相符時，會使用這些標準化名稱。因此，包含這些格式的命名空間或名稱的套件群組必須使用標準化的命名空間和名稱。有關軟件包名稱和命名空間如何標準化的更多信息，請參閱 NuGet，Python 和 Swift 名稱標準化文檔。
套件群組定義中的命名空間
對於沒有命名空間 (Python 和 NuGet) 的套件或套件格式，套件群組不得包含命名空間。這些套件群組的套件群組定義包含空白的命名空間區段。例如，名為請求的 Python 包的路徑是 /python// 請求。
對於具有命名空間（Maven，泛型和 Swift）的包或包格式，如果包含包名稱，則必須包含命名空間。對於斯威夫特包格式，規範化的包命名空間將被使用。如需 Swift 套件命名空間如何標準化的詳細資訊，請參閱。Swift 包名稱和命名空間規範化
Package 群組階層與模式特異性
「in」或「關聯」套件群組的套件是包含與群組模式相符的套件路徑，但不符合更具體群組的模式。例如，給定了包組/npm/space/*，/npm/*並且包路徑 /npm//反應與第一組（）相關聯，而 /npm/ 空間/ aui.組件和/npm/空間/ 與第二個組（/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 群組定義區分大小寫，也就是說，只有大小寫不同的模式可以作為個別的套件群組存在。例如，用戶可以使用模式創建單獨的軟件包組 /npm//AsyncStorage$/npm//asyncStorage$，以及/npm//asyncstorage$對於 npm 公共註冊表中存在的三個單獨的軟件包：AsyncStor age AsyncStorage，僅因大小寫而異的異步存儲。
儘管案例很重要，但如果套件的模式有不同的變化，則 CodeArtifact 仍會將套件與套件群組產生關聯。如果用戶在沒有創建上面顯示的其他兩個組的情況下創建了/npm//AsyncStorage$軟件包組，那麼名稱的所有大小寫變化 AsyncStorage，包括 AsyncStorage 和 asyncstorage 都將與軟件包組相關聯。但是，如下一節所述強弱匹配，這些變化的處理方式與完全符合模式的方式不同。AsyncStorage
強弱匹配
上一節中的資訊指出封裝群組區分大小寫，然後繼續說明它們不區分大小寫。區分大小寫這是因為中的包組定義 CodeArtifact 具有強匹配（或完全匹配）和弱匹配（或變體匹配）的概念。一個強大的匹配是當包裝完全匹配的模式，沒有任何變化。一個弱的匹配是當包匹配的模式的變化，如不同的字母大小寫。弱比對行為可防止套件群組模式變化的套件彙整為更一般的套件群組。當套件是最特定相符群組模式的變體 (弱比對) 時，套件會與群組產生關聯，但套件會遭到封鎖，而不是套用群組的原始控制組態，以防止套件的任何新版本從串流上移或發佈。這種行為可降低因名稱幾乎相同的套件相依性混淆而造成供應鏈攻擊的風險。
為了說明弱匹配行為，假設軟件包組/npm/*允許獲取和阻止發布。更具體的套件群組會設定為封鎖擷取並允許發佈。/npm//anycompany-spicy-client$名anycompany-spicy-client為的套件與套件群組相符，它允許發佈套件版本並封鎖擷取套件版本。允許發布的軟件包名稱的唯一大小寫是 anycompany-spicy-client，因為它與軟件包定義模式具有很強的匹配。不同的情況變化，例如 AnyCompany-辣-client 被阻止發布，因為它是一個弱匹配。更重要的是，套件群組會封鎖擷取所有大小寫變體，而不僅僅是模式中使用的小寫名稱，進而降低相依性混淆攻擊的風險。
其他變化
除了大小寫差異之外，弱匹配還忽略了破折號-，點 ._，下劃線和可混淆字符（例如來自單獨字母的類似字符）序列中的差異。在用於弱匹配的正規化期間， CodeArtifact 執行 case 折疊（類似於轉換為小寫），用單個點替換破折號，點和底線字符的序列，並將可混淆的字符標準化。
弱匹配將破折號，點和下劃線視為等效，但不會完全忽略它們。這意味著 FO O 酒吧，foo.bar，foo.. bar 和 foo_bar 都是弱匹配等價物，但不是。雖然有幾個公用儲存庫實作了防止這些變異類型的步驟，但是公用儲存庫所提供的保護並不會讓套件群組的這項功能變得不必要。例如，公共存儲庫（如 npm 公共註冊表註冊表）只會阻止名為 my-package 的軟件包的新變體，如果我的包已經發布到它。如果 my-package 是一個內部軟件包，並且創建了允許發布和塊獲取的包組/npm//my-package$，那麼您可能不希望將 my-package 發佈到 npm 公共註冊表以防止允許諸如 my. package 之類的變體。
儘管某些包格式（例如 Maven）對這些字符的方式對待這些字符（Maven 將其視.為命名空間層次結構分隔符，但不是-或_），但類似 com.act-on 的內容仍然可能與 com.act.on 混淆。
注意
請注意，無論何時有多個變體與封裝群組相關聯，管理員都可以針對特定變體建立新的封裝群組，以針對該變體配置不同的行為。
