Network Working Group R. Faith
Request for Comments: 2229 U. North Carolina, Chapel Hill
Category: Informational B. Martin
Miranda Productions
October 1997
Network Working Group R. Faith
Request for Comments: 2229 U. North Carolina, Chapel Hill
Category: Informational B. Martin
Miranda Productions
October 1997
A Dictionary Server Protocol
字典服务器协议
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
Abstract
摘要
The Dictionary Server Protocol (DICT) is a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases.
字典服务器协议（DICT）是一种基于TCP事务的查询/响应协议，允许客户端从一组自然语言字典数据库访问字典定义。
Table of Contents
目录
1. Introduction ......................................... 2
1.1. Requirements ......................................... 3
2. Protocol Overview .................................... 3
2.1. Link Level ........................................... 3
2.2. Lexical Tokens ....................................... 3
2.3. Commands ............................................. 4
2.4. Responses ............................................ 5
2.4.1. Status Responses ..................................... 5
2.4.2. General Status Responses ............................. 6
2.4.3. Text Responses ....................................... 6
3. Command and Response Details ......................... 7
3.1. Initial Connection ................................... 7
3.2. The DEFINE Command ................................... 9
3.3. The MATCH Command .................................... 10
3.4. A Note on Virtual Databases .......................... 12
3.5. The SHOW Command ..................................... 13
3.5.1. SHOW DB .............................................. 13
3.5.2. SHOW STRAT ........................................... 13
3.5.3. SHOW INFO ............................................ 14
3.5.4. SHOW SERVER .......................................... 14
3.6. The CLIENT Command ................................... 15
1. Introduction ......................................... 2
1.1. Requirements ......................................... 3
2. Protocol Overview .................................... 3
2.1. Link Level ........................................... 3
2.2. Lexical Tokens ....................................... 3
2.3. Commands ............................................. 4
2.4. Responses ............................................ 5
2.4.1. Status Responses ..................................... 5
2.4.2. General Status Responses ............................. 6
2.4.3. Text Responses ....................................... 6
3. Command and Response Details ......................... 7
3.1. Initial Connection ................................... 7
3.2. The DEFINE Command ................................... 9
3.3. The MATCH Command .................................... 10
3.4. A Note on Virtual Databases .......................... 12
3.5. The SHOW Command ..................................... 13
3.5.1. SHOW DB .............................................. 13
3.5.2. SHOW STRAT ........................................... 13
3.5.3. SHOW INFO ............................................ 14
3.5.4. SHOW SERVER .......................................... 14
3.6. The CLIENT Command ................................... 15
3.7. The STATUS Command ................................... 15
3.8. The HELP Command ..................................... 15
3.9. The QUIT Command ..................................... 16
3.10. The OPTION Command ................................... 16
3.10.1. OPTION MIME .......................................... 16
3.11. The AUTH Command ..................................... 18
3.12. The SASLAUTH Command ................................. 18
4. Command Pipelining ................................... 20
5. URL Specification .................................... 20
6. Extensions ........................................... 22
6.1. Experimental Command Syntax .......................... 22
6.2. Experimental Commands and Pipelining ................. 22
7. Summary of Response Codes ............................ 23
8. Sample Conversations ................................. 23
8.1. Sample 1 - HELP, DEFINE, and QUIT commands ........... 24
8.2. Sample 2 - SHOW commands, MATCH command .............. 25
8.3. Sample 3 - Server downtime ........................... 26
8.4. Sample 4 - Authentication ............................ 26
9. Security Considerations .............................. 26
10. References ........................................... 27
11. Acknowledgements ..................................... 29
12. Authors' Addresses ................................... 29
13. Full Copyright Statement ............................. 30
3.7. The STATUS Command ................................... 15
3.8. The HELP Command ..................................... 15
3.9. The QUIT Command ..................................... 16
3.10. The OPTION Command ................................... 16
3.10.1. OPTION MIME .......................................... 16
3.11. The AUTH Command ..................................... 18
3.12. The SASLAUTH Command ................................. 18
4. Command Pipelining ................................... 20
5. URL Specification .................................... 20
6. Extensions ........................................... 22
6.1. Experimental Command Syntax .......................... 22
6.2. Experimental Commands and Pipelining ................. 22
7. Summary of Response Codes ............................ 23
8. Sample Conversations ................................. 23
8.1. Sample 1 - HELP, DEFINE, and QUIT commands ........... 24
8.2. Sample 2 - SHOW commands, MATCH command .............. 25
8.3. Sample 3 - Server downtime ........................... 26
8.4. Sample 4 - Authentication ............................ 26
9. Security Considerations .............................. 26
10. References ........................................... 27
11. Acknowledgements ..................................... 29
12. Authors' Addresses ................................... 29
13. Full Copyright Statement ............................. 30
For many years, the Internet community has relied on the "webster" protocol for access to natural language definitions. The webster protocol supports access to a single dictionary and (optionally) to a single thesaurus. In recent years, the number of publicly available webster servers on the Internet has dramatically decreased.
多年来，互联网社区一直依赖“韦伯斯特”协议访问自然语言定义。webster协议支持访问单个词典和（可选）单个同义词表。近年来，互联网上公开可用的webster服务器数量急剧减少。
Fortunately, several freely-distributable dictionaries and lexicons have recently become available on the Internet. However, these freely-distributable databases are not accessible via a uniform interface, and are not accessible from a single site. They are often small and incomplete individually, but would collectively provide an interesting and useful database of English words. Examples include the Jargon file [JARGON], the WordNet database [WORDNET], MICRA's version of the 1913 Webster's Revised Unabridged Dictionary [WEB1913], and the Free Online Dictionary of Computing [FOLDOC]. Translating and non-English dictionaries are also becoming available (for example, the FOLDOC dictionary is being translated into Spanish).
幸运的是，最近互联网上出现了一些可自由分发的词典。但是，这些可自由分发的数据库无法通过统一接口访问，也无法从单个站点访问。它们通常都很小，个别不完整，但它们共同提供了一个有趣而有用的英语单词数据库。例如行话文件[Jargon]、WordNet数据库[WordNet]、MICRA版本的1913年韦氏修订版未删节词典[WEB1913]和免费在线计算词典[FOLDOC]。翻译词典和非英语词典也开始使用（例如，FOLDOC词典正在被翻译成西班牙语）。
The webster protocol is not suitable for providing access to a large number of separate dictionary databases, and extensions to the current webster protocol were not felt to be a clean solution to the dictionary database problem.
webster协议不适合提供对大量单独字典数据库的访问，对当前webster协议的扩展被认为不是字典数据库问题的干净解决方案。
The DICT protocol is designed to provide access to multiple databases. Word definitions can be requested, the word index can be searched (using an easily extended set of algorithms), information about the server can be provided (e.g., which index search strategies are supported, or which databases are available), and information about a database can be provided (e.g., copyright, citation, or distribution information). Further, the DICT protocol has hooks that can be used to restrict access to some or all of the databases.
DICT协议旨在提供对多个数据库的访问。可以请求单词定义，可以搜索单词索引（使用一组易于扩展的算法），可以提供关于服务器的信息（例如，支持哪些索引搜索策略，或者哪些数据库可用），可以提供关于数据库的信息（例如，版权、引用或发行信息）. 此外，DICT协议具有挂钩，可用于限制对部分或全部数据库的访问。
In this document, we adopt the convention discussed in Section 1.3.2 of [RFC1122] of using the capitalized words MUST, REQUIRED, SHOULD, RECOMMENDED, MAY, and OPTIONAL to define the significance of each particular requirement specified in this document.
在本文件中，我们采用[RFC1122]第1.3.2节中讨论的约定，即使用大写单词“必须”、“必需”、“应该”、“建议”、“可以”和“可选”来定义本文件中规定的每个特定要求的重要性。
In brief: "MUST" (or "REQUIRED") means that the item is an absolute requirement of the specification; "SHOULD" (or "RECOMMENDED") means there may exist valid reasons for ignoring this item, but the full implications should be understood before doing so; and "MAY" (or "OPTIONAL") means that his item is optional, and may be omitted without careful consideration.
简言之：“必须”（或“必需”）是指该项目是本规范的绝对要求；“应该”（或“建议”）是指可能存在忽略此项的有效原因，但在这样做之前，应了解其全部含义；“可以”（或“可选”）表示他的项目是可选的，可以不经仔细考虑而省略。
The DICT protocol assumes a reliable data stream such as provided by TCP. When TCP is used, a DICT server listens on port 2628.
DICT协议采用可靠的数据流，如TCP提供的数据流。使用TCP时，DICT服务器侦听端口2628。
This server is only an interface between programs and the dictionary databases. It does not perform any user interaction or presentation-level functions.
此服务器只是程序和字典数据库之间的接口。它不执行任何用户交互或表示级别的功能。
Commands and replies are composed of characters from the UCS character set [ISO10646] using the UTF-8 [RFC2044] encoding. More specifically, using the grammar conventions from [RFC822]:
命令和回复由UCS字符集[ISO10646]中使用UTF-8[RFC2044]编码的字符组成。更具体地说，使用[RFC822]中的语法约定：
; ( Octal, Decimal.)
CHAR = <any UTF-8 character (1 to 6 octets)>
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
CR = <ASCII CR, carriage return> ; ( 15, 13.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
SPACE = <ASCII SP, space> ; ( 40, 32.)
HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
<"> = <ASCII quote mark> ; ( 42, 34.)
<'> = <ASCII single quote mark> ; ( 47, 39.)
CRLF = CR LF
WS = 1*(SPACE / HTAB)
; ( Octal, Decimal.)
CHAR = <any UTF-8 character (1 to 6 octets)>
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
CR = <ASCII CR, carriage return> ; ( 15, 13.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
SPACE = <ASCII SP, space> ; ( 40, 32.)
HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
<"> = <ASCII quote mark> ; ( 42, 34.)
<'> = <ASCII single quote mark> ; ( 47, 39.)
CRLF = CR LF
WS = 1*(SPACE / HTAB)
dqstring = <"> *(dqtext/quoted-pair) <">
dqtext = <any CHAR except <">, "\", and CTLs>
sqstring = <'> *(dqtext/quoted-pair) <'>
sqtext = <any CHAR except <'>, "\", and CTLs>
quoted-pair = "\" CHAR
dqstring = <"> *(dqtext/quoted-pair) <">
dqtext = <any CHAR except <">, "\", and CTLs>
sqstring = <'> *(dqtext/quoted-pair) <'>
sqtext = <any CHAR except <'>, "\", and CTLs>
quoted-pair = "\" CHAR
atom = 1*<any CHAR except SPACE, CTLs, <'>, <">, and "\">
string = *<dqstring / sqstring / quoted-pair>
word = *<atom / string>
description = *<word / WS>
text = *<word / WS>
atom = 1*<any CHAR except SPACE, CTLs, <'>, <">, and "\">
string = *<dqstring / sqstring / quoted-pair>
word = *<atom / string>
description = *<word / WS>
text = *<word / WS>
Commands consist of a command word followed by zero or more parameters. Commands with parameters must separate the parameters from each other and from the command by one or more space or tab characters. Command lines must be complete with all required parameters, and may not contain more than one command.
命令由一个命令字后跟零个或多个参数组成。带有参数的命令必须通过一个或多个空格或制表符将参数彼此分开，并与命令分开。命令行必须包含所有必需的参数，并且不能包含多个命令。
Each command line must be terminated by a CRLF.
每个命令行必须由CRLF终止。
The grammar for commands is:
命令的语法是：
command = cmd-word *<WS cmd-param>
cmd-word = atom
cmd-param = database / strategy / word
database = atom
strategy = atom
command = cmd-word *<WS cmd-param>
cmd-word = atom
cmd-param = database / strategy / word
database = atom
strategy = atom
Commands are not case sensitive.
命令不区分大小写。
Command lines MUST NOT exceed 1024 characters in length, counting all characters including spaces, separators, punctuation, and the trailing CRLF. There is no provision for the continuation of command lines. Since UTF-8 may encode a character using up to 6 octets, the command line buffer MUST be able to accept up to 6144 octets.
命令行的长度不得超过1024个字符，包括空格、分隔符、标点符号和尾随的CRLF在内的所有字符都应计算在内。没有关于命令行延续的规定。由于UTF-8可以使用最多6个八位字节对字符进行编码，因此命令行缓冲区必须能够接受最多6144个八位字节。
Responses are of two kinds, status and textual.
回答有两种，状态和文本。
Status responses indicate the server's response to the last command received from the client.
状态响应指示服务器对从客户端接收的最后一个命令的响应。
Status response lines begin with a 3 digit numeric code which is sufficient to distinguish all responses. Some of these may herald the subsequent transmission of text.
状态响应行以3位数字代码开头，足以区分所有响应。其中一些可能预示着随后的文本传输。
The first digit of the response broadly indicates the success, failure, or progress of the previous command (based generally on [RFC640,RFC821]):
响应的第一位数字大致表示上一个命令的成功、失败或进度（通常基于[RFC640，RFC821]）：
1yz - Positive Preliminary reply 2yz - Positive Completion reply 3yz - Positive Intermediate reply 4yz - Transient Negative Completion reply 5yz - Permanent Negative Completion reply
1yz-初步肯定回复2yz-肯定完成回复3yz-中间肯定回复4yz-暂时否定完成回复5yz-永久否定完成回复
The next digit in the code indicates the response category:
代码中的下一位数字表示响应类别：
x0z - Syntax x1z - Information (e.g., help) x2z - Connections x3z - Authentication x4z - Unspecified as yet x5z - DICT System (These replies indicate the status of the receiver DICT system vis-a-vis the requested transfer or other DICT system action.) x8z - Nonstandard (private implementation) extensions
x0z-语法x1z-信息（例如，帮助）x2z-连接x3z-身份验证x4z-尚未指定的x5z-DICT系统（这些回复指示接收器DICT系统相对于请求的传输或其他DICT系统操作的状态。）x8z-非标准（专用实现）扩展
The exact response codes that should be expected from each command are detailed in the description of that command.
每个命令预期的准确响应代码在该命令的说明中有详细说明。
Certain status responses contain parameters such as numbers and strings. The number and type of such parameters is fixed for each response code to simplify interpretation of the response. Other status responses do not require specific text identifiers. Parameter
某些状态响应包含数字和字符串等参数。对于每个响应代码，此类参数的数量和类型是固定的，以简化响应的解释。其他状态响应不需要特定的文本标识符。参数
requirements are detailed in the description of relevant commands. Except for specifically detailed parameters, the text following response codes is server-dependent.
相关命令的说明中详细说明了要求。除特别详细的参数外，响应代码后面的文本取决于服务器。
Parameters are separated from the numeric response code and from each other by a single space. All numeric parameters are decimal, and may have leading zeros. All string parameters MUST conform to the "atom" or "dqstring" grammar productions.
参数与数字响应代码分开，并通过单个空格彼此分开。所有数值参数都是十进制的，并且可能有前导零。所有字符串参数必须符合“atom”或“dqstring”语法结果。
If no parameters are present, and the server implementation provides no implementation-specific text, then there MAY or MAY NOT be a space after the response code.
如果不存在任何参数，并且服务器实现未提供特定于实现的文本，则响应代码后面可能有空格，也可能没有空格。
Response codes not specified in this standard may be used for any installation-specific additional commands also not specified.
本标准中未规定的响应代码可用于也未规定的任何安装特定附加命令。
These should be chosen to fit the pattern of x8z specified above. The use of unspecified response codes for standard commands is prohibited.
应选择适合上面指定的x8z模式。禁止对标准命令使用未指定的响应代码。
In response to every command, the following general status responses are possible:
为了响应每个命令，可以进行以下一般状态响应：
500 Syntax error, command not recognized 501 Syntax error, illegal parameters 502 Command not implemented 503 Command parameter not implemented 420 Server temporarily unavailable 421 Server shutting down at operator request
500语法错误，命令未识别501语法错误，非法参数502命令未执行503命令参数未执行420服务器暂时不可用421服务器应操作员请求关闭
Before text is sent a numeric status response line, using a 1yz code, will be sent indicating text will follow. Text is sent as a series of successive lines of textual matter, each terminated with a CRLF. A single line containing only a period (decimal code 46, ".") is sent to indicate the end of the text (i.e., the server will send a CRLF at the end of the last line of text, a period, and another CRLF).
在发送文本之前，将发送一个使用1yz代码的数字状态响应行，指示文本将跟随。文本作为一系列连续的文本行发送，每行以CRLF结尾。发送仅包含句点（十进制代码46，“.”）的单行以指示文本的结尾（即，服务器将在最后一行文本的结尾处发送一个CRLF、一个句点和另一个CRLF）。
If a line of original text contained a period as the first character of the line, that first period is doubled by the DICT server. Therefore, the client must examine the first character of each line received. Those that begin with two periods must have those two periods collapsed into one period. Those that contain only a single period followed by a CRLF indicate the end of the text response.
如果一行原始文本包含一个句点作为该行的第一个字符，则DICT服务器会将第一个句点加倍。因此，客户机必须检查收到的每一行的第一个字符。那些以两个周期开始的，必须将这两个周期折叠成一个周期。那些只包含一个句点并后跟CRLF的句点表示文本响应的结束。
If the OPTION MIME command has been given, all textual responses will be prefaced by a MIME header [RFC2045] followed by a single blank line (CRLF). See section 3.10.1 for more details on OPTION MIME.
如果已给出选项MIME命令，则所有文本响应将以MIME头[RFC2045]开头，后跟一个空行（CRLF）。有关选项MIME的更多详细信息，请参见第3.10.1节。
Following a text response, a 2yz response code will be sent.
文本响应后，将发送2yz响应代码。
Text lines MUST NOT exceed 1024 characters in length, counting all characters including spaces, separators, punctuation, the extra initial period (if needed), and the trailing CRLF. Since UTF-8 may encode a character using up to 6 octets, the text line input buffer MUST be able to accept up to 6144 octets.
文本行的长度不得超过1024个字符，包括空格、分隔符、标点符号、额外的初始句点（如果需要）和尾随的CRLF。由于UTF-8可以使用最多6个八位字节对字符进行编码，因此文本行输入缓冲区必须能够接受最多6144个八位字节。
By default, the text of the definitions MUST be composed of characters from the UCS character set [ISO10644] using the UTF-8 [RFC2044] encoding. The UTF-8 encoding has the advantage of preserving the full range of 7-bit US ASCII [USASCII] values. Clients and servers MUST support UTF-8, even if only in some minimal fashion.
默认情况下，定义的文本必须由使用UTF-8[RFC2044]编码的UCS字符集[ISO10644]中的字符组成。UTF-8编码的优点是保留了7位美国ASCII[USASCII]值的完整范围。客户端和服务器必须支持UTF-8，即使只是以某种最小的方式。
Below, each DICT command and appropriate responses are detailed. Each command is shown in upper case for clarity, but the DICT server is case-insensitive.
下面详细介绍了每个DICT命令和相应的响应。为了清晰起见，每个命令都以大写字母显示，但DICT服务器不区分大小写。
Except for the AUTH and SASLAUTH commands, every command described in this section MUST be implemented by all DICT servers.
除AUTH和SASLAUTH命令外，本节中描述的每个命令都必须由所有DICT服务器实现。
When a client initially connects to a DICT server, a code 220 is sent if the client's IP is allowed to connect:
当客户端最初连接到DICT服务器时，如果允许客户端的IP连接，则发送代码220：
220 text capabilities msg-id
220文本功能msg id
The code 220 is a banner, usually containing host name and DICT server version information.
代码220是一个横幅，通常包含主机名和DICT服务器版本信息。
The second-to-last sequence of characters in the banner is the optional capabilities string, which will allow servers to declare support for extensions to the DICT protocol. The capabilities string is defined below:
横幅中倒数第二个字符序列是可选功能字符串，它允许服务器声明对DICT协议扩展的支持。功能字符串定义如下：
capabilities = ["<" msg-atom *("." msg-atom) ">"]
msg-atom = 1*<any CHAR except SPACE, CTLs,
"<", ">", ".", and "\">
capabilities = ["<" msg-atom *("." msg-atom) ">"]
msg-atom = 1*<any CHAR except SPACE, CTLs,
"<", ">", ".", and "\">
Individual capabilities are described by a single msg-atom. For example, the string <html.gzip> might be used to describe a server that supports extensions which allow HTML or compressed output. Capability names beginning with "x" or "X" are reserved for experimental extensions, and SHOULD NOT be defined in any future DICT protocol specification. Some of these capabilities may inform the client that certain functionality is available or can be requested. The following capabilities are currently defined:
单个功能由单个msg原子描述。例如，字符串<html.gzip>可用于描述支持允许html或压缩输出的扩展的服务器。以“x”或“x”开头的功能名称保留用于实验扩展，不应在任何未来的DICT协议规范中定义。其中一些功能可能会通知客户某些功能可用或可以请求。目前定义了以下功能：
mime The OPTION MIME command is supported auth The AUTH command is supported kerberos_v4 The SASL Kerberos version 4 mechanism is supported gssapi The SASL GSSAPI [RFC2078] mechanism is supported skey The SASL S/Key [RFC1760] mechanism is supported external The SASL external mechanism is supported
mime选项mime命令受支持auth auth命令受支持kerberos_v4支持SASL kerberos版本4机制gssapi支持SASL gssapi[RFC2078]机制skey支持SASL S/Key[RFC1760]机制外部支持SASL外部机制
The last sequence of characters in the banner is a msg-id, similar to the format specified in [RFC822]. The simplified description is given below:
横幅中的最后一个字符序列是消息id，类似于[RFC822]中指定的格式。简化说明如下所示：
msg-id = "<" spec ">" ; Unique message id
spec = local-part "@" domain
local-part = msg-atom *("." msg-atom)
domain = msg-atom *("." msg-atom)
msg-id = "<" spec ">" ; Unique message id
spec = local-part "@" domain
local-part = msg-atom *("." msg-atom)
domain = msg-atom *("." msg-atom)
Note that, in contrast to [RFC822], spaces and quoted pairs are not allowed in the msg-id. This restriction makes the msg-id much easier for the client to locate and parse but does not significantly decrease any security benefits, since the msg-id may be arbitrarily long (as bounded by the response length limits set forth elsewhere in this document).
请注意，与[RFC822]相反，msg-id中不允许使用空格和引号对。此限制使msg id更易于客户端定位和解析，但不会显著降低任何安全性，因为msg id可能任意长（以本文件其他地方规定的响应长度限制为界限）。
Note also that the open and close brackets are part of the msg-id and should be included in the string that is used to compute the MD5 checksum.
还请注意，开括号和闭括号是msg id的一部分，应该包含在用于计算MD5校验和的字符串中。
This message id will be used by the client when formulating the authentication string used in the AUTH command.
客户端在制定AUTH命令中使用的身份验证字符串时将使用此消息id。
If the client's IP is not allowed to connect, then a code 530 is sent instead:
如果不允许客户端的IP连接，则发送代码530：
530 Access denied
530拒绝访问
Transient failure responses are also possible:
瞬态故障响应也是可能的：
420 Server temporarily unavailable 421 Server shutting down at operator request
420服务器暂时不可用421服务器应操作员请求关闭
For example, response code 420 should be used if the server cannot currently fork a server process (or cannot currently obtain other resources required to proceed with a usable connection), but expects to be able to fork or obtain these resources in the near future.
例如，如果服务器当前无法分叉服务器进程（或当前无法获取继续进行可用连接所需的其他资源），但期望在不久的将来能够分叉或获取这些资源，则应使用响应代码420。
Response code 421 should be used when the server has been shut down at operator request, or when conditions indicate that the ability to service more requests in the near future will be impossible. This may be used to allow a graceful operator-mediated temporary shutdown of a server, or to indicate that a well known server has been permanently removed from service (in which case, the text message might provide more information).
当服务器在操作员请求下关闭时，或者当条件表明无法在不久的将来为更多请求提供服务时，应使用响应代码421。这可用于允许操作员临时关闭服务器，或表示已知服务器已永久停止服务（在这种情况下，文本消息可能提供更多信息）。
DEFINE database word
定义数据库字
This command will look up the specified word in the specified database. All DICT servers MUST implement this command.
此命令将在指定的数据库中查找指定的单词。所有DICT服务器都必须执行此命令。
If the database name is specified with an exclamation point (decimal code 33, "!"), then all of the databases will be searched until a match is found, and all matches in that database will be displayed. If the database name is specified with a star (decimal code 42, "*"), then all of the matches in all available databases will be displayed. In both of these special cases, the databases will be searched in the same order as that printed by the "SHOW DB" command.
如果使用感叹号（十进制代码33，“！”）指定数据库名称，则将搜索所有数据库，直到找到匹配项，并显示该数据库中的所有匹配项。如果使用星号（十进制代码42，“*”）指定数据库名称，则将显示所有可用数据库中的所有匹配项。在这两种特殊情况下，数据库的搜索顺序与“showdb”命令打印的顺序相同。
If the word was not found, then status code 552 is sent.
如果未找到单词，则发送状态代码552。
If the word was found, then status code 150 is sent, indicating that one or more definitions follow.
如果找到该词，则发送状态代码150，表示随后有一个或多个定义。
For each definition, status code 151 is sent, followed by the textual body of the definition. The first three space-delimited parameters following status code 151 give the word retrieved, the name of the database (which is the same as the first column of the SHOW DB command), and a short description for the database (which is the same as the second column of the SHOW DB command). The short name is suitable for printing as:
对于每个定义，发送状态代码151，后跟定义的文本体。状态代码151之后的前三个空格分隔的参数给出检索到的单词、数据库名称（与SHOW DB命令的第一列相同）和数据库的简短描述（与SHOW DB命令的第二列相同）。短名称适合打印为：
From name:
发件人姓名：
before the definition is printed. This provides source information for the user.
在定义打印之前。这将为用户提供源信息。
The textual body of each definition is terminated with a CRLF period CRLF sequence.
每个定义的文本体以CRLF周期CRLF序列终止。
After all of the definitions have been sent, status code 250 is sent. This command can provide optional timing information (which is server dependent and is not intended to be parsable by the client). This additional information is useful when debugging and tuning the server.
发送所有定义后，将发送状态代码250。此命令可以提供可选的定时信息（这取决于服务器，不希望客户端可以解析）。调试和调优服务器时，此附加信息非常有用。
550 Invalid database, use "SHOW DB" for list of databases 552 No match 150 n definitions retrieved - definitions follow 151 word database name - text follows 250 ok (optional timing information here)
550无效数据库，对数据库列表使用“SHOW DB”552不匹配检索到的150 n定义-定义跟在151字数据库名称后面-文本跟在250 ok后面（此处可选计时信息）
Response codes 150 and 151 require special parameters as part of their text. The client can use these parameters to display information on the user's terminal.
响应代码150和151需要特殊参数作为其文本的一部分。客户端可以使用这些参数在用户终端上显示信息。
For code 150, parameters 1 indicates the number of definitions retrieved.
对于代码150，参数1表示检索到的定义数。
For code 151, parameter 1 is the word retrieved, parameter 2 is the database name (the first name as shown by "SHOW DB") from which the definition has been retrieved, and parameter 3 is the the short database description (the second column of the "SHOW DB" command).
对于代码151，参数1是检索到的单词，参数2是检索到定义的数据库名称（“SHOW DB”所示的第一个名称），参数3是简短的数据库描述（“SHOW DB”命令的第二列）。
MATCH database strategy word
匹配数据库策略word
This command searches an index for the dictionary, and reports words which were found using a particular strategy. Not all strategies are useful for all dictionaries, and some dictionaries may support additional search strategies (e.g., reverse lookup). All DICT servers MUST implement the MATCH command, and MUST support the "exact" and "prefix" strategies. These are easy to implement and are generally the most useful. Other strategies are server dependent.
此命令搜索字典索引，并报告使用特定策略找到的单词。并非所有策略都适用于所有词典，有些词典可能支持其他搜索策略（例如，反向查找）。所有DICT服务器必须实现MATCH命令，并且必须支持“精确”和“前缀”策略。它们易于实现，通常是最有用的。其他策略依赖于服务器。
The "exact" strategy matches a word exactly, although different servers may treat non-alphanumeric data differently. We have found that a case-insensitive comparison which ignores non-alphanumeric
“精确”策略精确匹配一个单词，尽管不同的服务器可能会对非字母数字数据进行不同的处理。我们发现不区分大小写的比较忽略了非字母数字
characters and which folds whitespace is useful for English-language dictionaries. Other comparisons may be more appropriate for other languages or when using extended character sets.
字符和折叠空格对于英语词典很有用。其他比较可能更适用于其他语言或使用扩展字符集时。
The "prefix" strategy is similar to "exact", except that it only compares the first part of the word.
“前缀”策略类似于“精确”，只是它只比较单词的前半部分。
Different servers may implement these algorithms differently. The requirement is that strategies with the names "exact" and "prefix" exist so that a simple client can use them.
不同的服务器可能以不同的方式实现这些算法。其要求是，存在名称为“精确”和“前缀”的策略，以便简单的客户机可以使用它们。
Other strategies that might be considered by a server implementor are matches based on substring, suffix, regular expressions, soundex [KNUTH73], and Levenshtein [PZ85] algorithms. These last two are especially useful for correcting spelling errors. Other useful strategies perform some sort of "reverse" lookup (i.e., by searching definitions to find the word that the query suggests).
服务器实现者可能考虑的其他策略是基于子字符串、后缀、正则表达式、soundex[KNUTH73]和Levenshtein[PZ85]算法的匹配。最后两项对于纠正拼写错误特别有用。其他有用的策略执行某种“反向”查找（即，通过搜索定义来查找查询建议的单词）。
If the database name is specified with an exclamation point (decimal code 33, "!"), then all of the databases will be searched until a match is found, and all matches in that database will be displayed. If the database name is specified with a star (decimal code 42, "*"), then all of the matches in all available databases will be displayed. In both of these special cases, the databases will be searched in the same order as that printed by the "SHOW DB" command.
如果使用感叹号（十进制代码33，“！”）指定数据库名称，则将搜索所有数据库，直到找到匹配项，并显示该数据库中的所有匹配项。如果使用星号（十进制代码42，“*”）指定数据库名称，则将显示所有可用数据库中的所有匹配项。在这两种特殊情况下，数据库的搜索顺序与“showdb”命令打印的顺序相同。
If the strategy is specified using a period (decimal code 46, "."), then the word will be matched using a server-dependent default strategy, which should be the best strategy available for interactive spell checking. This is usually a derivative of the Levenshtein algorithm [PZ85].
如果使用句点（十进制代码46，“.”）指定策略，则将使用依赖于服务器的默认策略匹配单词，这应该是交互式拼写检查可用的最佳策略。这通常是Levenshtein算法[PZ85]的衍生物。
If no matches are found in any of the searched databases, then status code 552 will be returned.
如果在任何搜索的数据库中未找到匹配项，则将返回状态代码552。
Otherwise, status code 152 will be returned followed by a list of matched words, one per line, in the form:
否则，将返回状态代码152，后跟匹配单词列表，每行一个，格式如下：
database word
数据库字
This makes the responses directly useful in a DEFINE command.
这使得响应在DEFINE命令中直接有用。
The textual body of the match list is terminated with a CRLF period CRLF sequence.
匹配列表的文本体以CRLF周期CRLF序列终止。
Following the list, status code 250 is sent, which may include server-specific timing and statistical information, as discussed in the section on the DEFINE command.
在该列表之后，将发送状态代码250，其中可能包括服务器特定的定时和统计信息，如定义命令一节中所述。
550 Invalid database, use "SHOW DB" for list of databases 551 Invalid strategy, use "SHOW STRAT" for a list of strategies 552 No match 152 n matches found - text follows 250 ok (optional timing information here)
550无效数据库，使用“SHOW DB”表示数据库列表551无效策略，使用“SHOW STRAT”表示策略列表552未找到匹配项152 n找到匹配项-文本后跟250 ok（此处可选定时信息）
Response code 152 requires a special parameter as part of its text. Parameter 1 must be the number of matches retrieved.
响应代码152需要一个特殊参数作为其文本的一部分。参数1必须是检索到的匹配数。
The ability to search all of the provided databases using a single command is given using the special "*" and "!" databases.
使用特殊的“*”和“！”数据库，可以使用单个命令搜索所有提供的数据库。
However, sometimes, a client may want to search over some but not all of the databases that a particular server provides. One alternative is for the client to use the SHOW DB command to obtain a list of databases and descriptions, and then (perhaps with the help of a human), select a subset of these databases for an interactive search. Once this selection has been done once, the results can be saved, for example, in a client configuration file.
但是，有时，客户机可能希望搜索特定服务器提供的部分但不是全部数据库。另一种方法是，客户端使用showdb命令获取数据库和描述的列表，然后（可能在人工的帮助下）选择这些数据库的子集进行交互式搜索。此选择完成一次后，可以保存结果，例如，保存在客户机配置文件中。
Another alternative is for the server to provide "virtual" databases which merge several of the regular databases into one. For example, a virtual database may be provided which includes all of the translating dictionaries, but which does not include regular dictionaries or thesauri. The special "*" and "!" databases can be considered as names of virtual databases which provide access to all of the databases. If a server implements virtual databases, then the special "*" and "!" databases should probably exclude other virtual databases (since they merely provide information duplicated in other databases). If virtual databases are supported, they should be listed as a regular database with the SHOW DB command (although, since "*" and "!" are required, they need not be listed).
另一种选择是服务器提供“虚拟”数据库，将多个常规数据库合并为一个数据库。例如，可以提供一个虚拟数据库，其中包括所有翻译词典，但不包括常规词典或同义词表。特殊的“*”和“！”数据库可以被视为虚拟数据库的名称，虚拟数据库提供对所有数据库的访问。如果服务器实现了虚拟数据库，那么特殊的“*”和“！”数据库可能会排除其他虚拟数据库（因为它们只提供与其他数据库重复的信息）。如果支持虚拟数据库，则应使用SHOW DB命令将其作为常规数据库列出（不过，由于需要“*”和“！”，因此无需列出它们）。
Virtual databases are an implementation-specific detail which has absolutely no impact on the DICT protocol. The DICT protocol views virtual and non-virtual databases the same way.
虚拟数据库是一个特定于实现的细节，它对DICT协议绝对没有影响。DICT协议以相同的方式查看虚拟和非虚拟数据库。
We mention virtual databases here, however, because they solve a problem of database selection which could also have been solved by changes in the protocol. For example, each dictionary could be assigned attributes, and the protocol could be extended to specify searches over databases with certain attributes. However, this needlessly complicates the parsing and analysis that must be performed by the implementation. Further, unless the classification
然而，我们在这里提到虚拟数据库，因为它们解决了数据库选择的问题，这个问题也可以通过协议中的更改来解决。例如，可以为每个字典分配属性，并且可以扩展协议以指定对具有特定属性的数据库的搜索。然而，这不必要地使实现必须执行的解析和分析复杂化。此外，除非分类
system is extremely general, there is a risk that it would restrict the types of databases that can be used with the DICT protocol (although the protocol has been designed with human-language databases in mind, it is applicable to any read-only database application, especially those with a single semi-unique alphanumeric key and textual data).
系统非常通用，存在限制可与DICT协议一起使用的数据库类型的风险（尽管协议设计时考虑了人类语言数据库，但它适用于任何只读数据库应用程序，尤其是具有单个半唯一字母数字键和文本数据的应用程序）。
SHOW DB SHOW DATABASES
显示数据库显示数据库
Displays the list of currently accessible databases, one per line, in the form:
以以下形式显示当前可访问数据库的列表，每行一个：
database description
数据库描述
The textual body of the database list is terminated with a CRLF period CRLF sequence. All DICT servers MUST implement this command.
数据库列表的文本体以CRLF周期CRLF序列终止。所有DICT服务器都必须执行此命令。
Note that some databases may be restricted due to client domain or lack of user authentication (see the AUTH and SASLAUTH commands in sections 3.11 and 3.12). Information about these databases is not available until authentication is performed. Until that time, the client will interact with the server as if the additional databases did not exist.
请注意，某些数据库可能由于客户端域或缺少用户身份验证而受到限制（请参阅第3.11节和第3.12节中的AUTH和SASLAUTH命令）。在执行身份验证之前，有关这些数据库的信息不可用。在此之前，客户机将与服务器进行交互，就像其他数据库不存在一样。
110 n databases present - text follows 554 No databases present
存在110个数据库-文本后跟554个不存在的数据库
Response code 110 requires a special parameter. Parameter 1 must be the number of databases available to the user.
响应代码110需要一个特殊参数。参数1必须是用户可用的数据库数。
SHOW STRAT SHOW STRATEGIES
展示战略
Displays the list of currently supported search strategies, one per line, in the form:
以以下形式显示当前支持的搜索策略列表，每行一个：
strategy description
策略描述
The textual body of the strategy list is terminated with a CRLF period CRLF sequence. All DICT servers MUST implement this command.
策略列表的文本体以CRLF周期CRLF序列终止。所有DICT服务器都必须执行此命令。
111 n strategies available - text follows 555 No strategies available
111 n可用策略-文本后面是555无可用策略
Response code 111 requires a special parameter. Parameter 1 must be the number of strategies available.
响应代码111需要一个特殊参数。参数1必须是可用策略的数量。
SHOW INFO database
显示信息数据库
Displays the source, copyright, and licensing information about the specified database. The information is free-form text and is suitable for display to the user in the same manner as a definition. The textual body of the information is terminated with a CRLF period CRLF sequence. All DICT servers MUST implement this command.
显示指定数据库的源、版权和许可信息。信息是自由格式的文本，适合以与定义相同的方式向用户显示。信息的文本体以CRLF周期CRLF序列终止。所有DICT服务器都必须执行此命令。
550 Invalid database, use "SHOW DB" for list of databases 112 database information follows
550无效数据库，请使用“SHOW DB”作为数据库列表112数据库信息如下
These response codes require no special parameters.
这些响应代码不需要特殊参数。
SHOW SERVER
显示服务器
Displays local server information written by the local administrator. This could include information about local databases or strategies, or administrative information such as who to contact for access to databases requiring authentication. All DICT servers MUST implement this command.
显示本地管理员写入的本地服务器信息。这可能包括有关本地数据库或策略的信息，或管理信息，如需要身份验证才能访问数据库的联系人。所有DICT服务器都必须执行此命令。
114 server information follows
114服务器信息如下
This response code requires no special parameters.
此响应代码不需要特殊参数。
CLIENT text
客户端文本
This command allows the client to provide information about itself for possible logging and statistical purposes. All clients SHOULD send this command after connecting to the server. All DICT servers MUST implement this command (note, though, that the server doesn't have to do anything with the information provided by the client).
此命令允许客户端提供有关其自身的信息，以用于可能的日志记录和统计目的。所有客户端都应在连接到服务器后发送此命令。所有DICT服务器都必须实现此命令（不过请注意，服务器不必对客户机提供的信息执行任何操作）。
250 ok (optional timing information here)
250正常（此处可选定时信息）
This response code requires no special parameters.
此响应代码不需要特殊参数。
STATUS
地位
Display some server-specific timing or debugging information. This information may be useful in debugging or tuning a DICT server. All DICT servers MUST implement this command (note, though, that the text part of the response is not specified and may be omitted).
显示某些特定于服务器的计时或调试信息。此信息在调试或调优DICT服务器时可能很有用。所有DICT服务器都必须实现此命令（但请注意，响应的文本部分没有指定，可能会被忽略）。
210 (optional timing and statistical information here)
210（此处可选定时和统计信息）
This response code requires no special parameters.
此响应代码不需要特殊参数。
HELP
帮助
Provides a short summary of commands that are understood by this implementation of the DICT server. The help text will be presented as a textual response, terminated by a single period on a line by itself. All DICT servers MUST implement this command.
提供此DICT服务器实现可以理解的命令的简短摘要。帮助文本将以文本响应的形式呈现，在一行中以单个句点结束。所有DICT服务器都必须执行此命令。
113 help text follows
113帮助文本如下
This response code requires no special parameters.
此响应代码不需要特殊参数。
QUIT
退出
This command is used by the client to cleanly exit the server. All DICT servers MUST implement this command.
客户机使用此命令干净地退出服务器。所有DICT服务器都必须执行此命令。
221 Closing Connection
221闭合连接
This response code requires no special parameters.
此响应代码不需要特殊参数。
OPTION MIME
选项MIME
Requests that all text responses be prefaced by a MIME header [RFC2045] followed by a single blank line (CRLF).
请求在所有文本响应前面加上MIME头[RFC2045]，后跟一个空行（CRLF）。
If a client requests this option, then the client MUST be able to parse Content-Type and Content-transfer-encoding headers, and MUST be able to ignore textual responses which have an unsupported content or encoding. A client MUST support the UTF-8 encoding [RFC2044], which minimally means that the client MUST recognize UTF-8 multi-octet encodings and convert these into some symbol that can be printed by the client.
如果客户端请求此选项，则客户端必须能够解析内容类型和内容传输编码头，并且必须能够忽略具有不受支持的内容或编码的文本响应。客户机必须支持UTF-8编码[RFC2044]，这至少意味着客户机必须识别UTF-8多八位组编码，并将其转换为可由客户机打印的符号。
If a client requests this option, then the server will provide a MIME header. If the header is empty, the text response will start with a single blank line (CRLF), in which case a client MUST interpret this as a default header. The default header for SASL authentication is:
如果客户端请求此选项，则服务器将提供MIME头。如果标题为空，文本响应将以单个空行（CRLF）开始，在这种情况下，客户端必须将其解释为默认标题。SASL身份验证的默认标头为：
Content-type: application/octet-stream Content-transfer-encoding: base64
内容类型：应用程序/八位字节流内容传输编码：base64
The default header for all other textual responses is:
所有其他文本响应的默认标题为：
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
If OPTION MIME is not specified by the client, then the server may restrict the information content provided to the client. For example, a definition may be accompanied by an image and an audio clip, but the server cannot transmit this information unless the client is able to parse MIME format headers.
如果客户端未指定选项MIME，则服务器可能会限制提供给客户端的信息内容。例如，定义可能伴随着图像和音频剪辑，但服务器无法传输此信息，除非客户端能够解析MIME格式头。
Note that, because of the line length restrictions and end-of-response semantics, the "binary" content-transfer-encoding MUST NOT be used. In the future, extensions to the protocol may be provided which allow a client to request binary encodings, but the default SHOULD always be that the client can look for a "CRLF . CRLF" sequence to locate the end of the current text response. This allows clients to easily skip over text responses which have unsupported types or encodings.
请注意，由于行长度限制和响应结束语义，因此不能使用“二进制”内容传输编码。将来，可能会提供协议扩展，允许客户端请求二进制编码，但默认情况下，客户端可以查找“CRLF.CRLF”序列以定位当前文本响应的结尾。这允许客户端轻松跳过具有不支持的类型或编码的文本响应。
In the future, after significant experience with large databases in various languages has been gained, and after evaluating the need for specifying character sets and other encodings (e.g., compressed or BASE64 encoding), standard extensions to this protocol should be proposed which allow the client to request certain content types or encodings. Care should be taken that these extensions do not require a handshake which defeats pipelining. In the mean time, private extensions should be used to explore the parameter space to determine how best to implement these extensions.
将来，在获得使用各种语言的大型数据库的丰富经验后，以及在评估指定字符集和其他编码（例如，压缩或BASE64编码）的需要后，应建议对该协议进行标准扩展，允许客户端请求某些内容类型或编码。应注意，这些扩展不需要握手，因为握手会破坏流水线。同时，应该使用私有扩展来探索参数空间，以确定如何最好地实现这些扩展。
OPTION MIME is a REQUIRED server capability, all DICT servers MUST implement this command.
选项MIME是必需的服务器功能，所有DICT服务器都必须实现此命令。
250 ok (optional timing information here)
250正常（此处可选定时信息）
Note that some older server implementations, completed before this document was finalized, will return a status code 500 if this command is not implemented. Clients SHOULD be able to accept this behavior,
请注意，如果未执行此命令，则在本文档最终确定之前完成的一些旧服务器实现将返回状态代码500。客户应该能够接受这种行为，
making default assumptions. Clients may also examine the capabilities string in the status code 220 header to determine if a server supports this capability.
做出默认假设。客户端还可以检查状态代码220报头中的能力字符串，以确定服务器是否支持该能力。
AUTH username authentication-string
验证用户名验证字符串
The client can authenticate itself to the server using a username and password. The authentication-string will be computed as in the APOP protocol discussed in [RFC1939]. Briefly, the authentication-string is the MD5 checksum of the concatenation of the msg-id (obtained from the initial banner) and the "shared secret" that is stored in the server and client configuration files. Since the user does not have to type this shared secret when accessing the server, the shared secret can be an arbitrarily long passphrase. Because of the computational ease of computing the MD5 checksum, the shared secret should be significantly longer than a usual password.
客户端可以使用用户名和密码向服务器进行身份验证。验证字符串将按照[RFC1939]中讨论的APOP协议进行计算。简而言之，身份验证字符串是msg id（从初始横幅获得）与存储在服务器和客户端配置文件中的“共享机密”的串联MD5校验和。由于用户在访问服务器时不必键入此共享密钥，因此共享密钥可以是任意长的密码短语。由于计算MD5校验和的计算简单，共享密钥应该比普通密码长很多。
Authentication may make more dictionary databases available for the current session. For example, there may be some publicly distributable databases available to all users, and other private databases available only to authenticated users. Or, a server may require authentication from all users to minimize resource utilization on the server machine.
身份验证可能使更多字典数据库可用于当前会话。例如，可能有一些可公开分发的数据库可供所有用户使用，而其他私有数据库仅可供经过身份验证的用户使用。或者，服务器可能需要所有用户的身份验证，以最小化服务器机器上的资源利用率。
Authentication is an optional server capability. The AUTH command MAY be implemented by a DICT server.
身份验证是可选的服务器功能。AUTH命令可以由DICT服务器实现。
230 Authentication successful 531 Access denied, use "SHOW INFO" for server information
230身份验证成功531访问被拒绝，请使用“显示信息”获取服务器信息
These response codes require no special parameters.
这些响应代码不需要特殊参数。
SASLAUTH mechanism initial-response SASLRESP response
SASLAUTH机制初始响应SASLRESP响应
The Simple Authentication and Security Layer (SASL) is currently being developed [RFC2222]. The DICT protocol reserves the SASLAUTH and SASLRESP commands for this method of authentication. The results
目前正在开发简单身份验证和安全层（SASL）[RFC2222]。DICT协议保留用于此身份验证方法的SASLAUTH和SASLRESP命令。结果
of successful authentication with SALSAUTH will be the same as the results of successful AUTH authentication: more dictionary databases may become available for the current session.
使用SALSAUTH成功进行身份验证的结果与成功进行身份验证的结果相同：当前会话可能会有更多字典数据库可用。
The initial-response is an optional parameter for the SASLAUTH command, encoded using BASE64 encoding [RFC2045]. Some SASL mechanisms may allow the use of this parameter. If SASL authentication is supported by a DICT server, then this parameter MUST also be supported.
初始响应是SASLAUTH命令的可选参数，使用BASE64编码[rfc245]进行编码。某些SASL机制可能允许使用此参数。如果DICT服务器支持SASL身份验证，则还必须支持此参数。
A typical SASL authentication will be initiated by the client using the SASLAUTH command. The server will reply with status code 130, followed by a challenge. The challenge will be followed by status code 330, indicating that the client must now send a response to the server.
典型的SASL身份验证将由客户端使用SASLAUTH命令启动。服务器将回复状态代码130，然后是质询。质询之后将是状态代码330，指示客户端现在必须向服务器发送响应。
Depending on the details of the SASL mechanism currently in use, the server will either continue the exchange using status code 130, a challenge, and status code 330; or the server will use status code 230 or 531 to indicate authentication was successful or has failed.
根据当前使用的SASL机制的细节，服务器将使用状态代码130、质询和状态代码330继续交换；或者服务器将使用状态代码230或531指示身份验证成功或失败。
The challenges sent by the server are defined by the mechanisms as binary tokens of arbitrary length, and should be sent using a standard DICT textual response, as described in section 2.4.3. If OPTION MIME is not set, then BASE64 encoding MUST be used. If
服务器发送的质询由机制定义为任意长度的二进制令牌，应使用标准DICT文本响应发送，如第2.4.3节所述。如果未设置MIME选项，则必须使用BASE64编码。如果
OPTION MIME is set, then BASE64 is the default encoding, as specified in section 3.10.1.
设置MIME选项，则BASE64为默认编码，如第3.10.1节所述。
The client will send all responses using the SASLRESP command and a BASE64-encoded parameter. The responses sent by the client are defined by the mechanisms as binary tokens of arbitrary length. Remember that DICT command lines may only be 1024 characters in length, so the response provided by a DICT client is limited.
客户端将使用SASLRESP命令和BASE64编码参数发送所有响应。客户端发送的响应由机制定义为任意长度的二进制令牌。请记住，DICT命令行的长度可能只有1024个字符，因此DICT客户端提供的响应是有限的。
If the mechanism specified in the SASLAUTH command is not supported, then status code 532 will be returned.
如果不支持SASLAUTH命令中指定的机制，则将返回状态代码532。
Authentication is an optional server capability. The SASLAUTH command MAY be implemented by a DICT server.
身份验证是可选的服务器功能。SASLAUTH命令可以由DICT服务器实现。
130 challenge follows 330 send response 230 Authentication successful 531 Access denied, use "SHOW INFO" for server information 532 Access denied, unknown mechanism
130质询之后330发送响应230身份验证成功531访问被拒绝，使用“显示信息”获取服务器信息532访问被拒绝，未知机制
These response codes require no special parameters.
这些响应代码不需要特殊参数。
All DICT servers MUST be able to accept multiple commands in a single TCP send operation. Using a single TCP send operation for multiple commands can improved DICT performance significantly, especially in the face of high latency network links.
所有DICT服务器必须能够在单个TCP发送操作中接受多个命令。对多个命令使用单个TCP发送操作可以显著提高DICT性能，尤其是在面对高延迟网络链路时。
The possible implementation problems for a DICT server which would prevent command pipelining are similar to the problems that prevent pipelining in an SMTP server. These problems are discussed in detail in [RFC1854], which should be consulted by all DICT server implementors.
DICT服务器可能出现的阻止命令管道化的实现问题与SMTP服务器中阻止管道化的问题类似。[RFC1854]中详细讨论了这些问题，所有DICT服务器实现者都应该参考这些问题。
The main implication is that a DICT server implementation MUST NOT flush or otherwise lose the contents of the TCP input buffer under any circumstances whatsoever.
主要含义是DICT服务器实现在任何情况下都不得刷新或丢失TCP输入缓冲区的内容。
A DICT client may pipeline several commands and must check the responses to each command individually. If the server has shut down, it is possible that all of the commands will not be processed. For example, a simple DICT client may pipeline a CLIENT, DEFINE, and QUIT command sequence as it is connecting to the server. If the server is shut down, the initial response code sent by the server may be 420 (temporarily unavailable) instead of 220 (banner). In this case, the definition cannot be retrieved, and the client should report and error or retry the command. If the server is working, it may be able to send back the banner, definition, and termination message in a single TCP send operation.
DICT客户端可以通过管道传输多个命令，并且必须单独检查每个命令的响应。如果服务器已关闭，则可能无法处理所有命令。例如，一个简单的DICT客户机可以在连接到服务器时对客户机进行管道化、定义并退出命令序列。如果服务器关闭，则服务器发送的初始响应代码可能是420（暂时不可用），而不是220（横幅）。在这种情况下，无法检索定义，客户端应报告并出错或重试该命令。如果服务器正在工作，它可能能够在单个TCP发送操作中发回标题、定义和终止消息。
The DICT URL scheme is used to refer to definitions or word lists available using the DICT protocol:
DICT URL方案用于引用使用DICT协议可用的定义或单词列表：
dict://<user>;<auth>@<host>:<port>/d:<word>:<database>:<n>
dict://<user>;<auth>@<host>:<port>/m:<word>:<database>:<strat>:<n>
dict://<user>;<auth>@<host>:<port>/d:<word>:<database>:<n>
dict://<user>;<auth>@<host>:<port>/m:<word>:<database>:<strat>:<n>
The "/d" syntax specifies the DEFINE command (section 3.2), whereas the "/m" specifies the MATCH command (section 3.3).
“/d”语法指定DEFINE命令（第3.2节），而“/m”语法指定MATCH命令（第3.3节）。
Some or all of "<user>;<auth>@", ":<port>", "<database>", "<strat>", and "<n>" may be omitted.
可以省略部分或全部“<user>；<auth>@”、“：<port>”、“<database>”、“<strat>”和“<n>”。
"<n>" will usually be omitted, but when included, it specifies the nth definition or match of a word. A method for extracting exactly this information from the server is not available using the DICT protocol. However, a client using the URL specification could obtain all of the definitions or matches, and then select the one that is specified.
“<n>”通常会被省略，但包含时，它会指定单词的第n个定义或匹配项。无法使用DICT协议从服务器中准确提取此信息。但是，使用URL规范的客户端可以获得所有定义或匹配项，然后选择指定的定义或匹配项。
If "<user>;<auth>@" is omitted, no authentication is done. If ":<port>" is omitted, the default port (2628) SHOULD be used. If "<database>" is omitted, "!" SHOULD be used (see section 3.2). If "<strat>" is omitted, "." SHOULD be used (see section 3.3).
如果省略“<user>；<auth>@”，则不会进行身份验证。如果省略“：<port>”，则应使用默认端口（2628）。如果省略“<database>”，则应使用“！”（见第3.2节）。如果省略“<strat>”，则应使用“.”（见第3.3节）。
"<user>;<auth>@" specifies the username and the type of authentication performed. For "<auth>", the string "AUTH" indicates that APOP authentication using the AUTH command will be performed, whereas the string "SASLAUTH=<auth_type>" indicates that the SASLAUTH and SASLRESP commands will be used, with "<auth_type>" indicating the type of SASL authentication which will be used. If "<auth_type>" is a star (decimal code 42, "*"), then the client will select some type of authentication.
“<user>；<auth>@”指定用户名和执行的身份验证类型。对于“<auth>”，字符串“auth”表示将使用auth命令执行APOP身份验证，而字符串“SASLAUTH=<auth\u type>”表示将使用SASLAUTH和SASLRESP命令，“<auth\u type>”表示将使用的SASL身份验证类型。如果“<auth_type>”是星形（十进制代码42，*”），则客户端将选择某种类型的身份验证。
Whenever authentication is required, the client SHOULD request additional information (e.g., a passphrase) from the user. In contrast to [RFC1738], clear text passwords are not permitted in the URL.
无论何时需要身份验证，客户端都应向用户请求附加信息（例如，密码短语）。与[RFC1738]相反，URL中不允许使用明文密码。
Trailing colons may be omitted. For example, the following URLs might specify definitions or matches:
尾随冒号可以省略。例如，以下URL可能指定定义或匹配项：
dict://dict.org/d:shortcake:
dict://dict.org/d:shortcake:*
dict://dict.org/d:shortcake:wordnet:
dict://dict.org/d:shortcake:wordnet:1
dict://dict.org/d:abcdefgh
dict://dict.org/d:sun
dict://dict.org/d:sun::1
dict://dict.org/d:shortcake:
dict://dict.org/d:shortcake:*
dict://dict.org/d:shortcake:wordnet:
dict://dict.org/d:shortcake:wordnet:1
dict://dict.org/d:abcdefgh
dict://dict.org/d:sun
dict://dict.org/d:sun::1
dict://dict.org/m:sun dict://dict.org/m:sun::soundex dict://dict.org/m:sun:wordnet::1 dict://dict.org/m:sun::soundex:1 dict://dict.org/m:sun:::
dict://dict.org/m:sun dict://dict.org/m:sun::soundex dict://dict.org/m:sun:wordnet::1 dict://dict.org/m:sun::soundex:1 dict://dict.org/m:sun:::
This protocol was designed so that flat text databases can be used with a server after a minimum of analysis and formatting. Our experience is that merely constructing an index for a database may be sufficient to make it useful with a DICT server. The ability to serve preformatted text is especially important since freely-available databases are often distributed as flat text files without any semantic mark-up information (and often contain "ASCII art" which precludes the automation of even simple formatting).
此协议的设计目的是，在进行最少的分析和格式化之后，可以将平面文本数据库与服务器一起使用。我们的经验是，仅仅为数据库构造一个索引就足以使它对DICT服务器有用。提供预格式化文本的能力尤其重要，因为免费提供的数据库通常作为平面文本文件分发，而没有任何语义标记信息（并且通常包含“ASCII艺术”，即使是简单的格式化也无法实现自动化）。
However, given a database with sufficient mark-up information, it may be possible to generate output in a variety of different formats (e.g., simple HTML or more sophisticated SGML). The specification of formatting is beyond the scope of this document. The requirements for negotiation of format (including character set and other encodings) is complex and should be examined over time as more experience is gained. We suggest that the use of different formats, as well as other server features, be explored as extensions to the protocol.
但是，如果数据库具有足够的标记信息，则可以生成各种不同格式的输出（例如，简单的HTML或更复杂的SGML）。格式规范超出了本文档的范围。格式协商（包括字符集和其他编码）的要求是复杂的，随着经验的积累，应该随着时间的推移进行检查。我们建议使用不同的格式以及其他服务器功能，作为协议的扩展。
Single-letter commands are reserved for debugging and testing, SHOULD NOT be defined in any future DICT protocol specification, and MUST NOT be used by any client software.
单字母命令保留用于调试和测试，不应在任何未来的DICT协议规范中定义，并且不得由任何客户端软件使用。
Commands beginning with the letter "X" are reserved for experimental extensions, and SHOULD NOT be defined in any future DICT protocol specification. Authors of client software should understand that these commands are not part of the DICT protocol and may not be available on all DICT servers.
以字母“X”开头的命令保留用于实验性扩展，不应在任何未来的DICT协议规范中定义。客户机软件的作者应了解，这些命令不是DICT协议的一部分，可能无法在所有DICT服务器上使用。
Experimental commands should be designed so that a client can pipeline the experimental commands without knowing if a server supports the commands (e.g., instead of using feature negotiation). If the server does not support the commands, then a response code in the 5yz series (usually 500) will be given, notifying the client that the extension is not supported. Of course, depending on the complexity of the extensions added, feature negotiation may be necessary. To help minimize negotiation time, server-supported features may be announced in the banner (code 220) using the optional capabilities parameter.
实验命令的设计应确保客户端可以在不知道服务器是否支持这些命令的情况下通过管道传输实验命令（例如，不使用功能协商）。如果服务器不支持这些命令，则会给出5yz系列（通常为500）中的响应代码，通知客户端不支持扩展。当然，根据添加的扩展的复杂性，功能协商可能是必要的。为了帮助最小化协商时间，可以使用可选的capabilities参数在横幅（代码220）中宣布服务器支持的功能。
Below is a summary of response codes. A star (*) in the first column indicates the response has defined arguments that must be provided.
下面是响应代码的摘要。第一列中的星号（*）表示响应定义了必须提供的参数。
* 110 n databases present - text follows * 111 n strategies available - text follows 112 database information follows 113 help text follows 114 server information follows 130 challenge follows * 150 n definitions retrieved - definitions follow * 151 word database name - text follows * 152 n matches found - text follows 210 (optional timing and statistical information here) * 220 text msg-id 221 Closing Connection 230 Authentication successful 250 ok (optional timing information here) 330 send response 420 Server temporarily unavailable 421 Server shutting down at operator request 500 Syntax error, command not recognized 501 Syntax error, illegal parameters 502 Command not implemented 503 Command parameter not implemented 530 Access denied 531 Access denied, use "SHOW INFO" for server information 532 Access denied, unknown mechanism 550 Invalid database, use "SHOW DB" for list of databases 551 Invalid strategy, use "SHOW STRAT" for a list of strategies 552 No match 554 No databases present 555 No strategies available
* 存在110 n数据库-文本跟随*111 n可用策略-文本跟随112数据库信息跟随113帮助文本跟随114服务器信息跟随130挑战跟随*检索150 n定义-定义跟随*151单词数据库名称-文本跟随*找到152 n匹配项-文本跟随210（此处可选定时和统计信息）*220文本消息id 221关闭连接230身份验证成功250正常（此处可选定时信息）330发送响应420服务器暂时不可用421服务器在操作员请求时关闭500语法错误，命令未识别501语法错误，非法参数502命令未执行503命令参数未执行530访问被拒绝531访问被拒绝，使用“显示信息”对于服务器信息532拒绝访问，未知机制550无效数据库，使用“SHOW DB”查看数据库列表551无效策略，使用“SHOW STRAT”查看策略列表552不匹配554不存在数据库555不可用策略
Theses are samples of the conversations that might be expected with a typical DICT server. The notation "C:" indicates commands set by the client, and "S:" indicates responses sent by the server. Blank lines are included for clarity and do not indicate actual newlines in the transaction.
这些是典型的DICT服务器可能需要的对话示例。符号“C:”表示客户端设置的命令，“S:”表示服务器发送的响应。为清晰起见，包含空行，不表示交易中的实际换行。
C: [ client initiates connection ]
C:[客户端启动连接]
S: 220 dict.org dictd (version 0.9) <27831.860032493@dict.org>
S: 220 dict.org dictd (version 0.9) <27831.860032493@dict.org>
C: HELP
C:救命
S: 113 Help text follows
S: DEFINE database word look up word in database
S: MATCH database strategy word match word in database using strategy
S: [ more server-dependent help text ]
S: .
S: 250 Command complete
S: 113 Help text follows
S: DEFINE database word look up word in database
S: MATCH database strategy word match word in database using strategy
S: [ more server-dependent help text ]
S: .
S: 250 Command complete
C: DEFINE ! penguin
C:定义！企鹅
S: 150 1 definitions found: list follows
S: 151 "penguin" wn "WordNet 1.5" : definition text follows
S: penguin
S: 1. n: short-legged flightless birds of cold southern esp. Antarctic
S: regions having webbed feet and wings modified as flippers
S: .
S: 250 Command complete
S: 150 1 definitions found: list follows
S: 151 "penguin" wn "WordNet 1.5" : definition text follows
S: penguin
S: 1. n: short-legged flightless birds of cold southern esp. Antarctic
S: regions having webbed feet and wings modified as flippers
S: .
S: 250 Command complete
C: DEFINE * shortcake
C:定义*快捷键
S: 150 2 definitions found: list follows
S: 151 "shortcake" wn "WordNet 1.5" : text follows
S: shortcake
S: 1. n: very short biscuit spread with sweetened fruit and usu.
S: whipped cream
S: .
S: 151 "Shortcake" web1913 "Webster's Dictionary (1913)" : text follows
S: Shortcake
S: \Short"cake`\, n.
S: An unsweetened breakfast cake shortened with butter or lard,
S: rolled thin, and baked.
S: .
S: 250 Command complete
S: 150 2 definitions found: list follows
S: 151 "shortcake" wn "WordNet 1.5" : text follows
S: shortcake
S: 1. n: very short biscuit spread with sweetened fruit and usu.
S: whipped cream
S: .
S: 151 "Shortcake" web1913 "Webster's Dictionary (1913)" : text follows
S: Shortcake
S: \Short"cake`\, n.
S: An unsweetened breakfast cake shortened with butter or lard,
S: rolled thin, and baked.
S: .
S: 250 Command complete
C: DEFINE abcdefgh
C:定义abcdefgh
S: 552 No match
S:552不匹配
C: quit
C:退出
S: 221 Closing connection
S:221闭合连接
C: SHOW DB
C:显示数据库
S: 110 3 databases present: list follows
S: wn "WordNet 1.5"
S: foldoc "Free On-Line Dictionary of Computing"
S: jargon "Hacker Jargon File"
S: .
S: 250 Command complete
S: 110 3 databases present: list follows
S: wn "WordNet 1.5"
S: foldoc "Free On-Line Dictionary of Computing"
S: jargon "Hacker Jargon File"
S: .
S: 250 Command complete
C: SHOW STRAT
C:SHOW STRAT
S: 111 5 strategies present: list follows
S: exact "Match words exactly"
S: prefix "Match word prefixes"
S: substring "Match substrings anywhere in word"
S: regex "Match using regular expressions"
S: reverse "Match words given definition keywords"
S: .
S: 250 Command complete
S: 111 5 strategies present: list follows
S: exact "Match words exactly"
S: prefix "Match word prefixes"
S: substring "Match substrings anywhere in word"
S: regex "Match using regular expressions"
S: reverse "Match words given definition keywords"
S: .
S: 250 Command complete
C: MATCH foldoc regex "s.si"
C:匹配foldoc regex“s.si”
S: 152 7 matches found: list follows
S: foldoc Fast SCSI
S: foldoc SCSI
S: foldoc SCSI-1
S: foldoc SCSI-2
S: foldoc SCSI-3
S: foldoc Ultra-SCSI
S: foldoc Wide SCSI
S: .
S: 250 Command complete
S: 152 7 matches found: list follows
S: foldoc Fast SCSI
S: foldoc SCSI
S: foldoc SCSI-1
S: foldoc SCSI-2
S: foldoc SCSI-3
S: foldoc Ultra-SCSI
S: foldoc Wide SCSI
S: .
S: 250 Command complete
C: MATCH wn substring "abcdefgh"
C:匹配wn子字符串“abcdefgh”
S: 552 No match
S:552不匹配
C: [ client initiates connection ]
C:[客户端启动连接]
S: 420 Server temporarily unavailable
S:420服务器暂时不可用
C: [ client initiates connection ]
C:[客户端启动连接]
S: 421 Server shutting down at operator request
S:421服务器应操作员请求关闭
C: [ client initiates connection ]
C:[客户端启动连接]
S: 220 dict.org dictd (version 0.9) <27831.860032493@dict.org>
S: 220 dict.org dictd (version 0.9) <27831.860032493@dict.org>
C: SHOW DB
C:显示数据库
S: 110 1 database present: list follows
S: free "Free database"
S: .
S: 250 Command complete
S: 110 1 database present: list follows
S: free "Free database"
S: .
S: 250 Command complete
C: AUTH joesmith authentication-string
C:AUTH joesmith身份验证字符串
S: 230 Authentication successful
S:230身份验证成功
C: SHOW DB
C:显示数据库
S: 110 2 databases present: list follows
S: free "Free database"
S: licensed "Local licensed database"
S: .
S: 250 Command complete
S: 110 2 databases present: list follows
S: free "Free database"
S: licensed "Local licensed database"
S: .
S: 250 Command complete
This RFC raises no security issues.
此RFC不会引起任何安全问题。
[ASCII] US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
[ASCII]US-ASCII。编码字符集.信息交换用7位美国标准代码。标准ANSI X3.4-1986，ANSI，1986。
[FOLDOC] Howe, Denis, ed. The Free On-Line Dictionary of
Computing, <URL:http://wombat.doc.ic.ac.uk/>
[FOLDOC] Howe, Denis, ed. The Free On-Line Dictionary of
Computing, <URL:http://wombat.doc.ic.ac.uk/>
[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. UTF-8 is described in Annex R, adopted but not yet published. UTF-16 is described in Annex Q, adopted but not yet published.
[ISO10646]ISO/IEC 10646-1:1993。国际标准信息技术通用多八位编码字符集（UCS）第1部分：体系结构和基本多语言平面。附件R中描述了UTF-8，已采用但尚未发布。附件Q中描述了UTF-16，已采用但尚未发布。
[JARGON] The on-line hacker Jargon File, version 4.0.0, 25 JUL
1996, <URL:http://www.ccil.org/jargon/>
[JARGON] The on-line hacker Jargon File, version 4.0.0, 25 JUL
1996, <URL:http://www.ccil.org/jargon/>
[KNUTH73] Knuth, Donald E. "The Art of Computer Programming", Volume 3: Sorting and Searching (Addison-Wesley Publishing Co., 1973, pages 391 and 392). Knuth notes that the soundex method was originally described by Margaret K. Odell and Robert C. Russell [US Patents 1261167 (1918) and 1435663 (1922)].
[KNUTH73]Donald E.Knuth，“计算机编程的艺术”，第3卷：分类和搜索（Addison-Wesley Publishing Co.，1973，第391和392页）。Knuth指出soundex方法最初由Margaret K.Odell和Robert C.Russell描述[美国专利1261167（1918）和1435663（1922）]。
[PZ85] Pollock, Joseph J. and Zamora, Antonio, "Automatic spelling correction in scientific and scholarly text," CACM, 27(4): Apr. 1985, 358-368.
[PZ85]Pollock，Joseph J.和Zamora，Antonio，“科学和学术文本中的自动拼写更正”，CACM，27（4）：1985年4月，358-368。
[RFC640] Postel, J., "Revised FTP Reply Codes", RFC 640, June, 1975.
[RFC640]Postel，J.，“修改后的FTP回复代码”，RFC 640，1975年6月。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC821]Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[RFC977] Kantor, B., and P. Lapsley, "Network News Transfer Protocol: A Proposed Standard for the Stream-Based Transmission of News", RFC 977, February 1986.
[RFC977]Kantor，B.和P.Lapsley，“网络新闻传输协议：基于流的新闻传输的拟议标准”，RFC 977，1986年2月。
[RFC2045] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738]Berners Lee，T.，Masinter，L.和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[RFC1760] Haller, N., "The S/KEY One-Time Password System", RFC 1760, February 1995.
[RFC1760]Haller，N.，“S/键一次性密码系统”，RFC1760，1995年2月。
[RFC1985] Freed, N., and A. Cargille, "SMTP Service Extension for Command Pipelining", RFC 1854, October 1995.
[RFC1985]Freed，N.和A.Cargille，“用于命令管道的SMTP服务扩展”，RFC18541995年10月。
[RFC1939] Myers, J., and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[RFC2044]Yergeau，F.，“UTF-8，Unicode和ISO10646的转换格式”，RFC 2044，1996年10月。
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[RFC2068]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[RFC2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[RFC2078]Linn，J.，“通用安全服务应用程序接口，第2版”，RFC 2078，1997年1月。
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC2222]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
[WEB1913] Webster's Revised Unabridged Dictionary (G & C. Merriam
Co., 1913, edited by Noah Porter). Online version prepared by
MICRA, Inc., Plainfield, N.J. and edited by Patrick Cassidy
<cassidy@micra.com>. For further information, see
<URL:ftp://uiarchive.cso.uiuc.edu/pub/etext/gutenberg/etext96/pgw*>,
and
<URL:http://humanities.uchicago.edu/forms_unrest/webster.form.html>
[WEB1913] Webster's Revised Unabridged Dictionary (G & C. Merriam
Co., 1913, edited by Noah Porter). Online version prepared by
MICRA, Inc., Plainfield, N.J. and edited by Patrick Cassidy
<cassidy@micra.com>. For further information, see
<URL:ftp://uiarchive.cso.uiuc.edu/pub/etext/gutenberg/etext96/pgw*>,
and
<URL:http://humanities.uchicago.edu/forms_unrest/webster.form.html>
[WORDNET] Miller, G.A. (1990), ed. WordNet: An On-Line Lexical
Database. International Journal of Lexicography. Volume 3,
Number 4. <URL:http://www.cogsci.princeton.edu/~wn/>
[WORDNET] Miller, G.A. (1990), ed. WordNet: An On-Line Lexical
Database. International Journal of Lexicography. Volume 3,
Number 4. <URL:http://www.cogsci.princeton.edu/~wn/>
Thanks to Arnt Gulbrandsen and Nicolai Langfeldt for many helpful discussions. Thanks to Bennet Yee, Doug Hoffman, Kevin Martin, and Jay Kominek for extensive testing and feedback on the initial implementations of the DICT server. Thanks to Zhong Shao for advice and support.
感谢Arnt Gulbrandsen和Nicolai Langfeldt进行了许多有益的讨论。感谢Bennet Yee、Doug Hoffman、Kevin Martin和Jay Kominek对DICT服务器的初始实现进行了广泛的测试和反馈。感谢钟绍的建议和支持。
Thanks to Brian Kanto, Phil Lapsley, and Jon Postel for writing exemplary RFCs which were consulted during the preparation of this document.
感谢Brian Kanto、Phil Lapsley和Jon Postel编写了示例性RFC，在编写本文件过程中参考了这些RFC。
Thanks to Harald T. Alvestrand, whose comments helped improve this document.
感谢Harald T.Alvestrand，他的评论帮助改进了本文件。
Rickard E. Faith EMail: faith@cs.unc.edu (or faith@acm.org)
Rickard E.Faith电子邮件：faith@cs.unc.edu（或faith@acm.org)
Bret Martin EMail: bamartin@miranda.org
Bret Martin电子邮件：bamartin@miranda.org
The majority of this work was completed while Bret Martin was a student at Yale University.
这项工作的大部分是在布莱特·马丁还是耶鲁大学的学生时完成的。
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published andand distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。