ftpclient.h

实现了wince 客户端上传下载查看文件及目录的功能接口d

   A string of n filler bytes can be compressed into a single
   byte, where the filler byte varies with the representation
   type.  If the type is ASCII or EBCDIC the filler byte is <SP>
   (Space, ASCII code 32, EBCDIC code 64).  If the type is Image
   or Local byte the filler is a zero byte.

   Filler String:
<PRE>
         2       6
      +-+-+-+-+-+-+-+-+
      |1 1|     n     |
      +-+-+-+-+-+-+-+-+
</PRE>
   The escape sequence is a double byte, the first of which is the
   escape byte (all zeros) and the second of which contains
   descriptor codes as defined in Block mode.  The descriptor
   codes have the same meaning as in Block mode and apply to the
   succeeding string of bytes.

   Compressed mode is useful for obtaining increased bandwidth on
   very large network transmissions at a little extra CPU cost.
   It can be most effectively used to reduce the size of printer
   files such as those generated by RJE hosts.
*/

/** \class nsFTP::CRepresentation
   DATA REPRESENTATION AND STORAGE

   Data is transferred from a storage device in the sending host to a
   storage device in the receiving host.  Often it is necessary to
   perform certain transformations on the data because data storage
   representations in the two systems are different.  For example,
   NVT-ASCII has different data storage representations in different
   systems.  DEC TOPS-20s's generally store NVT-ASCII as five 7-bit
   ASCII characters, left-justified in a 36-bit word. IBM Mainframe's
   store NVT-ASCII as 8-bit EBCDIC codes.  Multics stores NVT-ASCII
   as four 9-bit characters in a 36-bit word.  It is desirable to
   convert characters into the standard NVT-ASCII representation when
   transmitting text between dissimilar systems.  The sending and
   receiving sites would have to perform the necessary
   transformations between the standard representation and their
   internal representations.

   A different problem in representation arises when transmitting
   binary data (not character codes) between host systems with
   different word lengths.  It is not always clear how the sender
   should send data, and the receiver store it.  For example, when
   transmitting 32-bit bytes from a 32-bit word-length system to a
   36-bit word-length system, it may be desirable (for reasons of
   efficiency and usefulness) to store the 32-bit bytes
   right-justified in a 36-bit word in the latter system.  In any
   case, the user should have the option of specifying data
   representation and transformation functions.  It should be noted

   that FTP provides for very limited data type representations.
   Transformations desired beyond this limited capability should be
   performed by the user directly.

   Several types take a second parameter. The first parameter is
   denoted by a single Telnet character, as is the second
   Format parameter for ASCII and EBCDIC; the second parameter
   for local byte is a decimal integer to indicate Bytesize.
   The parameters are separated by a <SP> (Space, ASCII code
   32).

   The following codes are assigned for type:
<PRE>
                \    /
      A - ASCII |    | N - Non-print
                |-><-| T - Telnet format effectors
      E - EBCDIC|    | C - Carriage Control (ASA)
                /    \
      I - Image

      L <byte size> - Local byte Byte size
</PRE>
   The default representation type is ASCII Non-print.  If the
   Format parameter is changed, and later just the first
   argument is changed, Format then returns to the Non-print
   default.
*/

/** \class nsFTP::CType
   Objects of this class are only used in conjunction with CRepresentation.

   DATA TYPES

   Data representations are handled in FTP by a user specifying a
   representation type.  This type may implicitly (as in ASCII or
   EBCDIC) or explicitly (as in Local byte) define a byte size for
   interpretation which is referred to as the "logical byte size."
   Note that this has nothing to do with the byte size used for
   transmission over the data connection, called the "transfer
   byte size", and the two should not be confused.  For example,
   NVT-ASCII has a logical byte size of 8 bits.  If the type is
   Local byte, then the TYPE command has an obligatory second
   parameter specifying the logical byte size.  The transfer byte
   size is always 8 bits.
*/

/** \fn static const CType nsFTP::CType::ASCII()
   This is the default type and must be accepted by all FTP
   implementations.  It is intended primarily for the transfer
   of text files, except when both hosts would find the EBCDIC
   type more convenient.

   The sender converts the data from an internal character
   representation to the standard 8-bit NVT-ASCII
   representation (see the Telnet specification).  The receiver
   will convert the data from the standard form to his own
   internal form.

   In accordance with the NVT standard, the <CRLF> sequence
   should be used where necessary to denote the end of a line
   of text.  (See the discussion of file structure at the end
   of the Section on Data Representation and Storage.)

   Using the standard NVT-ASCII representation means that data
   must be interpreted as 8-bit bytes.

   The Format parameter for ASCII and EBCDIC types is discussed
   below.
*/

/** \fn static const CType nsFTP::CType::EBCDIC()
   This type is intended for efficient transfer between hosts
   which use EBCDIC for their internal character
   representation.

   For transmission, the data are represented as 8-bit EBCDIC
   characters.  The character code is the only difference
   between the functional specifications of EBCDIC and ASCII
   types.

   End-of-line (as opposed to end-of-record--see the discussion
   of structure) will probably be rarely used with EBCDIC type
   for purposes of denoting structure, but where it is
   necessary the <NL> character should be used.
*/

