[要約] RFC 8493は、BagItファイルパッケージング形式（V1.0）に関する要約と目的を提供します。このRFCは、デジタルアーカイブやデータの長期保存などの用途で使用されるファイルパッケージング形式の標準化を目指しています。
Independent Submission J. Kunze
Request for Comments: 8493 California Digital Library
Category: Informational J. Littman
ISSN: 2070-1721 Stanford Libraries
E. Madden
Library of Congress
J. Scancella
C. Adams Library of Congress October 2018
C.アダムス議会図書館2018年10月
The BagIt File Packaging Format (V1.0)
BagItファイルパッケージフォーマット（V1.0）
Abstract
概要
This document describes BagIt, a set of hierarchical file layout conventions for storage and transfer of arbitrary digital content. A "bag" has just enough structure to enclose descriptive metadata "tags" and a file "payload" but does not require knowledge of the payload's internal semantics. This BagIt format is suitable for reliable storage and transfer.
このドキュメントでは、任意のデジタルコンテンツを保存および転送するための階層的なファイルレイアウト規則のセットであるBagItについて説明します。 「バッグ」は、説明的なメタデータ「タグ」とファイル「ペイロード」を囲むのに十分な構造を持っていますが、ペイロードの内部セマンティクスの知識は必要ありません。このBagItフォーマットは、信頼性の高い保存と転送に適しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8493.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8493で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Required Elements . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Bag Declaration: bagit.txt . . . . . . . . . . . . . 6
2.1.2. Payload Directory: data/ . . . . . . . . . . . . . . 7
2.1.3. Payload Manifest: manifest-algorithm.txt . . . . . . 7
2.2. Optional Elements . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Tag Manifest: tagmanifest-algorithm.txt . . . . . . . 8
2.2.2. Bag Metadata: bag-info.txt . . . . . . . . . . . . . 9
2.2.3. Fetch File: fetch.txt . . . . . . . . . . . . . . . . 12
2.2.4. Other Tag Files . . . . . . . . . . . . . . . . . . . 12
2.3. Text Tag File Format . . . . . . . . . . . . . . . . . . 13
2.4. Bag Checksum Algorithms . . . . . . . . . . . . . . . . . 13
3. Complete and Valid Bags . . . . . . . . . . . . . . . . . . . 14
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Example of a Basic Bag . . . . . . . . . . . . . . . . . 15
4.2. Example Bag Using fetch.txt . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.1. Special Directory Characters . . . . . . . . . . . . . . 16
5.2. Control of URLs in fetch.txt . . . . . . . . . . . . . . 17
5.3. File Sizes in fetch.txt . . . . . . . . . . . . . . . . . 17
5.4. Attacks on Payload File Content . . . . . . . . . . . . . 17
6. Practical Considerations (Non-normative) . . . . . . . . . . 17
6.1. Interoperability . . . . . . . . . . . . . . . . . . . . 17
6.1.1. Filename Normalization . . . . . . . . . . . . . . . 18
6.1.2. Windows and Unix File Naming . . . . . . . . . . . . 18
6.1.3. Legacy Checksum Tools . . . . . . . . . . . . . . . . 18
7. Augmented Backus-Naur Form (Non-normative) . . . . . . . . . 21
7.1. Bag Declaration: bagit.txt . . . . . . . . . . . . . . . 21
7.2. Payload Manifest: manifest-algorithm.txt . . . . . . . . 21
7.3. Bag Metadata: bag-info.txt . . . . . . . . . . . . . . . 22
7.4. Fetch File: fetch.txt . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
BagIt is a set of hierarchical file layout conventions designed to support storage and transfer of arbitrary digital content. A "bag" consists of a directory containing the payload files and other accompanying metadata files known as "tag" files. The "tags" are metadata files intended to facilitate and document the storage and transfer of the bag. Processing a bag does not require any understanding of the payload file contents, and the payload files can be accessed without processing the BagIt metadata.
BagItは、任意のデジタルコンテンツの保存と転送をサポートするために設計された階層型ファイルレイアウト規則のセットです。 「バッグ」は、「タグ」ファイルと呼ばれるペイロードファイルとその他の付随するメタデータファイルを含むディレクトリで構成されます。 「タグ」は、バッグの保管と移動を容易にし、文書化することを目的としたメタデータファイルです。バッグを処理するためにペイロードファイルの内容を理解する必要はありません。また、BagItメタデータを処理せずにペイロードファイルにアクセスできます。
The name, BagIt, is inspired by the "enclose and deposit" method [ENCDEP], sometimes referred to as "bag it and tag it". BagIt differs from serialized archival formats such as MIME, TAR, or ZIP in two general areas:
BagItという名前は、「囲んで保管する」方法[ENCDEP]から着想を得ており、「バッグしてタグを付ける」とも呼ばれます。 BagItは、2つの一般的な領域でMIME、TAR、ZIPなどのシリアル化されたアーカイブ形式とは異なります。
1. Strong integrity assurances. The format supports cryptographic-quality hash algorithms (see Section 2.4) and allows for in-place upgrades to add additional manifests using stronger algorithms without breaking backwards compatibility. This provides high levels of confidence against data corruption, but it is not designed to be secure against active attacks.
1. 強力な整合性の保証。この形式は、暗号品質のハッシュアルゴリズム（セクション2.4を参照）をサポートし、下位互換性を損なうことなく、強力なアルゴリズムを使用して追加のマニフェストを追加するインプレースアップグレードを可能にします。これにより、データ破損に対する高いレベルの信頼性が提供されますが、アクティブな攻撃から保護するようには設計されていません。
2. Direct file access. Because BagIt specifies an actual filesystem hierarchy rather than a serialized representation of one, files can be accessed using standard operating system utilities, implementations do not need to process a potentially large archival file to extract a subset of data, and the format imposes no size limits for either individual files or a bag.
2. ファイルへの直接アクセス。 BagItは、シリアル化された表現ではなく実際のファイルシステム階層を指定するため、標準のオペレーティングシステムユーティリティを使用してファイルにアクセスでき、実装は潜在的に大きなアーカイブファイルを処理してデータのサブセットを抽出する必要がなく、フォーマットによりサイズ制限がありません。個々のファイルまたはバッグのいずれか。
BagIt is widely used for preserving digital assets originating from different domains. Organizations involved in digital preservation with BagIt include the Library of Congress, Dryad Data Repository, NSF DataONE, and the Rockefeller Archive Center. Software implementations are available for many languages, including Python, Ruby, Java, Perl, and PHP. It is also used in the libraries of many universities, such as Cornell, Purdue, Stanford, Ghent University, New York University, and the University of California.
BagItは、さまざまなドメインに由来するデジタル資産を保存するために広く使用されています。 BagItのデジタル保存に関わる組織には、米国議会図書館、ドライアドデータリポジトリ、NSF DataONE、ロックフェラーアーカイブセンターなどがあります。ソフトウェアの実装は、Python、Ruby、Java、Perl、PHPなど、多くの言語で利用できます。コーネル大学、パーデュー大学、スタンフォード大学、ゲント大学、ニューヨーク大学、カリフォルニア大学などの多くの大学の図書館でも使用されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Implementers are strongly encouraged to review the interoperability considerations described in Section 6.1.
実装者は、セクション6.1で説明されている相互運用性の考慮事項を確認することを強くお勧めします。
The following terms have precise definitions as used in this document:
次の用語には、このドキュメントで使用されている正確な定義があります。
bag: A set of opaque files contained within the structure defined by this document.
バッグ：このドキュメントで定義されている構造内に含まれる一連の不透明ファイル。
bag declaration: The file required to be in all bags conforming to this document. Contains values necessary to process the rest of a bag. See Section 2.1.1.
バッグの宣言：ファイルは、このドキュメントに準拠するすべてのバッグに入れる必要があります。バッグの残りの部分を処理するために必要な値が含まれています。セクション2.1.1を参照してください。
bag checksum algorithm: The name of a cryptographic checksum algorithm that has been normalized for use in a manifest or tag manifest file name (e.g., "sha512") as described in Section 2.4.
バッグチェックサムアルゴリズム：セクション2.4で説明されているように、マニフェストまたはタグマニフェストファイル名（「sha512」など）で使用するために正規化された暗号チェックサムアルゴリズムの名前。
manifest: A tag file that maps filepaths to checksums. A manifest can be a payload manifest (see Section 2.1.3) or a tag manifest (see Section 2.2.1).
manifest：ファイルパスをチェックサムにマップするタグファイル。マニフェストは、ペイロードマニフェスト（セクション2.1.3を参照）またはタグマニフェスト（セクション2.2.1を参照）にすることができます。
payload: The data encapsulated by the bag as a set of named files, which may be organized in subdirectories. The contents of the payload files are opaque to this document, and, with respect to BagIt processing, are always considered as sequences of uninterpreted octets. See Section 2.1.2.
ペイロード：名前付きファイルのセットとしてバッグによってカプセル化されたデータ。サブディレクトリに編成される場合があります。ペイロードファイルの内容はこのドキュメントでは不透明であり、BagIt処理に関しては常に、解釈されないオクテットのシーケンスと見なされます。セクション2.1.2を参照してください。
tag directory: A directory that contains one or more tag files.
タグディレクトリ：1つ以上のタグファイルを含むディレクトリ。
tag file: A file that contains metadata about the bag or its payload. This document defines the standard BagIt tag files: the bag declaration in "bagit.txt" (see Section 2.1.1), payload manifests (see Section 2.1.3), tag manifests (see Section 2.2.1), bag metadata in "bag-info.txt" (see Section 2.2.2), and remote payload in "fetch.txt" (see Section 2.2.3). This document also allows other arbitrary tag files as described in Section 2.2.4.
タグファイル：バッグまたはそのペイロードに関するメタデータを含むファイル。このドキュメントでは、標準のBagItタグファイルを定義します。「bagit.txt」のバッグ宣言（セクション2.1.1を参照）、ペイロードマニフェスト（セクション2.1.3を参照）、タグマニフェスト（セクション2.2.1を参照）、「 bag-info.txt」（セクション2.2.2を参照）、および「fetch.txt」（セクション2.2.3を参照）のリモートペイロードこのドキュメントでは、セクション2.2.4で説明されているように、他の任意のタグファイルも使用できます。
complete: A bag that contains every element required by this document, every payload file listed in a manifest, and any optional files that are listed in a tag manifest. See Section 3.
complete：このドキュメントに必要なすべての要素、マニフェストにリストされているすべてのペイロードファイル、およびタグマニフェストにリストされているオプションファイルを含むバッグ。セクション3を参照してください。
valid: A complete bag where every checksum in every manifest has been successfully verified against the corresponding file.
有効：すべてのマニフェストのすべてのチェックサムが対応するファイルに対して正常に検証された完全なバッグ。
A bag MUST consist of a base directory containing the following:
バッグは、以下を含むベースディレクトリで構成する必要があります。
1. a set of required and optional tag files (see Section 2.2);
1. 必須およびオプションのタグファイルのセット（セクション2.2を参照）。
2. a subdirectory named "data", called the payload directory (see Section 2.1.2); and
2. ペイロードディレクトリと呼ばれる「データ」というサブディレクトリ（セクション2.1.2を参照）。そして
3. a set of optional tag directories.
3. オプションのタグディレクトリのセット。
The tag files in the base directory consist of one or more files named "manifest-_algorithm_.txt" (see Sections 2.1.3 and 2.4), a file named "bagit.txt" (see Section 2.1.1), and zero or more additional tag files (see Section 2.2). The tag files and directories are in arbitrary file hierarchies and MAY have any name that is not reserved for a file or directory in this document.
ベースディレクトリ内のタグファイルは、「manifest-_algorithm_.txt」（セクション2.1.3および2.4を参照）、「bagit.txt」（セクション2.1.1を参照）、およびゼロまたは追加のタグファイル（セクション2.2を参照）。タグのファイルとディレクトリは任意のファイル階層にあり、このドキュメントのファイルまたはディレクトリ用に予約されていない名前を付けることができます。
The base directory can have any name, as illustrated by the figure below.
下の図に示すように、ベースディレクトリには任意の名前を付けることができます。
<base directory>/
|
+-- bagit.txt
|
+-- manifest-<algorithm>.txt
|
+-- [additional tag files]
|
+-- data/
| |
| +-- [payload files]
|
+-- [tag directories]/
|
+-- [tag files]
The "bagit.txt" tag file MUST consist of exactly two lines in this order:
「bagit.txt」タグファイルは、この順序で正確に2行で構成する必要があります。
BagIt-Version: M.N Tag-File-Character-Encoding: ENCODING
BagIt-Version：M.N Tag-File-Character-Encoding：ENCODING
_M.N_ identifies the BagIt major (M) and minor (N) version numbers. _ENCODING_ identifies the character set encoding used by the remaining tag files. _ENCODING_ SHOULD be "UTF-8", but for backwards compatibility it MAY be any other encoding registered in [cs-registry]. The bag declaration itself MUST be encoded in UTF-8 and MUST NOT contain a Byte Order Mark (BOM) [RFC3629].
_M.N_は、BagItのメジャー（M）およびマイナー（N）のバージョン番号を示します。 _ENCODING_は、残りのタグファイルで使用される文字セットエンコーディングを識別します。 _ENCODING_は「UTF-8」にする必要がありますが、下位互換性のために、[cs-registry]に登録されている他のエンコーディングにする必要があります。バッグ宣言自体はUTF-8でエンコードする必要があり、バイトオーダーマーク（BOM）[RFC3629]を含めることはできません。
The number for this version of BagIt is "1.0".
このバージョンのBagItの数は「1.0」です。
The base directory MUST contain a subdirectory named "data".
ベースディレクトリには、「data」という名前のサブディレクトリが含まれている必要があります。
The payload directory contains the arbitrary digital content within the bag. The files under the payload directory are called payload files, or the payload. Each payload file is treated as an opaque octet stream when verifying file correctness. Payload files MAY be organized in arbitrary subdirectory structures within the payload directory; however, for the purpose of this document, such subdirectory structures and filenames have no given meaning.
ペイロードディレクトリには、バッグ内の任意のデジタルコンテンツが含まれています。ペイロードディレクトリの下のファイルは、ペイロードファイルまたはペイロードと呼ばれます。各ペイロードファイルは、ファイルが正しいことを確認するときに、不透明なオクテットストリームとして扱われます。ペイロードファイルは、ペイロードディレクトリ内の任意のサブディレクトリ構造で編成される場合があります。ただし、このドキュメントでは、このようなサブディレクトリ構造とファイル名には意味がありません。
A payload manifest file provides a complete listing of each payload file name along with a corresponding checksum to permit data integrity checking. A bag can have more than one payload manifest, with each using a different checksum algorithm. Manifest entries MUST satisfy the following constraints:
ペイロードマニフェストファイルは、各ペイロードファイル名の完全なリストと、対応するチェックサムを提供して、データの整合性チェックを可能にします。バッグは複数のペイロードマニフェストを持つことができ、それぞれが異なるチェックサムアルゴリズムを使用します。マニフェストエントリは、次の制約を満たす必要があります。
o Every bag MUST contain at least one payload manifest file and MAY contain more than one.
o すべてのバッグには少なくとも1つのペイロードマニフェストファイルを含める必要があり、複数のバッグを含めることができます（MAY）。
o Every payload manifest MUST list every payload file name exactly once.
o すべてのペイロードマニフェストは、すべてのペイロードファイル名を1回だけリストする必要があります。
o A payload manifest file MUST have a name of the form "manifest-_algorithm_.txt", where _algorithm_ is a string specifying the checksum algorithm used by that manifest as described in Section 2.4.
o ペイロードマニフェストファイルには、「manifest-_algorithm_.txt」という形式の名前が必要です。ここで、_algorithm_は、2.4で説明されているように、そのマニフェストで使用されるチェックサムアルゴリズムを指定する文字列です。
Example payload manifest filenames:
ペイロードマニフェストファイル名の例：
manifest-sha256.txt manifest-sha512.txt Each line of a payload manifest file MUST be of the form
manifest-sha256.txt manifest-sha512.txtペイロードマニフェストファイルの各行は、次の形式でなければなりません。
checksum filepath
チェックサムファイルパス
where _filepath_ is the pathname of a file relative to the base directory, and _checksum_ is a hex-encoded checksum calculated by applying _algorithm_ over the file.
ここで、_filepath_は、ベースディレクトリを基準にしたファイルのパス名で、_checksum_は、ファイルに_algorithm_を適用して計算された16進エンコードされたチェックサムです。
o The hex-encoded checksum MAY use uppercase and/or lowercase letters.
o 16進数でエンコードされたチェックサムでは、大文字または小文字、あるいはその両方を使用できます。
o The slash character ('/') MUST be used as a path separator in _filepath_.
o スラッシュ文字（ '/'）は、_filepath_のパス区切り文字として使用する必要があります。
o One or more linear whitespace characters (spaces or tabs) MUST separate _checksum_ from _filepath_.
o 1つ以上の線形空白文字（スペースまたはタブ）は、_checksum_を_filepath_から分離する必要があります。
o There is no limitation on the length of a pathname.
o パス名の長さに制限はありません。
o The payload manifest MUST NOT reference files outside the payload directory.
o ペイロードマニフェストは、ペイロードディレクトリ外のファイルを参照してはなりません。
o If a _filepath_ includes a Line Feed (LF), a Carriage Return (CR), a Carriage-Return Line Feed (CRLF), or a percent sign (%), those characters (and only those) MUST be percent-encoded following [RFC3986].
o _filepath_にラインフィード（LF）、キャリッジリターン（CR）、キャリッジリターンラインフィード（CRLF）、またはパーセント記号（％）が含まれている場合、これらの文字（およびそれらのみ）は、[に続いてパーセントエンコードする必要があります。 RFC3986]。
A manifest MUST NOT reference directories. Bag creators who wish to create an otherwise empty directory have typically done so by creating an empty placeholder file with a name such as ".keep".
マニフェストはディレクトリを参照してはなりません。通常は空のディレクトリを作成したいバッグの作成者は、通常、「。keep」などの名前の空のプレースホルダーファイルを作成します。
A tag manifest is a tag file that lists other tag files and checksums for those tag files generated using a particular bag checksum algorithm.
タグマニフェストは、他のタグファイルと、特定のバッグチェックサムアルゴリズムを使用して生成されたタグファイルのチェックサムをリストするタグファイルです。
A bag MAY contain one or more tag manifests, in which case each tag manifest SHOULD list the same set of tag files.
バッグには1つ以上のタグマニフェストを含めることができます（MAY）。この場合、各タグマニフェストは同じタグファイルのセットをリストする必要があります（SHOULD）。
Each tag manifest MUST list every payload manifest. Each tag manifest MUST NOT list any tag manifests but SHOULD list the remaining tag files present in the bag.
各タグマニフェストは、すべてのペイロードマニフェストをリストする必要があります。各タグマニフェストはタグマニフェストをリストしてはなりませんが、バッグに存在する残りのタグファイルをリストする必要があります。
A tag manifest file MUST have a name of the form "tagmanifest-_algorithm_.txt", where _algorithm_ is a string following the format described in Section 2.4 that specifies the bag checksum algorithm used in that manifest.
タグマニフェストファイルには、「tagmanifest-_algorithm_.txt」という形式の名前を指定する必要があります。ここで、_algorithm_は、2.4で説明されているフォーマットに従って、そのマニフェストで使用されるバッグチェックサムアルゴリズムを指定する文字列です。
Tag manifests SHOULD use the same algorithms as the payload manifests that are present in the bag.
タグマニフェストは、バッグに存在するペイロードマニフェストと同じアルゴリズムを使用する必要があります（SHOULD）。
Example tag manifest filenames:
タグマニフェストファイル名の例：
tagmanifest-sha256.txt tagmanifest-sha512.txt
tagmanifest-sha256.txt tagmanifest-sha512.txt
A tag manifest file has the same form as the payload manifest file described in Section 2.1.3 but MUST NOT list any payload files. As a result, no _filepath_ listed in a tag manifest begins "data/".
タグマニフェストファイルは、セクション2.1.3で説明されているペイロードマニフェストファイルと同じ形式ですが、ペイロードファイルをリストしてはなりません。その結果、タグマニフェストにリストされている_filepath_は、「data /」で始まりません。
The "bag-info.txt" file is a tag file that contains metadata elements describing the bag and the payload. The metadata elements contained in the "bag-info.txt" file are intended primarily for human use. All metadata elements are OPTIONAL and MAY be repeated. Because "bag-info.txt" is intended for human reading and editing, ordering MAY be significant and the ordering of metadata elements MUST be preserved.
「bag-info.txt」ファイルは、バッグとペイロードを説明するメタデータ要素を含むタグファイルです。 「bag-info.txt」ファイルに含まれるメタデータ要素は、主に人間による使用を目的としています。すべてのメタデータ要素はオプションであり、繰り返すことができます。 "bag-info.txt"は人間による読み取りと編集を目的としているため、順序付けは重要である場合があり、メタデータ要素の順序を維持する必要があります。
A metadata element MUST consist of a label, a colon ":", a single linear whitespace character (space or tab), and a value that is terminated with an LF, a CR, or a CRLF.
メタデータ要素は、ラベル、コロン「：」、1つの線形空白文字（スペースまたはタブ）、およびLF、CR、またはCRLFで終了する値で構成する必要があります。
The label MUST NOT contain a colon (:), LF, or CR. The label MAY contain linear whitespace characters but MUST NOT start or end with whitespace.
ラベルには、コロン（:)、LF、またはCRを含めることはできません。ラベルには線形の空白文字を含めることができますが、空白で開始または終了してはなりません。
It is RECOMMENDED that lines not exceed 79 characters in length. Long values MAY be continued onto the next line by inserting a LF, CR, or CRLF, and then indenting the next line with one or more linear white space characters (spaces or tabs). Except for linebreaks, such padding does not form part of the value.
行の長さが79文字を超えないようにすることをお勧めします。 LF、CR、またはCRLFを挿入し、次の行を1つ以上の線形空白文字（スペースまたはタブ）でインデントすることにより、長い値を次の行に続けることができます（MAY）。改行を除いて、そのようなパディングは値の一部を形成しません。
Implementations wishing to support previous BagIt versions MUST accept multiple linear whitespace characters before and after the colon when the bag version is earlier than 1.0; such whitespace does not form part of the label or value.
以前のBagItバージョンをサポートする実装は、バッグバージョンが1.0より前の場合、コロンの前後に複数の線形空白文字を受け入れる必要があります。このような空白は、ラベルまたは値の一部を形成しません。
The following are reserved metadata elements. The use of these reserved metadata elements is OPTIONAL but encouraged. Reserved metadata element names are case insensitive. Except where indicated otherwise, these metadata element names MAY be repeated to capture multiple values.
以下は、予約済みのメタデータ要素です。これらの予約済みメタデータ要素の使用はオプションですが、お勧めします。予約済みのメタデータ要素名では、大文字と小文字が区別されません。特に明記されていない限り、これらのメタデータ要素名は、複数の値を取得するために繰り返される場合があります。
Source-Organization: Organization transferring the content.
ソース組織：コンテンツを転送する組織。
Organization-Address: Mailing address of the source organization.
Organization-Address：ソース組織の住所。
Contact-Name: Person at the source organization who is responsible for the content transfer.
連絡先名：コンテンツの転送を担当するソース組織の担当者。
Contact-Phone: International format telephone number of person or position responsible.
連絡先電話：責任者または職位の国際形式の電話番号。
Contact-Email: Fully qualified email address of person or position responsible.
連絡先メール：担当者または職位の完全修飾メールアドレス。
External-Description: A brief explanation of the contents and provenance.
外部記述：内容と来歴の簡単な説明。
Bagging-Date: Date (YYYY-MM-DD) that the content was prepared for transfer. This metadata element SHOULD NOT be repeated.
Bagging-Date：コンテンツが転送用に準備された日付（YYYY-MM-DD）。このメタデータ要素は繰り返されるべきではありません。
External-Identifier: A sender-supplied identifier for the bag.
外部識別子：バッグの送信者指定の識別子。
Bag-Size: The size or approximate size of the bag being transferred, followed by an abbreviation such as MB (megabytes), GB (gigabytes), or TB (terabytes): for example, 42600 MB, 42.6 GB, or .043 TB. Compared to Payload-Oxum (described next), Bag-Size is intended for human consumption. This metadata element SHOULD NOT be repeated.
Bag-Size：転送されるバッグのサイズまたはおおよそのサイズ。MB（メガバイト）、GB（ギガバイト）、TB（テラバイト）などの省略形が続きます。たとえば、42600 MB、42.6 GB、.043 TBなどです。 。 Payload-Oxum（次に説明）と比較して、Bag-Sizeは人間による消費を目的としています。このメタデータ要素は繰り返されるべきではありません。
Payload-Oxum: The "octetstream sum" of the payload, which is intended for the purpose of quickly detecting incomplete bags before performing checksum validation. This is strictly an optimization, and implementations MUST perform the standard checksum validation process before proclaiming a bag to be valid. This element MUST NOT be present more than once and, if present, MUST be in the form "_OctetCount_._StreamCount_", where _OctetCount_ is the total number of octets (8-bit bytes) across all payload file content and _StreamCount_ is the total number of payload files. This metadata element MUST NOT be repeated.
Payload-Oxum：ペイロードの「octetstream sum」。チェックサム検証を実行する前に不完全なバッグをすばやく検出することを目的としています。これは厳密に最適化であり、実装は、バッグが有効であることを宣言する前に、標準のチェックサム検証プロセスを実行する必要があります。この要素は複数存在してはならず、存在する場合は、「_ OctetCount _._ StreamCount_」の形式である必要があります。ここで、_OctetCount_はすべてのペイロードファイルコンテンツ全体のオクテット（8ビットバイト）の総数であり、_StreamCount_は総数ですペイロードファイルの。このメタデータ要素を繰り返すことはできません。
Bag-Group-Identifier: A sender-supplied identifier for the set, if any, of bags to which it logically belongs. This identifier SHOULD be unique across the sender's content, and if it is recognizable as belonging to a globally unique scheme, the receiver SHOULD make an effort to honor the reference to it. This metadata element SHOULD NOT be repeated.
Bag-Group-Identifier：セットが論理的に属しているバッグのセットの送信者提供の識別子（ある場合）。この識別子は送信者のコンテンツ全体で一意である必要があり、グローバルに一意のスキームに属していると認識できる場合、受信者はそれへの参照を尊重するよう努力する必要があります。このメタデータ要素は繰り返されるべきではありません。
Bag-Count: Two numbers separated by "of", in particular, "N of T", where T is the total number of bags in a group of bags and N is the ordinal number within the group. If T is not known, specify it as "?" (question mark): for example, 1 of 2, 4 of 4, 3 of ?, 89 of 145. This metadata element SHOULD NOT be repeated. If this metadata element is present, it is RECOMMENDED to also include the Bag-Group-Identifier element.
Bag-Count：「of」で区切られた2つの数値、特に「N of T」。Tはバッグのグループ内のバッグの総数、Nはグループ内の序数。 Tが不明な場合は、「？」と指定します（疑問符）：たとえば、1の2、4の4、3の？、89の145。このメタデータ要素は繰り返さないでください。このメタデータ要素が存在する場合は、Bag-Group-Identifier要素も含めることをお勧めします。
Internal-Sender-Identifier: An alternate sender-specific identifier for the content and/or bag.
内部送信者識別子：コンテンツやバッグの送信者固有の代替識別子。
Internal-Sender-Description: A sender-local explanation of the contents and provenance.
内部送信者説明：内容と来歴の送信者ローカル説明。
In addition to these metadata elements, other arbitrary metadata elements MAY also be present.
これらのメタデータ要素に加えて、他の任意のメタデータ要素も存在してもよい（MAY）。
An example of "bag-info.txt" file is as follows:
「bag-info.txt」ファイルの例は次のとおりです。
Source-Organization: FOO University Organization-Address: 1 Main St., Cupertino, California, 11111 Contact-Name: Jane Doe Contact-Phone: +1 111-111-1111 Contact-Email: example@example.com External-Description: Uncompressed greyscale TIFF images from the FOO papers colle... Bagging-Date: 2008-01-15 External-Identifier: university_foo_001 Payload-Oxum: 279164409832.1198 Bag-Group-Identifier: university_foo Bag-Count: 1 of 15 Internal-Sender-Identifier: /storage/images/foo Internal-Sender-Description: Uncompressed greyscale TIFFs created from microfilm and are...
出典：組織：FOO大学組織：住所：1 Main St.、クパチーノ、カリフォルニア、11111連絡先名：Jane Doe連絡先電話：+1 111-111-1111連絡先メール：example@example.com外部説明： FOOペーパーコレクションからの非圧縮グレースケールTIFF画像... Bagging-Date：2008-01-15 External-Identifier：University_foo_001 Payload-Oxum：279164409832.1198 Bag-Group-Identifier：University_foo Bag-Count：15 of 1 Internal-Sender-Identifier ：/ storage / images / foo Internal-Sender-Description：マイクロフィルムから作成された圧縮されていないグレースケールTIFFは...
For reasons of efficiency, a bag MAY be sent with a list of files to be fetched and added to the payload before it can meaningfully be checked for completeness. The fetch file allows a bag to be transmitted with "holes" in it, which can be practical for several reasons. For example, it obviates the need for the sender to stage a large serialized copy of the content while the bag is transferred to the receiver. Also, this method allows a sender to construct a bag from components that are either a subset of logically related components (e.g., the localized logical object could be much larger than what is intended for export) or assembled from logically distributed sources (e.g., the object components for export are not stored locally under one filesystem tree). An OPTIONAL tag file, called the fetch file, contains such a list.
効率上の理由から、バッグは、完全性を確認する前に、フェッチしてペイロードに追加するファイルのリストとともに送信できます。フェッチファイルを使用すると、バッグに「穴」を開けて送信できます。これは、いくつかの理由で実用的です。たとえば、バッグが受信者に転送される間、送信者がコンテンツの大量のシリアル化されたコピーをステージングする必要がなくなります。また、この方法により、送信者は論理的に関連するコンポーネントのサブセット（たとえば、ローカライズされた論理オブジェクトはエクスポート対象のものよりもはるかに大きくなる可能性があります）または論理的に分散されたソース（たとえば、エクスポート用のオブジェクトコンポーネントは、1つのファイルシステムツリーの下にローカルに保存されません）。フェッチファイルと呼ばれるオプションのタグファイルには、このようなリストが含まれています。
The fetch file MUST be named "fetch.txt". Every file listed in the fetch file MUST be listed in every payload manifest. A fetch file MUST NOT list any tag files.
フェッチファイルの名前は「fetch.txt」にする必要があります。フェッチファイルにリストされているすべてのファイルは、すべてのペイロードマニフェストにリストされている必要があります。フェッチファイルは、タグファイルをリストしてはなりません。
Each line of a fetch file MUST be of the form
フェッチファイルの各行は、次の形式でなければなりません。
url length filepath
URLの長さのファイルパス
where _url_ identifies the file to be fetched and MUST be an absolute URI as defined in [RFC3986], _length_ is the number of octets in the file (or "-", to leave it unspecified), and _filepath_ identifies the corresponding payload file, relative to the base directory.
ここで、_url_は、フェッチするファイルを識別し、[RFC3986]で定義されている絶対URIでなければなりません。_length_は、ファイル内のオクテットの数（または、指定しない場合は "-"）であり、_filepath_は、対応するペイロードファイルを識別します。ベースディレクトリを基準にしています。
The slash character ('/') MUST be used as a path separator in _filepath_. One or more linear whitespace characters (spaces or tabs) MUST separate these three values, and any such characters in the _url_ MUST be percent-encoded [RFC3986]. If _filename_ includes an LF, a CR, a CRLF, or a percent sign (%), those characters (and only those) MUST be percent-encoded as described in [RFC3986]. There is no limitation on the length of any of the fields in the fetch file.
スラッシュ文字（ '/'）は、_filepath_のパス区切り文字として使用する必要があります。 1つ以上の線形空白文字（スペースまたはタブ）はこれらの3つの値を区切る必要があり、_url_内のそのような文字はパーセントでエンコードする必要があります[RFC3986]。 _filename_にLF、CR、CRLF、またはパーセント記号（％）が含まれている場合、それらの文字（およびそれらのみ）は、[RFC3986]で説明されているようにパーセントでエンコードする必要があります。フェッチファイルのフィールドの長さに制限はありません。
A bag MAY contain other tag files that are not defined by this document. Implementations MUST perform standard checksum validation on any tag file that is listed in a tag manifest but MUST otherwise ignore their contents.
バッグには、このドキュメントで定義されていない他のタグファイルが含まれる場合があります。実装では、タグマニフェストにリストされているタグファイルに対して標準のチェックサム検証を実行する必要がありますが、それ以外の場合はその内容を無視する必要があります。
All tag files specifically described in this document MUST adhere to the text tag file format described below. Other tag files MAY adhere to the text tag file format described below.
このドキュメントで具体的に説明されているすべてのタグファイルは、以下で説明されているテキストタグファイル形式に準拠している必要があります。他のタグファイルは、以下で説明するテキストタグファイル形式に準拠する場合があります。
Text tag files are line oriented, and each line MUST be terminated by an LF, a CR, or a CRLF. It is RECOMMENDED that the last line in a tag file also end with LF, CR, or CRLF. Text tag file names MUST end in the extension ".txt".
テキストタグファイルは行指向であり、各行はLF、CR、またはCRLFで終了する必要があります。タグファイルの最後の行もLF、CR、またはCRLFで終了することをお勧めします。テキストタグファイル名は、拡張子「.txt」で終了する必要があります。
In all text tag files except for the bag declaration file, text MUST use the character encoding specified in the "bagit.txt" bag declaration file. Text tag files except for the bag declaration file MAY include a Byte Order Mark (BOM) only if the specified encoding requires it for proper decoding. In accordance with [RFC3629], when "bagit.txt" specifies UTF-8, the tag files MUST NOT begin with a BOM. See Section 2.1.1.
バッグ宣言ファイルを除くすべてのテキストタグファイルでは、テキストは「bagit.txt」バッグ宣言ファイルで指定された文字エンコーディングを使用する必要があります。バッグ宣言ファイルを除くテキストタグファイルは、指定されたエンコーディングが適切なデコードにそれを必要とする場合のみ、バイトオーダーマーク（BOM）を含めることができます。 [RFC3629]に従い、「bagit.txt」がUTF-8を指定する場合、タグファイルはBOMで開始してはなりません。セクション2.1.1を参照してください。
The use of UTF-8 for text tag files is strongly RECOMMENDED. A future version of BagIt may disallow encodings other than UTF-8.
テキストタグファイルにUTF-8を使用することを強くお勧めします。 BagItの将来のバージョンでは、UTF-8以外のエンコーディングを許可しない可能性があります。
The payload manifest and tag manifest permit validating the integrity of the payload and tag files in a bag produced by the checksum algorithms. Checksum values MUST be encoded so as to conform to the manifest format specified in Section 2.1.3. However, the internal details of a checksum are outside the scope of this document.
ペイロードマニフェストとタグマニフェストにより、チェックサムアルゴリズムによって生成されたバッグ内のペイロードとタグファイルの整合性を検証できます。チェックサム値は、セクション2.1.3で指定されたマニフェスト形式に準拠するようにエンコードする必要があります。ただし、チェックサムの内部の詳細は、このドキュメントの範囲外です。
To avoid future ambiguity, the checksum algorithm SHOULD be registered in IANA's "Named Information Hash Algorithm Registry" [ni-registry] according to [RFC6920] but MAY, for backwards compatibility, also be MD5 [RFC1321] or SHA-1 [RFC3174].
将来のあいまいさを避けるために、チェックサムアルゴリズムは、[RFC6920]に従ってIANAの「名前付き情報ハッシュアルゴリズムレジストリ」[ni-registry]に登録する必要がありますが、下位互換性のために、MD5 [RFC1321]またはSHA-1 [RFC3174]でもかまいません。 。
The name of the checksum algorithm MUST be normalized for use in the manifest's filename by lowercasing the common name of the algorithm and removing all non-alphanumeric characters. Following is a partial list that maps common algorithm names to normalized names:
チェックサムアルゴリズムの名前は、アルゴリズムの一般名を小文字にしてすべての非英数字を削除することにより、マニフェストのファイル名で使用するために正規化する必要があります。以下は、一般的なアルゴリズム名を正規化された名前にマッピングするリストの一部です。
o MD5: md5
o 煙：煙
o SHA-1: sha1
o しゃー１： しゃ１
o sha-256: sha256
o しゃー２５６： しゃ２５６
o sha-512: sha512 Starting with BagIt 1.0, bag creation and validation tools MUST support the SHA-256 and SHA-512 algorithms [RFC6234] and SHOULD enable SHA-512 by default when creating new bags. For backwards compatibility, implementers SHOULD support MD5 [RFC1321] and SHA-1 [RFC3174]. Implementers are encouraged to simplify the process of adding additional manifests using new algorithms to streamline the process of in-place upgrades.
o sha-512：sha512 BagIt 1.0以降、バッグ作成および検証ツールはSHA-256およびSHA-512アルゴリズム[RFC6234]をサポートする必要があり、新しいバッグを作成するときにデフォルトでSHA-512を有効にする必要があります。下位互換性のために、実装者はMD5 [RFC1321]およびSHA-1 [RFC3174]をサポートする必要があります（SHOULD）。実装者は、新しいアルゴリズムを使用して追加のマニフェストを追加するプロセスを簡略化して、インプレースアップグレードのプロセスを合理化することをお勧めします。
A _complete_ bag MUST meet the following requirements:
_complete_バッグは次の要件を満たす必要があります。
1. Every required element MUST be present (see Section 2.1).
1. すべての必要な要素が存在しなければなりません（セクション2.1を参照）。
2. Every file listed in every tag manifest MUST be present.
2. すべてのタグマニフェストにリストされているすべてのファイルが存在している必要があります。
3. Every file listed in every payload manifest MUST be present.
3. すべてのペイロードマニフェストにリストされているすべてのファイルが存在する必要があります。
4. For BagIt 1.0, every payload file MUST be listed in every payload manifest. Note that older versions of BagIt allowed payload files to be listed in just one of the manifests.
4. BagIt 1.0では、すべてのペイロードファイルをすべてのペイロードマニフェストにリストする必要があります。 BagItの古いバージョンでは、ペイロードファイルをマニフェストの1つだけにリストすることができました。
5. Every element present MUST conform to BagIt 1.0.
5. 存在するすべての要素は、BagIt 1.0に準拠する必要があります。
A _valid_ bag MUST meet the following requirements:
_valid_バッグは次の要件を満たす必要があります。
1. The bag MUST be _complete_.
1. バッグは_complete_である必要があります。
2. Every checksum in every payload manifest and tag manifest has been successfully verified against the contents of the corresponding file.
2. すべてのペイロードマニフェストとタグマニフェストのすべてのチェックサムは、対応するファイルの内容に対して正常に検証されました。
This is the layout of a basic bag containing an image and a companion Optical Character Recognition (OCR) file. Lines of file content are shown with added parentheses to indicate each complete line. For brevity, this example uses MD5 rather than the recommended SHA-512.
これは、画像と関連する光学式文字認識（OCR）ファイルを含む基本的なバッグのレイアウトです。ファイルの内容の行は、括弧が追加されて示され、完全な各行を示します。簡潔にするために、この例では、推奨されるSHA-512ではなくMD5を使用しています。
myfirstbag/
|
| manifest-md5.txt
| (49afbd86a1ca9f34b677a3f09655eae9 data/27613-h/images/q172.png)
| (408ad21d50cef31da4df6d9ed81b01a7 data/27613-h/images/q172.txt)
|
| bagit.txt
| (BagIt-version: 1.0 )
| (Tag-File-Character-Encoding: UTF-8 )
|
\--- data/
|
| 27613-h/images/q172.png
| (... image bytes ... )
|
| 27613-h/images/q172.txt
| (... OCR text ... )
....
This is the layout of a bag that expects the receiver to download the files listed in the payload manifests prior to validation. Lines of file content are shown with added parentheses to indicate each complete line. For brevity, this example uses MD5 rather than the recommended SHA-512.
これは、検証前にペイロードマニフェストにリストされているファイルを受信者がダウンロードすることを期待するバッグのレイアウトです。ファイルの内容の行は、括弧が追加されて示され、完全な各行を示します。簡潔にするために、この例では、推奨されるSHA-512ではなくMD5を使用しています。
highsmith-tahoe/
|
| manifest-md5.txt
| (102b0e6effe208ef9b29864946de9e22 data/23364a.tif )
|
| fetch.txt
| (https://cdn.loc.gov/master/pnp/highsm/23300/23364a.tif
| 216951362 data/23364a.tif )
|
| bagit.txt
| (BagIt-version: 1.0 )
| (Tag-File-Character-Encoding: UTF-8 )
|
| bag-info.txt
| (Internal-Sender-Description: Download link found at )
| ( https://www.loc.gov/resource/highsm.23364/ )
The paths specified in the payload manifests, tag manifests, and fetch files do not prohibit special directory characters that have special meaning on some operating systems. Implementers MUST ensure that files outside the bag directory structure are not accessed when reading or writing files based on paths specified in a bag.
ペイロードマニフェスト、タグマニフェスト、およびフェッチファイルで指定されたパスは、一部のオペレーティングシステムで特別な意味を持つ特別なディレクトリ文字を禁止していません。実装者は、バッグで指定されたパスに基づいてファイルを読み書きするときに、バッグディレクトリ構造の外部のファイルにアクセスしないようにする必要があります。
All implementations SHOULD have a test suite to guard against special directory characters.
すべての実装には、特別なディレクトリ文字から保護するためのテストスイートが必要です（SHOULD）。
For example, a maliciously crafted "tagmanifest-sha512.txt" file might contain entries that begin with a path character such as "/", "..", or a "~username" home directory reference in an attempt to cause a naive implementation to leak or overwrite targeted files on a POSIX operating system.
たとえば、悪意を持って作成された「tagmanifest-sha512.txt」ファイルには、「/」、「..」、「〜username」などのパス文字で始まるエントリが含まれている可能性があります。 POSIXオペレーティングシステムでターゲットファイルをリークまたは上書きする実装。
Windows implementations SHOULD test their implementations to ensure that safety checks prevent use of drive letters and the less commonly used namespace sequences (e.g., "\\?\C:\...") described in [MSFNAM].
Windowsの実装では、実装をテストして、安全性チェックでドライブ文字の使用と、[MSFNAM]で説明されているあまり使用されない名前空間シーケンス（「\\？\ C：\ ...」など）が防止されていることを確認する必要があります。
To assist implementers, the Library of Congress conformance suite [LC-CONFORMANCE-SUITE] has some tests for invalid bags that are expected to fail on POSIX or Windows clients.
実装者を支援するために、米国議会図書館の適合性スイート[LC-CONFORMANCE-SUITE]には、POSIXまたはWindowsクライアントで失敗すると予想される無効なバッグに対するいくつかのテストがあります。
Implementers of tools that complete bags by retrieving URLs listed in a fetch file need to be aware that some of those URLs might point to hosts, intentionally or unintentionally, that are not under control of the bag's sender. Moreover, older checksum algorithms, even if reasonable for detecting corruption during transit, may not offer strong cryptographic protection against intentional spoofing.
フェッチファイルにリストされたURLを取得してバッグを完成させるツールの実装者は、それらのURLの一部が意図的または非意図的に、バッグの送信者の制御下にないホストをポイントしている可能性があることに注意する必要があります。さらに、古いチェックサムアルゴリズムは、転送中の破損を検出するのに妥当であっても、意図的なスプーフィングに対する強力な暗号保護を提供しない場合があります。
The size of files, as optionally reported in the fetch file, cannot be guaranteed to match the actual file size to be downloaded. Implementers SHOULD take steps to monitor and abort transfer when the received file size exceeds the file size reported in the fetch file. Implementers SHOULD NOT use the file size in the fetch file for critical resource allocation, such as buffer sizing or storage requisitioning.
フェッチファイルでオプションとして報告されるファイルのサイズは、ダウンロードされる実際のファイルサイズと一致することを保証できません。実装者は、受信したファイルサイズがフェッチファイルで報告されたファイルサイズを超えたときに、転送を監視して中止する手順を実行する必要があります（SHOULD）。実装者は、バッファのサイズ変更やストレージの要求などの重要なリソース割り当てに、フェッチファイルのファイルサイズを使用しないでください。
The integrity assurance provided by manifests is designed to provide high levels of confidence against data corruption but is not designed to be secure against active attacks. Organizations that need to secure bags against such threats SHOULD agree on additional measures, such as digital signatures, that are out of scope for this specification.
マニフェストによって提供される整合性保証は、データ破損に対する高いレベルの信頼性を提供するように設計されていますが、アクティブな攻撃から保護するようには設計されていません。そのような脅威からバッグを保護する必要がある組織は、この仕様の範囲外であるデジタル署名などの追加の対策に同意する必要があります。
This section lists practical considerations for implementers and users. None of the points below are required, but they are recommended for general-purpose usage.
このセクションでは、実装者とユーザーのための実際的な考慮事項を示します。以下のポイントは必須ではありませんが、一般的な用途に推奨されます。
Upon discovering errors in bags, an implementation is free to take action (for example, logging or reporting) in an application-specific manner. This document does not mandate any particular action.
バッグのエラーを検出すると、実装はアプリケーション固有の方法でアクション（たとえば、ロギングやレポート）を自由に実行できます。このドキュメントは、特定のアクションを強制するものではありません。
The Library of Congress conformance suite [LC-CONFORMANCE-SUITE] is provided as a public resource to test new implementations for compatibility and error handling.
米国議会図書館の適合性スイート[LC-CONFORMANCE-SUITE]は、互換性とエラー処理について新しい実装をテストするためのパブリックリソースとして提供されています。
This section provides background information on various challenges caused by differences in how operating systems, filesystems, and common tools handle filenames. This section is followed by a list of recommendations for implementers in Section 6.1.1.3.
このセクションでは、オペレーティングシステム、ファイルシステム、および一般的なツールがファイル名を処理する方法の違いによって引き起こされるさまざまな課題に関する背景情報を提供します。このセクションの後には、セクション6.1.1.3の実装者向けの推奨事項のリストが続きます。
There are three challenges for interoperability related to filename case:
ファイル名の大文字と小文字に関連する相互運用性には3つの課題があります。
o Filesystems such as File Allocation Table (FAT) or Extended File Allocation Table (EXFAT) always convert filenames to uppercase: "example.txt" will be stored as "EXAMPLE.TXT".
o ファイルアロケーションテーブル（FAT）や拡張ファイルアロケーションテーブル（EXFAT）などのファイルシステムは、常にファイル名を大文字に変換します。「example.txt」は「EXAMPLE.TXT」として保存されます。
o Many Unix filesystems save filenames exactly as provided, which allows multiple files that differ only in case: "example.txt" and "Example.txt" are separate files.
o 多くのUnixファイルシステムは、提供されたとおりにファイル名を保存します。これにより、「example.txt」と「Example.txt」は別々のファイルです。
o New Technology File System (NTFS) and Apple's Hierarchical File System (HFS) Plus usually preserve case when storing files but are case insensitive when retrieving them. A file saved as "Example.txt" will be retrieved by that name but will also be retrieved as "EXAMPLE.TXT", "example.txt", etc.
o New Technology File System（NTFS）およびAppleのHierarchical File System（HFS）Plusは、通常、ファイルを保存するときに大文字と小文字を保持しますが、ファイルを取得するときに大文字と小文字を区別しません。 「Example.txt」として保存されたファイルはその名前で取得されますが、「EXAMPLE.TXT」、「example.txt」などとしても取得されます。
The Unicode specification has common cases where different character sequences produce the same human-meaningful text. These are referred to as "canonically equivalent" and the Unicode specification defines different normalization forms - see [UNICODE-TR15] for the full details.
Unicode仕様には、異なる文字シーケンスが人間にとって意味のある同じテキストを生成する一般的なケースがあります。これらは「標準的に同等」と呼ばれ、Unicode仕様ではさまざまな正規化形式が定義されています。詳細については、[UNICODE-TR15]を参照してください。
The example below shows the common surname "Nunez" normalized in different forms.
次の例は、さまざまな形式で正規化された一般的な姓「Nunez」を示しています。
Normalization Form D (Decomposition)
正規化形式D（分解）
Char UTF8 Hex Name
----------------------------------------------
N 4e LATIN CAPITAL LETTER N
u 75 LATIN SMALL LETTER U
\u0301 cc81 COMBINING ACUTE ACCENT
n 6e LATIN SMALL LETTER N
\u0303 cc83 COMBINING TILDE
e 65 LATIN SMALL LETTER E
z 7a LATIN SMALL LETTER Z
Normalization Form C (Canonical Composition)
Char UTF8 Hex Name
----------------------------------------------
N 4e LATIN CAPITAL LETTER N
u c3ba LATIN SMALL LETTER U WITH ACUTE
n c3b1 LATIN SMALL LETTER N WITH TILDE
e 65 LATIN SMALL LETTER E
z 7a LATIN SMALL LETTER Z
Unicode normalization is relevant to BagIt implementors because different systems have different standards for normalization:
Unicodeの正規化はBagItインプリメンターに関連しています。これは、システムによって正規化の基準が異なるためです。
o Apple's HFS Plus filesystem always normalizes filenames to a fully decomposed form based on the Unicode 2.0 specification (see [TN1150]).
o AppleのHFS Plusファイルシステムは常に、ファイル名をUnicode 2.0仕様に基づいて完全に分解された形式に正規化します（[TN1150]を参照）。
o Windows treats filenames as opaque character sequences (see [MSFNAM]) and will store and return the encoded bytes exactly as provided.
o Windowsはファイル名を不透明な文字シーケンス（[MSFNAM]を参照）として扱い、エンコードされたバイトを提供されたとおりに格納して返します。
o Linux and other common Unix systems are generally similar to Windows in storing and returning opaque byte streams, but this behavior is technically dependent on the filesystem.
o Linuxおよびその他の一般的なUnixシステムは、不透明なバイトストリームを格納および返す点でWindowsとほぼ同じですが、この動作は技術的にはファイルシステムに依存しています。
o Utilities used for file management, transfer, and archiving may ignore this issue, apply an arbitrary normalization form, or allow the user to control how normalization is applied.
o ファイルの管理、転送、およびアーカイブに使用されるユーティリティは、この問題を無視するか、任意の正規化フォームを適用するか、正規化の適用方法をユーザーが制御できるようにします。
In practice, this means that the encoded filename stored in a manifest may fail a simple file existence check because the filename's normalization was changed at some point after the manifest was written. This situation is very confusing for users because the filenames are visually indistinguishable, and the "missing" file is obviously present in the payload directory.
実際には、これは、マニフェストに書き込まれたファイル名の正規化が変更されたため、マニフェストに格納されたエンコードされたファイル名が単純なファイル存在チェックに失敗する可能性があることを意味します。ファイル名は視覚的に区別できず、「見つからない」ファイルは明らかにペイロードディレクトリに存在するため、この状況はユーザーにとって非常に混乱します。
o Implementations SHOULD discourage the creation of bags containing files that differ only in case.
o 実装では、大文字と小文字のみが異なるファイルを含むバッグの作成は推奨されません。
o Implementations SHOULD prevent the creation of bags containing files that differ only in normalization form.
o 実装は、正規化形式のみが異なるファイルを含むバッグの作成を防止する必要があります（SHOULD）。
o BagIt implementations SHOULD tolerate differences in normalization form by comparing both the list of filesystem and manifest names after applying the same normalization form to both.
o BagIt実装は、ファイルシステムのリストとマニフェスト名の両方を同じ正規化形式に適用した後、両方を比較することにより、正規化形式の違いを許容する必要があります（SHOULD）。
o Implementations SHOULD issue a warning when multiple manifests are present that differ only in case or normalization form.
o 大文字と小文字または正規化形式のみが異なる複数のマニフェストが存在する場合、実装は警告を発行する必要があります（SHOULD）。
As specified above, only the Unix-based path separator ('/') may be used inside filenames listed in BagIt manifest and fetch.txt files. When bags are exchanged between Windows and Unix platforms, the path separator SHOULD be translated as needed. Receivers of bags on physical media SHOULD be prepared for filesystems created under either Windows or Unix. Besides the fundamental difference between path separators ('\' and '/'), generally, Windows filesystems have more limitations than Unix filesystems.
上記のように、Unixベースのパス区切り文字（ '/'）のみがBagItマニフェストおよびfetch.txtファイルにリストされているファイル名の内部で使用できます。 WindowsとUnixプラットフォーム間でバッグが交換される場合、パス区切り文字は必要に応じて変換する必要があります（SHOULD）。物理メディア上のバッグのレシーバーは、WindowsまたはUnixのいずれかで作成されたファイルシステム用に準備する必要があります。パス区切り文字（ '\'と '/'）の根本的な違いに加えて、一般に、WindowsファイルシステムにはUnixファイルシステムよりも多くの制限があります。
Windows path names have a maximum of 255 characters, and none of these characters may be used in a path component:
Windowsのパス名は最大255文字で、これらの文字はパスコンポーネントでは使用できません。
< > : " / | ? *
Windows also reserves the following names, with or without a file extension:
Windowsは、ファイル拡張子の有無にかかわらず、次の名前も予約しています。
CON, PRN, AUX, NUL COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9 LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9
CON、PRN、AUX、NUL COM1、COM2、COM3、COM4、COM5、COM6、COM7、COM8、COM9 LPT1、LPT2、LPT3、LPT4、LPT5、LPT6、LPT7、LPT8、LPT9
See [MSFNAM] for more information and possible alternatives.
詳細および可能な代替案については、[MSFNAM]を参照してください。
Some bags have been manually assembled using checksum utilities such as those contained in the GNU Coreutils package (md5sum, sha1sum, etc.), collectively referred to here as "md5sum". Implementers who desire wide support of legacy content should be aware of some known quirks of these tools.
一部のバッグは、GNU Coreutilsパッケージ（md5sum、sha1sumなど）に含まれているものなどのチェックサムユーティリティを使用して手動で組み立てられており、ここではこれらを総称して「md5sum」と呼びます。レガシーコンテンツの幅広いサポートを望む実装者は、これらのツールのいくつかの既知の癖に注意する必要があります。
md5sum can be run in "text mode", which causes it to normalize line endings on some operating systems. On Unix-like systems, both modes will usually produce the same results; on systems like Windows, they can produce different results based on the file contents. The md5sum output format has two characters between the checksum and the filepath: the first is always a space, and the second is an asterisk ("*") for binary mode and a space for text mode.
md5sumは「テキストモード」で実行でき、一部のオペレーティングシステムでは行末を正規化します。 Unixライクなシステムでは、両方のモードで通常同じ結果が得られます。 Windowsなどのシステムでは、ファイルの内容に基づいてさまざまな結果を生成できます。 md5sum出力フォーマットは、チェックサムとファイルパスの間に2文字あります。最初の文字は常にスペースで、2番目はバイナリモードのアスタリスク（ "*"）とテキストモードのスペースです。
A final note about md5sum-generated manifests is that, for a _filepath_ containing a backslash ('\'), the manifest line will have a backslash inserted in front of the _checksum_ and, under Windows, the backslashes inside _filepath_ can be doubled.
md5sumで生成されたマニフェストに関する最後の注意点は、円記号（ '\'）を含む_filepath_の場合、マニフェスト行の_checksum_の前にバックスラッシュが挿入され、Windowsでは、_filepath_内の円記号が2つになります。
Implementers MAY wish to accept this format by ignoring a leading asterisk or handling differences in line termination gracefully but, if so, implementations MUST warn the user that the bag in question will fail strict validation. In such cases, it is RECOMMENDED that tools provide an easy option to update the bag with valid manifests.
実装者は、先頭のアスタリスクを無視するか、行の終端の違いを適切に処理することにより、この形式を受け入れることができますが、そうである場合、実装は、問題のバッグが厳密な検証に失敗することをユーザーに警告する必要があります。そのような場合、ツールが有効なマニフェストでバッグを更新する簡単なオプションを提供することが推奨されます。
The Augmented Backus-Naur Form (ABNF) rules provided below are non-normative. If there is a discrepancy between requirements in the normative sections and the ABNF, the requirements in the normative sections prevail. Some definitions use the core rules (e.g., DIGIT, HEXDIG, etc) as defined in [RFC5234].
以下に提供される拡張バッカスナウアフォーム（ABNF）ルールは非規範的です。規範セクションの要件とABNFの要件に不一致がある場合、規範セクションの要件が優先されます。 [RFC5234]で定義されているコアルール（DIGIT、HEXDIGなど）を使用する定義もあります。
bagit.txt ABNF rules:
bagit.txt ABNFルール：
bagit-txt = "BagIt-Version: " 1*DIGIT "." 1*DIGIT ending
"Tag-File-Character-Encoding: " encoding ending
encoding = 1*CHAR
ending = CR / LF / CRLF
Payload Manifest ABNF rules:
ペイロードマニフェストABNFルール：
payload-manifest = 1*payload-manifest-line
payload-manifest-line = checksum 1*WSP filepath ending
checksum = 1*case-hexdig
case-hexdig = DIGIT / "A" / "a" / "B" / "b" / "C" / "c" /
"D" / "d" / "E"/ "e"/ "F" / "f"
filepath = "data/"
1*( unreserved / pct-encoded / sub-delims )
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims = "!" / "$" / "&" / DQUOTE / "'" / "(" / ")" /
"*" / "+" / "," / ";" / "=" / "/"
pct-encoded = "%0D" / "%0d" / "%0A" / "%0a" / "%25"
ending = CR / LF / CRLF
bag-info.txt ABNF rules:
bag-info.txt ABNFルール：
metadata = 1*metadata-line
metadata-line = key ":" WSP value ending *(continuation ending)
key = 1*non-reserved
value = 1*non-reserved
continuation = WSP 1*non-reserved
non-reserved = VCHAR / WSP
; any valid character for the specific encoding
; except those that match "ending"
ending = CR / LF / CRLF
fetch.txt ABNF rules:
fetch.txt ABNFルール：
fetch = 1*fetch-line
fetch-line = url 1*WSP length 1*WSP filepath ending
url = <absolute-URI, see [RFC3986], Section 4.3>
length = 1*DIGIT / "-"
filepath = ("data/"
1*( unreserved / pct-encoded / sub-delims ))
ending = CR / LF / CRLF
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[cs-registry] IANA, "Character Set", <https://www.iana.org/assignments/character-sets>.
[cs-registry] IANA、「Character Set」、<https://www.iana.org/assignments/character-sets>。
[ni-registry] IANA, "Named Information Hash Algorithm", <https://www.iana.org/assignments/named-information>.
[ni-registry] IANA、「Named Information Hash Algorithm」、<https://www.iana.org/assignments/named-information>。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <https://www.rfc-editor.org/info/rfc1321>.
[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、DOI 10.17487 / RFC1321、1992年4月、<https://www.rfc-editor.org/info/rfc1321>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, <https://www.rfc-editor.org/info/rfc3174>.
[RFC3174] Eastlake 3rd、D。およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、DOI 10.17487 / RFC3174、2001年9月、<https://www.rfc-editor.org/info/ rfc3174>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：/ /www.rfc-editor.org/info/rfc3986>。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.
[RFC6234] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and SHA-based HMAC and HKDF）」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<https：//www.rfc- editor.org/info/rfc6234>。
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <https://www.rfc-editor.org/info/rfc6920>.
[RFC6920] Farrell、S.、Kutscher、D.、Dannewitz、C.、Ohlman、B.、Keranen、A。、およびP. Hallam-Baker、「Naming Things with Hashes」、RFC 6920、DOI 10.17487 / RFC6920、 2013年4月、<https://www.rfc-editor.org/info/rfc6920>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[ENCDEP] Tabata, K., Okada, T., Nagamori, M., Sakaguchi, T., and S. Sugimoto, "A Collaboration Model between Archival Systems to Enhance the Reliability of Preservation by an Enclose-and-Deposit Method", 2005, <https://web.archive.org/web/20060508015635/ http://www.iwaw.net/05/papers/iwaw05-tabata.pdf>.
[ENCDEP]田端健太郎、岡田哲也、長森正明、坂口武司、杉本誠一、「囲い込み方式による保存の信頼性を高めるアーカイブシステムの連携モデル」 、2005、<https://web.archive.org/web/20060508015635/ http://www.iwaw.net/05/papers/iwaw05-tabata.pdf>。
[LC-CONFORMANCE-SUITE] The Library of Congress, "Test cases for validating Bagit Implementations", commit 43bcbdf, November 2017, <https://github.com/LibraryOfCongress/ bagit-conformance-suite/>.
[LC-CONFORMANCE-SUITE]米国議会図書館、「Bagit実装を検証するためのテストケース」、コミット43bcbdf、2017年11月、<https://github.com/LibraryOfCongress/ bagit-conformance-suite />。
[MSFNAM] Microsoft, Inc., "Naming Files, Paths, and Namespaces", May 2018, <http://msdn2.microsoft.com/en-us/library/aa365247.aspx>.
[MSFNAM] Microsoft、Inc。、「Naming Files、Paths、and Namespaces」、2018年5月、<http://msdn2.microsoft.com/en-us/library/aa365247.aspx>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[TN1150] Apple Inc., "Technical Note TN1150: HFS Plus Volume Format", March 2004, <https://developer.apple.com/legacy/ library/technotes/tn/tn1150.html>.
[TN1150] Apple Inc。、「Technical Note TN1150：HFS Plus Volume Format」、2004年3月、<https://developer.apple.com/legacy/library/technotes/tn/tn1150.html>。
[UNICODE-TR15] Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", Technical Report, Unicode 11.0.0, May 2018, <http://www.unicode.org/reports/tr15/>.
[UNICODE-TR15] Unicodeコンソーシアム、「Unicode Standard Annex＃15：Unicode Normalization Forms」、テクニカルレポート、Unicode 11.0.0、2018年5月、<http://www.unicode.org/reports/tr15/>。
Acknowledgements
謝辞
BagIt benefitted from the thoughtful assistance of Stephen Abrams, Mike Ashenfelder, Dan Chudnov, Dave Crocker, Scott Fisher, Brad Hards, Erik Hetzner, Keith Johnson, Leslie Johnston, David Loy, Mark Phillips, Tracy Seneca, Stian Soiland-Reyes, Brian Tingle, Adam Turoff, and Jim Tuttle.
BagItは、Stephen Abrams、Mike Ashenfelder、Dan Chudnov、Dave Crocker、Scott Fisher、Brad Hards、Erik Hetzner、Keith Johnson、Leslie Johnston、David Loy、Mark Phillips、Tracy Seneca、Stian Soiland-Reyes、Brian Tingle 、アダム・ターロフ、ジム・タトル。
Contributors
貢献者
Additional contributors to the authoring of BagIt are Andy Boyko, David Brunton, Rosie Storey, Ed Summers, Brian Vargas, and Kate Zwaard.
BagItのオーサリングへの追加の貢献者は、Andy Boyko、David Brunton、Rosie Storey、Ed Summers、Brian Vargas、Kate Zwaardです。
Authors' Addresses
著者のアドレス
John A. Kunze California Digital Library 415 20th St, 4th Floor Oakland, CA 94612 United States of America
ジョンA.クンゼカリフォルニアデジタルライブラリー415 20th St、4th Floorオークランド、CA 94612アメリカ合衆国
Email: jak@ucop.edu
Justin Littman Stanford Libraries 518 Memorial Way Stanford, CA 94305 United States of America
ジャスティン・リットマンスタンフォード図書館518 Memorial Wayスタンフォード、カリフォルニア94305アメリカ合衆国
Email: justinlittman@stanford.edu
Liz Madden Library of Congress 101 Independence Avenue SE Washington, DC 20540 United States of America
リズマッデン議会図書館101インディペンデンスアベニューSEワシントンDC 20540アメリカ合衆国
Email: emad@loc.gov
John Scancella
ジョン・スキャンセラ
Email: john.scancella@gmail.com
Chris Adams Library of Congress 101 Independence Avenue SE Washington, DC 20540 United States of America
クリスアダムス米国議会図書館101インディペンデンスアベニューSEワシントンDC 20540アメリカ合衆国
Email: cadams@loc.gov