翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# パッケージグループ定義の構文と一致動作
<a name="package-group-definition-syntax-matching-behavior"></a>

このトピックには、パッケージグループの定義、パターンマッチング動作、パッケージの関連付け強度、パッケージグループ階層に関する情報が含まれます。

**Contents**
+ [パッケージグループ定義の構文と例](#package-group-definition-syntax-examples)
  + [パッケージグループの定義と正規化](#package-group-definition-syntax-examples-normalization)
  + [パッケージグループ定義の名前空間](#package-group-definition-syntax-examples-namespaces)
+ [パッケージグループの階層とパターンの特異度](#package-group-hierarchy-pattern-specificity)
+ [単語、単語境界、プレフィックスマッチング](#package-group-word-boundary-prefix)
+ [大文字と小文字の区別](#package-group-case-sensitivity)
+ [強い一致と弱い一致](#package-group-strong-and-weak-match)
+ [その他のバリエーション](#package-group-additional-variations)

## パッケージグループ定義の構文と例
<a name="package-group-definition-syntax-examples"></a>

 パッケージグループを定義するためのパターン構文は、パッケージパスの形式に厳密に従います。パッケージパスは、パッケージの座標コンポーネント (形式、名前空間、名前) に基づき作成されます。先頭にスラッシュを追加し、各コンポーネントをスラッシュで区切ります。例えば、*space* という名前空間の *anycompany-ui-components* という npm パッケージのパッケージパスは、*/npm/space/anycompany-ui-components* です。

パッケージグループパターンは、パッケージパスと同じ構造に従います。ただし、グループ定義の一部として指定されていないコンポーネントは省略され、パターンの末尾にはサフィックスが付きます。付加されるサフィックスによって、パターンの一致動作が次のように決まります。
+ サフィックスが `$` の場合、完全なパッケージ座標が一致します。
+ サフィックスが `~` の場合、プレフィックスが一致します。
+ サフィックスが `*` の場合、以前に定義したコンポーネントのすべての値が一致します。

使用できる各組み合わせのパターン例を以下に示します。

1. すべてのパッケージ形式: `/*`

1. 特定のパッケージ形式: `/npm/*`

1. パッケージ形式と名前空間プレフィックス: `/maven/com.anycompany~`

1. パッケージ形式と名前空間: `/npm/space/*`

1. パッケージ形式、名前空間、名前プレフィックス: `/npm/space/anycompany-ui~`

1. パッケージ形式、名前空間、名前: `/maven/org.apache.logging.log4j/log4j-core$`

上記の例に示すように、`~` サフィックスは、プレフィックスの一致を表すために名前空間または名前の末尾に付加されます。パス内の次のコンポーネントのすべての値 (すべての形式、すべての名前空間、またはすべての名前) を一致させるために使用する場合、スラッシュの後に `*` が付加されます。

### パッケージグループの定義と正規化
<a name="package-group-definition-syntax-examples-normalization"></a>

CodeArtifact は、NuGet、Python、Swift パッケージ名を正規化し、保存する前に Swift パッケージ名前空間を正規化します。CodeArtifact は、パッケージグループ定義でパッケージを照合するときに、これらの正規化された名前を使用します。したがって、これらの形式の名前空間または名前を含むパッケージグループは、正規化された名前空間と名前を使用しなければなりません。パッケージ名と名前空間を正規化する方法の詳細については、[NuGet](nuget-name-normalization.md)、[Python](python-name-normalization.md)、[Swift](swift-name-normalization.md) の名前の正規化ドキュメントを参照してください。

### パッケージグループ定義の名前空間
<a name="package-group-definition-syntax-examples-namespaces"></a>

名前空間を含まないパッケージまたはパッケージ形式の場合 (Python および NuGet)、パッケージグループに名前空間を含めることはできません。これらのパッケージグループのパッケージグループ定義には、空白の名前空間セクションが含まれています。例えば、*requests* という名前の Python パッケージのパスは */python//requests* です。

名前空間を含むパッケージまたはパッケージ形式の場合 (Maven、汎用、Swift)、パッケージ名が含まれていれば名前空間を含める必要があります。Swift パッケージ形式の場合は、正規化されたパッケージ名前空間が使用されます。Swift パッケージ名前空間の正規化方法の詳細については、「[Swift パッケージ名と名前空間の正規化](swift-name-normalization.md)」を参照してください。

## パッケージグループの階層とパターンの特異度
<a name="package-group-hierarchy-pattern-specificity"></a>

パッケージグループに「含まれる」または「関連付けられる」パッケージとは、そのグループのパターンには一致するが、より詳細なパターンを持つ別のグループには一致しないパッケージです。例えば、パッケージグループ `/npm/*`と `/npm/space/*` の場合、パッケージパス */npm//react* は最初のグループ (`/npm/*`) に関連付けられ、*/npm/space/aui.components* と */npm/space/amplify-ui-core* は 2 番目のグループ (`/npm/space/*`) に関連付けられます。パッケージが複数のグループに一致する場合でも、そのパッケージが実際に関連付けられるのは 1 つのグループだけであり、それは最も特異的に一致するグループです。

パッケージパスが複数のパターンに一致する場合、より「特異的」なパターンとは、最長一致するパターンと考えることができます。別の言い方をすると、より特異的なパターンとは、より一般的なパターンに一致するパッケージのうち、真部分集合にだけ一致するパターンを指します。前の例では、`/npm/space/*` に一致するすべてのパッケージが `/npm/*` とも一致しますが、その逆は成り立ちません。つまり、`/npm/space/*` は、`/npm/*` の真部分集合であるため、より特異的なパターンになります。一方のグループがもう一方のグループの部分集合である場合、そこには階層が生じ、`/npm/space/*` は親グループである `/npm/*` のサブグループとなります。

パッケージには最も特異的なパッケージグループの設定のみが適用されますが、そのグループが親グループの設定を継承するように構成されている場合もあります。

## 単語、単語境界、プレフィックスマッチング
<a name="package-group-word-boundary-prefix"></a>

プレフィックスマッチングについて説明する前に、いくつかの重要な用語を定義します。
+ *単語*は、文字または数字であり、0 個以上の文字、数字、またはマーク文字 (アクセント、ウムラウトなど) が続きます。
+ *単語境界*は、単語以外の文字に達したときの単語の末尾にあります。単語以外の文字は、`.`、`-`、`_` などの句読点文字です。

具体的には、単語の正規表現パターンは `[\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}]*` は 0 個以上の文字、数字、またはマーク文字を表します。この正規表現パターンの各一致の末尾には単語境界があります。

**注記**  
単語境界の一致は、この「単語」の定義に基づいています。これは、辞書で定義される単語や CamelCase を基準にしたものではありません。例えば、`oneword` または `OneWord` に単語境界はありません。

以上のように単語と単語境界を定義したので、CodeArtifact のプレフィックスマッチングについて説明できます。単語境界のプレフィックスの一致を示すために、単語文字の後に一致文字 (`~`) が使用されます。例えば、パターン `/npm/space/foo~` は、パッケージパス `/npm/space/foo` と `/npm/space/foo-bar` に一致しますが、`/npm/space/food` と `/npm/space/foot` には一致しません。

パターン `/npm/*` のように、単語以外の文字に続く場合は `~` の代わりにワイルドカード (`*`) を使用する必要があります。

## 大文字と小文字の区別
<a name="package-group-case-sensitivity"></a>

パッケージグループ定義では大文字と小文字が区別されます。つまり、大文字と小文字だけが異なるパターンでも、個別のパッケージグループとして存在できます。例えば、ユーザーは、npm Public Registry に存在する、大文字と小文字のみが異なる *AsyncStorage*、*asyncStorage*、*asyncstorage* という 3 つの個別のパッケージに対して、パターン `/npm//AsyncStorage$`、`/npm//asyncStorage$`、および `/npm//asyncstorage$` を備える個別のパッケージグループを作成できます。

大文字と小文字は区別されますが、パッケージに大文字と小文字が異なるパターンのバリエーションがあっても、CodeArtifact はパッケージをパッケージグループに関連付けます。ユーザーが、上記のうち `/npm//AsyncStorage$` のパッケージグループのみを作成し、他の 2 つのグループを作成しない場合、*AsyncStorage* の大文字と小文字のすべてのバリエーション (*asyncStorage* と *asyncstorage* など) がパッケージグループに関連付けられます。ただし、次のセクション ([強い一致と弱い一致](#package-group-strong-and-weak-match)) で説明するように、これらのバリエーションはパターンと完全に一致する *AsyncStorage* とは異なる方法で処理されます。

## 強い一致と弱い一致
<a name="package-group-strong-and-weak-match"></a>

前のセクション ([大文字と小文字の区別](#package-group-case-sensitivity)) では、パッケージグループでは大文字と小文字が区別されると述べたうえで、大文字と小文字は同じように扱われると説明しました。これは、CodeArtifact のパッケージグループ定義には、強い一致 (完全一致) と弱い一致 (バリエーション一致) の概念があるためです。強い一致は、パッケージがパターンと完全に一致し、バリエーションがない場合です。弱い一致は、パッケージがパターンのバリエーション (大文字と小文字が異なるなど) と一致する場合です。弱い一致の動作により、パッケージグループのパターンのバリエーションにあたるパッケージが、より一般的なパッケージグループに割り当てられてしまうことを防ぎます。パッケージが、最も特異的に一致するグループのパターンのバリエーション (弱い一致) である場合、パッケージはグループに関連付けられます。ただし、グループのオリジンコントロール設定が適用されることはなく、パッケージはブロックされるため、パッケージの新しいバージョンがアップストリームからプルされたり公開されたりすることはありません。この動作により、ほぼ同名のパッケージの依存関係の混乱に起因するサプライチェーン攻撃のリスクが軽減されます。

弱い一致の動作を示す例として、パッケージグループ `/npm/*` が取り込みを許可し、公開をブロックするとします。より具体的なパッケージグループ `/npm//anycompany-spicy-client$` は、取り込みをブロックし、公開を許可するように設定されています。*anycompany-spicy-client* という名前のパッケージは、そのパッケージグループの強い一致であり、パッケージバージョンの公開を許可し、パッケージバージョンの取り込みをブロックします。公開が許可される、大文字と小文字を区別するパッケージ名は、パッケージ定義パターンとの強い一致である *anycompany-spicy-client* のみです。*AnyCompany-spicy-client* などの大文字と小文字が異なるバリエーションは、弱い一致であるため公開がブロックされます。さらに重要なのは、パッケージグループはパターンで使用される小文字の名前だけでなく、大文字と小文字のすべてのバリエーションの取り込みをブロックします。これにより、依存関係撹乱攻撃のリスクが低減されます。

## その他のバリエーション
<a name="package-group-additional-variations"></a>

大文字と小文字の違いに加えて、弱い一致では、ダッシュ (`-`)、ドット (`.`)、アンダースコア (`_`)、および紛らわしい文字 (別のアルファベットに見た目が似ている文字など) の並びの違いも無視されます。弱い一致に使用される正規化の際に、CodeArtifact は大文字小文字の畳み込み (小文字への変換と同様) を実行し、ダッシュ、ドット、アンダースコアの文字の並びを 1 つのドットに置き換え、混同されやすい文字を正規化します。

弱い一致では、ダッシュ、ドット、アンダースコアは同等に扱われますが、完全に無視されることはありません。つまり、*foo-bar*、*foo.bar*、*foo..bar*、および *foo\_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* と混同される可能性があります。

**注記**  
なお、複数のバリエーションがパッケージグループに関連付けられるたびに、管理者は特定のバリエーションの新しいパッケージグループを作成して、そのバリエーションに異なる動作を設定する場合があります。