/** \fn static const CType nsFTP::CType::Image()
   The data are sent as contiguous bits which, for transfer,
   are packed into the 8-bit transfer bytes.  The receiving
   site must store the data as contiguous bits.  The structure
   of the storage system might necessitate the padding of the
   file (or of each record, for a record-structured file) to
   some convenient boundary (byte, word or block).  This
   padding, which must be all zeros, may occur only at the end
   of the file (or at the end of each record) and there must be
   a way of identifying the padding bits so that they may be
   stripped off if the file is retrieved.  The padding
   transformation should be well publicized to enable a user to
   process a file at the storage site.

   Image type is intended for the efficient storage and
   retrieval of files and for the transfer of binary data.  It
   is recommended that this type be accepted by all FTP
   implementations.
*/

/** \fn static const CType nsFTP::CType::LocalByte()
   The data is transferred in logical bytes of the size
   specified by the obligatory second parameter, Byte size.
   The value of Byte size must be a decimal integer; there is
   no default value.  The logical byte size is not necessarily
   the same as the transfer byte size.  If there is a
   difference in byte sizes, then the logical bytes should be
   packed contiguously, disregarding transfer byte boundaries
   and with any necessary padding at the end.

   When the data reaches the receiving host, it will be
   transformed in a manner dependent on the logical byte size
   and the particular host.  This transformation must be
   invertible (i.e., an identical file can be retrieved if the
   same parameters are used) and should be well publicized by
   the FTP implementors.

   For example, a user sending 36-bit floating-point numbers to
   a host with a 32-bit word could send that data as Local byte
   with a logical byte size of 36.  The receiving host would
   then be expected to store the logical bytes so that they
   could be easily manipulated; in this example putting the
   36-bit logical bytes into 64-bit double words should
   suffice.

   In another example, a pair of hosts with a 36-bit word size
   may send data to one another in words by using TYPE L 36.
   The data would be sent in the 8-bit transmission bytes
   packed so that 9 transmission bytes carried two host words.
*/

/** \class nsFTP::CTypeFormat
   Objects of this class are only used in conjunction with CRepresentation.

   FORMAT CONTROL

   The types ASCII and EBCDIC also take a second (optional)
   parameter; this is to indicate what kind of vertical format
   control, if any, is associated with a file.  The following
   data representation types are defined in FTP:

   A character file may be transferred to a host for one of
   three purposes: for printing, for storage and later
   retrieval, or for processing.  If a file is sent for
   printing, the receiving host must know how the vertical
   format control is represented.  In the second case, it must
   be possible to store a file at a host and then retrieve it
   later in exactly the same form.  Finally, it should be
   possible to move a file from one host to another and process
   the file at the second host without undue trouble.  A single
   ASCII or EBCDIC format does not satisfy all these
   conditions.  Therefore, these types have a second parameter
   specifying one of the following three formats:
*/

/** \fn static const CTypeFormat nsFTP::CTypeFormat::NonPrint()
   NON PRINT

   This is the default format to be used if the second
   (format) parameter is omitted.  Non-print format must be
   accepted by all FTP implementations.

   The file need contain no vertical format information.  If
   it is passed to a printer process, this process may
   assume standard values for spacing and margins.

   Normally, this format will be used with files destined
   for processing or just storage.
*/

/** \fn static const CTypeFormat nsFTP::CTypeFormat::TelnetFormat()
   TELNET FORMAT CONTROLS

   The file contains ASCII/EBCDIC vertical format controls
   (i.e., <CR>, <LF>, <NL>, <VT>, <FF>) which the printer
   process will interpret appropriately.  <CRLF>, in exactly
   this sequence, also denotes end-of-line.
*/

/** \fn static const CTypeFormat nsFTP::CTypeFormat::CarriageControl()
   CARRIAGE CONTROL (ASA)

   The file contains ASA (FORTRAN) vertical format control
   characters.  (See RFC 740 Appendix C; and Communications
   of the ACM, Vol. 7, No. 10, p. 606, October 1964.)  In a
   line or a record formatted according to the ASA Standard,
   the first character is not to be printed.  Instead, it
   should be used to determine the vertical movement of the
   paper which should take place before the rest of the
   record is printed.

   The ASA Standard specifies the following control
   characters:

      Character     Vertical Spacing

      blank         Move paper up one line
      0             Move paper up two lines
      1             Move paper to top of next page
      +             No movement, i.e., overprint

   Clearly there must be some way for a printer process to
   distinguish the end of the structural entity.  If a file
   has record structure (see below) this is no problem;
   records will be explicitly marked during transfer and
   storage.  If the file has no record structure, the <CRLF>
   end-of-line sequence is used to separate printing lines,
   but these format effectors are overridden by the ASA
   controls.
*/