[要約] RFC 3659はFTPの拡張機能に関する規格であり、主な目的はFTPの機能を拡張し、より効率的なファイル転送を可能にすることです。
Network Working Group P. Hethmon
Request for Comments: 3659 Hethmon Software
Updates: 959 March 2007
Category: Standards Track
Extensions to FTP
FTPの拡張
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
Copyright（C）IETF Trust（2007）。
Abstract
概要
This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode. It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure.
このドキュメントでは、定義された形式でリモートディレクトリのリストを取得し、中断されたデータ転送をSTREAMモードで再開できるようにする新しいFTPコマンドを指定します。 US-ASCII以外の文字セットを許可し、オプションの仮想ファイルストレージ構造も定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3
2.1. Basic Tokens . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Pathnames. . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Times. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Server Replies . . . . . . . . . . . . . . . . . . . . . 7
2.5. Interpreting Examples. . . . . . . . . . . . . . . . . . 8
3. File Modification Time (MDTM). . . . . . . . . . . . . . . . . 8
3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Error Responses. . . . . . . . . . . . . . . . . . . . . 9
3.3. FEAT Response for MDTM . . . . . . . . . . . . . . . . . 10
3.4. MDTM Examples. . . . . . . . . . . . . . . . . . . . . . 10
4. File SIZE. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Error Responses. . . . . . . . . . . . . . . . . . . . . 12
4.3. FEAT Response for SIZE . . . . . . . . . . . . . . . . . 12
4.4. Size Examples. . . . . . . . . . . . . . . . . . . . . . 12
5. Restart of Interrupted Transfer (REST) . . . . . . . . . . . . 13
5.1. Restarting in STREAM Mode. . . . . . . . . . . . . . . . 14
5.2. Error Recovery and Restart . . . . . . . . . . . . . . . 14
5.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. FEAT Response for REST . . . . . . . . . . . . . . . . . 16
5.5. REST Example . . . . . . . . . . . . . . . . . . . . . . 17
6. A Trivial Virtual File Store (TVFS). . . . . . . . . . . . . . 17
6.1. TVFS File Names. . . . . . . . . . . . . . . . . . . . . 18
6.2. TVFS Pathnames . . . . . . . . . . . . . . . . . . . . . 18
6.3. FEAT Response for TVFS . . . . . . . . . . . . . . . . . 20
6.4. OPTS for TVFS. . . . . . . . . . . . . . . . . . . . . . 21
6.5. TVFS Examples. . . . . . . . . . . . . . . . . . . . . . 21
7. Listings for Machine Processing (MLST and MLSD). . . . . . . . 23
7.1. Format of MLSx Requests. . . . . . . . . . . . . . . . . 23
7.2. Format of MLSx Response. . . . . . . . . . . . . . . . . 24
7.3. File Name Encoding . . . . . . . . . . . . . . . . . . . 26
7.4. Format of Facts. . . . . . . . . . . . . . . . . . . . . 28
7.5. Standard Facts . . . . . . . . . . . . . . . . . . . . . 28
7.6. System Dependent and Local Facts . . . . . . . . . . . . 36
7.7. MLSx Examples. . . . . . . . . . . . . . . . . . . . . . 37
7.8. FEAT Response for MLSx . . . . . . . . . . . . . . . . . 49
7.9. OPTS Parameters for MLST . . . . . . . . . . . . . . . . 51
8. Impact on Other FTP Commands . . . . . . . . . . . . . . . . . 54
9. Character Sets and Internationalization. . . . . . . . . . . . 55
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 55
10.1. The OS Specific Fact Registry. . . . . . . . . . . . . . 56
10.2. The OS Specific Filetype Registry. . . . . . . . . . . . 56
11. Security Considerations. . . . . . . . . . . . . . . . . . . . 57
12. Normative References . . . . . . . . . . . . . . . . . . . . . 58
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 59
This document updates the File Transfer Protocol (FTP) [3]. Four new commands are added: "SIZE", "MDTM", "MLST", and "MLSD". The existing command "REST" is modified. Of those, the "SIZE" and "MDTM" commands, and the modifications to "REST" have been in wide use for many years. The others are new.
このドキュメントは、ファイル転送プロトコル（FTP）[3]を更新します。 「SIZE」、「MDTM」、「MLST」、「MLSD」の4つの新しいコマンドが追加されました。既存のコマンド「REST」が変更されました。これらのうち、「SIZE」および「MDTM」コマンド、および「REST」への変更は、長年にわたって広く使用されています。他は新しいです。
These commands allow a client to restart an interrupted transfer in transfer modes not previously supported in any documented way, and to obtain a directory listing in a machine friendly, predictable, format.
これらのコマンドを使用すると、クライアントは、文書化された方法でこれまでサポートされていなかった転送モードで中断された転送を再開し、マシンフレンドリで予測可能な形式のディレクトリリストを取得できます。
An optional structure for the server's file store (NVFS) is also defined, allowing servers that support such a structure to convey that information to clients in a standard way, thus allowing clients more certainty in constructing and interpreting pathnames.
サーバーのファイルストア（NVFS）のオプションの構造も定義されており、そのような構造をサポートするサーバーが標準的な方法でその情報をクライアントに伝えることができるため、クライアントはパス名の構築と解釈をより確実に行うことができます。
This document makes use of the document conventions defined in BCP 14, RFC 2119 [4]. That provides the interpretation of capitalized imperative words like MUST, SHOULD, etc.
このドキュメントは、BCP 14、RFC 2119 [4]で定義されているドキュメントの規則を利用しています。これは、MUST、SHOULDなどの大文字の命令語の解釈を提供します。
This document also uses notation defined in STD 9, RFC 959 [3]. In particular, the terms "reply", "user", "NVFS" (Network Virtual File System), "file", "pathname", "FTP commands", "DTP" (data transfer process), "user-FTP process", "user-PI" (user protocol interpreter), "user-DTP", "server-FTP process", "server-PI", "server-DTP", "mode", "type", "NVT" (Network Virtual Terminal), "control connection", "data connection", and "ASCII", are all used here as defined there.
このドキュメントでは、STD 9、RFC 959 [3]で定義されている表記法も使用しています。特に、「返信」、「ユーザー」、「NVFS」（ネットワーク仮想ファイルシステム）、「ファイル」、「パス名」、「FTPコマンド」、「DTP」（データ転送プロセス）、「ユーザーFTPプロセス"、" user-PI "（ユーザープロトコルインタープリター）、" user-DTP "、" server-FTPプロセス "、" server-PI "、" server-DTP "、" mode "、" type "、" NVT "（ネットワーク仮想ターミナル）、「制御接続」、「データ接続」、および「ASCII」はすべて、ここで定義されているとおりに使用されます。
Syntax required is defined using the Augmented BNF defined in [5]. Some general ABNF definitions that are required throughout the document will be defined later in this section. At first reading, it may be wise to simply recall that these definitions exist here, and skip to the next section.
必要な構文は、[5]で定義されている拡張BNFを使用して定義されています。ドキュメント全体で必要となるいくつかの一般的なABNF定義は、このセクションの後半で定義されます。最初に読んで、これらの定義がここに存在することを思い出して、次のセクションにスキップするのが賢明かもしれません。
This document imports the core ABNF definitions given in Appendix A of [5]. There definitions will be found for basic ABNF elements like ALPHA, DIGIT, SP, etc. The following terms are added for use in this document.
このドキュメントは、[5]の付録Aに記載されているコアABNF定義をインポートします。 ALPHA、DIGIT、SPなどの基本的なABNF要素の定義があります。このドキュメントで使用するために、次の用語が追加されています。
TCHAR = VCHAR / SP / HTAB ; visible plus white space
RCHAR = ALPHA / DIGIT / "," / "." / ":" / "!" /
"@" / "#" / "$" / "%" / "^" /
"&" / "(" / ")" / "-" / "_" /
"+" / "?" / "/" / "\" / "'" /
DQUOTE ; <"> -- double quote character (%x22)
SCHAR = RCHAR / "=" ;
The VCHAR (from [5]), RCHAR, SCHAR, and TCHAR types give basic character types from varying sub-sets of the ASCII character set for use in various commands and responses.
VCHAR（[5]から）、RCHAR、SCHAR、およびTCHARタイプは、さまざまなコマンドおよび応答で使用するために、ASCII文字セットのさまざまなサブセットからの基本的な文字タイプを提供します。
token = 1*RCHAR
A "token" is a string whose precise meaning depends upon the context in which it is used. In some cases it will be a value from a set of possible values maintained elsewhere. In others it might be a string invented by one party to an FTP conversation from whatever sources it finds relevant.
「トークン」は、その正確な意味が、それが使用されるコンテキストに依存するストリングです。場合によっては、他の場所で維持されている可能な値のセットからの値になります。それ以外の場合は、関係があると思われるソースからのFTP会話の一方の当事者によって発明された文字列である可能性があります。
Note that in ABNF, string literals are case insensitive. That convention is preserved in this document, and implies that FTP commands added by this specification have names that can be represented in any case. That is, "MDTM" is the same as "mdtm", "Mdtm" and "MdTm" etc. However note that ALPHA, in particular, is case sensitive. That implies that a "token" is a case sensitive value. That implication is correct, except where explicitly stated to the contrary in this document, or in some other specification that defines the values this document specifies be used in a particular context.
ABNFでは、文字列リテラルは大文字と小文字を区別しないことに注意してください。この規則はこのドキュメントでも保持されており、この仕様で追加されたFTPコマンドには、どのような場合でも表現できる名前が付けられています。つまり、「MDTM」は「mdtm」、「Mdtm」、「MdTm」などと同じです。ただし、ALPHAは特に大文字と小文字を区別することに注意してください。これは、「トークン」が大文字と小文字を区別する値であることを意味します。この含意は正しいですが、このドキュメント、またはこのドキュメントで特定のコンテキストで使用される値を定義する他の仕様で明示的に述べられている場合を除きます。
Various FTP commands take pathnames as arguments, or return pathnames in responses. When the MLST command is supported, as indicated in the response to the FEAT command [6], pathnames are to be transferred in one of the following two formats.
さまざまなFTPコマンドは、パス名を引数として取るか、応答でパス名を返します。 MLSTコマンドがサポートされている場合、FEATコマンド[6]への応答に示されているように、パス名は次の2つの形式のいずれかで転送されます。
pathname = utf-8-name / raw
utf-8-name = <a UTF-8 encoded Unicode string>
raw = <any string that is not a valid UTF-8 encoding>
Which format is used is at the option of the user-PI or server-PI sending the pathname. UTF-8 encodings [2] contain enough internal structure that it is always, in practice, possible to determine whether a UTF-8 or raw encoding has been used, in those cases where it matters. While it is useful for the user-PI to be able to correctly display a pathname received from the server-PI to the user, it is far more important for the user-PI to be able to retain and retransmit the identical pathname when required. Implementations are advised against converting a UTF-8 pathname to a local charset that isn't capable of representing the full Unicode character repertoire, and then attempting to invert the charset translation later. Note that ASCII is a subset of UTF-8. See also [1].
使用される形式は、パス名を送信するユーザーPIまたはサーバーPIのオプションです。 UTF-8エンコーディング[2]には十分な内部構造が含まれているため、実際には常に、UTF-8またはrawエンコーディングが使用されているかどうかを判断することができます。ユーザーPIがサーバーPIから受信したパス名をユーザーに正しく表示できると便利ですが、ユーザーPIが必要に応じて同じパス名を保持して再送信できることははるかに重要です。実装では、UTF-8パス名を、完全なUnicode文字レパートリーを表すことができないローカル文字セットに変換し、後で文字セット変換を反転させないようにしてください。 ASCIIはUTF-8のサブセットであることに注意してください。 [1]も参照してください。
Unless otherwise specified, the pathname is terminated by the CRLF that terminates the FTP command, or by the CRLF that ends a reply. Any trailing spaces preceding that CRLF form part of the name. Exactly one space will precede the pathname and serve as a separator from the preceding syntax element. Any additional spaces form part of the pathname. See [7] for a fuller explanation of the character encoding issues. All implementations supporting MLST MUST support [7].
特に指定がない限り、パス名はFTPコマンドを終了するCRLF、または応答を終了するCRLFで終了します。そのCRLFの前にある末尾のスペースは、名前の一部を形成します。正確に1つのスペースがパス名の前にあり、前の構文要素との区切り文字として機能します。追加のスペースはパス名の一部を形成します。文字エンコーディングの問題の詳細については、[7]を参照してください。 MLSTをサポートするすべての実装は、[7]をサポートする必要があります。
Note: for pathnames transferred over a data connection, there is no way to represent a pathname containing the characters CR and LF in sequence, and distinguish that from the end of line indication. Hence, pathnames containing the CRLF pair of characters cannot be transmitted over a data connection. Data connections only contain file names transmitted from server-FTP to user-FTP as the result of one of the directory listing commands. Files with names containing the CRLF sequence must either have that sequence converted to some other form, such that the other form can be recognised and be correctly converted back to CRLF, or be omitted from the listing.
注：データ接続を介して転送されるパス名の場合、CRとLFの文字を順番に含むパス名を表し、行末の表示と区別する方法はありません。したがって、CRLF文字のペアを含むパス名は、データ接続を介して送信できません。データ接続には、ディレクトリ一覧コマンドの1つの結果としてサーバーFTPからユーザーFTPに送信されたファイル名のみが含まれます。 CRLFシーケンスを含む名前のファイルは、そのシーケンスを他の形式に変換して、他の形式を認識してCRLFに正しく変換できるようにするか、リストから省略する必要があります。
Implementations should also beware that the FTP control connection uses Telnet NVT conventions [8], and that the Telnet IAC character, if part of a pathname sent over the control connection, MUST be correctly escaped as defined by the Telnet protocol.
実装は、FTP制御接続がTelnet NVT規約[8]を使用していること、および制御接続を介して送信されたパス名の一部である場合、Telnet IAC文字がTelnetプロトコルの定義に従って正しくエスケープされなければならないことにも注意する必要があります。
NVT also distinguishes between CR, LF, and the end of line CRLF, and so would permit pathnames containing the pair of characters CR and LF to be correctly transmitted. However, because such a sequence cannot be transmitted over a data connection (as part of the result of a LIST, NLST, or MLSD command), such pathnames are best avoided.
NVTはCR、LF、および行末CRLFも区別するため、CRとLFのペアを含むパス名を正しく送信できます。ただし、このようなシーケンスは（LIST、NLST、またはMLSDコマンドの結果の一部として）データ接続を介して送信できないため、そのようなパス名は回避するのが最善です。
Implementors should also be aware that, although Telnet NVT conventions are used over the control connections, Telnet option negotiation MUST NOT be attempted. See section 4.1.2.12 of [9].
実装者は、制御接続でTelnet NVT規則が使用されている場合でも、Telnetオプションのネゴシエーションを試行してはならないことに注意してください。 [9]のセクション4.1.2.12を参照してください。
Except where TVFS is supported (see section 6), this specification imposes no syntax upon pathnames. Nor does it restrict the character set from which pathnames are created. This does not imply that the NVFS is required to make sense of all possible pathnames. Server-PIs may restrict the syntax of valid pathnames in their NVFS in any manner appropriate to their implementation or underlying file system. Similarly, a server-PI may parse the pathname and assign meaning to the components detected.
TVFSがサポートされている場合（セクション6を参照）を除いて、この仕様はパス名に構文を課しません。また、パス名の作成元の文字セットも制限されません。これは、NVFSがすべての可能なパス名を理解する必要があることを意味するものではありません。サーバーPIは、NVFS内の有効なパス名の構文を、その実装または基礎となるファイルシステムに適した方法で制限する場合があります。同様に、サーバーPIはパス名を解析し、検出されたコンポーネントに意味を割り当てることができます。
For the commands defined in this specification, all pathnames are to be treated literally. That is, for a pathname given as a parameter to a command, the file whose name is identical to the pathname given is implied. No characters from the pathname may be treated as special or "magic", thus no pattern matching (other than for exact equality) between the pathname given and the files present in the NVFS of the server-FTP is permitted.
この仕様で定義されているコマンドの場合、すべてのパス名は文字どおりに扱われます。つまり、コマンドのパラメーターとして指定されたパス名の場合、指定されたパス名と同じ名前のファイルが暗黙指定されます。パス名からの文字は特殊または「マジック」として扱うことができないため、指定されたパス名とサーバーFTPのNVFSに存在するファイルとの間のパターンマッチング（正確に等しい場合を除く）は許可されません。
Clients that desire some form of pattern matching functionality must obtain a listing of the relevant directory, or directories, and implement their own file name selection procedures.
何らかのパターンマッチング機能を希望するクライアントは、関連するディレクトリのリストを取得し、独自のファイル名選択手順を実装する必要があります。
The syntax of a time value is:
時間値の構文は次のとおりです。
time-val = 14DIGIT [ "." 1*DIGIT ]
time-val = 14DIGIT ["。" 1 * DIGIT]
The leading, mandatory, fourteen digits are to be interpreted as, in order from the leftmost, four digits giving the year, with a range of 1000--9999, two digits giving the month of the year, with a range of 01--12, two digits giving the day of the month, with a range of 01--31, two digits giving the hour of the day, with a range of 00--23, two digits giving minutes past the hour, with a range of 00--59, and finally, two digits giving seconds past the minute, with a range of 00--60 (with 60 being used only at a leap second). Years in the tenth century, and earlier, cannot be expressed. This is not considered a serious defect of the protocol.
先頭の必須の14桁は、左端から順に、年を表す4桁で、範囲は1000から9999で、2桁は月を表し、範囲は01です。 12、2桁で月の日を示し、範囲は01--31、2桁で時間を示し、範囲は00--23、2桁で時間を分で示し、範囲は00--59、そして最後に、00から60の範囲で、分を過ぎた秒を表す2桁（60はうるう秒でのみ使用されます）。 10世紀以前の年は表現できません。これはプロトコルの重大な欠陥とは見なされません。
The optional digits, which are preceded by a period, give decimal fractions of a second. These may be given to whatever precision is appropriate to the circumstance, however implementations MUST NOT add precision to time-vals where that precision does not exist in the underlying value being transmitted.
ピリオドが前に付いているオプションの数字は、小数秒を表します。これらは状況に適した精度に与えることができますが、実装は、送信される基になる値にその精度が存在しない場合、time-valsに精度を追加してはなりません。
Symbolically, a time-val may be viewed as
象徴的に、time-valは、
YYYYMMDDHHMMSS.sss
YYYYMMDDHHMMSS.sss
The "." and subsequent digits ("sss") are optional. However the "." MUST NOT appear unless at least one following digit also appears.
「。」以降の数字（ "sss"）はオプションです。しかし "。"次の少なくとも1つの数字も表示されない限り、表示しないでください。
Time values are always represented in UTC (GMT), and in the Gregorian calendar regardless of what calendar may have been in use at the date and time indicated at the location of the server-PI.
時間値は常にUTC（GMT）で表され、サーバーPIの場所に示されている日時にどのカレンダーが使用されていたとしても、グレゴリオ暦で表されます。
The technical differences among GMT, TAI, UTC, UT1, UT2, etc., are not considered here. A server-FTP process should always use the same time reference, so the times it returns will be consistent. Clients are not expected to be time synchronized with the server, so the possible difference in times that might be reported by the different time standards is not considered important.
ここでは、GMT、TAI、UTC、UT1、UT2などの技術的な違いは考慮されていません。サーバーFTPプロセスは常に同じ時間参照を使用する必要があるため、プロセスが返す時間は一貫しています。クライアントはサーバーと時刻が同期しているとは想定されていないため、さまざまな時刻標準によって報告される可能性のある時刻の違いは重要とは見なされません。
Section 4.2 of [3] defines the format and meaning of replies by the server-PI to FTP commands from the user-PI. Those reply conventions are used here without change.
[3]のセクション4.2は、ユーザーPIからFTPコマンドへのサーバーPIによる応答の形式と意味を定義しています。ここでは、これらの返信規則をそのまま使用します。
error-response = error-code SP *TCHAR CRLF
error-code = ("4" / "5") 2DIGIT
Implementors should note that the ABNF syntax used in this document and in other FTP related documents (but not used in [3]), sometimes shows replies using the one-line format. Unless otherwise explicitly stated, that is not intended to imply that multi-line responses are not permitted. Implementors should assume that, unless stated to the contrary, any reply to any FTP command (including QUIT) may use the multi-line format described in [3].
実装者は、このドキュメントおよび他のFTP関連ドキュメント（[3]では使用されていません）で使用されるABNF構文が、1行形式を使用して返信を表示する場合があることに注意してください。特に明記されていない限り、複数行の応答が許可されていないことを意味するものではありません。実装者は、反対に述べられていない限り、FTPコマンド（QUITを含む）への応答には、[3]で説明されている複数行形式を使用できると想定する必要があります。
Throughout this document, replies will be identified by the three digit code that is their first element. Thus the term "500 reply" means a reply from the server-PI using the three digit code "500".
このドキュメント全体で、返信は最初の要素である3桁のコードで識別されます。したがって、「500応答」という用語は、3桁のコード「500」を使用したサーバーPIからの応答を意味します。
In the examples of FTP dialogs presented in this document, lines that begin "C> " were sent over the control connection from the user-PI to the server-PI, lines that begin "S> " were sent over the control connection from the server-PI to the user-PI, and each sequence of lines that begin "D> " was sent from the server-PI to the user-PI over a data connection created just to send those lines and closed immediately after. No examples here show data transferred over a data connection from the client to the server. In all cases, the prefixes shown above, including the one space, have been added for the purposes of this document, and are not a part of the data exchanged between client and server.
このドキュメントに示されているFTPダイアログの例では、「C>」で始まる行は制御接続を介してユーザーPIからサーバーPIに送信され、「S>」で始まる行は制御接続を介して送信されましたサーバーPIからユーザーPI、および「D>」で始まる行の各シーケンスは、これらの行を送信するためだけに作成され、直後に閉じられたデータ接続を介してサーバーPIからユーザーPIに送信されました。ここでは、クライアントからサーバーへのデータ接続を介して転送されたデータを示す例はありません。すべての場合において、1つのスペースを含む上記のプレフィックスは、このドキュメントの目的で追加されたものであり、クライアントとサーバー間で交換されるデータの一部ではありません。
The FTP command, MODIFICATION TIME (MDTM), can be used to determine when a file in the server NVFS was last modified. This command has existed in many FTP servers for many years, as an adjunct to the REST command for STREAM mode, thus is widely available. However, where supported, the "modify" fact that can be provided in the result from the new MLST command is recommended as a superior alternative.
FTPコマンドMODIFICATION TIME（MDTM）を使用して、サーバーのNVFS内のファイルが最後に変更された日時を判別できます。このコマンドは、STREAMモードのRESTコマンドの補助として、多くのFTPサーバーに長年存在していたため、広く利用できます。ただし、サポートされている場合は、新しいMLSTコマンドの結果で提供される「変更」ファクトが優れた代替手段として推奨されます。
When attempting to restart a RETRieve, the user-FTP can use the MDTM command or the "modify" fact to check if the modification time of the source file is more recent than the modification time of the partially transferred file. If it is, then most likely the source file has changed, and it would be unsafe to restart the previously incomplete file transfer.
RETRieveを再起動しようとする場合、ユーザーFTPはMDTMコマンドまたは「変更」ファクトを使用して、ソースファイルの変更時刻が部分的に転送されたファイルの変更時刻よりも新しいかどうかを確認できます。そうである場合、ソースファイルが変更されている可能性が高く、以前は不完全だったファイル転送を再開するのは危険です。
Because the user- and server-FTPs' clocks are not necessarily synchronised, user-FTPs intending to use this method should usually obtain the modification time of the file from the server before the initial RETRieval, and compare that with the modification time before a RESTart. If they differ, the files may have changed, and RESTart would be inadvisable. Where this is not possible, the user-FTP should make sure to allow for possible clock skew when comparing times.
ユーザーFTPとサーバーFTPのクロックは必ずしも同期されていないため、このメソッドを使用するユーザーFTPは通常、最初のRETRievalの前にサーバーからファイルの変更時刻を取得し、それをRESTartの前の変更時刻と比較する必要があります。 。それらが異なる場合、ファイルが変更されている可能性があり、RESTartはお勧めできません。これが不可能な場合、ユーザーFTPは、時間を比較するときに、可能なクロックスキューを考慮に入れておく必要があります。
When attempting to restart a STORe, the User FTP can use the MDTM command to discover the modification time of the partially transferred file. If it is older than the modification time of the file that is about to be STORed, then most likely the source file has changed, and it would be unsafe to restart the file transfer.
STOReを再起動しようとすると、ユーザーFTPはMDTMコマンドを使用して、部分的に転送されたファイルの変更時刻を検出できます。保存しようとしているファイルの変更時刻よりも古い場合、ソースファイルが変更されている可能性が高く、ファイル転送を再開するのは危険です。
Note that using MLST (described below), where available, can provide this information and much more, thus giving an even better indication that a file has changed and that restarting a transfer would not give valid results.
MLST（以下で説明）を使用すると、利用可能な場合にこの情報などを提供できるため、ファイルが変更され、転送を再開しても有効な結果が得られないことを示す、より優れた指標となります。
Note that this is applicable to any RESTart attempt, regardless of the mode of the file transfer.
これは、ファイル転送のモードに関係なく、すべてのRESTart試行に適用できることに注意してください。
The syntax for the MDTM command is:
MDTMコマンドの構文は次のとおりです。
mdtm = "MdTm" SP pathname CRLF
mdtm = "MdTm" SPパス名CRLF
As with all FTP commands, the "MDTM" command label is interpreted in a case-insensitive manner.
すべてのFTPコマンドと同様に、「MDTM」コマンドラベルは大文字と小文字を区別しない方法で解釈されます。
The "pathname" specifies an object in the NVFS that may be the object of a RETR command. Attempts to query the modification time of files that exist but are unable to be retrieved may generate an error-response, or can result in a positive response carrying a time-val with an unspecified value, the choice being made by the server-PI.
「パス名」は、RETRコマンドのオブジェクトである可能性があるNVFS内のオブジェクトを指定します。存在するが取得できないファイルの変更時刻を照会しようとすると、エラー応答が生成されるか、値が指定されていないtime-valを含む肯定的な応答が返され、サーバーPIによって選択が行われます。
The server-PI will respond to the MDTM command with a 213 reply giving the last modification time of the file whose pathname was supplied, or a 550 reply if the file does not exist, the modification time is unavailable, or some other error has occurred.
server-PIはMDTMコマンドに応答して、パス名が指定されたファイルの最終変更時刻を示す213応答を返します。ファイルが存在しない場合、変更時刻が利用できない場合、またはその他のエラーが発生した場合は550応答を返します。 。
mdtm-response = "213" SP time-val CRLF / error-response
mdtm-response = "213" SP time-val CRLF / error-response
Note that when the 213 response is issued, that is, when there is no error, the format MUST be exactly as specified. Multi-line responses are not permitted.
213応答が発行された場合、つまりエラーがない場合、形式は指定されたとおりでなければならないことに注意してください。複数行の応答は許可されていません。
Where the command is correctly parsed but the modification time is not available, either because the pathname identifies no existing entity or because the information is not available for the entity named, then a 550 reply should be sent. Where the command cannot be correctly parsed, a 500 or 501 reply should be sent, as specified in [3]. Various 4xy replies are also possible in appropriate circumstances.
コマンドが正しく解析されているが、パス名が既存のエンティティを識別していないため、または指定されたエンティティの情報が利用できないために、変更時間が利用できない場合は、550応答を送信する必要があります。コマンドを正しく解析できない場合は、[3]で指定されているように、500または501の応答を送信する必要があります。適切な状況では、さまざまな4xy応答も可能です。
When replying to the FEAT command [6], a server-FTP process that supports the MDTM command MUST include a line containing the single word "MDTM". This MAY be sent in upper or lower case or a mixture of both (it is case insensitive), but SHOULD be transmitted in upper case only. That is, the response SHOULD be:
FEATコマンド[6]に応答する場合、MDTMコマンドをサポートするサーバーFTPプロセスには、「MDTM」という単一の単語を含む行を含める必要があります。これは大文字、小文字、または両方の組み合わせで送信できます（大文字小文字は区別されません）が、大文字のみで送信する必要があります（SHOULD）。つまり、応答は次のようにする必要があります。
C> Feat
S> 211- <any descriptive text>
S> ...
S> MDTM
S> ...
S> 211 End
The ellipses indicate place holders where other features may be included, but are not required. The one-space indentation of the feature lines is mandatory [6].
省略記号は、他の機能を含めることができるプレースホルダーを示していますが、必須ではありません。計画線の1スペースのインデントは必須です[6]。
If we assume the existence of three files, A B and C, a directory D, two files with names that end with the string "ile6", and no other files at all, then the MDTM command may behave as indicated. The "C>" lines are commands from user-PI to server-PI, the "S>" lines are server-PI replies.
3つのファイルA BとC、ディレクトリD、文字列「ile6」で終わる名前の2つのファイルが存在し、他のファイルはまったく存在しないと想定すると、MDTMコマンドは指示どおりに動作する可能性があります。 "C>"行はユーザーPIからサーバーPIへのコマンドであり、 "S>"行はサーバーPI応答です。
C> MDTM A S> 213 19980615100045.014 C> MDTM B S> 213 19980615100045.014 C> MDTM C S> 213 19980705132316 C> MDTM D S> 550 D is not retrievable C> MDTM E S> 550 No file named "E" C> mdtm file6 S> 213 19990929003355 C> MdTm 19990929043300 File6 S> 213 19991005213102 C> MdTm 19990929043300 file6 S> 550 19990929043300 file6: No such file or directory.
C> MDTM AS> 213 19980615100045.014 C> MDTM BS> 213 19980615100045.014 C> MDTM CS> 213 19980705132316 C> MDTM DS> 550 Dを取得できないC> MDTM ES> 550「E」という名前のファイルがないC> mdtm file6 S> 213 19990929003355 C> MdTm 19990929043300 File6 S> 213 19991005213102 C> MdTm 19990929043300 file6 S> 550 19990929043300 file6：そのようなファイルまたはディレクトリはありません。
From that we can conclude that both A and B were last modified at the same time (to the nearest millisecond), and that C was modified 20 days and several hours later.
このことから、AとBの両方が同時に（最も近いミリ秒に）最後に変更され、Cが20日と数時間後に変更されたと結論付けることができます。
The times are in GMT, so file A was modified on the 15th of June, 1998, at approximately 11am in London (summer time was then in effect), or perhaps at 8pm in Melbourne, Australia, or at 6am in New York. All of those represent the same absolute time, of course. The location where the file was modified, and consequently the local wall clock time at that location, is not available.
時刻はGMTであるため、ファイルAは1998年6月15日のロンドンで午前11時頃（夏時間が有効でした）、オーストラリアのメルボルンで午後8時、またはニューヨークで午前6時に変更されました。もちろん、これらはすべて同じ絶対時間を表します。ファイルが変更された場所、およびその結果、その場所のローカルの壁時計時刻は利用できません。
There is no file named "E" in the current directory, but there are files named both "file6" and "19990929043300 File6". The modification times of those files were obtained. There is no file named "19990929043300 file6".
現在のディレクトリに「E」という名前のファイルはありませんが、「file6」と「19990929043300 File6」の両方の名前が付いたファイルがあります。それらのファイルの変更時刻が取得されました。 「19990929043300 file6」という名前のファイルはありません。
The FTP command, SIZE OF FILE (SIZE), is used to obtain the transfer size of a file from the server-FTP process. This is the exact number of octets (8 bit bytes) that would be transmitted over the data connection should that file be transmitted. This value will change depending on the current STRUcture, MODE, and TYPE of the data connection or of a data connection that would be created were one created now. Thus, the result of the SIZE command is dependent on the currently established STRU, MODE, and TYPE parameters.
FTPコマンドSIZE OF FILE（SIZE）は、サーバーFTPプロセスからファイルの転送サイズを取得するために使用されます。これは、そのファイルが送信された場合にデータ接続を介して送信されるオクテット（8ビットバイト）の正確な数です。この値は、データ接続または現在作成されているデータ接続の現在のSTRUcture、MODE、およびTYPEに応じて変化します。したがって、SIZEコマンドの結果は、現在確立されているSTRU、MODE、およびTYPEパラメーターに依存します。
The SIZE command returns how many octets would be transferred if the file were to be transferred using the current transfer structure, mode, and type. This command is normally used in conjunction with the RESTART (REST) command when STORing a file to a remote server in STREAM mode, to determine the restart point. The server-PI might need to read the partially transferred file, do any appropriate conversion, and count the number of octets that would be generated when sending the file in order to correctly respond to this command. Estimates of the file transfer size MUST NOT be returned; only precise information is acceptable.
SIZEコマンドは、ファイルが現在の転送構造、モード、およびタイプを使用して転送される場合、転送されるオクテットの数を返します。このコマンドは通常、再起動ポイントを決定するために、STREAMモードでリモートサーバーにファイルを格納するときにRESTART（REST）コマンドと組み合わせて使用されます。サーバーPIは、このコマンドに正しく応答するために、部分的に転送されたファイルを読み取り、適切な変換を行い、ファイルの送信時に生成されるオクテットの数を数える必要がある場合があります。ファイル転送サイズの推定値を返してはいけません。正確な情報のみが許容されます。
The syntax of the SIZE command is:
SIZEコマンドの構文は次のとおりです。
size = "Size" SP pathname CRLF
サイズ= "サイズ" SPパス名CRLF
The server-PI will respond to the SIZE command with a 213 reply giving the transfer size of the file whose pathname was supplied, or an error response if the file does not exist, the size is unavailable, or some other error has occurred. The value returned is in a format suitable for use with the RESTART (REST) command for mode STREAM, provided the transfer mode and type are not altered.
server-PIはSIZEコマンドに応答して、パス名が指定されたファイルの転送サイズを示す213応答を返します。ファイルが存在しない、サイズが利用できない、またはその他のエラーが発生した場合は、エラー応答を返します。返される値は、転送モードとタイプが変更されていなければ、モードSTREAMのRESTART（REST）コマンドでの使用に適した形式です。
size-response = "213" SP 1*DIGIT CRLF / error-response
size-response = "213" SP 1 * DIGIT CRLF / error-response
Note that when the 213 response is issued, that is, when there is no error, the format MUST be exactly as specified. Multi-line responses are not permitted.
213応答が発行された場合、つまりエラーがない場合、形式は指定されたとおりでなければならないことに注意してください。複数行の応答は許可されていません。
Where the command is correctly parsed but the size is not available, perhaps because the pathname identifies no existing entity or because the entity named cannot be transferred in the current MODE and TYPE (or at all), then a 550 reply should be sent. Where the command cannot be correctly parsed, a 500 or 501 reply should be sent, as specified in [3]. The presence of the 550 error response to a SIZE command MUST NOT be taken by the client as an indication that the file cannot be transferred in the current MODE and TYPE. A server may generate this error for other reasons -- for instance if the processing overhead is considered too great. Various 4xy replies are also possible in appropriate circumstances.
コマンドが正しく解析されてもサイズが利用できない場合、おそらくパス名が既存のエンティティを識別していないか、指定されたエンティティを現在のMODEおよびTYPEで転送できない（またはまったく）ことができないため、550応答を送信する必要があります。コマンドを正しく解析できない場合は、[3]で指定されているように、500または501の応答を送信する必要があります。 SIZEコマンドに対する550エラー応答の存在は、クライアントが、現在のモードとタイプでファイルを転送できないことを示すものであってはなりません。サーバーは、他の理由でこのエラーを生成する可能性があります。たとえば、処理のオーバーヘッドが大きすぎると考えられる場合などです。適切な状況では、さまざまな4xy応答も可能です。
When replying to the FEAT command [6], a server-FTP process that supports the SIZE command MUST include a line containing the single word "SIZE". This word is case insensitive, and MAY be sent in any mixture of upper or lower case, however it SHOULD be sent in upper case. That is, the response SHOULD be:
FEATコマンド[6]に応答する場合、SIZEコマンドをサポートするサーバーFTPプロセスには、「SIZE」という単一の単語を含む行を含める必要があります。この単語は大文字と小文字を区別せず、大文字と小文字を混在させて送信できますが、大文字で送信する必要があります（SHOULD）。つまり、応答は次のようにする必要があります。
C> FEAT
S> 211- <any descriptive text>
S> ...
S> SIZE
S> ...
S> 211 END
The ellipses indicate place holders where other features may be included, and are not required. The one-space indentation of the feature lines is mandatory [6].
楕円は、他の機能を含めることができるプレースホルダーを示しており、必須ではありません。計画線の1スペースのインデントは必須です[6]。
Consider a text file "Example" stored on a Unix(TM) server where each end of line is represented by a single octet. Assume the file contains 112 lines, and 1830 octets total. Then the SIZE command would produce:
行の各端が単一のオクテットで表されているUnix（TM）サーバーに保存されているテキストファイル「例」を考えてみましょう。ファイルに112行、合計1830オクテットが含まれていると仮定します。次に、SIZEコマンドは以下を生成します。
C> TYPE I S> 200 Type set to I. C> size Example S> 213 1830 C> TYPE A S> 200 Type set to A. C> Size Example S> 213 1942
C>タイプI S> 200タイプをIに設定。C>サイズの例S> 213 1830 C>タイプA S> 200タイプをAに設定。C>サイズの例S> 213 1942
Notice that with TYPE=A the SIZE command reports an extra 112 octets. Those are the extra octets that need to be inserted, one at the end of each line, to provide correct end-of-line semantics for a transfer using TYPE=A. Other systems might need to make other changes to the transfer format of files when converting between TYPEs and MODEs. The SIZE command takes all of that into account.
TYPE = Aを指定すると、SIZEコマンドが余分な112オクテットを報告することに注意してください。これらは、TYPE = Aを使用した転送に正しい行末セマンティクスを提供するために、各行の終わりに1つずつ挿入する必要がある追加のオクテットです。他のシステムでは、TYPEとMODEの間で変換するときに、ファイルの転送フォーマットに他の変更を加える必要がある場合があります。 SIZEコマンドはそれらすべてを考慮に入れます。
Since calculating the size of a file with this degree of precision may take considerable effort on the part of the server-PI, user-PIs should not used this command unless this precision is essential (such as when about to restart an interrupted transfer). For other uses, the "Size" fact of the MLST command (see section 7.5.7) ought be requested.
この精度でファイルのサイズを計算するには、サーバーPIの側でかなりの労力がかかる場合があるため、この精度が不可欠でない限り（中断された転送を再開するときなど）、ユーザーPIはこのコマンドを使用しないでください。その他の用途では、MLSTコマンドの「サイズ」ファクト（セクション7.5.7を参照）を要求する必要があります。
To avoid having to resend the entire file if the file is only partially transferred, both sides need some way to agree on where in the data stream to restart the data transfer.
ファイルが部分的にしか転送されない場合にファイル全体を再送信する必要がないようにするには、両側で、データストリームのどこにデータ転送を再開するかについて合意する方法が必要です。
The FTP specification [3] includes three modes of data transfer, STREAM, Block, and Compressed. In Block and Compressed modes, the data stream that is transferred over the data connection is formatted, allowing the embedding of restart markers into the stream. The sending DTP can include a restart marker with whatever information it needs to be able to restart a file transfer at that point. The receiving DTP can keep a list of these restart markers, and correlate them with how the file is being saved. To restart the file transfer, the receiver just sends back that last restart marker, and both sides know how to resume the data transfer. Note that there are some flaws in the description of the restart mechanism in STD 9, RFC 959 [3]. See section 4.1.3.4 of RFC 1123 [9] for the corrections.
FTP仕様[3]には、STREAM、Block、Compressedの3つのデータ転送モードが含まれています。ブロックモードと圧縮モードでは、データ接続を介して転送されるデータストリームがフォーマットされ、ストリームにリスタートマーカーを埋め込むことができます。送信DTPには、その時点でファイル転送を再開するために必要なすべての情報を含む再開マーカーを含めることができます。受信側のDTPは、これらのリスタートマーカーのリストを保持し、それらをファイルの保存方法と関連付けることができます。ファイル転送を再開するために、受信機はその最後の再開マーカーを送り返すだけで、両側はデータ転送を再開する方法を知っています。 STD 9、RFC 959 [3]の再起動メカニズムの説明にいくつかの欠陥があることに注意してください。修正については、RFC 1123 [9]のセクション4.1.3.4を参照してください。
In STREAM mode, the data connection contains just a stream of unformatted octets of data. Explicit restart markers thus cannot be inserted into the data stream, they would be indistinguishable from data. For this reason, the FTP specification [3] did not provide the ability to do restarts in stream mode. However, there is not really a need to have explicit restart markers in this case, as restart markers can be implied by the octet offset into the data stream.
STREAMモードでは、データ接続にはフォーマットされていないオクテットのデータのストリームのみが含まれます。したがって、明示的なリスタートマーカーをデータストリームに挿入することはできず、データと区別がつかなくなります。このため、FTP仕様[3]は、ストリームモードで再起動する機能を提供していませんでした。ただし、再始動マーカーはデータストリームへのオクテットオフセットによって暗示される可能性があるため、この場合は実際には明示的な再始動マーカーを用意する必要はありません。
Because the data stream defines the file in STREAM mode, a different data stream would represent a different file. Thus, an offset will always represent the same position within a file. On the other hand, in other modes than STREAM, the same file can be transferred using quite different octet sequences and yet be reconstructed into the one identical file. Thus an offset into the data stream in transfer modes other than STREAM would not give an unambiguous restart point.
データストリームはSTREAMモードでファイルを定義するため、異なるデータストリームは異なるファイルを表します。したがって、オフセットは常にファイル内の同じ位置を表します。一方、STREAM以外のモードでは、まったく異なるオクテットシーケンスを使用して同じファイルを転送できますが、同じファイルに再構築できます。したがって、STREAM以外の転送モードでのデータストリームへのオフセットは、明確な再開ポイントを提供しません。
If the data representation TYPE is IMAGE and the STRUcture is File, for many systems the file will be stored exactly in the same format as it is sent across the data connection. It is then usually very easy for the receiver to determine how much data was previously received, and notify the sender of the offset where the transfer should be restarted. In other representation types and structures more effort will be required, but it remains always possible to determine the offset with finite, but perhaps non-negligible, effort. In the worst case, an FTP process may need to open a data connection to itself, set the appropriate transfer type and structure, and actually transmit the file, counting the transmitted octets.
データ表現TYPEがIMAGEでSTRUctureがFileの場合、多くのシステムでは、ファイルはデータ接続を介して送信されるときとまったく同じ形式で格納されます。これにより、通常、受信者が以前に受信したデータの量を判断し、転送を再開するオフセットを送信者に通知するのが非常に簡単になります。他の表現タイプと構造では、より多くの労力が必要になりますが、有限の、おそらく無視できない労力でオフセットを決定することは常に可能です。最悪の場合、FTPプロセスはそれ自体へのデータ接続を開き、適切な転送タイプと構造を設定し、実際にファイルを送信して、送信されたオクテットを数える必要があります。
If the user-FTP process is intending to restart a retrieve, it will directly calculate the restart marker and send that information in the RESTart command. However, if the user-FTP process is intending to restart sending the file, it needs to be able to determine how much data was previously sent, and correctly received and saved. A new FTP command is needed to get this information. This is the purpose of the SIZE command, as documented in section 4.
ユーザーFTPプロセスがリトリーブを再開しようとしている場合は、リスタートマーカーを直接計算し、その情報をRESTartコマンドで送信します。ただし、ユーザーFTPプロセスがファイルの送信を再開しようとしている場合は、以前に送信され、正しく受信および保存されたデータの量を判別できる必要があります。この情報を取得するには、新しいFTPコマンドが必要です。これは、セクション4で説明されているように、SIZEコマンドの目的です。
STREAM mode transfers with FILE STRUcture may be restarted even though no restart marker has been transferred in addition to the data itself. This is done by using the SIZE command, if needed, in combination with the RESTART (REST) command, and one of the standard file transfer commands.
データ自体に加えてリスタートマーカーが転送されていなくても、FILE STRUctureを使用したSTREAMモードの転送が再開される場合があります。これは、必要に応じて、SIZEコマンドをRESTART（REST）コマンドと標準のファイル転送コマンドの1つと組み合わせて使用することによって行われます。
When using TYPE ASCII or IMAGE, the SIZE command will return the number of octets that would actually be transferred if the file were to be sent between the two systems, i.e., with type IMAGE, the SIZE normally would be the number of octets in the file. With type ASCII, the SIZE would be the number of octets in the file including any modifications required to satisfy the TYPE ASCII CR-LF end-of-line convention.
TYPE ASCIIまたはIMAGEを使用する場合、SIZEコマンドは、ファイルが2つのシステム間で送信される場合に実際に転送されるオクテットの数を返します。つまり、IMAGEタイプの場合、SIZEは通常、ファイル。 ASCIIタイプの場合、SIZEはTYPE ASCII CR-LF行末規則を満たすために必要な変更を含む、ファイル内のオクテットの数になります。
The syntax for the REST command when the current transfer mode is STREAM is:
現在の転送モードがSTREAMの場合のRESTコマンドの構文は次のとおりです。
rest = "Rest" SP 1*DIGIT CRLF
rest = "Rest" SP 1 * DIGIT CRLF
The numeric value gives the number of octets of the immediately-following transfer to not actually send, effectively causing the transmission to be restarted at a later point. A value of zero effectively disables restart, causing the entire file to be transmitted. The server-PI will respond to the REST command with a 350 reply, indicating that the REST parameter has been saved, and that another command, which should be either RETR or STOR, should then follow to complete the restart.
数値は、実際に送信しない、直後の転送のオクテット数を示します。これにより、送信が後で再開されます。値を0にすると、再起動が実質的に無効になり、ファイル全体が送信されます。 server-PIはRESTコマンドに350応答で応答します。これは、RESTパラメータが保存されたこと、およびRETRまたはSTORのいずれかである必要がある別のコマンドが再起動を完了するために実行する必要があることを示します。
rest-response = "350" SP *TCHAR CRLF / error-response
rest-response = "350" SP * TCHAR CRLF /エラー応答
Server-FTP processes may permit transfer commands other than RETR and STOR, such as APPE and STOU, to complete a restart; however, this is not recommended. STOU (store unique) is undefined in this usage, as storing the remainder of a file into a unique file name is rarely going to be useful. If APPE (append) is permitted, it MUST act identically to STOR when a restart marker has been set. That is, in both cases, octets from the data connection are placed into the file at the location indicated by the restart marker value.
サーバーFTPプロセスでは、APPEやSTOUなどのRETRおよびSTOR以外の転送コマンドが再起動を完了することを許可する場合があります。ただし、これは推奨されません。 STOU（一意のストア）はこの使用法では定義されていません。ファイルの残りの部分を一意のファイル名に格納することはほとんど役に立ちません。 APPE（追加）が許可されている場合、再起動マーカーが設定されている場合、STORと同じように動作する必要があります。つまり、どちらの場合でも、データ接続からのオクテットは、ファイルのリスタートマーカー値で示される場所に配置されます。
The REST command is intended to complete a failed transfer. Use with RETR is comparatively well defined in all cases, as the client bears the responsibility of merging the retrieved data with the partially retrieved file. It may choose to use the data obtained other than to complete an earlier transfer, or to re-retrieve data that had been retrieved before. With STOR, however, the server must insert the data into the file named. The results are undefined if a client uses REST to do other than restart to complete a transfer of a file that had previously failed to completely transfer. In particular, if the restart marker set with a REST command is not at the end of the data currently stored at the server, as reported by the server, or if insufficient data are provided in a STOR that follows a REST to extend the destination file to at least its previous size, then the effects are undefined.
RESTコマンドは、失敗した転送を完了することを目的としています。取得したデータを部分的に取得したファイルとマージする責任はクライアントが負うため、RETRでの使用はすべてのケースで比較的明確に定義されています。取得したデータを使用して、以前の転送を完了するか、以前に取得したデータを再取得するかを選択できます。ただし、STORでは、サーバーは指定されたファイルにデータを挿入する必要があります。以前に完全に転送できなかったファイルの転送を完了するために、クライアントが再起動以外の目的でRESTを使用する場合、結果は未定義です。特に、RESTコマンドで設定された再起動マーカーが、サーバーによって報告されているように、現在サーバーに格納されているデータの最後にない場合、または宛先ファイルを拡張するためにRESTに続くSTORで提供されるデータが不十分な場合少なくとも前のサイズにすると、効果は未定義になります。
The REST command must be the last command issued before the data transfer command that is to cause a restarted, rather than a complete, file transfer. The effect of issuing a REST command at any other time is undefined. The server-PI may react to a badly positioned REST command by issuing an error response to the following command, not being a restartable data transfer command, or it may save the restart value and apply it to the next data transfer command, or it may silently ignore the inappropriate restart attempt. Because of this, a user-PI that has issued a REST command, but that has not successfully transmitted the following data transfer command for any reason, should send another REST command before the next data transfer command. If that transfer is not to be restarted, then "REST 0" should be issued.
RESTコマンドは、データ転送コマンドの前に発行される最後のコマンドである必要があります。これにより、完全なファイル転送ではなく、再起動が行われます。それ以外のときにRESTコマンドを発行した場合の影響は定義されていません。 server-PIは、再起動可能なデータ転送コマンドではなく、次のコマンドにエラー応答を発行することにより、不適切に配置されたRESTコマンドに反応するか、再起動値を保存して次のデータ転送コマンドに適用するか、または不適切な再起動の試みを黙って無視します。このため、RESTコマンドを発行したが、何らかの理由で次のデータ転送コマンドを正常に送信しなかったユーザーPIは、次のデータ転送コマンドの前に別のRESTコマンドを送信する必要があります。その転送を再開しない場合は、「REST 0」を発行する必要があります。
An error response will follow a REST command only when the server does not implement the command, or when the restart marker value is syntactically invalid for the current transfer mode (e.g., in STREAM mode, something other than one or more digits appears in the parameter to the REST command). Any other errors, including such problems as restart marker out of range, should be reported when the following transfer command is issued. Such errors will cause that transfer request to be rejected with an error indicating the invalid restart attempt.
エラー応答は、サーバーがコマンドを実装していない場合、または現在の転送モードで構文的にリスタートマーカーの値が無効な場合（たとえば、ストリームモードでは、パラメーターに1桁以上の数字以外が表示される場合）にのみRESTコマンドに従います。 RESTコマンドに）。範囲外のリスタートマーカーなどの問題を含むその他のエラーは、次の転送コマンドが発行されたときに報告する必要があります。このようなエラーが発生すると、その転送要求は拒否され、無効な再起動の試みを示すエラーが発生します。
Where a server-FTP process supports RESTart in STREAM mode, as specified here, it MUST include, in the response to the FEAT command [6], a line containing exactly the string "REST STREAM". This string is not case sensitive, but it SHOULD be transmitted in upper case. Where REST is not supported at all or supported only in block or compressed modes, the REST line MUST NOT be included in the FEAT response. Where required, the response SHOULD be:
ここで指定されているように、サーバーFTPプロセスがストリームモードでRESTartをサポートしている場合、FEATコマンドへの応答[6]に、文字列「REST STREAM」を正確に含む行を含める必要があります。この文字列は大文字と小文字を区別しませんが、大文字で送信する必要があります。 RESTがまったくサポートされていないか、ブロックモードまたは圧縮モードでのみサポートされている場合、REST行をFEAT応答に含めることはできません。必要な場合、応答は次のようにする必要があります。
C> feat
S> 211- <any descriptive text>
S> ...
S> REST STREAM
S> ...
S> 211 end
The ellipses indicate place holders where other features may be included, and are not required. The one-space indentation of the feature lines is mandatory [6].
楕円は、他の機能を含めることができるプレースホルダーを示しており、必須ではありません。計画線の1スペースのインデントは必須です[6]。
Assume that the transfer of a largish file has previously been interrupted after 802816 octets had been received, that the previous transfer was with TYPE=I, and that it has been verified that the file on the server has not since changed.
802816オクテットが受信された後、大量のファイルの転送が以前に中断され、前回の転送がTYPE = Iで行われ、サーバー上のファイルが変更されていないことが確認されたと想定します。
C> TYPE I S> 200 Type set to I. C> PORT 127,0,0,1,15,107 S> 200 PORT command successful. C> REST 802816 S> 350 Restarting at 802816. Send STORE or RETRIEVE C> RETR cap60.pl198.tar S> 150 Opening BINARY mode data connection [...] S> 226 Transfer complete.
C>タイプI S> 200タイプがIに設定されています。C>ポート127,0,0,1,15,107 S> 200ポートコマンドが成功しました。 C> REST 802816 S> 350 802816で再起動します。STOREまたはRETRIEVEを送信しますC> RETR cap60.pl198.tar S> 150 BINARYモードのデータ接続を開いています[...] S> 226転送が完了しました。
Traditionally, FTP has placed almost no constraints upon the file store (NVFS) provided by a server. This specification does not alter that. However, it has become common for servers to attempt to provide at least file system naming conventions modeled loosely upon those of the UNIX(TM) file system. This is a tree-structured file system, built of directories, each of which can contain other directories, or other kinds of files, or both. Each file and directory has a name relative to the directory that contains it, except for the directory at the root of the tree, which is contained in no other directory, and hence has no name of its own.
従来、FTPはサーバーによって提供されるファイルストア（NVFS）にほとんど制約を課していませんでした。この仕様はそれを変更しません。ただし、サーバーが少なくともUNIX（TM）ファイルシステムの命名規則を大まかにモデル化したファイルシステム命名規則を提供しようとすることが一般的になっています。これは、ツリー構造のファイルシステムであり、ディレクトリで構成されています。各ディレクトリには、他のディレクトリまたは他の種類のファイル、あるいはその両方を含めることができます。各ファイルとディレクトリは、ツリーのルートにあるディレクトリを除き、それを含むディレクトリに相対的な名前を持っています。これは、他のディレクトリに含まれていないため、独自の名前はありません。
That which has so far been described is perfectly consistent with the standard FTP NVFS and access mechanisms. The "CWD" command is used to move from one directory to an embedded directory. "CDUP" may be provided to return to the parent directory, and the various file manipulation commands ("RETR", "STOR", the rename commands, etc.) are used to manipulate files within the current directory.
これまで説明してきたことは、標準のFTP NVFSおよびアクセスメカニズムと完全に一致しています。 「CWD」コマンドは、1つのディレクトリから埋め込みディレクトリに移動するために使用されます。 「CDUP」は親ディレクトリに戻るために提供され、さまざまなファイル操作コマンド（「RETR」、「STOR」、名前変更コマンドなど）は、現在のディレクトリ内のファイルを操作するために使用されます。
However, it is often useful to be able to reference files other than by changing directories, especially as FTP provides no guaranteed mechanism to return to a previous directory. The Trivial Virtual File Store (TVFS), if implemented, provides that mechanism.
ただし、特にFTPには以前のディレクトリに戻る保証されたメカニズムがないため、ディレクトリを変更する以外の方法でファイルを参照できると便利な場合があります。 Trivial Virtual File Store（TVFS）が実装されている場合は、そのメカニズムが提供されます。
Where a server implements the TVFS, no elementary file name shall contain the character "/". Where the underlying natural file store permits files, or directories, to contain the "/" character in their names, a server-PI implementing TVFS must encode that character in some manner whenever file or directory names are being returned to the user-PI, and reverse that encoding whenever such names are being accepted from the user-PI.
サーバーがTVFSを実装する場合、基本ファイル名に文字「/」を含めないでください。基になるナチュラルファイルストアがファイルまたはディレクトリの名前に「/」文字を含めることを許可している場合、TV-FSを実装するサーバーPIは、ファイルまたはディレクトリ名がユーザーPIに返されるときは常に、その文字を何らかの方法でエンコードする必要があります。そして、そのような名前がユーザーPIから受け入れられるときはいつでも、そのエンコードを逆にします。
The encoding method to be used is not specified here. Where some other character is illegal in file and directory names in the underlying file store, a simple transliteration may be sufficient. Where there is no suitable substitute character a more complex encoding scheme, possibly using an escape character, is likely to be required.
使用するエンコード方式はここでは指定しません。基になるファイルストアのファイル名とディレクトリ名に他の文字が無効な場合は、単純な音訳で十分な場合があります。適切な代替文字がない場合は、エスケープ文字を使用するなど、より複雑なエンコード方式が必要になる可能性があります。
With the one exception of the unnamed root directory, a TVFS file name may not be empty. That is, all other file names contain at least one character.
名前のないルートディレクトリを除いて、TVFSファイル名は空にできません。つまり、他のすべてのファイル名には少なくとも1文字が含まれます。
With the sole exception of the "/" character, any valid IS10646 character [10] may be used in a TVFS file name. When transmitted, file name characters are encoded using the UTF-8 encoding [2]. Note that the two-character sequence CR LF occurring in a file name will make that name impossible to transmit over a data connection. Consequently, it should be avoided, or if that is impossible to achieve, it MUST be encoded in some reversible way.
「/」文字を除いて、有効なIS10646文字[10]をTVFSファイル名に使用できます。送信されると、ファイル名文字はUTF-8エンコーディング[2]を使用してエンコードされます。ファイル名に2文字のシーケンスCR LFが含まれていると、その名前がデータ接続で送信できなくなることに注意してください。その結果、それは避けられるべきです、またはそれが達成できないならば、それは何らかの可逆的な方法でエンコードされなければなりません。
A TVFS "Pathname" combines the file or directory name of a target file or directory, with the directory names of zero or more enclosing directories, so as to allow the target file or directory to be referenced other than when the server's "current working directory" is the directory directly containing the target file or directory.
TVFSの「パス名」は、ターゲットファイルまたはディレクトリのファイル名またはディレクトリ名と、0個以上の包含ディレクトリのディレクトリ名を組み合わせて、サーバーの「現在の作業ディレクトリ」以外の場合にターゲットファイルまたはディレクトリを参照できるようにします。 "は、ターゲットファイルまたはディレクトリを直接含むディレクトリです。
By definition, every TVFS file or directory name is also a TVFS pathname. Such a pathname is valid to reference the file from the directory containing the name, that is, when that directory is the server-FTP's current working directory.
定義により、すべてのTVFSファイルまたはディレクトリ名もTVFSパス名です。このようなパス名は、名前を含むディレクトリからファイルを参照するのに有効です。つまり、そのディレクトリがサーバーFTPの現在の作業ディレクトリである場合です。
Other TVFS pathnames are constructed by prefixing a pathname by a name of a directory from which the path is valid, and separating the two with the "/" character. Such a pathname is valid to reference the file or directory from the directory containing the newly added directory name.
他のTVFSパス名は、パスが有効であるディレクトリの名前をパス名の前に付け、2つを「/」文字で区切ることによって構築されます。このようなパス名は、新しく追加されたディレクトリ名を含むディレクトリからファイルまたはディレクトリを参照するのに有効です。
Where a pathname has been extended to the point where the directory added is the unnamed root directory, the pathname will begin with the "/" character. Such a path is known as a fully qualified pathname. Fully qualified paths may, obviously, not be further extended, as, by definition, no directory contains the root directory. Being unnamed, it cannot be represented in any other directory. A fully qualified pathname is valid to reference the named file or directory from any location (that is, regardless of what the current working directory may be) in the virtual file store.
追加されたディレクトリが名前のないルートディレクトリになるまでパス名が拡張されている場合、パス名は「/」文字で始まります。このようなパスは、完全修飾パス名と呼ばれます。定義上、ルートディレクトリを含むディレクトリはないため、完全修飾パスは明らかに拡張できません。名前が付いていないため、他のディレクトリで表すことはできません。完全修飾パス名は、仮想ファイルストア内の任意の場所から（つまり、現在の作業ディレクトリが何であるかに関係なく）指定されたファイルまたはディレクトリを参照するのに有効です。
Any pathname that is not a fully qualified pathname may be referred to as a "relative pathname" and will only correctly reference the intended file when the current working directory of the server-FTP is a directory from which the relative pathname is valid.
完全修飾パス名ではないパス名は「相対パス名」と呼ばれ、サーバーFTPの現在の作業ディレクトリが相対パス名が有効なディレクトリである場合にのみ、目的のファイルを正しく参照します。
As a special case, the pathname "/" is defined to be a fully qualified pathname referring to the root directory. That is, the root directory does not have a directory (or file) name, but does have a pathname. This special pathname may be used only as is as a reference to the root directory. It may not be combined with other pathnames using the rules above, as doing so would lead to a pathname containing two consecutive "/" characters, which is an undefined sequence.
特殊なケースとして、パス名「/」は、ルートディレクトリを参照する完全修飾パス名として定義されます。つまり、ルートディレクトリにはディレクトリ（またはファイル）の名前はありませんが、パス名はあります。この特別なパス名は、ルートディレクトリへの参照としてのみ使用できます。上記のルールを使用して他のパス名と組み合わせることはできません。これを行うと、未定義のシーケンスである2つの連続する「/」文字を含むパス名につながるためです。
+ It is not required, or expected, that there be only one fully qualified pathname that will reference any particular file or directory.
+ 特定のファイルまたはディレクトリを参照する完全修飾パス名が1つだけである必要はありません。
+ As a caveat, though the TVFS file store is basically tree structured, there is no requirement that any file or directory have only one parent directory.
+ 注意点として、TVFSファイルストアは基本的にツリー構造ですが、ファイルやディレクトリに親ディレクトリが1つしかないという要件はありません。
+ As defined, no TVFS pathname will ever contain two consecutive "/" characters. Such a name is not illegal however, and may be defined by the server for any purpose that suits it. Clients implementing this specification should not assume any semantics for such names.
+ 定義されているとおり、TVFSパス名に2つの連続する「/」文字が含まれることはありません。ただし、このような名前は違法ではなく、適切な目的でサーバーによって定義される場合があります。この仕様を実装するクライアントは、そのような名前のセマンティクスを想定しないでください。
+ Similarly, other than the special case path that refers to the root directory, no TVFS pathname constructed as defined here will ever end with the "/" character. Such names are also not illegal, but are undefined.
+ 同様に、ルートディレクトリを参照する特別な場合のパスを除いて、ここで定義されているように構築されたTVFSパス名は、「/」文字で終わりません。このような名前も違法ではありませんが、定義されていません。
+ While any legal IS10646 character is permitted to occur in a TVFS file or directory name, other than "/", server FTP implementations are not required to support all possible IS10646 characters. The subset supported is entirely at the discretion of the server. The case (where it exists) of the characters that make up file, directory, and pathnames may be significant. Unless determined otherwise by means unspecified here, clients should assume that all such names are comprised of characters whose case is significant. Servers are free to treat case (or any other attribute) of a name as irrelevant, and hence map two names that appear to be distinct onto the same underlying file.
+ "/"以外の有効なIS10646文字をTVFSファイルまたはディレクトリ名で使用することは許可されていますが、サーバーのFTP実装は、可能なすべてのIS10646文字をサポートする必要はありません。サポートされるサブセットは、完全にサーバーの裁量に任されています。ファイル、ディレクトリ、およびパス名を構成する文字の大文字と小文字（存在する場合）は重要な場合があります。ここで明記されていない手段で別段の定めがない限り、クライアントは、そのような名前はすべて大文字と小文字が区別される文字で構成されていると想定する必要があります。サーバーは、名前の大文字と小文字（またはその他の属性）を無関係として扱うことができるため、異なるように見える2つの名前を同じ基本ファイルにマッピングします。
+ There are no defined "magic" names, like ".", ".." or "C:". Servers may implement such names, with any semantics they choose, but are not required to do so.
+ 「。」、「..」、「C：」などの「マジック」名は定義されていません。サーバーは、選択したセマンティクスでそのような名前を実装できますが、そうする必要はありません。
+ TVFS imposes no particular semantics or properties upon files, guarantees no access control schemes, or any of the other common properties of a file store. Only the naming scheme is defined.
+ TVFSは、ファイルに特定のセマンティクスやプロパティを課すことはなく、アクセス制御スキームやファイルストアの他の一般的なプロパティを保証しません。命名方式のみが定義されています。
In response to the FEAT command [6] a server that wishes to indicate support for the TVFS as defined here will include a line that begins with the four characters "TVFS" (in any case, or mixture of cases, upper case is not required). Servers SHOULD send upper case.
FEATコマンド[6]に応じて、ここで定義されているTVFSのサポートを示すサーバーには、4文字の「TVFS」で始まる行が含まれます（いずれの場合でも、または大文字と小文字の混合でも、大文字は不要です） ）。サーバーは大文字を送信する必要があります。
Such a response to the FEAT command MUST NOT be returned unless the server implements TVFS as defined here.
ここで定義されているようにサーバーがTVFSを実装していない限り、FEATコマンドに対するそのような応答は返されてはなりません（MUST NOT）。
Later specifications may add to the TVFS definition. Such additions should be notified by means of additional text appended to the TVFS feature line. Such specifications, if any, will define the extra text.
後で仕様がTVFS定義に追加される場合があります。そのような追加は、TVFS機能行に追加された追加のテキストによって通知される必要があります。そのような仕様があれば、追加のテキストを定義します。
Until such a specification is defined, servers should not include anything after "TVFS" in the TVFS feature line. Clients, however, should be prepared to deal with arbitrary text following the four defined characters, and simply ignore it if unrecognized.
そのような仕様が定義されるまで、サーバーはTVFS機能ラインの「TVFS」の後に何も含めるべきではありません。ただし、クライアントは、定義された4つの文字に続く任意のテキストを処理できるように準備し、認識されない場合は無視する必要があります。
A typical response to the FEAT command issued by a server implementing only this specification would be:
この仕様のみを実装するサーバーによって発行されたFEATコマンドに対する典型的な応答は次のとおりです。
C> feat
S> 211- <any descriptive text>
S> ...
S> TVFS
S> ...
S> 211 end
The ellipses indicate place holders where other features may be included, but are not required. The one-space indentation of the feature lines is mandatory [6] and is not counted as one of the first four characters for the purposes of this feature listing.
省略記号は、他の機能を含めることができるプレースホルダーを示していますが、必須ではありません。計画線の1スペースのインデントは必須[6]であり、この特徴リストでは最初の4文字の1つとして数えられません。
The TVFS feature adds no new commands to the FTP command repertoire.
TVFS機能は、FTPコマンドのレパートリーに新しいコマンドを追加しません。
There are no options in this TVFS specification, and hence there is no OPTS command defined.
このTVFS仕様にはオプションがないため、OPTSコマンドは定義されていません。
Assume a TVFS file store is comprised of a root directory, which contains two directories (A and B) and two non-directory files (X and Y). The A directory contains two directories (C and D) and one other file (Z). The B directory contains just two non-directory files (P and Q) and the C directory also two non-directory files (also named P and Q, by chance). The D directory is empty, that is, contains no files or directories. This structure may depicted graphically as...
TVFSファイルストアは、2つのディレクトリ（AおよびB）と2つの非ディレクトリファイル（XおよびY）を含むルートディレクトリで構成されていると想定します。 Aディレクトリーには、2つのディレクトリー（CおよびD）および1つの他のファイル（Z）が含まれています。 Bディレクトリには2つの非ディレクトリファイル（PとQ）だけが含まれ、Cディレクトリには2つの非ディレクトリファイル（偶然にPとQとも呼ばれます）も含まれます。 Dディレクトリは空です。つまり、ファイルやディレクトリが含まれていません。この構造は、次のようにグラフィカルに表すことができます...
(unnamed root)
/ | \ \
/ | \ \
A X B Y
/|\ / \
/ | \ / \
C D Z P Q
/ \
/ \
P Q
Given this structure, the following fully qualified pathnames exist.
この構造を前提として、次の完全修飾パス名が存在します。
/
/A
/B
/X
/Y
/A/C
/A/D
/A/Z
/A/C/P
/A/C/Q
/B/P
/B/Q
It is clear that none of the paths / /A /B or /A/D refer to the same
directory, as the contents of each is different. Nor do any of / /A
/A/C or /A/D. However /A/C and /B might be the same directory, there
is insufficient information given to tell. Any of the other
pathnames (/X /Y /A/Z /A/C/P /A/C/Q /B/P and /B/Q) may refer to the
same underlying files, in almost any combination.
If the current working directory of the server-FTP is /A then the following pathnames, in addition to all the fully qualified pathnames, are valid
サーバーFTPの現在の作業ディレクトリが/ Aの場合、すべての完全修飾パス名に加えて、次のパス名が有効です。
C D Z C/P C/Q
C D Z C / P C / Q
These all refer to the same files or directories as the corresponding fully qualified path with "/A/" prepended.
これらはすべて、 "/ A /"を前に付加した対応する完全修飾パスと同じファイルまたはディレクトリを参照します。
That those pathnames all exist does not imply that the TVFS sever will necessarily grant any kind of access rights to the named paths, or that access to the same file via different pathnames will necessarily be granted equal rights.
これらのパス名がすべて存在するということは、TVFSサーバーが名前付きパスへのあらゆる種類のアクセス権を必ずしも付与すること、または異なるパス名を介して同じファイルへのアクセス権が必然的に同等の権利を付与されることを意味しません。
None of the following relative paths are valid when the current directory is /A
現在のディレクトリが/ Aの場合、次の相対パスはいずれも無効です
A B X Y B/P B/Q P Q
A B X Y B / P B / Q P Q
Any of those could be made valid by changing the server-FTP's current working directory to the appropriate directory. Note that the paths "P" and "Q" might refer to different files depending upon which directory is selected to cause those to become valid TVFS relative paths.
サーバーFTPの現在の作業ディレクトリを適切なディレクトリに変更することで、これらのいずれも有効にすることができます。パス「P」と「Q」は、有効なTVFS相対パスになるように選択されたディレクトリに応じて、異なるファイルを参照する場合があることに注意してください。
The MLST and MLSD commands are intended to standardize the file and directory information returned by the server-FTP process. These commands differ from the LIST command in that the format of the replies is strictly defined although extensible.
MLSTおよびMLSDコマンドは、サーバーFTPプロセスによって返されるファイルおよびディレクトリ情報を標準化することを目的としています。これらのコマンドは、応答のフォーマットが拡張可能ですが厳密に定義されているという点でLISTコマンドとは異なります。
Two commands are defined, MLST and MLSD. MLST provides data about exactly the object named on its command line, and no others. MLSD, on the other, lists the contents of a directory if a directory is named, otherwise a 501 reply is returned. In either case, if no object is named, the current directory is assumed. That will cause MLST to send a one-line response, describing the current directory itself, and MLSD to list the contents of the current directory.
MLSTとMLSDの2つのコマンドが定義されています。 MLSTは、コマンドラインで指定されたオブジェクトに関するデータのみを提供し、他のオブジェクトに関するデータは提供しません。一方、MLSDは、ディレクトリに名前が付けられている場合はディレクトリの内容をリストし、そうでない場合は501応答が返されます。どちらの場合も、オブジェクトが指定されていない場合は、現在のディレクトリが想定されます。これにより、MLSTは現在のディレクトリ自体を説明する1行の応答を送信し、MLSDは現在のディレクトリの内容を一覧表示します。
In the following, the term MLSx will be used wherever either MLST or MLSD may be inserted.
以下では、MLSTまたはMLSDのどちらが挿入される場合でも、MLSxという用語が使用されます。
The MLST and MLSD commands also extend the FTP protocol as presented in STD 9, RFC 959 [3] and STD 3, RFC 1123 [9] to allow that transmission of 8-bit data over the control connection. Note this is not specifying character sets which are 8-bit, but specifying that FTP implementations are to specifically allow the transmission and reception of 8-bit bytes, with all bits significant, over the control connection. That is, all 256 possible octet values are permitted. The MLSx command allows both UTF-8/Unicode and "raw" forms as arguments, and in responses both to the MLST and MLSD commands, and all other FTP commands which take pathnames as arguments.
MLSTおよびMLSDコマンドは、STD 9、RFC 959 [3]およびSTD 3、RFC 1123 [9]で提示されているようにFTPプロトコルを拡張して、制御接続を介した8ビットデータの送信を可能にします。これは8ビットの文字セットを指定するのではなく、制御接続を介して、すべてのビットが有効な8ビットバイトの送受信をFTP実装で明確に許可することを指定することに注意してください。つまり、256個の可能なオクテット値すべてが許可されます。 MLSxコマンドでは、引数としてUTF-8 / Unicodeと「raw」形式の両方を使用できます。また、MLSTコマンドとMLSDコマンドの両方、およびパス名を引数として使用する他のすべてのFTPコマンドへの応答としても使用できます。
The MLST and MLSD commands each allow a single optional argument. This argument may be either a directory name or, for MLST only, a file name. For these purposes, a "file name" is the name of any entity in the server NVFS which is not a directory. Where TVFS is supported, any TVFS relative pathname valid in the current working directory, or any TVFS fully qualified pathname, may be given. If a directory name is given then MLSD must return a listing of the contents of the named directory, otherwise it issues a 501 reply, and does not open a data connection. In all cases for MLST, a single set of fact lines (usually a single fact line) containing the information about the named file or directory shall be returned over the control connection, without opening a data connection.
MLSTおよびMLSDコマンドはそれぞれ、単一のオプションの引数を許可します。この引数は、ディレクトリ名、またはMLSTの場合のみファイル名のいずれかです。これらの目的のために、「ファイル名」は、ディレクトリではないサーバーNVFS内のエンティティの名前です。 TVFSがサポートされている場合、現在の作業ディレクトリで有効なTVFS相対パス名、またはTVFS完全修飾パス名を指定できます。ディレクトリ名が指定されている場合、MLSDは指定されたディレクトリの内容のリストを返す必要があります。それ以外の場合、MLSDは501応答を発行し、データ接続を開きません。 MLSTのすべてのケースで、名前付きファイルまたはディレクトリに関する情報を含むファクト行の単一のセット（通常は単一のファクト行）は、データ接続を開かずに、制御接続を介して返されます。
If no argument is given then MLSD must return a listing of the contents of the current working directory, and MLST must return a listing giving information about the current working directory itself. For these purposes, the contents of a directory are whatever file or directory names (not pathnames) the server-PI will allow to be referenced when the current working directory is the directory named, and which the server-PI desires to reveal to the user-PI. Note that omitting the argument is the only defined way to obtain a listing of the current directory, unless a pathname that represents the directory happens to be known. In particular, there is no defined shorthand name for the current directory. This does not prohibit any particular server-PI implementing such a shorthand.
引数を指定しない場合、MLSDは現在の作業ディレクトリの内容のリストを返す必要があり、MLSTは現在の作業ディレクトリ自体に関する情報を示すリストを返す必要があります。これらの目的のために、ディレクトリの内容は、現在の作業ディレクトリが指定されたディレクトリであり、サーバーPIがユーザーに明らかにしたいときに、サーバーPIが参照できるファイルまたはディレクトリ名（パス名ではない）です。 -PI。ディレクトリを表すパス名がたまたまわかっていない限り、引数を省略することが現在のディレクトリのリストを取得する唯一の定義された方法であることに注意してください。特に、現在のディレクトリに定義された省略名はありません。これは、そのような省略表現を実装する特定のサーバーPIを禁止するものではありません。
No title, header, or summary, lines, or any other formatting, other than as is specified below, is ever returned in the output of an MLST or MLSD command.
MLSTまたはMLSDコマンドの出力では、以下に指定されている以外のタイトル、ヘッダー、要約、行、またはその他の書式は返されません。
If the Client-FTP sends an invalid argument, the server-FTP MUST reply with an error code of 501.
クライアントFTPが無効な引数を送信した場合、サーバーFTPはエラーコード501で応答する必要があります。
The syntax for the MLSx command is:
MLSxコマンドの構文は次のとおりです。
mlst = "MLst" [ SP pathname ] CRLF mlsd = "MLsD" [ SP pathname ] CRLF
mlst = "MLst" [SPパス名] CRLF mlsd = "MLsD" [SPパス名] CRLF
The format of a response to an MLSx command is as follows:
MLSxコマンドへの応答の形式は次のとおりです。
mlst-response = control-response / error-response
mlsd-response = ( initial-response final-response ) /
error-response
control-response = "250-" [ response-message ] CRLF 1*( SP entry CRLF ) "250" [ SP response-message ] CRLF
control-response = "250-" [応答メッセージ] CRLF 1 *（SPエントリCRLF） "250" [SP応答メッセージ] CRLF
initial-response = "150" [ SP response-message ] CRLF final-response = "226" SP response-message CRLF
initial-response = "150" [SP応答メッセージ] CRLF final-response = "226" SP応答メッセージCRLF
response-message = *TCHAR
data-response = *( entry CRLF )
entry = [ facts ] SP pathname
facts = 1*( fact ";" )
fact = factname "=" value
factname = "Size" / "Modify" / "Create" /
"Type" / "Unique" / "Perm" /
"Lang" / "Media-Type" / "CharSet" /
os-depend-fact / local-fact
os-depend-fact = <IANA assigned OS name> "." token
local-fact = "X." token
value = *SCHAR
Upon receipt of an MLSx command, the server will verify the parameter, and if invalid return an error-response. For this purpose, the parameter should be considered to be invalid if the client issuing the command does not have permission to perform the requested operation.
MLSxコマンドを受信すると、サーバーはパラメーターを検証し、無効な場合はエラー応答を返します。このため、コマンドを発行するクライアントに、要求された操作を実行する権限がない場合、パラメーターは無効であると見なされます。
If the parameter is valid, then for an MLST command, the server-PI will send the first (leading) line of the control response, the entry for the pathname given, or the current directory if no pathname was provided, and the terminating line. Normally exactly one entry would be returned, more entries are permitted only when required to represent a file that is to have multiple "Type" facts returned. In this case, the pathname component of every response MUST be identical.
パラメータが有効な場合、MLSTコマンドの場合、サーバーPIは制御応答の最初の（先頭の）行、指定されたパス名のエントリ、またはパス名が指定されていない場合は現在のディレクトリ、および終了行を送信します。通常は正確に1つのエントリが返されますが、複数の「タイプ」ファクトが返されるファイルを表す必要がある場合にのみ、より多くのエントリが許可されます。この場合、すべての応答のパス名コンポーネントは同一である必要があります。
Note that for MLST the fact set is preceded by a space. That is provided to guarantee that the fact set cannot be accidentally interpreted as the terminating line of the control response, but is required even when that would not be possible. Exactly one space exists between the set of facts and the pathname. Where no facts are present, there will be exactly two leading spaces before the pathname. No spaces are permitted in the facts, any other spaces in the response are to be treated as being a part of the pathname.
MLSTの場合、ファクトセットの前にはスペースが1つあることに注意してください。これは、ファクトセットが誤って制御応答の終了行として解釈されないことを保証するために提供されていますが、それが不可能な場合でも必要です。ファクトのセットとパス名の間に正確に1つのスペースが存在します。ファクトが存在しない場合、パス名の前に正確に2つの先行スペースがあります。ファクトではスペースを使用できません。応答の他のスペースはパス名の一部として扱われます。
If the command was an MLSD command, the server will open a data connection as indicated in section 3.2 of STD 9, RFC 959 [3]. If that fails, the server will return an error-response. If all is OK, the server will return the initial-response, send the appropriate data-response over the new data connection, close that connection, and then send the final-response over the control connection. The grammar above defines the format for the data-response, which defines the format of the data returned over the data connection established.
コマンドがMLSDコマンドである場合、サーバーは、STD 9、RFC 959 [3]のセクション3.2に示されているようにデータ接続を開きます。それが失敗した場合、サーバーはエラー応答を返します。すべて問題なければ、サーバーは初期応答を返し、新しいデータ接続を介して適切なデータ応答を送信し、その接続を閉じてから、制御接続を介して最終応答を送信します。上記の文法は、確立されたデータ接続を介して返されるデータの形式を定義するデータ応答の形式を定義します。
The data connection opened for a MLSD response shall be a connection as if the "TYPE L 8", "MODE S", and "STRU F" commands had been given, whatever FTP transfer type, mode and structure had actually been set, and without causing those settings to be altered for future commands. That is, this transfer type shall be set for the duration of the data connection established for this command only. While the content of the data sent can be viewed as a series of lines, implementations should note that there is no maximum line length defined. Implementations should be prepared to deal with arbitrarily long lines.
MLSD応答用に開かれたデータ接続は、「TYPE L 8」、「MODE S」、および「STRU F」コマンドが指定されたかのように、実際に設定されたFTP転送タイプ、モード、および構造に関係なく、これらの設定を将来のコマンドのために変更することなく。つまり、この転送タイプは、このコマンドに対してのみ確立されたデータ接続の期間に設定されます。送信されるデータの内容は一連の行として表示できますが、実装では、行の最大長が定義されていないことに注意してください。実装は、任意の長い行を処理できるように準備する必要があります。
The facts part of the specification would contain a series of "file facts" about the file or directory named on the same line. Typical information to be presented would include file size, last modification time, creation time, a unique identifier, and a file/directory flag.
仕様のファクト部分には、同じ行に指定されたファイルまたはディレクトリに関する一連の「ファイルファクト」が含まれます。提示される一般的な情報には、ファイルサイズ、最終変更時刻、作成時刻、一意の識別子、ファイル/ディレクトリフラグが含まれます。
The complete format for a successful reply to the MLSD command would be:
MLSDコマンドへの正常な応答の完全な形式は次のとおりです。
facts SP pathname CRLF facts SP pathname CRLF facts SP pathname CRLF ...
ファクトSPパス名CRLFファクトSPパス名CRLFファクトSPパス名CRLF ...
Note that the format is intended for machine processing, not human viewing, and as such the format is very rigid. Implementations MUST NOT vary the format by, for example, inserting extra spaces for readability, replacing spaces by tabs, including header or title lines, or inserting blank lines, or in any other way alter this format. Exactly one space is always required after the set of facts (which may be empty). More spaces may be present on a line if, and only if, the pathname presented contains significant spaces. The set of facts must not contain any spaces anywhere inside it. Facts should be provided in each output line only if they both provide relevant information about the file named on the same line, and they are in the set requested by the user-PI. See section 7.9 (page 51). There is no requirement that the same set of facts be provided for each file, or that the facts presented occur in the same order for each file.
この形式は人間による表示ではなく、機械処理を目的としているため、形式は非常に厳密です。実装は、たとえば、読みやすさのために余分なスペースを挿入したり、ヘッダーまたはタイトル行を含むタブでスペースを置き換えたり、空白行を挿入したり、他の方法でこのフォーマットを変更したりして、フォーマットを変更してはなりません。ファクト（空の場合があります）のセットの後には必ず1つのスペースが必要です。提示されたパス名に有意なスペースが含まれている場合に限り、行にさらにスペースが存在する可能性があります。ファクトのセットには、スペースを含めないでください。ファクトは、両方が同じ行に指定されたファイルに関する関連情報を提供し、かつユーザーPIによって要求されたセットに含まれている場合にのみ、各出力行に提供する必要があります。 7.9項（51ページ）を参照してください。各ファクトに同じファクトのセットが提供されている必要はありません。また、提示されたファクトが各ファイルで同じ順序で発生している必要はありません。
Many of the 4xy and 5xy responses defined in section 4.2 of STD 9, RFC 959 [3] are possible in response to the MLST and MLSD commands. In particular, syntax errors can generate 500 or 501 replies. Giving a pathname that exists but is not a directory as the argument to a MLSD command generates a 501 reply. Giving a name that does not exist, or for which access permission (to obtain directory information as requested) is not granted will elicit a 550 reply. Other replies (530, 553, 503, 504, and any of the 4xy replies) are also possible in appropriate circumstances.
STD 9、RFC 959 [3]のセクション4.2で定義されている4xyおよび5xy応答の多くは、MLSTおよびMLSDコマンドに応答して可能です。特に、構文エラーは500または501の応答を生成する可能性があります。存在するがディレクトリではないパス名をMLSDコマンドの引数として指定すると、501応答が生成されます。存在しない名前や、（要求されたとおりにディレクトリ情報を取得するための）アクセス許可が付与されていない名前を付けると、550応答が引き出されます。適切な状況では、他の応答（530、553、503、504、および4xy応答のいずれか）も可能です。
An FTP implementation supporting the MLSx commands must be 8-bit clean. This is necessary in order to transmit UTF-8 encoded file names. This specification recommends the use of UTF-8 encoded file names. FTP implementations SHOULD use UTF-8 whenever possible to encourage the maximum inter-operability.
MLSxコマンドをサポートするFTP実装は、8ビットクリーンである必要があります。これは、UTF-8でエンコードされたファイル名を送信するために必要です。この仕様では、UTF-8でエンコードされたファイル名の使用を推奨しています。 FTP実装は、最大限の相互運用性を促進するために、可能な限りUTF-8を使用する必要があります（SHOULD）。
File names are not restricted to UTF-8, however treatment of arbitrary character encodings is not specified by this standard. Applications are encouraged to treat non-UTF-8 encodings of file names as octet sequences.
ファイル名はUTF-8に制限されていませんが、この規格では任意の文字エンコーディングの扱いは指定されていません。アプリケーションでは、ファイル名の非UTF-8エンコーディングをオクテットシーケンスとして扱うことをお勧めします。
Note that this encoding is unrelated to that of the contents of the file, even if the file contains character data.
このエンコードは、ファイルに文字データが含まれている場合でも、ファイルの内容のエンコードとは関係がないことに注意してください。
Further information about file name encoding for FTP may be found in "Internationalization of the File Transfer Protocol" [7].
FTPのファイル名エンコーディングの詳細については、「ファイル転送プロトコルの国際化」[7]を参照してください。
The file name returned in the MLST response should be the same name as was specified in the MLST command, or, where TVFS is supported, a fully qualified TVFS path naming the same file. Where no argument was given to the MLST command, the server-PI may either include an empty file name in the response, or it may supply a name that refers to the current directory, if such a name is available. Where TVFS is supported, a fully qualified pathname of the current directory SHOULD be returned.
MLST応答で返されるファイル名は、MLSTコマンドで指定された名前と同じであるか、またはTVFSがサポートされている場合は、同じファイルを指定する完全修飾TVFSパスでなければなりません。 MLSTコマンドに引数が指定されていない場合、server-PIは空のファイル名を応答に含めるか、現在のディレクトリを参照する名前を提供します（そのような名前が利用可能な場合）。 TVFSがサポートされている場合、現在のディレクトリの完全修飾パス名を返す必要があります（SHOULD）。
File names returned in the output from an MLSD command SHOULD be unqualified names within the directory named, or the current directory if no argument was given. That is, the directory named in the MLSD command SHOULD NOT appear as a component of the file names returned.
MLSDコマンドからの出力で返されるファイル名は、指定されたディレクトリ内の非修飾名、または引数が指定されていない場合は現在のディレクトリである必要があります（SHOULD）。つまり、MLSDコマンドで指定されたディレクトリは、返されるファイル名のコンポーネントとして表示されるべきではありません（SHOULD NOT）。
If the server-FTP process is able, and the "type" fact is being returned, it MAY return in the MLSD response, an entry whose type is "cdir", which names the directory from which the contents of the listing were obtained. Where TVFS is supported, the name MAY be the fully qualified pathname of the directory, or MAY be any other pathname that is valid to refer to that directory from the current working directory of the server-FTP. Where more than one name exists, multiple of these entries may be returned. In a sense, the "cdir" entry can be viewed as a heading for the MLSD output. However, it is not required to be the first entry returned, and may occur anywhere within the listing.
サーバーFTPプロセスが可能で、「タイプ」ファクトが返されている場合、それはMLSD応答で返される場合があります。これは、リストのコンテンツが取得されたディレクトリを示す「cdir」タイプのエントリです。 TVFSがサポートされている場合、名前はディレクトリの完全修飾パス名でも、サーバーFTPの現在の作業ディレクトリからそのディレクトリを参照するのに有効な他のパス名でもかまいません。複数の名前が存在する場合、これらのエントリの複数が返されることがあります。ある意味で、「cdir」エントリは、MLSD出力の見出しと見なすことができます。ただし、最初に返されるエントリである必要はなく、リスト内の任意の場所で発生する可能性があります。
When TVFS is supported, a user-PI can refer to any file or directory in the listing by combining a type "cdir" name, with the appropriate name from the directory listing using the procedure defined in section 6.2.
TVFSがサポートされている場合、ユーザーPIは、「cdir」タイプの名前と、セクション6.2で定義された手順を使用してディレクトリリストからの適切な名前を組み合わせることにより、リスト内の任意のファイルまたはディレクトリを参照できます。
Alternatively, whether TVFS is supported or not, the user-PI can issue a CWD command ([3]) giving a name of type "cdir" from the listing returned, and from that point reference the files returned in the MLSD response from which the cdir was obtained by using the file name components of the listing.
あるいは、TVFSがサポートされているかどうかにかかわらず、ユーザーPIはCWDコマンド（[3]）を発行して、返されたリストから「cdir」タイプの名前を指定し、そのポイントから、MLSD応答で返されたファイルを参照できます。 cdirは、リストのファイル名コンポーネントを使用して取得されました。
The "facts" for a file in a reply to a MLSx command consist of information about that file. The facts are a series of keyword=value pairs each followed by semi-colon (";") characters. An individual fact may not contain a semi-colon in its name or value. The complete series of facts may not contain the space character. See the definition or "RCHAR" in section 2.1 for a list of the characters that can occur in a fact value. Not all are applicable to all facts.
MLSxコマンドへの応答におけるファイルの「事実」は、そのファイルに関する情報で構成されています。ファクトは、一連のkeyword = valueのペアであり、それぞれにセミコロン（ ";"）文字が続きます。個々のファクトの名前または値にセミコロンを含めることはできません。一連のファクトには、スペース文字が含まれていない場合があります。ファクト値で発生する可能性のある文字のリストについては、セクション2.1の定義または「RCHAR」を参照してください。すべてがすべての事実に当てはまるわけではありません。
A sample of a typical series of facts would be: (spread over two lines for presentation here only)
典型的な一連の事実のサンプルは次のようになります：（ここでのみ表示するために2行に広げて）
size=4161;lang=en-US;modify=19970214165800;create=19961001124534;
type=file;x.myfact=foo,bar;
This document defines a standard set of facts as follows:
このドキュメントでは、次のような一連の標準的な事実を定義しています。
size -- Size in octets modify -- Last modification time create -- Creation time type -- Entry type unique -- Unique id of file/directory perm -- File permissions, whether read, write, execute is allowed for the login id. lang -- Language of the file name per IANA [11] registry. media-type -- MIME media-type of file contents per IANA registry. charset -- Character set per IANA registry (if not UTF-8)
size-オクテット単位のサイズmodify-最終変更時刻create-作成時刻のタイプ-エントリータイプunique-ファイル/ディレクトリの一意のID perm-ログインIDに対して読み取り、書き込み、実行が許可されているかどうかのファイル権限。 lang-IANA [11]レジストリごとのファイル名の言語。 media-type-IANAレジストリごとのファイルコンテンツのMIMEメディアタイプ。 charset-IANAレジストリごとの文字セット（UTF-8でない場合）
Fact names are case-insensitive. Size, size, SIZE, and SiZe are the same fact.
ファクト名は大文字と小文字を区別しません。サイズ、サイズ、サイズ、サイズは同じです。
Further operating system specific keywords could be specified by using the IANA operating system name as a prefix (examples only):
IANAオペレーティングシステム名をプレフィックスとして使用することで、オペレーティングシステム固有のキーワードをさらに指定できます（例のみ）。
OS/2.ea -- OS/2 extended attributes
MACOS.rf -- MacIntosh resource forks
UNIX.mode -- Unix file modes (permissions)
Implementations may define keywords for experimental, or private use. All such keywords MUST begin with the two character sequence "x.". As type names are case independent, "x." and "X." are equivalent. For example:
実装では、実験的または私的使用のためのキーワードを定義できます。このようなキーワードはすべて、2文字のシーケンス「x。」で始まる必要があります。タイプ名は大文字と小文字が区別されないため、「x」。と「X」。同等です。例えば：
x.ver -- Version information x.desc -- File description x.type -- File type
x.ver-バージョン情報x.desc-ファイルの説明x.type-ファイルタイプ
The type fact needs a special description. Part of the problem with current practices is deciding when a file is a directory. If it is a directory, is it the current directory, a regular directory, or a parent directory? The MLST specification makes this unambiguous using the type fact. The type fact given specifies information about the object listed on the same line of the MLST response.
タイプファクトには特別な説明が必要です。現在の慣行の問題の一部は、ファイルがディレクトリである場合を決定することです。ディレクトリの場合、それは現在のディレクトリ、通常のディレクトリ、または親ディレクトリですか？ MLST仕様では、タイプファクトを使用してこれを明確にしています。与えられたタイプfactは、MLST応答の同じ行にリストされているオブジェクトに関する情報を指定します。
Five values are possible for the type fact:
タイプ・ファクトには5つの値が可能です。
file -- a file entry cdir -- the listed directory pdir -- a parent directory dir -- a directory or sub-directory OS.name=type -- an OS or file system dependent file type
file-ファイルエントリcdir-リストされたディレクトリpdir-親ディレクトリdir-ディレクトリまたはサブディレクトリOS.name = type-OSまたはファイルシステムに依存するファイルタイプ
The syntax is defined to be:
構文は次のように定義されています。
type-fact = type-label "=" type-val
type-label = "Type"
type-val = "File" / "cdir" / "pdir" / "dir" /
os-type
The value of the type fact (the "type-val") is a case independent string.
タイプfact（「type-val」）の値は、大文字小文字を区別しない文字列です。
The presence of the type=file fact indicates the listed entry is a file containing non-system data. That is, it may be transferred from one system to another of quite different characteristics, and perhaps still be meaningful.
type = fileファクトの存在は、リストされたエントリが非システムデータを含むファイルであることを示しています。つまり、あるシステムから非常に異なる特性を持つ別のシステムに転送される可能性がありますが、それでも意味がある可能性があります。
The type=cdir fact indicates the listed entry contains a pathname of the directory whose contents are listed. An entry of this type will only be returned as a part of the result of an MLSD command when the type fact is included, and provides a name for the listed directory, and facts about that directory. In a sense, it can be viewed as representing the title of the listing, in a machine friendly format. It may appear at any point of the listing, it is not restricted to appearing at the start, though frequently may do so, and may occur multiple times. It MUST NOT be included if the type fact is not included, or there would be no way for the user-PI to distinguish the name of the directory from an entry in the directory.
type = cdirファクトは、リストされたエントリに、内容がリストされているディレクトリのパス名が含まれていることを示します。このタイプのエントリは、ファクトタイプが含まれている場合にのみMLSDコマンドの結果の一部として返され、リストされたディレクトリの名前とそのディレクトリに関するファクトを提供します。ある意味では、それは機械に優しい形式でリストのタイトルを表すものと見なすことができます。リストのどの時点でも表示される可能性があり、最初に表示されることに限定されていませんが、頻繁に発生する場合があり、複数回発生する場合もあります。タイプファクトが含まれていない場合は含めないでください。含まれていない場合、またはユーザーPIがディレクトリの名前とディレクトリのエントリを区別する方法がありません。
Where TVFS is supported by the server-FTP, this name may be used to construct pathnames with which to refer to the files and directories returned in the same MLSD output (see section 6.2). These pathnames are only expected to work when the server-PI's position in the NVFS file tree is the same as its position when the MLSD command was issued, unless a fully qualified pathname results.
TVFSがサーバーFTPでサポートされている場合、この名前を使用して、同じMLSD出力で返されるファイルとディレクトリを参照するパス名を作成できます（セクション6.2を参照）。これらのパス名は、完全修飾パス名が生成されない限り、NVFSファイルツリーでのサーバーPIの位置がMLSDコマンドが発行されたときの位置と同じである場合にのみ機能すると想定されます。
Where TVFS is not supported, the only defined semantics associated with a "type=cdir" entry are that, provided the current working directory of the server-PI has not been changed, a pathname of type "cdir" may be used as an argument to a CWD command, which will cause the current directory of the server-PI to change so that the directory that was listed in its current working directory.
TVFSがサポートされていない場合、「type = cdir」エントリに関連付けられている唯一の定義されたセマンティクスは、サーバーPIの現在の作業ディレクトリが変更されていない場合、「cdir」タイプのパス名を引数として使用できます。 CWDコマンドに変更すると、サーバーPIの現在のディレクトリが変更され、現在の作業ディレクトリにリストされていたディレクトリが変更されます。
If present, the type=dir entry gives the name of a directory. Such an entry typically cannot be transferred from one system to another using RETR, etc., but should (permissions permitting) be able to be the object of an MLSD command.
存在する場合、type = dirエントリはディレクトリの名前を示します。このようなエントリは、通常、RETRなどを使用して1つのシステムから別のシステムに転送することはできませんが、（許可が許可されれば）MLSDコマンドのオブジェクトである必要があります。
If present, which will occur only in the response to a MLSD command when the type fact is included, the type=pdir entry represents a pathname of the parent directory of the listed directory. As well as having the properties of a type=dir, a CWD command that uses the pathname from this entry should change the user to a parent directory of the listed directory. If the listed directory is the current directory, a CDUP command may also have the effect of changing to the named directory. User-FTP processes should note not all responses will include this information, and that some systems may provide multiple type=pdir responses.
存在する場合、タイプファクトが含まれているときにMLSDコマンドへの応答でのみ発生します。type= pdirエントリは、リストされたディレクトリの親ディレクトリのパス名を表します。 type = dirのプロパティを持つだけでなく、このエントリからのパス名を使用するCWDコマンドは、リストされたディレクトリの親ディレクトリにユーザーを変更する必要があります。リストされたディレクトリーが現在のディレクトリーである場合、CDUPコマンドは指定されたディレクトリーに変更する効果もある可能性があります。ユーザーFTPプロセスでは、すべての応答にこの情報が含まれるわけではなく、一部のシステムでは複数のtype = pdir応答が提供される場合があることに注意してください。
Where TVFS is supported, a "type=pdir" name may be a relative pathname, or a fully qualified pathname. A relative pathname will be relative to the directory being listed, not to the current directory of the server-PI at the time.
TVFSがサポートされている場合、「type = pdir」の名前は、相対パス名または完全修飾パス名にすることができます。相対パス名は、一覧表示されているディレクトリからの相対パスであり、現時点でのサーバーPIの現在のディレクトリからの相対パス名ではありません。
For the purposes of this type value, a "parent directory" is any directory in which there is an entry of type=dir that refers to the directory in which the type=pdir entity was found. Thus it is not required that all entities with type=pdir refer to the same directory. The "unique" fact (if supported and supplied) can be used to determine whether there is a relationship between the type=pdir entries or not.
このtype値の目的では、「親ディレクトリ」は、type = pdirエンティティが見つかったディレクトリを参照するtype = dirのエントリがある任意のディレクトリです。したがって、type = pdirのすべてのエンティティが同じディレクトリを参照する必要はありません。 「一意の」ファクト（サポートおよび提供されている場合）を使用して、type = pdirエントリー間に関係があるかどうかを判別できます。
Files types that are specific to a specific operating system, or file system, can be encoded using the "OS." type names. The format is:
特定のオペレーティングシステムまたはファイルシステムに固有のファイルタイプは、「OS」を使用してエンコードできます。タイプ名。形式は次のとおりです。
os-type = "OS." os-name "=" os-kind
os-name = <an IANA registered operating system name>
os-kind = token
The "os-name" indicates the specific system type that supports the particular localtype. OS specific types are registered by the IANA using the procedures specified in section 10. The "os-kind" provides the system dependent information as to the type of the file listed. The os-name and os-kind strings in an os-type are case independent. "OS.unix=block" and "OS.Unix=BLOCK" represent the same type (or would, if such a type were registered.)
「os-name」は、特定のローカルタイプをサポートする特定のシステムタイプを示します。 OS固有のタイプは、セクション10で指定された手順を使用してIANAによって登録されます。「os-kind」は、リストされたファイルのタイプに関するシステム依存情報を提供します。 os-typeのos-nameとos-kind文字列は大文字と小文字が区別されません。 "OS.unix = block"と "OS.Unix = BLOCK"は同じタイプを表します（そのようなタイプが登録されている場合はそうなります）。
Note: Where the underlying system supports a file type that is essentially an indirect pointer to another file, the NVFS representation of that type should normally be to represent the file that the reference indicates. That is, the underlying basic file will appear more than once in the NVFS, each time with the "unique" fact (see immediately following section) containing the same value, indicating that the same file is represented by all such names. User-PIs transferring the file need then transfer it only once, and then insert their own form of indirect reference to construct alternate names where desired, or perhaps even copy the local file if that is the only way to provide two names with the same content. A file which would be a reference to another file, if only the other file actually existed, may be represented in any OS dependent manner appropriate, or not represented at all.
注：基本となるシステムが、基本的に別のファイルへの間接ポインターであるファイルタイプをサポートしている場合、そのタイプのNVFS表現は、通常、参照が示すファイルを表す必要があります。つまり、基礎となる基本ファイルは、NVFSに複数回表示され、毎回同じ値を含む「ユニークな」ファクト（直後のセクションを参照）が表示され、同じファイルがそのようなすべての名前で表されていることを示します。ファイルを転送するユーザーPIは、ファイルを1回だけ転送してから、独自の形式の間接参照を挿入して、必要に応じて代替名を作成するか、ローカルファイルをコピーして、同じ内容の2つの名前を提供する唯一の方法である場合はコピーします。 。他のファイルのみが実際に存在する場合、別のファイルへの参照となるファイルは、OSに依存する方法で適切に表されるか、まったく表されない場合があります。
Where a file is such that it may validly, and sensibly, treated by the server-PI as being of more than one of the above types, then multiple entries should be returned, each with its own "Type" fact of the appropriate type, and each containing the same pathname. This may occur, for example, with a structured file, which may contain sub-files, and where the server-PI permits the structured file to be treated as a unit, or treated as a directory allowing the sub-files within it to be referenced. When this is done, the pathname returned with each entry MUST be identical to the others representing the same file.
ファイルが、有効かつ賢明な方法で、サーバーPIによって上記のタイプの1つ以上として扱われる可能性がある場合、複数のエントリが返され、それぞれに適切なタイプの独自の「タイプ」ファクトがあります。それぞれに同じパス名が含まれています。これは、たとえば、サブファイルを含む可能性のある構造化ファイルで発生する可能性があり、サーバーPIが構造化ファイルを1つの単位として処理することを許可したり、ディレクトリとして処理して、その中のサブファイルを参照。この場合、各エントリで返されるパス名は、同じファイルを表す他のパス名と同一でなければなりません。
The unique fact is used to present a unique identifier for a file or directory in the NVFS accessed via a server-FTP process. The value of this fact should be the same for any number of pathnames that refer to the same underlying file. The fact should have different values for names that reference distinct files. The mapping between files, and unique fact tokens should be maintained, and remain consistent, for at least the lifetime of the control connection from user-PI to server-PI.
一意のファクトは、サーバーFTPプロセスを介してアクセスされるNVFS内のファイルまたはディレクトリの一意の識別子を提示するために使用されます。このファクトの値は、同じ基本ファイルを参照するパス名の数に関係なく同じでなければなりません。ファクトは、個別のファイルを参照する名前に対して異なる値を持つ必要があります。ファイル間のマッピングと一意のファクトトークンは、少なくともユーザーPIからサーバーPIへの制御接続の存続期間中、維持され、一貫性を保つ必要があります。
unique-fact = "Unique" "=" token
unique-fact = "Unique" "="トークン
This fact would be expected to be used by server-FTPs whose host system allows things such as symbolic links so that the same file may be represented in more than one directory on the server. The only conclusion that should be drawn is that if two different names each have the same value for the unique fact, they refer to the same underlying object. The value of the unique fact (the token) should be considered an opaque string for comparison purposes, and is a case dependent value. The tokens "A" and "a" do not represent the same underlying object.
この事実は、ホストシステムがシンボリックリンクなどを許可するサーバーFTPによって使用され、同じファイルがサーバー上の複数のディレクトリで表現されることが期待されます。描かれるべき唯一の結論は、2つの異なる名前がそれぞれ一意のファクトに対して同じ値を持つ場合、それらは同じ基礎となるオブジェクトを参照するということです。一意のファクト（トークン）の値は、比較のために不透明な文字列と見なされる必要があり、ケースに依存する値です。トークン「A」と「a」は、同じ基本オブジェクトを表していません。
The modify fact is used to determine the last time the content of the file (or directory) indicated was modified. Any change of substance to the file should cause this value to alter. That is, if a change is made to a file such that the results of a RETR command would differ, then the value of the modify fact should alter. User-PIs should not assume that a different modify fact value indicates that the file contents are necessarily different than when last retrieved. Some systems may alter the value of the modify fact for other reasons, though this is discouraged wherever possible. Also a file may alter, and then be returned to its previous content, which would often be indicated as two incremental alterations to the value of the modify fact.
変更ファクトは、示されたファイル（またはディレクトリ）のコンテンツが最後に変更された時刻を決定するために使用されます。ファイルの内容が変更されると、この値が変更されます。つまり、RETRコマンドの結果が異なるようにファイルが変更された場合、変更ファクトの値が変更されます。ユーザーPIは、異なるファクトファクト値が、ファイルの内容が最後に取得されたときとは必ずしも異なることを示すと想定してはなりません。システムによっては、他の理由で変更ファクトの値を変更する場合がありますが、これは可能な限り推奨されません。また、ファイルが変更され、その後、以前のコンテンツに戻る場合があります。これは、変更ファクトの値に対する2つの増分変更として示されることがよくあります。
For directories, this value should alter whenever a change occurs to the directory such that different file names would (or might) be included in MLSD output of that directory.
ディレクトリの場合、ディレクトリに変更が発生するたびにこの値が変更され、そのディレクトリのMLSD出力に異なるファイル名が含まれる（または含まれる）ようになります。
modify-fact = "Modify" "=" time-val
modify-fact = "Modify" "=" time-val
The create fact indicates when a file, or directory, was first created. Exactly what "creation" is for this purpose is not specified here, and may vary from server to server. About all that can be said about the value returned is that it can never indicate a later time than the modify fact.
作成ファクトは、ファイルまたはディレクトリがいつ最初に作成されたかを示します。この目的のための「作成」が正確に何であるかはここでは指定されておらず、サーバーによって異なる場合があります。返される値について言えることは、変更ファクトより後の時間を示すことはできないということです。
create-fact = "Create" "=" time-val
create-fact = "Create" "=" time-val
Implementation Note: Implementors of this fact on UNIX(TM) systems should note that the unix "stat" "st_ctime" field does not give creation time, and that unix file systems do not record creation time at all. Unix (and POSIX) implementations will normally not include this fact.
実装上の注意：UNIX（TM）システムでのこの事実の実装者は、UNIXの「stat」「st_ctime」フィールドは作成時間を与えず、UNIXファイルシステムは作成時間をまったく記録しないことに注意する必要があります。 Unix（およびPOSIX）の実装には通常、この事実は含まれません。
The perm fact is used to indicate access rights the current FTP user has over the object listed. Its value is always an unordered sequence of alphabetic characters.
パーマファクトは、現在のFTPユーザーがリストされているオブジェクトに対して持つアクセス権を示すために使用されます。その値は常にアルファベット文字の順序付けられていないシーケンスです。
perm-fact = "Perm" "=" *pvals
pvals = "a" / "c" / "d" / "e" / "f" /
"l" / "m" / "p" / "r" / "w"
There are ten permission indicators currently defined. Many are meaningful only when used with a particular type of object. The indicators are case independent, "d" and "D" are the same indicator.
現在定義されている許可インジケーターは10個あります。多くは、特定のタイプのオブジェクトで使用する場合にのみ意味があります。インジケーターは大文字小文字の区別がなく、「d」と「D」は同じインジケーターです。
The "a" permission applies to objects of type=file, and indicates that the APPE (append) command may be applied to the file named.
「a」権限は、type = fileのオブジェクトに適用され、APPE（追加）コマンドを指定されたファイルに適用できることを示します。
The "c" permission applies to objects of type=dir (and type=pdir, type=cdir). It indicates that files may be created in the directory named. That is, that a STOU command is likely to succeed, and that STOR and APPE commands might succeed if the file named did not previously exist, but is to be created in the directory object that has the "c" permission. It also indicates that the RNTO command is likely to succeed for names in the directory.
「c」権限は、type = dir（およびtype = pdir、type = cdir）のオブジェクトに適用されます。指定されたディレクトリにファイルが作成される可能性があることを示します。つまり、STOUコマンドは成功する可能性が高く、STORコマンドとAPPEコマンドは、指定されたファイルが以前は存在していなかったが、「c」権限を持つディレクトリオブジェクトに作成される場合は成功する可能性があります。また、ディレクトリ内の名前に対してRNTOコマンドが成功する可能性が高いことも示しています。
The "d" permission applies to all types. It indicates that the object named may be deleted, that is, that the RMD command may be applied to it if it is a directory, and otherwise that the DELE command may be applied to it.
「d」権限はすべてのタイプに適用されます。これは、指定されたオブジェクトが削除される可能性があること、つまり、RMDコマンドがディレクトリの場合はそれに適用され、それ以外の場合はDELEコマンドが適用されることを示します。
The "e" permission applies to the directory types. When set on an object of type=dir, type=cdir, or type=pdir it indicates that a CWD command naming the object should succeed, and the user should be able to enter the directory named. For type=pdir it also indicates that the CDUP command may succeed (if this particular pathname is the one to which a CDUP would apply.)
「e」権限は、ディレクトリタイプに適用されます。 type = dir、type = cdir、またはtype = pdirのオブジェクトに設定されている場合、オブジェクトを指定するCWDコマンドが成功し、指定されたディレクトリにユーザーが入ることができることを示します。 type = pdirの場合、CDUPコマンドが成功する可能性があることも示します（この特定のパス名がCDUPが適用されるパス名である場合）。
The "f" permission for objects indicates that the object named may be renamed - that is, may be the object of an RNFR command.
オブジェクトの「f」権限は、指定されたオブジェクトの名前が変更される可能性があること、つまり、RNFRコマンドのオブジェクトである可能性があることを示します。
The "l" permission applies to the directory file types, and indicates that the listing commands, LIST, NLST, and MLSD may be applied to the directory in question.
「l」権限はディレクトリファイルタイプに適用され、リストコマンドLIST、NLST、およびMLSDが問題のディレクトリに適用される可能性があることを示します。
The "m" permission applies to directory types, and indicates that the MKD command may be used to create a new directory within the directory under consideration.
「m」権限はディレクトリタイプに適用され、検討中のディレクトリ内にMKDコマンドを使用して新しいディレクトリを作成できることを示します。
The "p" permission applies to directory types, and indicates that objects in the directory may be deleted, or (stretching naming a little) that the directory may be purged. Note: it does not indicate that the RMD command may be used to remove the directory named itself, the "d" permission indicator indicates that.
「p」権限はディレクトリタイプに適用され、ディレクトリ内のオブジェクトが削除される可能性があること、または（名前を少し伸ばして）ディレクトリが削除される可能性があることを示します。注：これは、RMDコマンドを使用して、それ自体の名前のディレクトリを削除できることを示すものではありません。「d」許可インジケータは、それを示します。
The "r" permission applies to type=file objects, and for some systems, perhaps to other types of objects, and indicates that the RETR command may be applied to that object.
「r」権限は、type = fileオブジェクトに適用され、一部のシステムではおそらく他のタイプのオブジェクトに適用され、RETRコマンドがそのオブジェクトに適用される可能性があることを示します。
The "w" permission applies to type=file objects, and for some systems, perhaps to other types of objects, and indicates that the STOR command may be applied to the object named.
「w」権限は、type = fileオブジェクトに適用され、一部のシステムではおそらく他のタイプのオブジェクトに適用され、指定されたオブジェクトにSTORコマンドを適用できることを示します。
Note: That a permission indicator is set can never imply that the appropriate command is guaranteed to work -- just that it might. Other system specific limitations, such as limitations on available space for storing files, may cause an operation to fail, where the permission flags may have indicated that it was likely to succeed. The permissions are a guide only.
注：許可標識が設定されていても、適切なコマンドが機能することが保証されているとは限りません。ファイルを格納するための使用可能なスペースの制限など、他のシステム固有の制限により、操作が失敗する場合があります。その場合、許可フラグが成功する可能性が高いことを示している可能性があります。権限はガイドのみです。
Implementation note: The permissions are described here as they apply to FTP commands. They may not map easily into particular permissions available on the server's operating system. Servers are expected to synthesize these permission bits from the permission information available from operating system. For example, to correctly determine whether the "D" permission bit should be set on a directory for a server running on the UNIX(TM) operating system, the server should check that the directory named is empty, and that the user has write permission on both the directory under consideration, and its parent directory.
実装上の注意：FTPコマンドに適用されるため、ここでは権限について説明します。それらは、サーバーのオペレーティングシステムで利用可能な特定の権限に簡単にマッピングできない場合があります。サーバーは、オペレーティングシステムから入手できる許可情報からこれらの許可ビットを合成することが期待されています。たとえば、UNIX（TM）オペレーティングシステムで実行されているサーバーのディレクトリに「D」許可ビットを設定する必要があるかどうかを正しく判断するには、サーバーは指定されたディレクトリが空であること、およびユーザーが書き込み許可を持っていることを確認する必要があります。検討中のディレクトリとその親ディレクトリの両方。
Some systems may have more specific permissions than those listed here, such systems should map those to the flags defined as best they are able. Other systems may have only more broad access controls. They will generally have just a few possible permutations of permission flags, however they should attempt to correctly represent what is permitted.
一部のシステムには、ここに記載されているものよりも特定の権限がある場合があります。そのようなシステムは、それらをできる限り最善と定義されたフラグにマップする必要があります。他のシステムでは、より広範なアクセス制御しか持たない場合があります。通常、許可フラグの可能な置換はほんのわずかですが、許可されているものを正しく表現する必要があります。
The lang fact describes the natural language of the file name for use in display purposes. Values used here should be taken from the language registry of the IANA. See [12] for the syntax, and procedures, related to language tags.
langファクトは、表示目的で使用するファイル名の自然言語を示します。ここで使用される値は、IANAの言語レジストリから取得する必要があります。言語タグに関連する構文と手順については、[12]を参照してください。
lang-fact = "Lang" "=" token
lang-fact = "Lang" "="トークン
Server-FTP implementations MUST NOT guess language values. Language values must be determined in an unambiguous way such as file system tagging of language or by user configuration. Note that the lang fact provides no information at all about the content of a file, only about the encoding of its name.
サーバーFTPの実装は、言語値を推測してはなりません（MUST NOT）。言語の値は、ファイルシステムのタグ付けなどの明確な方法で、またはユーザーの構成によって決定する必要があります。 langファクトは、ファイルのコンテンツに関する情報をまったく提供せず、ファイル名のエンコーディングについてのみ提供することに注意してください。
The size fact applies to non-directory file types and should always reflect the approximate size of the file. This should be as accurate as the server can make it, without going to extraordinary lengths, such as reading the entire file. The size is expressed in units of octets of data in the file.
サイズの事実は、非ディレクトリファイルタイプに適用され、常にファイルのおおよそのサイズを反映する必要があります。これは、サーバーができる限り正確であり、ファイル全体を読み取るなどの特別な長さを必要としません。サイズは、ファイル内のデータのオクテット単位で表されます。
Given limitations in some systems, Client-FTP implementations must understand this size may not be precise and may change between the time of a MLST and RETR operation.
一部のシステムには制限があるため、クライアントFTPの実装では、このサイズが正確ではなく、MLST操作とRETR操作の間に変化する可能性があることを理解する必要があります。
Clients that need highly accurate size information for some particular reason should use the SIZE command as defined in section 4. The most common need for this accuracy is likely to be in conjunction with the REST command described in section 5. The size fact, on the other hand, should be used for purposes such as indicating to a human user the approximate size of the file to be transferred, and perhaps to give an idea of expected transfer completion time.
何らかの特定の理由で非常に正確なサイズ情報を必要とするクライアントは、セクション4で定義されているSIZEコマンドを使用する必要があります。この正確さの最も一般的なニーズは、セクション5で説明されているRESTコマンドと関連している可能性があります。一方、転送されるファイルのおおよそのサイズを人間のユーザーに示すなどの目的で使用し、予想される転送完了時間を知ることもできます。
size-fact = "Size" "=" 1*DIGIT
The media-type fact represents the IANA media type of the file named, and applies only to non-directory types. The list of values used must follow the guidelines set by the IANA registry.
メディアタイプファクトは、指定されたファイルのIANAメディアタイプを表し、非ディレクトリタイプにのみ適用されます。使用される値のリストは、IANAレジストリで設定されたガイドラインに従う必要があります。
media-type = "Media-Type" "=" <per IANA guidelines>
Server-FTP implementations MUST NOT guess media type values. Media type values must be determined in an unambiguous way such as file system tagging of media-type or by user configuration. This fact gives information about the content of the file named. Both the primary media type, and any appropriate subtype should be given, separated by a slash "/" as is traditional.
サーバーFTPの実装は、メディアタイプの値を推測してはなりません（MUST NOT）。メディアタイプの値は、メディアタイプのファイルシステムのタグ付けなどの明確な方法で、またはユーザー設定によって決定する必要があります。この事実は、指定されたファイルの内容に関する情報を提供します。従来のように、プライマリメディアタイプと適切なサブタイプの両方をスラッシュ「/」で区切って指定する必要があります。
The charset fact provides the IANA character set name, or alias, for the encoded pathnames in a MLSx response. The default character set is UTF-8 unless specified otherwise. FTP implementations SHOULD use UTF-8 if possible to encourage maximum inter-operability. The value of this fact applies to the pathname only, and provides no information about the contents of the file.
charsetファクトは、MLSx応答のエンコードされたパス名のIANA文字セット名またはエイリアスを提供します。特に指定がない限り、デフォルトの文字セットはUTF-8です。 FTP実装では、相互運用性を最大限に高めるために、可能であればUTF-8を使用する必要があります（SHOULD）。このファクトの値はパス名にのみ適用され、ファイルの内容に関する情報は提供されません。
charset-type = "Charset" "=" token
charset-type = "Charset" "="トークン
Servers are not required to support any particular set of the available facts. However, servers SHOULD, if conceivably possible, support at least the type, perm, size, unique, and modify facts.
サーバーは、利用可能なファクトの特定のセットをサポートする必要はありません。ただし、サーバーは、可能であれば、少なくともタイプ、パーマ、サイズ、一意、および変更ファクトをサポートする必要があります（SHOULD）。
By using an system dependent fact, or a local fact, a server-PI may communicate to the user-PI information about the file named that is peculiar to the underlying file system.
システム依存ファクトまたはローカルファクトを使用することにより、サーバーPIは、基になるファイルシステムに固有の名前が付けられたファイルに関するユーザーPI情報と通信できます。
System dependent fact names are labeled by prefixing a label identifying the specific information returned by the name of the appropriate operating system from the IANA maintained list of operating system names.
システムに依存するファクト名は、IANAが維持するオペレーティングシステム名のリストから、適切なオペレーティングシステムの名前によって返される特定の情報を識別するラベルを前に付けることによってラベル付けされます。
The value of an OS dependent fact may be whatever is appropriate to convey the information available. It must be encoded as a "token" as defined in section 2.1 however.
OSに依存する事実の価値は、利用可能な情報を伝えるのに適切なものであれば何でもかまいません。ただし、セクション2.1で定義されている「トークン」としてエンコードする必要があります。
In order to allow reliable inter-operation between users of system dependent facts, the IANA will maintain a registry of system dependent fact names, their syntax, and the interpretation to be given to their values. Registrations of system dependent facts are to be accomplished according to the procedures of section 10.
システム依存のファクトのユーザー間で信頼できる相互運用を可能にするために、IANAはシステム依存のファクト名、それらの構文、およびそれらの値に与えられる解釈のレジストリを維持します。システムに依存するファクトの登録は、セクション10の手順に従って行われます。
Implementations may also make available other facts of their own choosing. As the method of interpretation of such information will generally not be widely understood, server-PIs should be aware that clients will typically ignore any local facts provided. As there is no registration of locally defined facts, it is entirely possible that different servers will use the same local fact name to provide vastly different information. Hence user-PIs should be hesitant about making any use of any information in a locally defined fact without some other specific assurance that the particular fact is one that they do comprehend.
実装は、独自に選択した他の事実を利用可能にすることもできます。このような情報の解釈方法は一般に広く理解されていないため、サーバーPIは、クライアントが通常提供されるローカルの事実を無視することを認識しておく必要があります。ローカルで定義されたファクトの登録がないため、異なるサーバーが同じローカルファクト名を使用して、非常に異なる情報を提供することは完全に可能です。したがって、ユーザーPIは、特定のファクトが理解しているものであるという他の特定の保証なしに、ローカルで定義されたファクト内の情報の使用をためらう必要があります。
Local fact names all begin with the sequence "X.". The rest of the name is a "token" (see section 2.1). The value of a local fact can be anything at all, provided it can be encoded as a "token".
ローカルのファクト名はすべてシーケンス「X.」で始まります。名前の残りの部分は「トークン」です（セクション2.1を参照）。ローカルファクトの値は、「トークン」としてエンコードできる場合、何でもかまいません。
The following examples are all taken from dialogues between existing FTP clients and servers. Because of this, not all possible variations of possible response formats are shown in the examples. This should not be taken as limiting the options of other server implementors. Where the examples show OS dependent information, that is to be treated as being purely for the purposes of demonstration of some possible OS specific information that could be defined. As at the time of the writing of this document, no OS specific facts or file types have been defined, the examples shown here should not be treated as in any way to be preferred over other possible similar definitions. Consult the IANA registries to determine what types and facts have been defined. Finally also beware that as the examples shown are taken from existing implementations, coded before this document was completed, the possibility of variations between the text of this document and the examples exists. In any such case of inconsistency, the example is to be treated as incorrect.
次の例はすべて、既存のFTPクライアントとサーバー間の対話から取られたものです。このため、可能な応答フォーマットのすべての可能なバリエーションが例に示されているわけではありません。これは、他のサーバー実装者のオプションを制限するものとして解釈されるべきではありません。例がOS依存の情報を示している場合、これは純粋に、定義できる可能性のあるOS固有の情報のデモンストレーションを目的とするものとして扱われます。このドキュメントの執筆時点では、OS固有のファクトやファイルタイプは定義されていません。ここに示す例は、他の可能な同様の定義よりも優先されるものとして扱われるべきではありません。 IANAレジストリを参照して、定義されているタイプとファクトを確認してください。最後に、示されている例は、このドキュメントが完成する前にコーディングされた既存の実装から取得されているため、このドキュメントのテキストと例の間にバリエーションがある可能性があることに注意してください。このような不一致のケースでは、例は正しくないものとして扱われます。
In the examples shown, only relevant commands and responses have been included. This is not to imply that other commands (including authentication, directory modification, PORT or PASV commands, or similar) would not be present in an actual connection, or were not, in fact, actually used in the examples before editing. Note also that the formats shown are those that are transmitted between client and server, not formats that would normally ever be reported to the user of the client.
示されている例では、関連するコマンドと応答のみが含まれています。これは、他のコマンド（認証、ディレクトリ変更、PORTまたはPASVコマンドなどを含む）が実際の接続に存在しない、または実際には編集前の例で実際に使用されなかったことを意味するものではありません。また、表示される形式はクライアントとサーバーの間で送信される形式であり、通常はクライアントのユーザーに報告される形式ではないことに注意してください。
C> PWD
S> 257 "/tmp" is current directory.
C> MLst cap60.pl198.tar.gz
S> 250- Listing cap60.pl198.tar.gz
S> Type=file;Size=1024990;Perm=r; /tmp/cap60.pl198.tar.gz
S> 250 End
The client first asked to be told the current directory of the server. This was purely for the purposes of clarity of this example. The client then requested facts about a specific file. The server returned the "250-" first control-response line, followed by a single line of facts about the file, followed by the terminating "250 " line. The text on the control-response line and the terminating line can be anything the server decides to send. Notice that the fact line is indented by a single space. Notice also that there are no spaces in the set of facts returned, until the single space before the file name. The file name returned on the fact line is a fully qualified pathname of the file listed. The facts returned show that the line refers to a file, that file contains approximately 1024990 bytes, though more or less than that may be transferred if the file is retrieved, and a different number may be required to store the file at the client's file store, and the connected user has permission to retrieve the file but not to do anything else particularly interesting.
クライアントは最初にサーバーの現在のディレクトリを通知するように求めました。これは、純粋にこの例を明確にするためのものです。次に、クライアントは特定のファイルに関する事実を要求しました。サーバーは「250-」の最初の制御応答行を返し、その後にファイルに関する1行のファクトが続き、最後に「250」行が続きます。制御応答行と終了行のテキストは、サーバーが送信することを決定したものであれば何でもかまいません。ファクトラインが1つのスペースでインデントされていることに注意してください。ファイル名の前の単一のスペースまで、返されるファクトのセットにスペースがないことにも注意してください。ファクト行に返されるファイル名は、リストされているファイルの完全修飾パス名です。返されたファクトは、行がファイルを参照していること、そのファイルには約1024990バイトが含まれていることを示していますが、ファイルが取得された場合はそれよりも多くまたは少なく転送され、クライアントのファイルストアにファイルを保存するには別の数が必要になる場合があります、および接続されたユーザーは、ファイルを取得する権限を持っていますが、特に興味深い他のことを行う権限はありません。
C> PWD
S> 257 "/" is current directory.
C> MLst tmp
S> 250- Listing tmp
S> Type=dir;Modify=19981107085215;Perm=el; /tmp
S> 250 End
Again the PWD is just for the purposes of demonstration for the example. The MLST fact line this time shows that the file listed is a directory, that it was last modified at 08:52:15 on the 7th of November, 1998 UTC, and that the user has permission to enter the directory, and to list its contents, but not to modify it in any way. Again, the fully qualified pathname of the directory listed is given.
繰り返しになりますが、障害者は例のデモンストレーションを目的としています。今回のMLSTファクト行は、リストされたファイルがディレクトリであること、1998年11月7日のUTC 08:52:15に最後に変更されたこと、およびユーザーがディレクトリに入り、そのリストを表示する権限を持っていることを示しています内容ですが、変更することはできません。ここでも、リストされているディレクトリの完全修飾パス名が指定されています。
C> MLSD tmp
S> 150 BINARY connection open for MLSD tmp
D> Type=cdir;Modify=19981107085215;Perm=el; tmp
D> Type=cdir;Modify=19981107085215;Perm=el; /tmp
D> Type=pdir;Modify=19990112030508;Perm=el; ..
D> Type=file;Size=25730;Modify=19940728095854;Perm=; capmux.tar.z
D> Type=file;Size=1830;Modify=19940916055648;Perm=r; hatch.c
D> Type=file;Size=25624;Modify=19951003165342;Perm=r; MacIP-02.txt
D> Type=file;Size=2154;Modify=19950501105033;Perm=r; uar.netbsd.patch
D> Type=file;Size=54757;Modify=19951105101754;Perm=r; iptnnladev.1.0.sit.hqx
D> Type=file;Size=226546;Modify=19970515023901;Perm=r; melbcs.tif
D> Type=file;Size=12927;Modify=19961025135602;Perm=r; tardis.1.6.sit.hqx
D> Type=file;Size=17867;Modify=19961025135602;Perm=r; timelord.1.4.sit.hqx
D> Type=file;Size=224907;Modify=19980615100045;Perm=r; uar.1.2.3.sit.hqx
D> Type=file;Size=1024990;Modify=19980130010322;Perm=r; cap60.pl198.tar.gz
S> 226 MLSD completed
In this example notice that there is no leading space on the fact lines returned over the data connection. Also notice that two lines of "type=cdir" have been given. These show two alternate names for the directory listed, one a fully qualified pathname, and the other a local name relative to the servers current directory when the MLSD was performed. Note that all other file names in the output are relative to the directory listed, though the server could, if it chose, give a fully qualified pathname for the "type=pdir" line. This server has chosen not to. The other files listed present a fairly boring set of files that are present in the listed directory. Note that there is no particular order in which they are listed. They are not sorted by file name, by size, or by modify time. Note also that the "perm" fact has an empty value for the file "capmux.tar.z" indicating that the connected user has no permissions at all for that file. This server has chosen to present the "cdir" and "pdir" lines before the lines showing the content of the directory, it is not required to do so. The "size" fact does not provide any meaningful information for a directory, so is not included in the fact lines for the directory types shown.
この例では、データ接続を介して返されるファクト行に先行スペースがないことに注意してください。また、「type = cdir」の2行が指定されていることにも注意してください。これらは、リストされているディレクトリの2つの代替名を示しています。1つは完全修飾パス名、もう1つはMLSDが実行されたときのサーバーの現在のディレクトリに関連するローカル名です。出力内の他のすべてのファイル名は、リストされたディレクトリに関連していますが、サーバーが選択した場合、「type = pdir」行に完全修飾パス名を指定できます。このサーバーは選択しません。リストされている他のファイルは、リストされているディレクトリにあるかなり退屈なファイルのセットを示しています。リストされている特定の順序がないことに注意してください。それらは、ファイル名、サイズ、または変更時間でソートされていません。また、「perm」ファクトのファイル「capmux.tar.z」には空の値があり、接続しているユーザーにはそのファイルに対する権限がまったくないことを示しています。このサーバーは、ディレクトリの内容を示す行の前に「cdir」行と「pdir」行を表示することを選択しました。これは必須ではありません。 「サイズ」ファクトは、ディレクトリに意味のある情報を提供しないため、表示されているディレクトリタイプのファクト行には含まれていません。
C> MLst test
S> 250- Listing test
S> Type=dir;Perm=el;Unique=keVO1+ZF4 test
S> 250 End
C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=slink:/foobar;Perm=;Unique=keVO1+4G4; foobar
D> Type=OS.unix=chr-13/29;Perm=;Unique=keVO1+5G4; device
D> Type=OS.unix=blk-11/108;Perm=;Unique=keVO1+6G4; block
D> Type=file;Perm=awr;Unique=keVO1+8G4; writable
D> Type=dir;Perm=cpmel;Unique=keVO1+7G4; promiscuous
D> Type=dir;Perm=;Unique=keVO1+1t2; no-exec
D> Type=file;Perm=r;Unique=keVO1+EG4; two words
D> Type=file;Perm=r;Unique=keVO1+IH4; leading space
D> Type=file;Perm=r;Unique=keVO1+1G4; file1
D> Type=dir;Perm=cpmel;Unique=keVO1+7G4; incoming
D> Type=file;Perm=r;Unique=keVO1+1G4; file2
D> Type=file;Perm=r;Unique=keVO1+1G4; file3
D> Type=file;Perm=r;Unique=keVO1+1G4; file4
S> 226 MLSD completed
C> MLSD test/incoming
S> 150 BINARY connection open for MLSD test/incoming
D> Type=cdir;Perm=cpmel;Unique=keVO1+7G4; test/incoming
D> Type=pdir;Perm=el;Unique=keVO1+ZF4; ..
D> Type=file;Perm=awdrf;Unique=keVO1+EH4; bar
D> Type=file;Perm=awdrf;Unique=keVO1+LH4;
D> Type=file;Perm=rf;Unique=keVO1+1G4; file5
D> Type=file;Perm=rf;Unique=keVO1+1G4; file6
D> Type=dir;Perm=cpmdelf;Unique=keVO1+!s2; empty
S> 226 MLSD completed
For the purposes of this example the fact set requested has been modified to delete the "size" and "modify" facts, and add the "unique" fact. First, facts about a file name have been obtained via MLST. Note that no fully qualified pathname was given this time. That was because the server was unable to determine that information. Then having determined that the file name represents a directory, that directory has been listed. That listing also shows no fully qualified pathname, for the same reason, thus has but a single "type=cdir" line. This directory (which was created especially for the purpose) contains several interesting files. There are some with OS dependent file types, several sub-directories, and several ordinary files.
この例では、要求されたファクトセットを変更して、「サイズ」および「変更」ファクトを削除し、「一意」ファクトを追加しています。まず、ファイル名に関する事実がMLSTを介して取得されました。今回は完全修飾パス名が指定されていないことに注意してください。これは、サーバーがその情報を判別できなかったためです。次に、ファイル名がディレクトリを表すと判断すると、そのディレクトリがリストされます。このリストには、同じ理由で完全修飾パス名も表示されていないため、「type = cdir」行が1つしかありません。このディレクトリ（特に目的で作成された）には、いくつかの興味深いファイルが含まれています。 OSに依存するファイルタイプのいくつか、いくつかのサブディレクトリ、いくつかの通常のファイルがあります。
Not much can be said here about the OS dependent file types, as none of the information shown there should be treated as any more than possibilities. It can be seen that the OS type of the server is "unix" though, which is one of the OS types in the IANA registry of Operating System names.
OSに依存するファイルの種類については、ここで説明できることはほとんどありません。そこに示されている情報はどれも、可能性として扱われるべきではないからです。サーバーのOSタイプは「unix」であることがわかります。これは、オペレーティングシステム名のIANAレジストリにあるOSタイプの1つです。
Of the three directories listed, "no-exec" has no permission granted to this user to access at all. From the "Unique" fact values, it can be determined that "promiscuous" and "incoming" in fact represent the same directory. Its permissions show that the connected user has permission to do essentially anything other than to delete the directory. That directory was later listed. It happens that the directory can not be deleted because it is not empty.
リストされた3つのディレクトリのうち、「no-exec」には、このユーザーにアクセスするためのアクセス権がまったく与えられていません。 「ユニークな」ファクト値から、「無差別」と「着信」が実際には同じディレクトリを表していると判断できます。その権限は、接続されたユーザーが、ディレクトリを削除する以外の本質的に何でもする権限を持っていることを示しています。そのディレクトリは後でリストされました。空でないため、ディレクトリを削除できない場合があります。
Of the normal files listed, two contain spaces in their names. The file called " leading space" actually contains two spaces in its name, one before the "l" and one between the "g" and the "s". The two spaces that separate the facts from the visible part of the pathname make that clear. The file "writable" has the "a" and "w" permission bits set, and consequently the connected user should be able to STOR or APPE to that file.
リストされている通常のファイルのうち、2つは名前にスペースが含まれています。 「リーディングスペース」と呼ばれるファイルは、実際には名前に2つのスペースが含まれています。1つは「l」の前、もう1つは「g」と「s」の間にあります。ファクトとパス名の表示部分を区切る2つのスペースは、それを明確にします。 「書き込み可能」ファイルには「a」および「w」許可ビットが設定されているため、接続されたユーザーはそのファイルにSTORまたはAPPEできるはずです。
The other four file names, "file1", "file2", "file3", and "file4" all represent the same underlying file, as can be seen from the values of the "unique" facts of each. It happens that "file1" and "file2" are Unix "hard" links, and that "file3" and "file4" are "soft" or "symbolic" links to the first two. None of that information is available via standard MLST facts, it is sufficient for the purposes of FTP to note that all represent the same file, and that the same data would be fetched no matter which of them was retrieved, and that all would be simultaneously modified were data stored in any.
他の4つのファイル名「file1」、「file2」、「file3」、および「file4」はすべて、それぞれの「固有」ファクトの値からわかるように、同じ基本ファイルを表します。 「file1」と「file2」はUnixの「ハード」リンクであり、「file3」と「file4」は最初の2つへの「ソフト」または「シンボリック」リンクです。これらの情報は標準のMLSTファクトを介して利用できません。FTPの目的では、すべてが同じファイルを表し、どのデータが取得されても同じデータがフェッチされ、すべてが同時に取得されることに注意するだけで十分です。変更されたデータが格納された。
Finally, the sub-directory "incoming" is listed. Since "promiscuous" is the same directory there would be no point listing it as well. In that directory, the files "file5" and "file6" represent still more names for the "file1" file we have seen before. Notice the entry between that for "bar" and "file5". Though it is not possible to easily represent it in this document, that shows a file with a name comprising exactly three spaces (" "). A client will have no difficulty determining that name from the output presented to it however. The directory "empty" is, as its name implies, empty, though that is not shown here. It can, however, be deleted, as can file "bar" and the file whose name is three spaces. All the files that reside in this directory can be renamed. This is a consequence of the UNIX semantics of the directory that contains them being modifiable.
最後に、サブディレクトリ「incoming」がリストされます。 「promiscuous」は同じディレクトリであるため、それをリストしても意味がありません。そのディレクトリでは、ファイル「file5」と「file6」は、以前に見た「file1」ファイルのさらに多くの名前を表しています。 「bar」と「file5」の間のエントリに注意してください。このドキュメントでは簡単に表すことはできませんが、3つのスペース（ ""）からなる名前のファイルを示しています。ただし、クライアントは、提示された出力からその名前を簡単に特定できます。 「空」のディレクトリは、その名前が示すように空ですが、ここでは示していません。ただし、ファイル「bar」および名前が3つのスペースのファイルと同様に、削除することもできます。このディレクトリにあるすべてのファイルの名前を変更できます。これは、それらを含むディレクトリのUNIXセマンティクスが変更可能であるためです。
C> MLst file1
S> 250- Listing file1
S> Type=file;Modify=19990929003355.237; file1
S> 250 End
In this example, the server-FTP is indicating that "file1" was last modified 237 milliseconds after 00:33:55 UTC on the 29th of September, 1999.
この例では、サーバーFTPは、「file1」が1999年9月29日00:33:55 UTCから237ミリ秒後に最後に変更されたことを示しています。
C> MLST S> 250-Begin S> type=dir;unique=AQkAAAAAAAABCAAA; / S> 250 End. C> MLSD S> 150 Opening ASCII mode data connection for MLS. D> type=cdir;unique=AQkAAAAAAAABCAAA; / D> type=dir;unique=AQkAAAAAAAABEAAA; bin D> type=dir;unique=AQkAAAAAAAABGAAA; etc D> type=dir;unique=AQkAAAAAAAAB8AwA; halflife D> type=dir;unique=AQkAAAAAAAABoAAA; incoming D> type=dir;unique=AQkAAAAAAAABIAAA; lib D> type=dir;unique=AQkAAAAAAAABWAEA; linux D> type=dir;unique=AQkAAAAAAAABKAEA; ncftpd D> type=dir;unique=AQkAAAAAAAABGAEA; outbox D> type=dir;unique=AQkAAAAAAAABuAAA; quake2 D> type=dir;unique=AQkAAAAAAAABQAEA; winstuff S> 226 Listing completed. C> MLSD linux S> 150 Opening ASCII mode data connection for MLS. D> type=cdir;unique=AQkAAAAAAAABWAEA; /linux D> type=pdir;unique=AQkAAAAAAAABCAAA; / D> type=dir;unique=AQkAAAAAAAABeAEA; firewall D> type=file;size=12;unique=AQkAAAAAAAACWAEA; helo_world D> type=dir;unique=AQkAAAAAAAABYAEA; kernel D> type=dir;unique=AQkAAAAAAAABmAEA; scripts D> type=dir;unique=AQkAAAAAAAABkAEA; security S> 226 Listing completed. C> MLSD linux/kernel S> 150 Opening ASCII mode data connection for MLS. D> type=cdir;unique=AQkAAAAAAAABYAEA; /linux/kernel D> type=pdir;unique=AQkAAAAAAAABWAEA; /linux D> type=file;size=6704;unique=AQkAAAAAAAADYAEA; k.config D> type=file;size=7269221;unique=AQkAAAAAAAACYAEA; linux-2.0.36.tar.gz D> type=file;size=12514594;unique=AQkAAAAAAAAEYAEA; linux-2.1.130.tar.gz S> 226 Listing completed.
C> MLST S> 250-Begin S> type = dir; unique = AQkAAAAAAAABCAAA; / S> 250終了。 C> MLSD S> 150 MLSのASCIIモードデータ接続を開きます。 D> type = cdir; unique = AQkAAAAAAAABCAAA; / D> type = dir; unique = AQkAAAAAAAABEAAA; bin D> type = dir; unique = AQkAAAAAAAABGAAA; etc D> type = dir; unique = AQkAAAAAAAAB8AwA;半減期D> type = dir; unique = AQkAAAAAAAABoAAA;着信D> type = dir; unique = AQkAAAAAAAABIAAA; lib D> type = dir; unique = AQkAAAAAAAABWAEA; linux D> type = dir; unique = AQkAAAAAAAABKAEA; ncftpd D> type = dir; unique = AQkAAAAAAAABGAEA;送信トレイD> type = dir; unique = AQkAAAAAAAABuAAA; quake2 D> type = dir; unique = AQkAAAAAAAABQAEA; winstuff S> 226リストが完成しました。 C> MLSD linux S> 150 MLSのASCIIモードデータ接続を開く。 D> type = cdir; unique = AQkAAAAAAAABWAEA; / linux D> type = pdir; unique = AQkAAAAAAAABCAAA; / D> type = dir; unique = AQkAAAAAAAABeAEA;ファイアウォールD> type = file; size = 12; unique = AQkAAAAAAAACWAEA; helo_world D> type = dir; unique = AQkAAAAAAAABYAEA;カーネルD> type = dir; unique = AQkAAAAAAAABmAEA;スクリプトD> type = dir; unique = AQkAAAAAAAABkAEA;セキュリティS> 226リストが完成しました。 C> MLSD linux / kernel S> 150 MLSのASCIIモードデータ接続を開く。 D> type = cdir; unique = AQkAAAAAAAABYAEA; / linux / kernel D> type = pdir; unique = AQkAAAAAAAABWAEA; / linux D> type = file; size = 6704; unique = AQkAAAAAAAADYAEA; k.config D> type = file; size = 7269221; unique = AQkAAAAAAAACYAEA; linux-2.0.36.tar.gz D> type = file; size = 12514594; unique = AQkAAAAAAAAEYAEA; linux-2.1.130.tar.gz S> 226リストが完成しました。
Note that this server returns its "unique" fact value in quite a different format. It also returns fully qualified pathnames for the "pdir" entry.
このサーバーは、まったく異なる形式で「一意の」ファクト値を返すことに注意してください。また、「pdir」エントリの完全修飾パス名を返します。
C> MLSD S> 150 BINARY connection open for MLSD . D> Type=cdir;Modify=19990219183438; /iana/assignments D> Type=pdir;Modify=19990112030453; .. D> Type=dir;Modify=19990219073522; media-types D> Type=dir;Modify=19990112033515; character-set-info D> Type=dir;Modify=19990112033529; languages D> Type=file;Size=44242;Modify=19990217230400; character-sets D> Type=file;Size=1947;Modify=19990209215600; operating-system-names S> 226 MLSD completed C> MLSD media-types S> 150 BINARY connection open for MLSD media-types D> Type=cdir;Modify=19990219073522; media-types D> Type=cdir;Modify=19990219073522; /iana/assignments/media-types D> Type=pdir;Modify=19990219183438; .. D> Type=dir;Modify=19990112033045; text D> Type=dir;Modify=19990219183442; image D> Type=dir;Modify=19990112033216; multipart D> Type=dir;Modify=19990112033254; video D> Type=file;Size=30249;Modify=19990218032700; media-types S> 226 MLSD completed C> MLSD character-set-info S> 150 BINARY connection open for MLSD character-set-info D> Type=cdir;Modify=19990112033515; character-set-info D> Type=cdir;Modify=19990112033515; /iana/assignments/character-set-info D> Type=pdir;Modify=19990219183438; .. D> Type=file;Size=1234;Modify=19980903020400; windows-1251 D> Type=file;Size=4557;Modify=19980922001400; tis-620 D> Type=file;Size=801;Modify=19970324130000; ibm775 D> Type=file;Size=552;Modify=19970320130000; ibm866 D> Type=file;Size=922;Modify=19960505140000; windows-1258 S> 226 MLSD completed C> MLSD languages S> 150 BINARY connection open for MLSD languages D> Type=cdir;Modify=19990112033529; languages D> Type=cdir;Modify=19990112033529; /iana/assignments/languages D> Type=pdir;Modify=19990219183438; .. D> Type=file;Size=2391;Modify=19980309130000; default D> Type=file;Size=943;Modify=19980309130000; tags D> Type=file;Size=870;Modify=19971026130000; navajo D> Type=file;Size=699;Modify=19950911140000; no-bok S> 226 MLSD completed C> PWD S> 257 "/iana/assignments" is current directory.
C> MLSD S> 150バイナリ接続がMLSD用に開いています。 D> Type = cdir; Modify = 19990219183438; / iana / assignments D> Type = pdir; Modify = 19990112030453; .. D> Type = dir; Modify = 19990219073522; media-types D> Type = dir; Modify = 19990112033515;文字セット情報D> Type = dir; Modify = 19990112033529;言語D> Type = file; Size = 44242; Modify = 19990217230400;文字セットD> Type = file; Size = 1947; Modify = 19990209215600; operating-system-names S> 226 MLSD完了C> MLSDメディアタイプS> 150 MLSDメディアタイプ用のBINARY接続オープンD> Type = cdir; Modify = 19990219073522; media-types D> Type = cdir; Modify = 19990219073522; / iana / assignments / media-types D> Type = pdir; Modify = 19990219183438; .. D> Type = dir; Modify = 19990112033045;テキストD> Type = dir; Modify = 19990219183442;画像D> Type = dir; Modify = 19990112033216; multipart D> Type = dir; Modify = 19990112033254;ビデオD> Type = file; Size = 30249; Modify = 19990218032700; media-types S> 226 MLSD完了C> MLSD文字セット情報S> 150 MLSD文字セット情報用のBINARY接続オープンD> Type = cdir; Modify = 19990112033515; character-set-info D> Type = cdir; Modify = 19990112033515; / iana / assignments / character-set-info D> Type = pdir; Modify = 19990219183438; .. D> Type = file; Size = 1234; Modify = 19980903020400; windows-1251 D> Type = file; Size = 4557; Modify = 19980922001400; tis-620 D>タイプ=ファイル;サイズ= 801;変更= 19970324130000; ibm775 D>タイプ=ファイル;サイズ= 552;変更= 19970320130000; ibm866 D>タイプ=ファイル;サイズ= 922;修正= 19960505140000; windows-1258 S> 226 MLSD完了C> MLSD言語S> 150バイナリ接続がMLSD言語に対して開いているD> Type = cdir; Modify = 19990112033529;言語D> Type = cdir; Modify = 19990112033529; / iana / assignments / languages D> Type = pdir; Modify = 19990219183438; .. D> Type = file; Size = 2391; Modify = 19980309130000;デフォルトD> Type = file; Size = 943; Modify = 19980309130000;タグD>タイプ=ファイル;サイズ= 870;修正= 19971026130000; navajo D> Type = file; Size = 699; Modify = 19950911140000; no-bok S> 226 MLSD完了C> PWD S> 257 "/ iana / assignments"が現在のディレクトリです。
This example shows some of the IANA maintained files that are relevant for this specification in MLSD format. Note that these listings have been edited by deleting many entries, the actual listings are much longer.
この例は、MLSD形式のこの仕様に関連するいくつかのIANA保守ファイルを示しています。これらのリストは多くのエントリを削除することによって編集されていることに注意してください。実際のリストははるかに長くなります。
The following example is intended to make clear some cases where case dependent strings are permitted in the MLSx commands, and where case independent strings are required.
次の例は、MLSxコマンドで大文字小文字を区別する文字列が許可されている場合と、大文字小文字を区別しない文字列が必要な場合を明確にすることを目的としています。
Note first that the "MLSD" command, shown here as "MlsD" is case independent. Clients may issue this command in any case, or combination of cases, they desire. This is the case for all FTP commands.
最初に、ここで「MlsD」として示されている「MLSD」コマンドは、ケースに依存しないことに注意してください。クライアントは、必要に応じてこのコマンドを発行できます。これは、すべてのFTPコマンドに当てはまります。
C> MlsD
S> 150 BINARY connection open for MLSD .
D> Type=pdir;Modify=19990929011228;Perm=el;Unique=keVO1+ZF4; ..
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; FILE2
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+aG8; file3
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+ag8; FILE3
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file1
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file2
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Ag8; File3
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; File1
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; File2
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bd8; FILE1
S> 226 MLSD completed
Next, notice the labels of the facts. These are also case-independent strings; the server-FTP is permitted to return them in any case desired. User-FTP must be prepared to deal with any case, though it may do this by mapping the labels to a common case if desired.
次に、事実のラベルに注意してください。これらも大文字小文字を区別しない文字列です。サーバーFTPは、必要に応じてそれらを返すことができます。ユーザーFTPは、すべてのケースに対応できるように準備する必要がありますが、必要に応じて、ラベルを一般的なケースにマッピングすることでこれを行うことができます。
Then, notice that there are nine objects of "type" file returned. In a case-independent NVFS these would represent three different file names, "file1", "file2", and "file3". With a case-dependent NVFS all nine represent different file names. Either is possible, server-FTPs may implement a case dependent or a case independent NVFS. User-FTPs must allow for case dependent selection of files to manipulate on the server.
次に、「タイプ」ファイルの9つのオブジェクトが返されることに注意してください。ケースに依存しないNVFSでは、これらは3つの異なるファイル名「file1」、「file2」、および「file3」を表します。ケースに依存するNVFSでは、9つすべてが異なるファイル名を表します。どちらの方法も可能ですが、サーバーFTPはケース依存またはケース非依存のNVFSを実装できます。ユーザーFTPは、サーバーで操作するファイルの大文字と小文字を区別した選択を許可する必要があります。
Lastly, notice that the value of the "unique" fact is case dependent. In the example shown, "file1", "File1", and "file2" all have the same "unique" fact value "keVO1+bD8", and thus all represent the same underlying file. On the other hand, "FILE1" has a different "unique" fact value ("keVO1+bd8") and hence represents a different file. Similarly, "FILE2" and "File2" are two names for the same underlying file, whereas "file3", "File3" and "FILE3" all represent different underlying files.
最後に、「ユニーク」ファクトの値はケースに依存することに注意してください。示されている例では、「file1」、「File1」、および「file2」はすべて同じ「一意の」ファクト値「keVO1 + bD8」を持っているため、すべて同じ基本ファイルを表します。一方、「FILE1」は「一意の」ファクト値（「keVO1 + bd8」）が異なるため、異なるファイルを表します。同様に、「FILE2」と「File2」は同じ基本ファイルの2つの名前ですが、「file3」、「File3」、「FILE3」はすべて異なる基本ファイルを表します。
That the approximate sizes ("size" fact) and last modification times ("modify" fact) are the same in all cases might be no more than a coincidence.
おおよそのサイズ（「サイズ」ファクト）と最終変更時刻（「変更」ファクト）がすべての場合で同じであるということは、偶然の一致にすぎません。
It is not suggested that the operators of server-FTPs create an NVFS that stresses the protocols to this extent; however, both user and server implementations must be prepared to deal with such extreme examples.
サーバーFTPのオペレーターがこの範囲でプロトコルに負荷をかけるNVFSを作成することはお勧めしません。ただし、このような極端な例に対処するには、ユーザーとサーバーの両方の実装を準備する必要があります。
C> MlsD
S> 150 File Listing Follows in IMAGE / Binary mode.
D> type=cdir;modify=19990426150227;perm=el; /MISC
D> type=pdir;modify=19791231130000;perm=el; /
D> type=dir;modify=19990426150227;perm=el; CVS
D> type=dir;modify=19990426150228;perm=el; SRC
S> 226 Transfer finished successfully.
C> MlsD src
S> 150 File Listing Follows in IMAGE / Binary mode.
D> type=cdir;modify=19990426150228;perm=el; /MISC/src
D> type=pdir;modify=19990426150227;perm=el; /MISC
D> type=dir;modify=19990426150228;perm=el; CVS
D> type=dir;modify=19990426150228;perm=el; INSTALL
D> type=dir;modify=19990426150230;perm=el; INSTALLI
D> type=dir;modify=19990426150230;perm=el; TREES
S> 226 Transfer finished successfully.
C> MlsD src/install
S> 150 File Listing Follows in IMAGE / Binary mode.
D> type=cdir;modify=19990426150228;perm=el; /MISC/src/install
D> type=pdir;modify=19990426150228;perm=el; /MISC/src
D> type=file;modify=19990406234304;perm=r;size=20059; BOOTPC.C
D> type=file;modify=19980401170153;perm=r;size=278; BOOTPC.H
D> type=file;modify=19990413153736;perm=r;size=54220; BOOTPC.O
D> type=file;modify=19990223044003;perm=r;size=3389; CDROM.C
D> type=file;modify=19990413153739;perm=r;size=30192; CDROM.O
D> type=file;modify=19981119155324;perm=r;size=1055; CHANGELO
D> type=file;modify=19981204171040;perm=r;size=8297; COMMANDS.C
D> type=file;modify=19980508041749;perm=r;size=580; COMMANDS.H
...
D> type=file;modify=19990419052351;perm=r;size=54264; URLMETHO.O
D> type=file;modify=19980218161629;perm=r;size=993; WINDOWS.C
D> type=file;modify=19970912154859;perm=r;size=146; WINDOWS.H
D> type=file;modify=19990413153731;perm=r;size=16812; WINDOWS.O
D> type=file;modify=19990322174959;perm=r;size=129; _CVSIGNO
D> type=file;modify=19990413153640;perm=r;size=82536; _DEPEND
S> 226 Transfer finished successfully.
C> MLst src/install/windows.c
S> 250-Listing src/install/windows.c
S> type=file;perm=r;size=993; /misc/src/install/windows.c
S> 250 End
S> ftp> mlst SRC/INSTALL/WINDOWS.C
C> MLst SRC/INSTALL/WINDOWS.C
S> 250-Listing SRC/INSTALL/WINDOWS.C
S> type=file;perm=r;size=993; /misc/SRC/INSTALL/WINDOWS.C
S> 250 End
Note that this server gives fully qualified pathnames for the "pdir" and "cdir" entries in MLSD listings. Also notice that this server does, though it is not required to, sort its directory listing outputs. That may be an artifact of the underlying file system access mechanisms of course. Finally notice that the NVFS supported by this server, in contrast to the earlier ones, implements its pathnames in a case independent manner. The server seems to return files using the case in which they were requested, when the name was sent by the client, and otherwise uses an algorithm known only to itself to select the case of the names it returns.
このサーバーは、MLSDリストの「pdir」および「cdir」エントリに完全修飾パス名を提供することに注意してください。また、必須ではありませんが、このサーバーはディレクトリリストの出力を並べ替えます。もちろん、これは基礎となるファイルシステムアクセスメカニズムのアーチファクトである可能性があります。最後に、このサーバーでサポートされているNVFSは、以前のサーバーとは対照的に、パス名をケースに依存しない方法で実装していることに注意してください。サーバーは、クライアントから名前が送信されたときに、要求されたケースを使用してファイルを返すようです。それ以外の場合は、サーバーだけが知っているアルゴリズムを使用して、返される名前のケースを選択します。
C> MLst f S> 250-MLST f S> Type=dir;Modify=20000710052229;Unique=AAD/AAAABIA; f S> 250 End C> CWD f S> 250 CWD command successful. C> MLSD S> 150 Opening ASCII mode data connection for 'MLSD'. D> Type=cdir;Unique=AAD/AAAABIA; . D> Type=pdir;Unique=AAD/AAAAAAI; .. D> Type=file;Size=987;Unique=AAD/AAAABIE; Makefile D> Type=file;Size=20148;Unique=AAD/AAAABII; conf.c D> Type=file;Size=11111;Unique=AAD/AAAABIM; extern.h D> Type=file;Size=38721;Unique=AAD/AAAABIQ; ftpcmd.y D> Type=file;Size=17922;Unique=AAD/AAAABIU; ftpd.8 D> Type=file;Size=60732;Unique=AAD/AAAABIY; ftpd.c D> Type=file;Size=3127;Unique=AAD/AAAABIc; logwtmp.c D> Type=file;Size=2294;Unique=AAD/AAAABIg; pathnames.h D> Type=file;Size=7605;Unique=AAD/AAAABIk; popen.c D> Type=file;Size=9951;Unique=AAD/AAAABIo; ftpd.conf.5 D> Type=file;Size=5023;Unique=AAD/AAAABIs; ftpusers.5 D> Type=file;Size=3547;Unique=AAD/AAAABIw; logutmp.c D> Type=file;Size=2064;Unique=AAD/AAAABI0; version.h D> Type=file;Size=20420;Unique=AAD/AAAAAAM; cmds.c D> Type=file;Size=15864;Unique=AAD/AAAAAAg; ls.c D> Type=file;Size=2898;Unique=AAD/AAAAAAk; ls.h D> Type=file;Size=2769;Unique=AAD/AAAAAAo; lsextern.h D> Type=file;Size=2042;Unique=AAD/AAAAAAs; stat_flags.h D> Type=file;Size=5708;Unique=AAD/AAAAAAw; cmp.c D> Type=file;Size=9280;Unique=AAD/AAAAAA0; print.c D> Type=file;Size=4657;Unique=AAD/AAAAAA4; stat_flags.c D> Type=file;Size=2664;Unique=AAD/AAAAAA8; util.c D> Type=file;Size=10383;Unique=AAD/AAAABJ0; ftpd.conf.cat5 D> Type=file;Size=3631;Unique=AAD/AAAABJ4; ftpusers.cat5 D> Type=file;Size=17729;Unique=AAD/AAAABJ8; ftpd.cat8 S> 226 MLSD complete.
C> MLst f S> 250-MLST f S> Type = dir; Modify = 20000710052229; Unique = AAD / AAAABIA; f S> 250終了C> CWD f S> 250 CWDコマンドが成功しました。 C> MLSD S> 150「MLSD」のASCIIモードデータ接続を開いています。 D> Type = cdir; Unique = AAD / AAAABIA; 。 D> Type = pdir; Unique = AAD / AAAAAAI; .. D> Type = file; Size = 987; Unique = AAD / AAAABIE; Makefile D> Type = file; Size = 20148; Unique = AAD / AAAABII; conf.c D> Type = file; Size = 11111; Unique = AAD / AAAABIM; extern.h D> Type = file; Size = 38721; Unique = AAD / AAAABIQ; ftpcmd.y D> Type = file; Size = 17922; Unique = AAD / AAAABIU; ftpd.8 D> Type = file; Size = 60732; Unique = AAD / AAAABIY; ftpd.c D> Type = file; Size = 3127; Unique = AAD / AAAABIc; logwtmp.c D> Type = file; Size = 2294; Unique = AAD / AAAABIg; pathnames.h D> Type = file; Size = 7605; Unique = AAD / AAAABIk; popen.c D> Type = file; Size = 9951; Unique = AAD / AAAABIo; ftpd.conf.5 D> Type = file; Size = 5023; Unique = AAD / AAAABIs; ftpusers.5 D> Type = file; Size = 3547; Unique = AAD / AAAABIw; logutmp.c D> Type = file; Size = 2064; Unique = AAD / AAAABI0; version.h D> Type = file; Size = 20420; Unique = AAD / AAAAAAM; cmds.c D> Type = file; Size = 15864; Unique = AAD / AAAAAAg; ls.c D> Type = file; Size = 2898; Unique = AAD / AAAAAAk; ls.h D> Type = file; Size = 2769; Unique = AAD / AAAAAAo; lsextern.h D> Type = file; Size = 2042; Unique = AAD / AAAAAAs; stat_flags.h D> Type = file; Size = 5708; Unique = AAD / AAAAAAw; cmp.c D> Type = file; Size = 9280; Unique = AAD / AAAAAA0; print.c D> Type = file; Size = 4657; Unique = AAD / AAAAAA4; stat_flags.c D> Type = file; Size = 2664; Unique = AAD / AAAAAA8; util.c D> Type = file; Size = 10383; Unique = AAD / AAAABJ0; ftpd.conf.cat5 D> Type = file; Size = 3631; Unique = AAD / AAAABJ4; ftpusers.cat5 D> Type = file; Size = 17729; Unique = AAD / AAAABJ8; ftpd.cat8 S> 226 MLSDが完了しました。
This examples shows yet another server implementation, showing a listing of its own source code. Note that this implementation does not include the fully qualified path name in its "cdir" and "pdir" entries, nor in the output from "MLST". Also note that the facts requested were modified between the "MLST" and "MLSD" commands, though that exchange has not been shown here.
この例は、さらに別のサーバー実装を示し、独自のソースコードのリストを示しています。この実装では、「cdir」および「pdir」エントリ、および「MLST」からの出力に完全修飾パス名が含まれていないことに注意してください。また、ここでは示されていませんが、要求されたファクトは「MLST」コマンドと「MLSD」コマンドの間で変更されました。
C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,46) C> MLSD S> 150 I tink I tee a trisector tree D> Type=file;Unique=aaaaafUYqaaa;Perm=rf;Size=15741; x D> Type=cdir;Unique=aaaaacUYqaaa;Perm=cpmel; / D> Type=file;Unique=aaaaajUYqaaa;Perm=rf;Size=5760; x4 D> Type=dir;Unique=aaabcaUYqaaa;Perm=elf; sub D> Type=file;Unique=aaaaagUYqaaa;Perm=rf;Size=8043; x1 D> Type=dir;Unique=aaab8aUYqaaa;Perm=cpmelf; files D> Type=file;Unique=aaaaahUYqaaa;Perm=rf;Size=4983; x2 D> Type=file;Unique=aaaaaiUYqaaa;Perm=rf;Size=6854; x3 S> 226 That's all folks... C> CWD sub S> 250 CWD command successful. C> PWD S> 257 "/sub" is current directory. C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,44) C> MLSD S> 150 I tink I tee a trisector tree D> Type=dir;Unique=aaabceUYqaaa;Perm=elf; dir D> Type=file;Unique=aaabcbUYqaaa;Perm=rf;Size=0; y1 D> Type=file;Unique=aaabccUYqaaa;Perm=rf;Size=0; y2 D> Type=file;Unique=aaabcdUYqaaa;Perm=rf;Size=0; y3 D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; / D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; .. D> Type=cdir;Unique=aaabcaUYqaaa;Perm=el; /sub S> 226 That's all folks... C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,42) C> MLSD dir S> 150 I tink I tee a trisector tree D> Type=pdir;Unique=aaabcaUYqaaa;Perm=el; /sub D> Type=pdir;Unique=aaabcaUYqaaa;Perm=el; .. D> Type=file;Unique=aaab8cUYqaaa;Perm=r;Size=15039; mlst.c D> Type=dir;Unique=aaabcfUYqaaa;Perm=el; ect D> Type=cdir;Unique=aaabceUYqaaa;Perm=el; dir D> Type=cdir;Unique=aaabceUYqaaa;Perm=el; /sub/dir D> Type=dir;Unique=aaabchUYqaaa;Perm=el; misc D> Type=file;Unique=aaab8bUYqaaa;Perm=r;Size=34589; ftpd.c S> 226 That's all folks... C> CWD dir/ect S> 250 CWD command successful. C> PWD S> 257 "/sub/dir/ect" is current directory. C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,40) C> MLSD S> 150 I tink I tee a trisector tree D> Type=dir;Unique=aaabcgUYqaaa;Perm=el; ory D> Type=pdir;Unique=aaabceUYqaaa;Perm=el; /sub/dir D> Type=pdir;Unique=aaabceUYqaaa;Perm=el; .. D> Type=cdir;Unique=aaabcfUYqaaa;Perm=el; /sub/dir/ect S> 226 That's all folks... C> CWD /files S> 250 CWD command successful. C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,36) C> MLSD S> 150 I tink I tee a trisector tree D> Type=cdir;Unique=aaab8aUYqaaa;Perm=cpmel; /files D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; / D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; .. D> Type=file;Unique=aaab8cUYqaaa;Perm=rf;Size=15039; mlst.c D> Type=file;Unique=aaab8bUYqaaa;Perm=rf;Size=34589; ftpd.c S> 226 That's all folks...
C> PASV S> 227パッシブモードの開始（127,0,0,1,255,46）C> MLSD S> 150ティンクトライセクターツリーのティーD> Type = file; Unique = aaaaafUYqaaa; Perm = rf; Size = 15741 ; x D> Type = cdir; Unique = aaaaacUYqaaa; Perm = cpmel; / D> Type = file; Unique = aaaaajUYqaaa; Perm = rf; Size = 5760; x4 D> Type = dir; Unique = aaabcaUYqaaa; Perm = elf; sub D> Type = file; Unique = aaaaagUYqaaa; Perm = rf; Size = 8043; x1 D> Type = dir; Unique = aaab8aUYqaaa; Perm = cpmelf;ファイルD> Type = file; Unique = aaaaahUYqaaa; Perm = rf; Size = 4983; x2 D> Type = file; Unique = aaaaaiUYqaaa; Perm = rf; Size = 6854; x3 S> 226以上です... C> CWDサブS> 250 CWDコマンドが成功しました。 C> PWD S> 257 "/ sub"が現在のディレクトリです。 C> PASV S> 227パッシブモードの開始（127,0,0,1,255,44）C> MLSD S> 150ティンクトライセクターツリーをティーしますD> Type = dir; Unique = aaabceUYqaaa; Perm = elf; dir D> Type = file; Unique = aaabcbUYqaaa; Perm = rf; Size = 0; y1 D> Type = file; Unique = aaabccUYqaaa; Perm = rf; Size = 0; y2 D> Type = file; Unique = aaabcdUYqaaa; Perm = rf; Size = 0; y3 D> Type = pdir; Unique = aaaaacUYqaaa; Perm = cpmel; / D> Type = pdir; Unique = aaaaacUYqaaa; Perm = cpmel; .. D> Type = cdir; Unique = aaabcaUYqaaa; Perm = el; / sub S> 226これで終わりです... C> PASV S> 227パッシブモードの開始（127,0,0,1,255,42）C> MLSD dir S> 150ティンクIトライセクターツリーD> Type = pdir ; Unique = aaabcaUYqaaa; Perm = el; / sub D> Type = pdir; Unique = aaabcaUYqaaa; Perm = el; .. D> Type = file; Unique = aaab8cUYqaaa; Perm = r; Size = 15039; mlst.c D> Type = dir; Unique = aaabcfUYqaaa; Perm = el; ect D> Type = cdir; Unique = aaabceUYqaaa; Perm = el; dir D> Type = cdir; Unique = aaabceUYqaaa; Perm = el; / sub / dir D> Type = dir; Unique = aaabchUYqaaa; Perm = el; misc D> Type = file; Unique = aaab8bUYqaaa; Perm = r; Size = 34589; ftpd.c S> 226以上です... C> CWD dir / ect S> 250 CWDコマンドが成功しました。 C> PWD S> 257 "/ sub / dir / ect"が現在のディレクトリです。 C> PASV S> 227パッシブモードの開始（127,0,0,1,255,40）C> MLSD S> 150ティンク3セクターツリーをティーしますD> Type = dir; Unique = aaabcgUYqaaa; Perm = el; ory D> Type = pdir; Unique = aaabceUYqaaa; Perm = el; / sub / dir D> Type = pdir; Unique = aaabceUYqaaa; Perm = el; .. D> Type = cdir; Unique = aaabcfUYqaaa; Perm = el; / sub / dir / ect S> 226以上です... C> CWD / files S> 250 CWDコマンドが成功しました。 C> PASV S> 227パッシブモードの開始（127,0,0,1,255,36）C> MLSD S> 150ティンクトライセクターツリーをティーD> Type = cdir; Unique = aaab8aUYqaaa; Perm = cpmel; / files D> Type = pdir; Unique = aaaaacUYqaaa; Perm = cpmel; / D> Type = pdir; Unique = aaaaacUYqaaa; Perm = cpmel; .. D> Type = file; Unique = aaab8cUYqaaa; Perm = rf; Size = 15039; mlst.c D> Type = file; Unique = aaab8bUYqaaa; Perm = rf; Size = 34589; ftpd.c S> 226以上です...
C> RNFR mlst.c S> 350 File exists, ready for destination name C> RNTO list.c S> 250 RNTO command successful. C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,34) C> MLSD S> 150 I tink I tee a trisector tree D> Type=file;Unique=aaab8cUYqaaa;Perm=rf;Size=15039; list.c D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; / D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; .. D> Type=file;Unique=aaab8bUYqaaa;Perm=rf;Size=34589; ftpd.c D> Type=cdir;Unique=aaab8aUYqaaa;Perm=cpmel; /files S> 226 That's all folks...
C> RNFR mlst.c S> 350ファイルが存在し、宛先名の準備ができていますC> RNTO list.c S> 250 RNTOコマンドが成功しました。 C> PASV S> 227パッシブモードの開始（127,0,0,1,255,34）C> MLSD S> 150ティンクトライセクターツリーのティーD> Type = file; Unique = aaab8cUYqaaa; Perm = rf; Size = 15039 ; list.c D> Type = pdir; Unique = aaaaacUYqaaa; Perm = cpmel; / D> Type = pdir; Unique = aaaaacUYqaaa; Perm = cpmel; .. D> Type = file; Unique = aaab8bUYqaaa; Perm = rf; Size = 34589; ftpd.c D> Type = cdir; Unique = aaab8aUYqaaa; Perm = cpmel; / files S> 226これで全員です...
The server shown here returns its directory listings in seemingly random order, and even seems to modify the order of the directory as its contents change -- perhaps the underlying directory structure is based upon hashing of some kind. Note that the "pdir" and "cdir" entries are interspersed with other entries in the directory. Note also that this server does not show a "pdir" entry when listing the contents of the root directory of the virtual filestore; however, it does however include multiple "cdir" and "pdir" entries when it feels inclined. The server also uses obnoxiously "cute" messages.
ここに示されているサーバーは、ディレクトリのリストを一見ランダムな順序で返し、コンテンツが変化するとディレクトリの順序を変更しているように見えます。おそらく、基礎となるディレクトリ構造は何らかのハッシュに基づいています。 「pdir」および「cdir」エントリは、ディレクトリ内の他のエントリと混在していることに注意してください。また、このサーバーは、仮想ファイルストアのルートディレクトリの内容を一覧表示するときに「pdir」エントリを表示しないことに注意してください。ただし、傾斜していると感じる場合は、複数の「cdir」および「pdir」エントリが含まれます。サーバーはまた、不愉快に「かわいい」メッセージを使用します。
When responding to the FEAT command, a server-FTP process that supports MLST, and MLSD, plus internationalization of pathnames, MUST indicate that this support exists. It does this by including a MLST feature line. As well as indicating the basic support, the MLST feature line indicates which MLST facts are available from the server, and which of those will be returned if no subsequent "OPTS MLST" command is sent.
FEATコマンドに応答するとき、MLSTおよびMLSDに加えてパス名の国際化をサポートするサーバーFTPプロセスは、このサポートが存在することを示さなければなりません（MUST）。これは、MLST計画線を含めることによって行われます。 MLSTフィーチャーラインは、基本的なサポートを示すだけでなく、サーバーから利用可能なMLSTファクトと、後続の「OPTS MLST」コマンドが送信されない場合に返されるファクトを示します。
mlst-feat = SP "MLST" [SP factlist] CRLF
factlist = 1*( factname ["*"] ";" )
The initial space shown in the mlst-feat response is that required by the FEAT command, two spaces are not permitted. If no factlist is given, then the server-FTP process is indicating that it supports MLST, but implements no facts. Only pathnames can be returned. This would be a minimal MLST implementation, and useless for most practical purposes. Where the factlist is present, the factnames included indicate the facts supported by the server. Where the optional asterisk appears after a factname, that fact will be included in MLST format responses, until an "OPTS MLST" is given to alter the list of facts returned. After that, subsequent FEAT commands will return the asterisk to show the facts selected by the most recent "OPTS MLST".
mlst-feat応答に表示される最初のスペースはFEATコマンドで必要なスペースであり、2つのスペースは許可されていません。ファクトリストが指定されていない場合、サーバーFTPプロセスはMLSTをサポートしていることを示していますが、ファクトは実装していません。返されるのはパス名のみです。これは最小限のMLST実装であり、ほとんどの実用的な目的には役に立たないでしょう。ファクトリストが存在する場合、含まれるファクト名はサーバーがサポートするファクトを示します。ファクト名の後にオプションのアスタリスクが表示される場合、返されるファクトのリストを変更するために「OPTS MLST」が指定されるまで、そのファクトはMLST形式の応答に含まれます。その後、後続のFEATコマンドはアスタリスクを返し、最新の「OPTS MLST」によって選択されたファクトを表示します。
Note that there is no distinct FEAT output for MLSD. The presence of the MLST feature indicates that both MLST and MLSD are supported.
MLSDには明確なFEAT出力がないことに注意してください。 MOST機能の存在は、NLSTとMLSDの両方がサポートされていることを示しています。
C> Feat
S> 211- Features supported
S> REST STREAM
S> MDTM
S> SIZE
S> TVFS
S> UTF8
S> MLST Type*;Size*;Modify*;Perm*;Unique*;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
Aside from some features irrelevant here, this server indicates that it supports MLST including several, but not all, standard facts, all of which it will send by default. It also supports two OS dependent facts, and one locally defined fact. The latter three must be requested expressly by the client for this server to supply them.
ここに関係のないいくつかの機能は別として、このサーバーは、すべてではなくいくつかの標準ファクトを含むMLSTをサポートしていることを示します。これらのファクトはすべてデフォルトで送信されます。また、2つのOS依存ファクトと1つのローカル定義ファクトもサポートしています。後者の3つは、このサーバーがクライアントに提供するために、クライアントから明示的に要求される必要があります。
C> Feat S> 211-Extensions supported: S> CLNT S> MDTM S> MLST type*;size*;modify*;UNIX.mode*;UNIX.owner;UNIX.group;unique; S> PASV S> REST STREAM S> SIZE S> TVFS S> Compliance Level: 19981201 (IETF mlst-05) S> 211 End.
C>特技S> 211-サポートされる拡張機能：S> CLNT S> MDTM S> MLSTタイプ*;サイズ*;変更*; UNIX.mode *; UNIX.owner; UNIX.group; unique; S> PASV S> REST STREAM S>サイズS> TVFS S>コンプライアンスレベル：19981201（IETF mlst-05）S> 211終了。
Again, in addition to some irrelevant features here, this server indicates that it supports MLST, four of the standard facts, one of which ("unique") is not enabled by default, and several OS dependent facts, one of which is provided by the server by default. This server actually supported more OS dependent facts. Others were deleted for the purposes of this document to comply with document formatting restrictions.
繰り返しますが、ここではいくつかの無関係な機能に加えて、このサーバーはMLST、4つの標準ファクト、そのうちの1つ（「一意」）がデフォルトで有効になっていないこと、および1つが以下によって提供されるOS依存ファクトをサポートしていることを示しています。デフォルトではサーバー。このサーバーは、実際にはより多くのOS依存の事実をサポートしていました。他のドキュメントは、ドキュメントのフォーマット制限に準拠するために、このドキュメントの目的で削除されました。
C> FEAT
S> 211-Features supported
S> MDTM
S> MLST Type*;Size*;Modify*;Perm;Unique*;
S> REST STREAM
S> SIZE
S> TVFS
S> 211 End
This server has wisely chosen not to implement any OS dependent facts. At the time of writing this document, no such facts have been defined (using the mechanisms of section 10.1) so rational support for them would be difficult at best. All but one of the facts supported by this server are enabled by default.
このサーバーは、OSに依存するファクトを実装しないことを賢明に選択しています。このドキュメントの執筆時点では、そのような事実は（セクション10.1のメカニズムを使用して）定義されていないため、合理的なサポートはせいぜい困難です。このサーバーでサポートされている1つのファクトを除くすべてがデフォルトで有効になっています。
For the MLSx commands, the Client-FTP may specify a list of facts it wishes to be returned in all subsequent MLSx commands until another OPTS MLST command is sent. The format is specified by:
MLSxコマンドの場合、クライアントFTPは、別のOPTS MLSTコマンドが送信されるまで、後続のすべてのMLSxコマンドで返されるファクトのリストを指定できます。形式は次のように指定されます。
mlst-opts = "OPTS" SP "MLST" [ SP 1*( factname ";" ) ]
mlst-opts = "OPTS" SP "MLST" [SP 1 *（factname ";"）]
By sending the "OPTS MLST" command, the client requests the server to include only the facts listed as arguments to the command in subsequent output from MLSx commands. Facts not included in the "OPTS MLST" command MUST NOT be returned by the server. Facts that are included should be returned for each entry returned from the MLSx command where they meaningfully apply. Facts requested that are not supported, or that are inappropriate to the file or directory being listed should simply be omitted from the MLSx output. This is not an error. Note that where no factname arguments are present, the client is requesting that only the file names be returned. In this case, and in any other case where no facts are included in the result, the space that separates the fact names and their values from the file name is still required. That is, the first character of the output line will be a space, (or two characters will be spaces when the line is returned over the control connection) and the file name will start immediately thereafter.
「OPTS MLST」コマンドを送信することにより、クライアントはサーバーに、MLSxコマンドからの後続の出力にコマンドの引数としてリストされたファクトのみを含めるように要求します。 「OPTS MLST」コマンドに含まれていないファクトは、サーバーから返されてはなりません。含まれているファクトは、MLSxコマンドから返されたエントリごとに、それらが意味をもって適用される場合に返される必要があります。サポートされていない、またはリストされているファイルまたはディレクトリに不適切な要求されたファクトは、MLSx出力から単純に省略されます。これはエラーではありません。 factname引数が存在しない場合、クライアントはファイル名のみを返すように要求していることに注意してください。この場合、およびファクトが結果に含まれていないその他の場合でも、ファクト名とその値をファイル名から区切るスペースが必要です。つまり、出力行の最初の文字はスペース（または、制御接続を介して行が返される場合は2文字がスペースになります）となり、その直後にファイル名が始まります。
Clients should note that generating values for some facts can be possible, but very expensive, for some servers. It is generally acceptable to retrieve any of the facts that the server offers as its default set before any "OPTS MLST" command has been given, however clients should use particular caution before requesting any facts not in that set. That is, while other facts may be available from the server, clients should refrain from requesting such facts unless there is a particular operational requirement for that particular information, which ought be more significant than perhaps simply improving the information displayed to an end user.
クライアントは、一部のファクトの値を生成することは可能ですが、一部のサーバーでは非常に高価になることに注意してください。 「OPTS MLST」コマンドを指定する前に、サーバーがデフォルトセットとして提供するファクトを取得することは一般的に許容されますが、クライアントはそのセットにないファクトを要求する前に特に注意する必要があります。つまり、サーバーから他のファクトを入手できる可能性がありますが、エンドユーザーに表示される情報を単に改善するよりも重要な特定の情報に対する特定の運用要件がない限り、クライアントはそのようなファクトを要求しないでください。
Note, there is no "OPTS MLSD" command, the fact names set with the "OPTS MLST" command apply to both MLST and MLSD commands.
「OPTS MLSD」コマンドはありません。「OPTS MLST」コマンドで設定されたファクト名は、MLSTコマンドとMLSDコマンドの両方に適用されます。
Servers are not required to accept "OPTS MLST" commands before authentication of the user-PI, but may choose to permit them.
サーバーは、ユーザーPIの認証前に「OPTS MLST」コマンドを受け入れる必要はありませんが、許可することを選択できます。
The "response-message" from [6] to a successful OPTS MLST command has the following syntax.
[6]から成功したOPTS MLSTコマンドへの「応答メッセージ」の構文は次のとおりです。
mlst-opt-resp = "MLST OPTS" [ SP 1*( factname ";" ) ]
This defines the "response-message" as used in the "opts-good" message in RFC 2389 [6].
これは、RFC 2389 [6]の「opts-good」メッセージで使用される「response-message」を定義します。
The facts named in the response are those that the server will now include in MLST (and MLSD) response, after the processing of the "OPTS MLST" command. Any facts from the request not supported by the server will be omitted from this response message. If no facts will be included, the list of facts will be empty. Note that the list of facts returned will be the same as those marked by a trailing asterisk ("*") in a subsequent FEAT command response. There is no requirement that the order of the facts returned be the same as that in which they were requested, or that in which they will be listed in a FEAT command response, or that in which facts are returned in MLST responses. The fixed string "MLST OPTS" in the response may be returned in any case, or mixture of cases.
応答で名前が付けられたファクトは、「OPTS MLST」コマンドの処理後に、サーバーがMLST（およびMLSD）応答に含めるものです。サーバーでサポートされていない要求のファクトは、この応答メッセージから省略されます。ファクトが含まれない場合、ファクトのリストは空になります。返されるファクトのリストは、後続のFEATコマンド応答で末尾のアスタリスク（ "*"）によってマークされたものと同じになることに注意してください。返されるファクトの順序が、要求されたファクトの順序、またはFEATコマンド応答にリストされるファクトの順序、またはファクトがMLST応答で返される順序と同じである必要はありません。応答の固定文字列「MLST OPTS」は、いずれの場合でも、または混合して返される場合があります。
C> Feat
S> 211- Features supported
S> MLST Type*;Size;Modify*;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
C> OptS Mlst Type;UNIX.mode;Perm;
S> 200 MLST OPTS Type;Perm;UNIX.mode;
C> Feat
S> 211- Features supported
S> MLST Type*;Size;Modify;Perm*;Unique;UNIX.mode*;UNIX.chgd;X.hidden;
S> 211 End
C> opts MLst lang;type;charset;create;
S> 200 MLST OPTS Type;
C> Feat
S> 211- Features supported
S> MLST Type*;Size;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
C> OPTS mlst size;frogs;
S> 200 MLST OPTS Size;
C> Feat
S> 211- Features supported
S> MLST Type;Size*;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
C> opts MLst unique type;
S> 501 Invalid MLST options
C> Feat
S> 211- Features supported
S> MLST Type;Size*;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
For the purposes of this example, features other than MLST have been deleted from the output to avoid clutter. The example shows the initial default feature output for MLST. The facts requested are then changed by the client. The first change shows facts that are available from the server being selected. Subsequent FEAT output shows the altered features as being returned. The client then attempts to select some standard features that the server does not support. This is not an error, however the server simply ignores the requests for unsupported features, as the FEAT output that follows shows. Then, the client attempts to request a non-standard, and unsupported, feature. The server ignores that, and selects only the supported features requested. Lastly, the client sends a request containing a syntax error (spaces cannot appear in the factlist.) The server-FTP sends an error response and completely ignores the request, leaving the fact set selected as it had been previously.
この例では、混乱を避けるために、MLST以外の機能が出力から削除されています。この例は、MLSTの初期デフォルト機能出力を示しています。次に、要求されたファクトがクライアントによって変更されます。最初の変更は、選択されているサーバーから利用可能なファクトを示しています。後続のFEAT出力は、変更されたフィーチャーが返されたことを示しています。次に、クライアントは、サーバーがサポートしていないいくつかの標準機能を選択しようとします。これはエラーではありませんが、次のFEAT出力が示すように、サーバーはサポートされていない機能の要求を単に無視します。次に、クライアントは非標準のサポートされていない機能を要求しようとします。サーバーはそれを無視し、要求されたサポートされている機能のみを選択します。最後に、クライアントは構文エラーを含む要求を送信します（スペースはファクトリストに表示できません）。サーバーFTPはエラー応答を送信し、要求を完全に無視して、以前と同じファクトセットを選択したままにします。
Note that in all cases, except the error response, the response lists the facts that have been selected.
エラーレスポンスを除くすべてのケースで、レスポンスには選択されたファクトがリストされることに注意してください。
C> Feat
S> 211- Features supported
S> MLST Type*;Size*;Modify*;Perm*;Unique*;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
C> Opts MLST
S> 200 MLST OPTS
C> Feat
S> 211- Features supported
S> MLST Type;Size;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
C> MLst tmp
S> 250- Listing tmp
S> /tmp
S> 250 End
C> OPTS mlst unique;size;
S> 200 MLST OPTS Size;Unique;
C> MLst tmp
S> 250- Listing tmp
S> Unique=keVO1+YZ5; /tmp
S> 250 End
C> OPTS mlst unique;type;modify;
S> 200 MLST OPTS Type;Modify;Unique;
C> MLst tmp
S> 250- Listing tmp
S> Type=dir;Modify=19990930152225;Unique=keVO1+YZ5; /tmp
S> 250 End
C> OPTS mlst fish;cakes;
S> 200 MLST OPTS
C> MLst tmp
S> 250- Listing tmp
S> /tmp
S> 250 End
C> OptS Mlst Modify;Unique;
S> 200 MLST OPTS Modify;Unique;
C> MLst tmp
S> 250- Listing tmp
S> Modify=19990930152225;Unique=keVO1+YZ5; /tmp
S> 250 End
C> opts MLst fish cakes;
S> 501 Invalid MLST options
C> MLst tmp
S> 250- Listing tmp
S> Modify=19990930152225;Unique=keVO1+YZ5; /tmp
S> 250 End
This example shows the effect of changing the facts requested upon subsequent MLST commands. Notice that a syntax error leaves the set of selected facts unchanged. Also notice exactly two spaces preceding the pathname when no facts were selected, either deliberately, or because none of the facts requested were available.
この例は、後続のMLSTコマンドで要求されたファクトを変更した場合の影響を示しています。構文エラーにより、選択したファクトのセットが変更されないことに注意してください。また、意図的に、または要求されたファクトがいずれも利用できなかったためにファクトが選択されなかった場合は、パス名の前にちょうど2つのスペースがあることに注意してください。
Along with the introduction of MLST, traditional FTP commands must be extended to allow for the use of more than US-ASCII [1] or EBCDIC character sets. In general, the support of MLST requires support for arbitrary character sets wherever file names and directory names are allowed. This applies equally to both arguments given to the following commands and to the replies from them, as appropriate.
MLSTの導入に伴い、US-ASCII [1]またはEBCDIC文字セット以外の文字セットを使用できるように、従来のFTPコマンドを拡張する必要があります。一般に、MLSTのサポートには、ファイル名とディレクトリ名が許可されている任意の文字セットのサポートが必要です。これは、必要に応じて、以下のコマンドに与えられる引数とそれらからの応答の両方に等しく適用されます。
APPE RMD CWD RNFR DELE RNTO MKD STAT PWD STOR RETR STOU
APPE RMD CWD RNFR DELE RNTO MKD STAT PWD STOR RETR STOU
The arguments to all of these commands should be processed the same way that MLST commands and responses are processed with respect to handling embedded spaces, CRs and NULs. See section 2.2.
これらすべてのコマンドの引数は、埋め込みスペース、CR、NULの処理に関してMLSTコマンドと応答を処理するのと同じ方法で処理する必要があります。セクション2.2を参照してください。
FTP commands are protocol elements, and are always expressed in ASCII. FTP responses are composed of the numeric code, which is a protocol element, and a message, which is often expected to convey information to the user. It is not expected that users normally interact directly with the protocol elements, rather the user-FTP process constructs the commands, and interprets the results, in the manner best suited for the particular user. Explanatory text in responses generally has no particular meaning to the protocol. The numeric codes provide all necessary information. Server-PIs are free to provide the text in any language that can be adequately represented in ASCII, or where an alternative language and representation has been negotiated (see [7]) in that language and representation.
FTPコマンドはプロトコル要素であり、常にASCIIで表現されます。 FTP応答は、プロトコル要素である数値コードと、ユーザーに情報を伝えることが期待されるメッセージで構成されます。通常、ユーザーがプロトコル要素と直接対話することは想定されていません。ユーザーFTPプロセスは、特定のユーザーに最適な方法でコマンドを作成し、結果を解釈します。応答の説明文は、通常、プロトコルに対して特別な意味はありません。数値コードはすべての必要な情報を提供します。サーバーPIは、ASCIIで適切に表現できる任意の言語、または代替言語と表現がその言語と表現でネゴシエートされている場合（[7]を参照）、自由にテキストを提供できます。
Pathnames are expected to be encoded in UTF-8 allowing essentially any character to be represented in a pathname. Meaningful pathnames are defined by the server NVFS.
パス名はUTF-8でエンコードされており、本質的に任意の文字をパス名で表すことができます。意味のあるパス名は、サーバーのNVFSによって定義されます。
No restrictions at all are placed upon the contents of files transferred using the FTP protocols. Unless the "media-type" fact is provided in a MLSx response nor is any advice given here that would allow determining the content type. That information is assumed to be obtained via other means.
FTPプロトコルを使用して転送されるファイルの内容には何の制限もありません。 「メディアタイプ」の事実がMLSx応答で提供されていない場合や、コンテンツタイプを決定できるようにするためのアドバイスがここで提供されていない場合を除きます。その情報は、他の手段によって取得されると想定されます。
This specification makes use of some lists of values currently maintained by the IANA, and creates two new lists for the IANA to maintain. It does not add any values to any existing registries.
この仕様は、IANAによって現在維持されているいくつかの値のリストを利用し、IANAが維持する2つの新しいリストを作成します。既存のレジストリに値を追加することはありません。
The existing IANA registries used by this specification are modified using mechanisms specified elsewhere.
この仕様で使用されている既存のIANAレジストリは、他の場所で指定されたメカニズムを使用して変更されます。
A registry of OS specific fact names shall be maintained by the IANA. The OS names for the OS portion of the fact name must be taken from the IANA's list of registered OS names. To add a fact name to this OS specific registry of OS specific facts, an applicant must send to the IANA a request, in which is specified the OS name, the OS specific fact name, a definition of the syntax of the fact value, which must conform to the syntax of a token as given in this document, and a specification of the semantics to be associated with the particular fact and its values. Upon receipt of such an application, and if the combination of OS name and OS specific fact name has not been previously defined, the IANA will add the specification to the registry.
OS固有のファクト名のレジストリは、IANAによって維持されます。ファクト名のOS部分のOS名は、IANAの登録済みOS名のリストから取得する必要があります。 OS固有のファクトのこのOS固有のレジストリにファクト名を追加するには、申請者はIANAにリクエストを送信する必要があります。リクエストには、OS名、OS固有のファクト名、ファクト値の構文の定義が指定されています。このドキュメントに記載されているトークンの構文、および特定のファクトとその値に関連付けられるセマンティクスの仕様に準拠している必要があります。そのようなアプリケーションを受け取り、OS名とOS固有のファクト名の組み合わせが以前に定義されていない場合、IANAはその仕様をレジストリに追加します。
Any examples of OS specific facts found in this document are to be treated as examples of possible OS specific facts, and do not form a part of the IANA's registry merely because of being included in this document.
このドキュメントに記載されているOS固有の事実の例は、考えられるOS固有の事実の例として扱われ、このドキュメントに含まれているという理由だけでIANAのレジストリの一部を構成するものではありません。
A registry of OS specific file types shall be maintained by the IANA. The OS names for the OS portion of the fact name must be taken from the IANA's list of registered OS names. To add a file type to this OS specific registry of OS specific file types, an applicant must send to the IANA a request, in which is specified the OS name, the OS specific file type, a definition of the syntax of the fact value, which must conform to the syntax of a token as given in this document, and a specification of the semantics to be associated with the particular fact and its values. Upon receipt of such an application, and if the combination of OS name and OS specific file type has not been previously defined, the IANA will add the specification to the registry.
OS固有のファイルタイプのレジストリは、IANAによって維持されます。ファクト名のOS部分のOS名は、IANAの登録済みOS名のリストから取得する必要があります。 OS固有のファイルタイプのこのOS固有のレジストリにファイルタイプを追加するには、申請者はIANAにリクエストを送信する必要があります。リクエストには、OS名、OS固有のファイルタイプ、ファクト値の構文の定義が指定されています。これは、このドキュメントで指定されているトークンの構文、および特定のファクトとその値に関連付けられるセマンティクスの仕様に準拠している必要があります。そのようなアプリケーションを受け取り、OS名とOS固有のファイルタイプの組み合わせが以前に定義されていない場合、IANAは仕様をレジストリに追加します。
Any examples of OS specific file types found in this document are to be treated as potential OS specific file types only, and do not form a part of the IANA's registry merely because of being included in this document.
このドキュメントで見つかったOS固有のファイルタイプの例は、潜在的なOS固有のファイルタイプとしてのみ扱われ、このドキュメントに含まれているという理由だけでIANAのレジストリの一部を構成しません。
This memo does not directly concern security. It is not believed that any of the mechanisms documented here impact in any particular way upon the security of FTP.
このメモはセキュリティに直接関係しません。ここに記載されているメカニズムがFTPのセキュリティに特定の方法で影響を与えるとは考えられていません。
Implementing the SIZE command, and perhaps some of the facts of the MLSx commands, may impose a considerable load on the server, which could lead to denial of service attacks. Servers have, however, implemented this for many years, without significant reported difficulties.
SIZEコマンド、およびおそらくMLSxコマンドのいくつかの事実を実装すると、サーバーにかなりの負荷がかかり、サービス拒否攻撃につながる可能性があります。しかし、サーバーはこれを何年もの間実装しており、大きな問題は報告されていません。
The server-FTP should take care not to reveal sensitive information about files to unauthorised parties. In particular, some underlying filesystems provide a file identifier that, if known, can allow many of the filesystem protection mechanisms to be by-passed. That identifier would not be a suitable choice to use as the basis of the value of the unique fact.
サーバーFTPは、ファイルに関する機密情報を不正な関係者に公開しないように注意する必要があります。特に、一部の基盤となるファイルシステムは、既知の場合、ファイルシステム保護メカニズムの多くをバイパスできるファイル識別子を提供します。その識別子は、固有の事実の価値の基礎として使用するのに適した選択ではありません。
The FEAT and OPTS commands may be issued before the FTP authentication has occurred [6]. This allows unauthenticated clients to determine which of the features defined here are supported, and to negotiate the fact list for MLSx output. No actual MLSx commands may be issued however, and no problems with permitting the selection of the format prior to authentication are foreseen.
FEATコマンドとOPTSコマンドは、FTP認証が発生する前に発行できます[6]。これにより、認証されていないクライアントは、ここで定義されている機能のどれがサポートされているかを判断し、MLSx出力のファクトリストをネゴシエートできます。ただし、実際のMLSxコマンドを発行することはできません。また、認証前にフォーマットの選択を許可することに問題はありません。
A general discussion of issues related to the security of FTP can be found in [13].
FTPのセキュリティに関連する問題の一般的な議論は[13]にあります。
[1] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986.
[1] コード化文字セット-情報交換のための7ビットのアメリカ標準コード、ANSI X3.4-1986。
[2] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003.
[2] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、RFC 3629、2003年11月。
[3] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[3] Postel、J。およびJ. Reynolds、「File Transfer Protocol（FTP）」、STD 9、RFC 959、1985年10月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[5] Crocker、D.およびP. Overell、「構文仕様の拡張BNF：ABNF」、RFC 4234、2005年10月。
[6] Hethmon, P. and R. Elz, "Feature negotiation mechanism for the File Transfer Protocol", RFC 2389, August 1998.
[6] Hethmon、P。およびR. Elz、「ファイル転送プロトコルの機能交渉メカニズム」、RFC 2389、1998年8月。
[7] Curtin, B., "Internationalization of the File Transfer Protocol", RFC 2640, July 1999.
[7] カーティンB.、「ファイル転送プロトコルの国際化」、RFC 2640、1999年7月。
[8] Postel, J. and J. Reynolds, "Telnet protocol Specification", STD 8, RFC 854, May 1983.
[8] Postel、J。およびJ. Reynolds、「Telnet protocol Specification」、STD 8、RFC 854、1983年5月。
[9] Braden, R,. "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[9] ブレーデン、R、 「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[10] ISO/IEC 10646-1:1993 "Universal multiple-octet coded character set (UCS) -- Part 1: Architecture and basic multilingual plane", International Standard -- Information Technology, 1993.
[10] ISO / IEC 10646-1：1993「Universal multiple-octet coded character set（UCS）-Part 1：Architecture and basic multilingual plane」、International Standard-Information Technology、1993。
[11] Internet Assigned Numbers Authority. http://www.iana.org Email: iana@iana.org.
[11] Internet Assigned Numbers Authority。 http://www.iana.orgメール：iana@iana.org。
[12] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
[12] Phillips、A。およびM. Davis、「Tags for Identificationing Languages」、BCP 47、RFC 4646、2006年9月。
[13] Allman, M. and S. Ostermann, "FTP Security Considerations" RFC 2577, May 1999.
[13] Allman、M。、およびS. Ostermann、「FTP Security Considerations」RFC 2577、1999年5月。
Acknowledgments
謝辞
This document is a product of the FTPEXT working group of the IETF.
このドキュメントは、IETFのFTPEXTワーキンググループの製品です。
The following people are among those who have contributed to this document:
以下の人々は、このドキュメントに貢献した人々の中にいます：
Alex Belits D. J. Bernstein Dave Cridland Martin J. Duerst Bill Fenner (and the rest of the IESG) Paul Ford-Hutchinson Mike Gleason Mark Harris Stephen Head Alun Jones Andrew Main James Matthews Luke Mewburn Jan Mikkelsen Keith Moore Buz Owen Mark Symons Stephen Tihor and the entire FTPEXT working group of the IETF.
アレックスベリッツDJバーンスタインデイブクリドランドマーティンJ.デュエルストビルフェナー（およびIESGの残りの部分）ポールフォード-ハッチンソンマイクグリーソンマークハリススティーブンヘッドアルンジョーンズアンドリューメインジェームズマシューズルークミューバーンヤンミッケルセンキースムーアブズオーウェンマークシモンズスティーブンティホールとIETFのFTPEXTワーキンググループ全体。
Apologies are offered to any inadvertently omitted.
誤って省略された場合は、謝罪が提供されます。
The description of the modifications to the REST command and the MDTM and SIZE commands comes from a set of modifications suggested for STD 9, RFC 959 by Rick Adams in 1989. A document containing just those commands, edited by David Borman, has been merged with this document.
RESTコマンドとMDTMおよびSIZEコマンドに対する変更の説明は、1989年にRick AdamsによってSTD 9、RFC 959に対して提案された一連の変更からのものです。DavidBormanによって編集されたこれらのコマンドのみを含むドキュメントは、このドキュメント。
Mike Gleason, Alun Jones and Luke Mewburn provided access to FTP servers used in some of the examples.
Mike Gleason、Alun Jones、Luke Mewburnは、いくつかの例で使用されているFTPサーバーへのアクセスを提供しました。
All of the examples in this document are taken from actual client/server exchanges, though some have been edited for brevity, or to meet document formatting requirements.
このドキュメントの例はすべて、実際のクライアント/サーバー交換からのものですが、簡潔にするため、またはドキュメントのフォーマット要件を満たすために編集されたものもあります。
RFC Editor Note:
RFC Editor Note：
Several of the examples in this document exceed the RFC standard line length of 72 characters. Since this document is a standards-track result of an IETF working group and is important to an IETF sub-community, the RFC Editor is publishing it with the margin violations. This is not a precedent.
このドキュメントの例のいくつかは、72文字のRFC標準行長を超えています。このドキュメントはIETFワーキンググループの標準化過程の結果であり、IETFサブコミュニティにとって重要であるため、RFCエディタはマージン違反を含めて公開しています。これは前例ではありません。
Author's Address
著者のアドレス
Paul Hethmon Hethmon Software 10420 Jackson Oaks Way, Suite 201 Knoxville, TN 37922
Paul Hethmon Hethmon Software 10420 Jackson Oaks Way、Suite 201 Knoxville、TN 37922
EMail: phethmon@hethmon.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2007).
Copyright（C）IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP 78に含まれる権利、ライセンス、および制限の対象であり、ここに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントおよびここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代表者、または（もしあれば）組織、インターネット社会、IETFトラストおよびインターネットエンジニアリングタスクフォースはすべてを否認します。明示または黙示を問わず、ここに含まれる情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害しないことを保証するものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。