zlib manual 1.1.4

zlib manual 1.1.4
zlib manual 1.1.4

zlib 1.1.4 Manual

Contents

I. Prologue

II. Introduction

III. Utility functions

IV. Basic functions

V. Advanced functions

VI. Constants

VII. struct z_stream_s

VIII. Checksum functions

IX. Misc

Prologue

'zlib' general purpose compression library version 1.1.4, March 11th, 2002

Copyright (C) 1995-2002 Jean-loup Gailly and Mark Adler

This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.

Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented ; you must not claim that you wrote the

original software. If you use this software in a product, an acknowledgment in the product

documentation would be appreciated but is not required.

2. Altered source versions must be plainly marked as such, and must not be misrepresented as being

the original software.

3. This notice may not be removed or altered from any source distribution.

Jean-loup Gailly

jloup@https://www.360docs.net/doc/8e17977250.html,

Mark Adler

madler@https://www.360docs.net/doc/8e17977250.html,

The data format used by the zlib library is described by RFCs (Request for Comments) 1950 to 1952 in the files rfc1950.txt (zlib format), rfc1951.txt (deflate format) and rfc1952.txt (gzip format).

This manual is converted from zlib.h by piaip

Visit https://www.360docs.net/doc/8e17977250.html, for the official zlib web page.

Introduction

The 'zlib' compression library provides in-memory compression and decompression functions, including integrity checks of the uncompressed data. This version of the library supports only one compression method (deflation) but other algorithms will be added later and will have the same stream interface.

Compression can be done in a single step if the buffers are large enough (for example if an input file is mmap'ed), or can be done by repeated calls of the compression function. In the latter case, the application must provide more input and/or consume the output (providing more output space) before each call.

The library also supports reading and writing files in gzip (.gz) format with an interface similar to that of stdio.

The library does not install any signal handler. The decoder checks the consistency of the compressed data, so the library should never crash even in case of corrupted input.

Utility functions

The following utility functions are implemented on top of the basic stream-oriented functions. To simplify the interface, some default options are assumed (compression level and memory usage, standard memory allocation functions). The source code of these utility functions can easily be modified if you need special options.

Function list

q int compress (Bytef *dest, uLongf *destLen, const Bytef *source, uLong sourceLen);

q int compress2 (Bytef *dest, uLongf *destLen, const Bytef *source, uLong sourceLen, int level);

q int uncompress (Bytef *dest, uLongf *destLen, const Bytef *source, uLong sourceLen);

q typedef voidp gzFile;

q gzFile gzopen (const char *path, const char *mode);

q gzFile gzdopen (int fd, const char *mode);

q int gzsetparams (gzFile file, int level, int strategy);

q int gzread (gzFile file, voidp buf, unsigned len);

q int gzwrite (gzFile file, const voidp buf, unsigned len);

q int VA gzprintf (gzFile file, const char *format, ...);

q int gzputs (gzFile file, const char *s);

q char * gzgets (gzFile file, char *buf, int len);

q int gzputc (gzFile file, int c);

q int gzgetc (gzFile file);

q int gzflush (gzFile file, int flush);

q z_off_t gzseek (gzFile file, z_off_t offset, int whence);

q z_off_t gztell (gzFile file);

q int gzrewind (gzFile file);

q int gzeof (gzFile file);

q int gzclose (gzFile file);

q const char * gzerror (gzFile file, int *errnum);

Function description

int compress (Bytef *dest, uLongf *destLen, const Bytef *source, uLong sourceLen);

Compresses the source buffer into the destination buffer. sourceLen is the byte length of the

source buffer. Upon entry, destLen is the total size of the destination buffer, which must be at least 0.1% larger than sourceLen plus 12 bytes. Upon exit, destLen is the actual size of the

compressed buffer.

This function can be used to compress a whole file at once if the input file is mmap'ed.

compress returns Z_OK if success, Z_MEM_ERROR if there was not enough memory,

Z_BUF_ERROR if there was not enough room in the output buffer.

int compress2 (Bytef *dest, uLongf *destLen, const Bytef *source, uLong sourceLen, int level);

Compresses the source buffer into the destination buffer. The level parameter has the same

meaning as in deflateInit. sourceLen is the byte length of the source buffer. Upon entry, destLen is the total size of the destination buffer, which must be at least 0.1% larger than sourceLen plus

12 bytes. Upon exit, destLen is the actual size of the compressed buffer.

compress2 returns Z_OK if success, Z_MEM_ERROR if there was not enough memory,

Z_BUF_ERROR if there was not enough room in the output buffer, Z_STREAM_ERROR if the level parameter is invalid.

int uncompress (Bytef *dest, uLongf *destLen, const Bytef *source, uLong sourceLen);

Decompresses the source buffer into the destination buffer. sourceLen is the byte length of the source buffer. Upon entry, destLen is the total size of the destination buffer, which must be large enough to hold the entire uncompressed data. (The size of the uncompressed data must have been saved previously by the compressor and transmitted to the decompressor by some mechanism

outside the scope of this compression library.) Upon exit, destLen is the actual size of the

compressed buffer.

This function can be used to decompress a whole file at once if the input file is mmap'ed.

uncompress returns Z_OK if success, Z_MEM_ERROR if there was not enough memory,

Z_BUF_ERROR if there was not enough room in the output buffer, or Z_DATA_ERROR if the input data was corrupted.

typedef voidp gzFile;

gzFile gzopen (const char *path, const char *mode);

Opens a gzip (.gz) file for reading or writing. The mode parameter is as in fopen ("rb" or "wb") but can also include a compression level ("wb9") or a strategy: 'f' for filtered data as in "wb6f", 'h' for Huffman only compression as in "wb1h". (See the description of deflateInit2 for more

information about the strategy parameter.)

gzopen can be used to read a file which is not in gzip format ; in this case gzread will directly

read from the file without decompression.

gzopen returns NULL if the file could not be opened or if there was insufficient memory to

allocate the (de)compression state ; errno can be checked to distinguish the two cases (if errno is zero, the zlib error is Z_MEM_ERROR).

gzFile gzdopen (int fd, const char *mode);

gzdopen() associates a gzFile with the file descriptor fd. File descriptors are obtained from calls like open, dup, creat, pipe or fileno (in the file has been previously opened with fopen). The

mode parameter is as in gzopen.

The next call of gzclose on the returned gzFile will also close the file descriptor fd, just like fclose (fdopen(fd), mode) closes the file descriptor fd. If you want to keep fd open, use gzdopen(dup

(fd), mode).

gzdopen returns NULL if there was insufficient memory to allocate the (de)compression state. int gzsetparams (gzFile file, int level, int strategy);

Dynamically update the compression level or strategy. See the description of deflateInit2 for the meaning of these parameters.

gzsetparams returns Z_OK if success, or Z_STREAM_ERROR if the file was not opened for

writing.

int gzread (gzFile file, voidp buf, unsigned len);

Reads the given number of uncompressed bytes from the compressed file. If the input file was

not in gzip format, gzread copies the given number of bytes into the buffer.

gzread returns the number of uncompressed bytes actually read (0 for end of file, -1 for error).

int gzwrite (gzFile file, const voidp buf, unsigned len);

Writes the given number of uncompressed bytes into the compressed file. gzwrite returns the

number of uncompressed bytes actually written (0 in case of error).

int VA gzprintf (gzFile file, const char *format, ...);

Converts, formats, and writes the args to the compressed file under control of the format string, as in fprintf. gzprintf returns the number of uncompressed bytes actually written (0 in case of

error).

int gzputs (gzFile file, const char *s);

Writes the given null-terminated string to the compressed file, excluding the terminating null

character.

gzputs returns the number of characters written, or -1 in case of error.

char * gzgets (gzFile file, char *buf, int len);

Reads bytes from the compressed file until len-1 characters are read, or a newline character is

read and transferred to buf, or an end-of-file condition is encountered. The string is then

terminated with a null character.

gzgets returns buf, or Z_NULL in case of error.

int gzputc (gzFile file, int c);

Writes c, converted to an unsigned char, into the compressed file. gzputc returns the value that was written, or -1 in case of error.

int gzgetc (gzFile file);

Reads one byte from the compressed file. gzgetc returns this byte or -1 in case of end of file or error.

int gzflush (gzFile file, int flush);

Flushes all pending output into the compressed file. The parameter flush is as in the deflate()

function. The return value is the zlib error number (see function gzerror below). gzflush returns Z_OK if the flush parameter is Z_FINISH and all output could be flushed.

gzflush should be called only when strictly necessary because it can degrade compression.

z_off_t gzseek (gzFile file, z_off_t offset, int whence);

Sets the starting position for the next gzread or gzwrite on the given compressed file. The offset represents a number of bytes in the uncompressed data stream. The whence parameter is defined as in lseek(2); the value SEEK_END is not supported.

If the file is opened for reading, this function is emulated but can be extremely slow. If the file is opened for writing, only forward seeks are supported ; gzseek then compresses a sequence of

zeroes up to the new starting position.

gzseek returns the resulting offset location as measured in bytes from the beginning of the

uncompressed stream, or -1 in case of error, in particular if the file is opened for writing and the new starting position would be before the current position.

int gzrewind (gzFile file);

Rewinds the given file. This function is supported only for reading.

gzrewind(file) is equivalent to (int)gzseek(file, 0L, SEEK_SET)

z_off_t gztell (gzFile file);

Returns the starting position for the next gzread or gzwrite on the given compressed file. This position represents a number of bytes in the uncompressed data stream.

gztell(file) is equivalent to gzseek(file, 0L, SEEK_CUR)

int gzeof (gzFile file);

Returns 1 when EOF has previously been detected reading the given input stream, otherwise

zero.

int gzclose (gzFile file);

Flushes all pending output if necessary, closes the compressed file and deallocates all the (de)

compression state. The return value is the zlib error number (see function gzerror below).

const char * gzerror (gzFile file, int *errnum);

Returns the error message for the last error which occurred on the given compressed file. errnum is set to zlib error number. If an error occurred in the file system and not in the compression

library, errnum is set to Z_ERRNO and the application may consult errno to get the exact error code.

Basic functions

Function list

q const char * zlibVersion (void);

q int deflateInit (z_streamp strm, int level);

q int deflate (z_streamp strm, int flush);

q int deflateEnd (z_streamp strm);

q int inflateInit (z_streamp strm);

q int inflate (z_streamp strm, int flush);

q int inflateEnd (z_streamp strm);

Function description

const char * zlibVersion (void);

The application can compare zlibVersion and ZLIB_VERSION for consistency. If the first

character differs, the library code actually used is not compatible with the zlib.h header file used by the application. This check is automatically made by deflateInit and inflateInit.

int deflateInit (z_streamp strm, int level);

Initializes the internal stream state for compression. The fields zalloc, zfree and opaque must be initialized before by the caller. If zalloc and zfree are set to Z_NULL, deflateInit updates them to use default allocation functions.

The compression level must be Z_DEFAULT_COMPRESSION, or between 0 and 9: 1 gives

best speed, 9 gives best compression, 0 gives no compression at all (the input data is simply

copied a block at a time).

Z_DEFAULT_COMPRESSION requests a default compromise between speed and compression (currently equivalent to level 6).

deflateInit returns Z_OK if success, Z_MEM_ERROR if there was not enough memory,

Z_STREAM_ERROR if level is not a valid compression level, Z_VERSION_ERROR if the zlib library version (zlib_version) is incompatible with the version assumed by the caller

(ZLIB_VERSION). msg is set to null if there is no error message. deflateInit does not perform any compression: this will be done by deflate().

int deflate (z_streamp strm, int flush);

deflate compresses as much data as possible, and stops when the input buffer becomes empty or the output buffer becomes full. It may introduce some output latency (reading input without

producing any output) except when forced to flush.

The detailed semantics are as follows. deflate performs one or both of the following actions:

r Compress more input starting at next_in and update next_in and avail_in accordingly. If

not all input can be processed (because there is not enough room in the output buffer),

next_in and avail_in are updated and processing will resume at this point for the next call

of deflate().

r Provide more output starting at next_out and update next_out and avail_out accordingly.

This action is forced if the parameter flush is non zero. Forcing flush frequently degrades

the compression ratio, so this parameter should be set only when necessary (in interactive

applications). Some output may be provided even if flush is not set.

Before the call of deflate(), the application should ensure that at least one of the actions is

possible, by providing more input and/or consuming more output, and updating avail_in or

avail_out accordingly ; avail_out should never be zero before the call. The application can

consume the compressed output when it wants, for example when the output buffer is full

(avail_out == 0), or after each call of deflate(). If deflate returns Z_OK and with zero avail_out, it must be called again after making room in the output buffer because there might be more output pending.

If the parameter flush is set to Z_SYNC_FLUSH, all pending output is flushed to the output

buffer and the output is aligned on a byte boundary, so that the decompressor can get all input

data available so far. (In particular avail_in is zero after the call if enough output space has been

provided before the call.) Flushing may degrade compression for some compression algorithms and so it should be used only when necessary.

If flush is set to Z_FULL_FLUSH, all output is flushed as with Z_SYNC_FLUSH, and the

compression state is reset so that decompression can restart from this point if previous

compressed data has been damaged or if random access is desired. Using Z_FULL_FLUSH too often can seriously degrade the compression.

If deflate returns with avail_out == 0, this function must be called again with the same value of the flush parameter and more output space (updated avail_out), until the flush is complete

(deflate returns with non-zero avail_out).

If the parameter flush is set to Z_FINISH, pending input is processed, pending output is flushed and deflate returns with Z_STREAM_END if there was enough output space ; if deflate returns with Z_OK, this function must be called again with Z_FINISH and more output space (updated avail_out) but no more input data, until it returns with Z_STREAM_END or an error. After

deflate has returned Z_STREAM_END, the only possible operations on the stream are

deflateReset or deflateEnd.

Z_FINISH can be used immediately after deflateInit if all the compression is to be done in a

single step. In this case, avail_out must be at least 0.1% larger than avail_in plus 12 bytes. If

deflate does not return Z_STREAM_END, then it must be called again as described above.

deflate() sets strm-> adler to the adler32 checksum of all input read so far (that is, total_in bytes).

deflate() may update data_type if it can make a good guess about the input data type (Z_ASCII or Z_BINARY). In doubt, the data is considered binary. This field is only for information purposes and does not affect the compression algorithm in any manner.

deflate() returns Z_OK if some progress has been made (more input processed or more output

produced), Z_STREAM_END if all input has been consumed and all output has been produced (only when flush is set to Z_FINISH), Z_STREAM_ERROR if the stream state was inconsistent (for example if next_in or next_out was NULL), Z_BUF_ERROR if no progress is possible (for example avail_in or avail_out was zero).

int deflateEnd (z_streamp strm);

All dynamically allocated data structures for this stream are freed. This function discards any

unprocessed input and does not flush any pending output.

deflateEnd returns Z_OK if success, Z_STREAM_ERROR if the stream state was inconsistent, Z_DATA_ERROR if the stream was freed prematurely (some input or output was discarded). In the error case, msg may be set but then points to a static string (which must not be deallocated). int inflateInit (z_streamp strm);

Initializes the internal stream state for decompression. The fields next_in, avail_in, zalloc, zfree and opaque must be initialized before by the caller. If next_in is not Z_NULL and avail_in is

large enough (the exact value depends on the compression method), inflateInit determines the

compression method from the zlib header and allocates all data structures accordingly ; otherwise the allocation will be deferred to the first call of inflate. If zalloc and zfree are set to Z_NULL, inflateInit updates them to use default allocation functions.

inflateInit returns Z_OK if success, Z_MEM_ERROR if there was not enough memory,

Z_VERSION_ERROR if the zlib library version is incompatible with the version assumed by the caller. msg is set to null if there is no error message. inflateInit does not perform any

decompression apart from reading the zlib header if present: this will be done by inflate(). (So

next_in and avail_in may be modified, but next_out and avail_out are unchanged.)

int inflate (z_streamp strm, int flush);

inflate decompresses as much data as possible, and stops when the input buffer becomes empty or the output buffer becomes full. It may some introduce some output latency (reading input without producing any output) except when forced to flush.

The detailed semantics are as follows. inflate performs one or both of the following actions:

r Decompress more input starting at next_in and update next_in and avail_in accordingly. If

not all input can be processed (because there is not enough room in the output buffer),

next_in is updated and processing will resume at this point for the next call of inflate().

r Provide more output starting at next_out and update next_out and avail_out accordingly.

inflate() provides as much output as possible, until there is no more input data or no more

space in the output buffer (see below about the flush parameter).

Before the call of inflate(), the application should ensure that at least one of the actions is

possible, by providing more input and/or consuming more output, and updating the next_* and avail_* values accordingly. The application can consume the uncompressed output when it

wants, for example when the output buffer is full (avail_out == 0), or after each call of inflate().

If inflate returns Z_OK and with zero avail_out, it must be called again after making room in the output buffer because there might be more output pending.

If the parameter flush is set to Z_SYNC_FLUSH, inflate flushes as much output as possible to the output buffer. The flushing behavior of inflate is not specified for values of the flush

parameter other than Z_SYNC_FLUSH and Z_FINISH, but the current implementation actually flushes as much output as possible anyway.

inflate() should normally be called until it returns Z_STREAM_END or an error. However if all decompression is to be performed in a single step (a single call of inflate), the parameter flush

should be set to Z_FINISH. In this case all pending input is processed and all pending output is flushed ; avail_out must be large enough to hold all the uncompressed data. (The size of the

uncompressed data may have been saved by the compressor for this purpose.) The next operation on this stream must be inflateEnd to deallocate the decompression state. The use of Z_FINISH is never required, but can be used to inform inflate that a faster routine may be used for the single inflate() call.

If a preset dictionary is needed at this point (see inflateSetDictionary below), inflate sets strm-

adler to the adler32 checksum of the dictionary chosen by the compressor and returns

Z_NEED_DICT ; otherwise it sets strm-> adler to the adler32 checksum of all output produced so far (that is, total_out bytes) and returns Z_OK, Z_STREAM_END or an error code as

described below. At the end of the stream, inflate() checks that its computed adler32 checksum is equal to that saved by the compressor and returns Z_STREAM_END only if the checksum is

correct.

inflate() returns Z_OK if some progress has been made (more input processed or more output

produced), Z_STREAM_END if the end of the compressed data has been reached and all

uncompressed output has been produced, Z_NEED_DICT if a preset dictionary is needed at this point, Z_DATA_ERROR if the input data was corrupted (input stream not conforming to the zlib format or incorrect adler32 checksum), Z_STREAM_ERROR if the stream structure was

inconsistent (for example if next_in or next_out was NULL), Z_MEM_ERROR if there was not enough memory, Z_BUF_ERROR if no progress is possible or if there was not enough room in the output buffer when Z_FINISH is used. In the Z_DATA_ERROR case, the application may then call inflateSync to look for a good compression block.

int inflateEnd (z_streamp strm);

All dynamically allocated data structures for this stream are freed. This function discards any

unprocessed input and does not flush any pending output.

inflateEnd returns Z_OK if success, Z_STREAM_ERROR if the stream state was inconsistent. In the error case, msg may be set but then points to a static string (which must not be deallocated).

Advanced functions

The following functions are needed only in some special applications.

Function list

q int deflateInit2 (z_streamp strm,

q int deflateSetDictionary (z_streamp strm, const Bytef *dictionary, uInt dictLength);

q int deflateCopy (z_streamp dest, z_streamp source);

q int deflateReset (z_streamp strm);

q int deflateParams (z_streamp strm, int level, int strategy);

q int inflateInit2 (z_streamp strm, int windowBits);

q int inflateSetDictionary (z_streamp strm, const Bytef *dictionary, uInt dictLength);

q int inflateSync (z_streamp strm);

q int inflateReset (z_streamp strm);

Function description

int deflateInit2 (z_streamp strm, int level, int method, int windowBits, int memLevel, int strategy);

This is another version of deflateInit with more compression options. The fields next_in, zalloc, zfree and opaque must be initialized before by the caller.

The method parameter is the compression method. It must be Z_DEFLATED in this version of the library.

The windowBits parameter is the base two logarithm of the window size (the size of the history buffer). It should be in the range 8..15 for this version of the library. Larger values of this

parameter result in better compression at the expense of memory usage. The default value is 15 if deflateInit is used instead.

The memLevel parameter specifies how much memory should be allocated for the internal

compression state. memLevel=1 uses minimum memory but is slow and reduces compression

ratio ; memLevel=9 uses maximum memory for optimal speed. The default value is 8. See zconf.

h for total memory usage as a function of windowBits and memLevel.

The strategy parameter is used to tune the compression algorithm. Use the value

Z_DEFAULT_STRATEGY for normal data, Z_FILTERED for data produced by a filter (or

predictor), or Z_HUFFMAN_ONLY to force Huffman encoding only (no string match). Filtered data consists mostly of small values with a somewhat random distribution. In this case, the

compression algorithm is tuned to compress them better. The effect of Z_FILTERED is to force more Huffman coding and less string matching ; it is somewhat intermediate between

Z_DEFAULT and Z_HUFFMAN_ONLY. The strategy parameter only affects the compression ratio but not the correctness of the compressed output even if it is not set appropriately.

deflateInit2 returns Z_OK if success, Z_MEM_ERROR if there was not enough memory,

Z_STREAM_ERROR if a parameter is invalid (such as an invalid method). msg is set to null if there is no error message. deflateInit2 does not perform any compression: this will be done by deflate().

int deflateSetDictionary (z_streamp strm, const Bytef *dictionary, uInt dictLength);

Initializes the compression dictionary from the given byte sequence without producing any

compressed output. This function must be called immediately after deflateInit, deflateInit2 or

deflateReset, before any call of deflate. The compressor and decompressor must use exactly the same dictionary (see inflateSetDictionary).

The dictionary should consist of strings (byte sequences) that are likely to be encountered later in the data to be compressed, with the most commonly used strings preferably put towards the end of the dictionary. Using a dictionary is most useful when the data to be compressed is short and can be predicted with good accuracy ; the data can then be compressed better than with the

default empty dictionary.

Depending on the size of the compression data structures selected by deflateInit or deflateInit2, a part of the dictionary may in effect be discarded, for example if the dictionary is larger than the window size in deflate or deflate2. Thus the strings most likely to be useful should be put at the end of the dictionary, not at the front.

Upon return of this function, strm-> adler is set to the Adler32 value of the dictionary ; the

decompressor may later use this value to determine which dictionary has been used by the

compressor. (The Adler32 value applies to the whole dictionary even if only a subset of the

dictionary is actually used by the compressor.)

deflateSetDictionary returns Z_OK if success, or Z_STREAM_ERROR if a parameter is invalid (such as NULL dictionary) or the stream state is inconsistent (for example if deflate has already been called for this stream or if the compression method is bsort). deflateSetDictionary does not perform any compression: this will be done by deflate().

int deflateCopy (z_streamp dest, z_streamp source);

Sets the destination stream as a complete copy of the source stream.

This function can be useful when several compression strategies will be tried, for example when there are several ways of pre-processing the input data with a filter. The streams that will be

discarded should then be freed by calling deflateEnd. Note that deflateCopy duplicates the

internal compression state which can be quite large, so this strategy is slow and can consume lots of memory.

deflateCopy returns Z_OK if success, Z_MEM_ERROR if there was not enough memory,

Z_STREAM_ERROR if the source stream state was inconsistent (such as zalloc being NULL).

msg is left unchanged in both source and destination.

int deflateReset (z_streamp strm);

This function is equivalent to deflateEnd followed by deflateInit, but does not free and reallocate all the internal compression state. The stream will keep the same compression level and any other attributes that may have been set by deflateInit2.

deflateReset returns Z_OK if success, or Z_STREAM_ERROR if the source stream state was

inconsistent (such as zalloc or state being NULL).

int deflateParams (z_streamp strm, int level, int strategy);

Dynamically update the compression level and compression strategy. The interpretation of level and strategy is as in deflateInit2. This can be used to switch between compression and straight

copy of the input data, or to switch to a different kind of input data requiring a different strategy.

If the compression level is changed, the input available so far is compressed with the old level

(and may be flushed); the new level will take effect only at the next call of deflate().

Before the call of deflateParams, the stream state must be set as for a call of deflate(), since the currently available input may have to be compressed and flushed. In particular, strm-> avail_out must be non-zero.

deflateParams returns Z_OK if success, Z_STREAM_ERROR if the source stream state was

inconsistent or if a parameter was invalid, Z_BUF_ERROR if strm->avail_out was zero.

int inflateInit2 (z_streamp strm, int windowBits);

This is another version of inflateInit with an extra parameter. The fields next_in, avail_in, zalloc, zfree and opaque must be initialized before by the caller.

The windowBits parameter is the base two logarithm of the maximum window size (the size of

the history buffer). It should be in the range 8..15 for this version of the library. The default value is 15 if inflateInit is used instead. If a compressed stream with a larger window size is given as input, inflate() will return with the error code Z_DATA_ERROR instead of trying to allocate a larger window.

inflateInit2 returns Z_OK if success, Z_MEM_ERROR if there was not enough memory,

Z_STREAM_ERROR if a parameter is invalid (such as a negative memLevel). msg is set to null if there is no error message. inflateInit2 does not perform any decompression apart from reading the zlib header if present: this will be done by inflate(). (So next_in and avail_in may be

modified, but next_out and avail_out are unchanged.)

int inflateSetDictionary (z_streamp strm, const Bytef *dictionary, uInt dictLength);

Initializes the decompression dictionary from the given uncompressed byte sequence. This

function must be called immediately after a call of inflate if this call returned Z_NEED_DICT.

The dictionary chosen by the compressor can be determined from the Adler32 value returned by this call of inflate. The compressor and decompressor must use exactly the same dictionary (see deflateSetDictionary).

inflateSetDictionary returns Z_OK if success, Z_STREAM_ERROR if a parameter is invalid

(such as NULL dictionary) or the stream state is inconsistent, Z_DATA_ERROR if the given

dictionary doesn't match the expected one (incorrect Adler32 value). inflateSetDictionary does not perform any decompression: this will be done by subsequent calls of inflate().

int inflateSync (z_streamp strm);

Skips invalid compressed data until a full flush point (see above the description of deflate with Z_FULL_FLUSH) can be found, or until all available input is skipped. No output is provided.

inflateSync returns Z_OK if a full flush point has been found, Z_BUF_ERROR if no more input was provided, Z_DATA_ERROR if no flush point has been found, or Z_STREAM_ERROR if the stream structure was inconsistent. In the success case, the application may save the current current value of total_in which indicates where valid compressed data was found. In the error

case, the application may repeatedly call inflateSync, providing more input each time, until

success or end of the input data.

int inflateReset (z_streamp strm);

This function is equivalent to inflateEnd followed by inflateInit, but does not free and reallocate all the internal decompression state. The stream will keep attributes that may have been set by

inflateInit2.

inflateReset returns Z_OK if success, or Z_STREAM_ERROR if the source stream state was

inconsistent (such as zalloc or state being NULL).

Checksum functions

These functions are not related to compression but are exported anyway because they might be useful in applications using the compression library.

Function list

q uLong adler32 (uLong adler, const Bytef *buf, uInt len);

q uLong crc32 (uLong crc, const Bytef *buf, uInt len);

Function description

uLong adler32 (uLong adler, const Bytef *buf, uInt len);

Update a running Adler-32 checksum with the bytes buf[0..len-1] and return the updated

checksum. If buf is NULL, this function returns the required initial value for the checksum.

An Adler-32 checksum is almost as reliable as a CRC32 but can be computed much faster. Usage example:

uLong adler = adler32(0L, Z_NULL, 0);

while (read_buffer(buffer, length) != EOF) {

adler = adler32(adler, buffer, length);

}

if (adler != original_adler) error();

uLong crc32 (uLong crc, const Bytef *buf, uInt len);

Update a running crc with the bytes buf[0..len-1] and return the updated crc. If buf is NULL, this function returns the required initial value for the crc. Pre- and post-conditioning (one's

complement) is performed within this function so it shouldn't be done by the application. Usage example:

uLong crc = crc32(0L, Z_NULL, 0);

while (read_buffer(buffer, length) != EOF) {

crc = crc32(crc, buffer, length);

}

if (crc != original_crc) error();

struct z_stream_s

typedef struct z_stream_s {

Bytef *

next_in; /* next input byte */ uInt avail_in; /* number of bytes available at next_in */ uLong total_in; /* total nb of input bytes read so far */ Bytef *next_out; /* next output byte should be put there */ uInt avail_out; /* remaining free space at next_out */ uLong total_out; /* total nb of bytes output so far */ char *msg; /* last error message, NULL if no error */ struct internal_state FAR *state; /* not visible by applications */ alloc_func zalloc; /* used to allocate the internal state */ free_func zfree; /* used to free the internal state */ voidpf opaque; /* private data object passed to zalloc and zfree */ int data_type; /* best guess about the data type: ascii or binary */ uLong adler; /* adler32 value of the uncompressed data */ uLong reserved; /* reserved for future use */ } z_stream ; typedef z_stream FAR * z_streamp; ? The application must update next_in and avail_in when avail_in has dropped to zero. It must update next_out and avail_out when avail_out has dropped to zero. The application must initialize zalloc, zfree and opaque before calling the init function. All other fields are set by the compression library and must not be updated by the application.

The opaque value provided by the application will be passed as the first parameter for calls of zalloc and zfree. This can be useful for custom memory management. The compression library attaches no meaning to the opaque value.

zalloc must return Z_NULL if there is not enough memory for the object. If zlib is used in a multi-threaded application, zalloc and zfree must be thread safe.

On 16-bit systems, the functions zalloc and zfree must be able to allocate exactly 65536 bytes, but will not be required to allocate more than this if the symbol MAXSEG_64K is defined (see zconf.h). WARNING: On MSDOS, pointers returned by zalloc for objects of exactly 65536 bytes *must* have their offset normalized to zero. The default allocation function provided by this library ensures this (see zutil.c). To reduce memory requirements and avoid any allocation of 64K objects, at the expense of

compression ratio, compile the library with -DMAX_WBITS=14 (see zconf.h).

The fields total_in and total_out can be used for statistics or progress reports. After compression,

total_in holds the total size of the uncompressed data and may be saved for use in the decompressor (particularly if the decompressor wants to decompress everything in a single step).

Constants

#define

Z_NO_FLUSH 0 #define Z_PARTIAL_FLUSH 1 /* will be removed, use Z_SYNC_FLUSH instead */ #define Z_SYNC_FLUSH 2 #define Z_FULL_FLUSH 3 #define Z_FINISH 4 /* Allowed flush values ; see deflate() below for details */ #define Z_OK 0 #define Z_STREAM_END 1 #define Z_NEED_DICT 2 #define Z_ERRNO (-1) #define Z_STREAM_ERROR (-2) #define Z_DATA_ERROR (-3) #define

Z_MEM_ERROR (-4) #define Z_BUF_ERROR (-5) #define Z_VERSION_ERROR (-6) /* Return codes for the compression/decompression functions. Negative * values are errors, positive values are used for special but normal events. */ #define Z_NO_COMPRESSION 0 #define Z_BEST_SPEED 1

#define Z_BEST_COMPRESSION 9 #define Z_DEFAULT_COMPRESSION (-1) /* compression levels */ #define Z_FILTERED 1 #define Z_HUFFMAN_ONLY 2 #define Z_DEFAULT_STRATEGY 0 /* compression strategy ; see deflateInit2() below for details */ #define Z_BINARY 0 #define

Z_ASCII 1 #define Z_UNKNOWN 2 /* Possible values of the data_type field */ #define

Z_DEFLATED 8 /* The deflate compression method (the only one supported in this version) */ #define Z_NULL 0 /* for initializing zalloc, zfree, opaque */ #define zlib_version zlibVersion() /* for compatibility with versions less than 1.0.2 */

Misc

deflateInit and inflateInit are macros to allow checking the zlib version and the compiler's view of

z_stream.

Other functions:

const char * zError (int err);

int inflateSyncPoint (z_streamp z);

const uLongf * get_crc_table (void);

Last update: 13 april 2002 piapi@https://www.360docs.net/doc/8e17977250.html,.tw

compare 的两个重要词组区别

compare to 和compare with 的区别是什么 Compare to 是“把……比作”的意思。例如: We compare him to a little tiger. 我们把他比作小老虎。 The last days before liberation are often compared to the darkness before the dawn. 将要解放的那些日子常常被比作黎明前的黑暗。 Compare ... with 是“把……和……比较”的意思。例如: We must compare the present with the past. 我们要把现在和过去比较一下。 We compared the translation with the original. 我们把译文和原文比较了下。 从上面比较可以看出,compare with 侧重一个仔细的比较过程。有时,两者都可以互相代替。例如: He compared London to (with) Paris. 他把伦敦比作巴黎。 London is large, compared to (with) Paris. 同巴黎比较而言,伦敦大些。 在表示“比不上”、“不能比”的意思时,用compare with 和compare to 都可以。例如: My spoken English can't be compared with yours. 我的口语比不上你的。 The pen is not compared to that one. 这笔比不上那支。 1、c ompare…to…意为“把…比作”,即把两件事物相比较的同时,发现某些方面相似的地方。这两件被比较的事物 或人在本质方面往往是截然不同的事物。如: He compared the girl to the moon in the poem. 他在诗中把那姑娘比作月亮。 2、compare…with…“与…相比,把两件事情相比较,从中找出异同”,这两件事又往往是同类的, 如:I'm afraid my English compares poorly with hers. 恐怕我的英语同她的英语相比要差得多。 compare to和compare with有何区别,当说打比方时和做比较是分别用哪个? compare…to…比喻.例如: The poets often compare life to a river. 诗人们经常把生活比喻成长河. compare…with…相比.例如: My English can't compare with his. 我的英文水平不如他.

五种计算机语言的特点与区别

php语言,PHP(PHP: Hypertext Preprocessor的缩写,中文名:“PHP:超文本预处理器”)是一种通用开源脚本语言。语法吸收了C语言、Java和Perl的特点,入门门槛较低,易于学习,使用广泛,主要适用于Web开发领域。 特性:PHP 独特的语法混合了C、Java、Perl 以及PHP 自创新的语法;PHP可以比CGI 或者Perl更快速的执行动态网页——动态页面方面,与其他的编程语言相比,PHP是将程序嵌入到HTML文档中去执行,执行效率比完全生成htmL标记的CGI要高许多,PHP具有非常强大的功能,所有的CGI的功能PHP都能实现;PHP支持几乎所有流行的数据库以及操作系统;最重要的是PHP可以用C、C++进行程序的扩展。 Java语言,Java是一种可以撰写跨平台应用软件的面向对象的程序设计语言,是由Sun Microsystems公司于1995年5月推出的Java程序设计语言和Java平台(即JavaSE, JavaEE, JavaME)的总称。 Java 技术具有卓越的通用性、高效性、平台移植性和安全性,广泛应用于个人PC、数据中心、游戏控制台、科学超级计算机、移动电话和互联网,同时拥有全球最大的开发者专业社群。在全球云计算和移动互联网的产业环境下,Java更具备了显著优势和广阔前景。 Java的优势,与传统程序不同,Sun 公司在推出Java 之际就将其作为一种开放的技术。全球数以万计的Java 开发公司被要求所设计的Java软件必须相互兼容。“Java 语言靠群体的力量而非公司的力量”是Sun公司的口号之一,并获得了广大软件开发商的认同。这与微软公司所倡导的注重精英和封闭式的模式完全不同。 Sun 公司对Java 编程语言的解释是:Java 编程语言是个简单、面向对象、分布式、解释性、健壮、安全与系统无关、可移植、高性能、多线程和动态的语言。 python语言,是一种面向对象、直译式计算机程序设计语言,Python语法简洁而清晰,具有丰富和强大的类库。它常被昵称为胶水语言,它能够很轻松的把用其他语言制作的各种模块(尤其是C/C++)轻松地联结在一起。 常见的一种应用情形是,使用python快速生成程序的原型(有时甚至是程序的最终界面),然后对其中有特别要求的部分,用更合适的语言改写。 Python是完全面向对象的语言。函数、模块、数字、字符串都是对象。并且完全支持继承、重载、派生、多继承,有益于增强源代码的复用性。 Python支持重载运算符和动态类型。相对于Lisp这种传统的函数式编程语言,Python对函数式设计只提供了有限的支持。有两个标准库(functools, itertools)提供了Haskell和Standard

现场处理措施和强措的区别

现场处理措施决定书: 1、现场处理措施决定书,是指安监部门在监督检查中,发现生产经营单位存在安全生产违法行为或者事故隐患的,依法作出现场处理决定而使用的文书。 2、制作说明 (1)使用范围:可以针对当场纠正、责令立即停止作业(施工)、责令立即停止使用、责令立即排除事故隐患、责令从危险区域撤出作业人员、责令暂时停产停业、停止建设、停止施工或者停止使用等多种决定使用。 (2)依据:现场处理措施是为预防、制止或者控制生产安全事故的发生,依法采取的对有关生产经营单位及其人员的财产和行为自由加以暂时性限制,使其保持一定状态的手段。作出现场处理决定,应当有法律法规规定,并在文书中列明所引用的条款。 (3)与其他文书的区别 一是与《责令限期整改指令书》的区别。《责令限期整改指令书》主要适用于责令限期整改、责令限期达到要求这两种情况。 二是与《强制措施决定书》的区别。《强制措施决定书》主要适用于查封、扣押和临时查封有关场所等行政强制措施。 三是责令暂时停产停业、停止建设、停止施工或者停止使用的期限届满或者依生产经营单位申请,安全监管部门应当进行复查,并制作《整改复查意见书》。 3、注意事项 文书要加盖安监部门公章,不得使用内设机构印章。送达由负责人在文书上签名并签署时间即可,其他人签收的,应有相应的职务证明或者同时加盖生产经营单位公章。 强制措施决定书 1、行政强制措施决定书,是行政执法机关为查明事实,保全证据而对当事人作出

强制性措施决定的文书。 本文书仅在依法实施采取查封、扣押、临时查封有关场所时使用。 2、制作说明 (1)存在的问题 该部分应当具体列明违反法律、法规、规章可以采取强制措施的情形。 (2)依据 该部分应当明确法律、法规、规章有关可以采取强制措施的条款,最好明确法律、法规、规章的名称、条、款、项。 (3)强制措施 该部分应当根据存在的问题,即违法的情形、情节以及严重程度,明确强制措施的种类。 3、注意事项 (1)对有根据认为不符合国家标准或行业标准的设施、设备、器材予以查封或扣押时,应当下发《强制措施决定书》。 (2)根据《易制毒化学品管理条例》(国务院令第445号)第三十二条第二款规定,行政主管部门在进行易制毒化学品监督检查时,可以依法查看现场、查阅和复制有关资料、记录有关情况、扣押有关的证据材料和违法物品;必要时,可以临时查封有关场所。 (3)符合《中华人民共和国安全生产法》第五十六条第一款第(四)项及相关法律法规规定的强制措施种类。

战略与策略的主要区别

战略与策略的主要区别 一,什么是战略营销? 必须首先明确,什么是战略。 1,战略的本质是一个企业的选择。为什么要做选择?因为任何一个企业都不是全能的。不可能做所有的事情,也不是所有的事情都能做好!任何企业的资源和能力都是有限的。战略就是要把有限的资源和能力,用到产出最大的地方。战略就是一个选择的过程,选择什么?如何选择?这是企业战略规划所要研究的课题。 2,战略首先意味着放弃。在中国目前的经济环境下,战略对于企业家的意义,更为重要的是“放弃”。中国的经济处在快速发展期,有太多的市场机会可供选择。但选择意味着放弃,而放弃是一件很痛苦的事情。 综上所述,战略选择的核心是对企业目标客户群的选择。而战略营销就是从战略的高度思考和规划企业的营销过程,是聚焦最有价值客户群的营销模式。 我们都知道80/20原理,20%的客户创造了企业80%的利润。战略营销要做的就是找到适合企业的目标客户群,并锁定他们进行精确打击,使企业的资源和能力发挥最大的效益,并实现企业能力的持续提升。 因此,战略营销的三个关键要素就是:1)客户细分;2)聚焦客户价值;3)为股东和客户增值。 二,什么是策略营销? 策略营销主要指的是在市场营销中,将企业的市场策略运用到营销中的过程。 比如: 1,低成本策略 通过降低产品生产和销售成本,在保证产品和服务质量的前提下,使自己的产品价格低于竞争对手的价格,以迅速扩大的销售量提高市场占有率的竞争策略。 2.差别化策略 通过发展企业别具一格的营销活动,争取在产品或服务等方面具有独特性,使消费者产生兴趣而消除价格的可比性,以差异优势产生竞争力的竞争策略。 3.聚焦策略 通过集中企业力量为某一个或几个细分市场提供有效的服务,充分满足一部分消费者的特殊需求,以争取局部竞争优势的竞争策略。 一个企业的市场营销策略必须是在企业的战略营销策略下确定的,可以简单把策略营销理解成企业在市场的战术营销。这就是两者的区别!

真理的定义和特点以及谬误的区别

、真理的定义和特点以及谬误的区别 定义:真理是人们对客观事物及其规律的正确反映。 特点:1、真理具有客观性。真理的内容是客观的;检验真理的标准是客观的。 2、真理具有价值性。真理的价值性是指真理对人类实践活动的功能性,它揭示了客观真理具有能满足主体需要、对主体有用的属性。 9.资本循环和资本周转(资本循环的三个阶段三大职能,两大前提条件;资本周转的定义,影响周转的因素) 资本循环指产品资本从一定的形式出发,经过一系列形式的变化,又回到原来出发点的运动。产品资本在循环过程中要经历三个不同的阶段,于此相联系的是资本依次执行三种不同的职能: 第一个阶段是购买阶段,即生产资料与劳动力的购买阶段。它属于商品的流通过程,在这一阶段,产业资本执行的是货币资本的职能。 第二个阶段是生产阶段,即生产资料与劳动者相结合生产物质财富并使生产资本得以增值,执行的是生产资本的职能。 第三个阶段是售卖阶段,即商品资本向货币资本的转化阶段。在此阶段产业资本所执行的是商品资本的职能,通过商品买卖实现商品的价值,满足人们的需要。 资本循环必须具备两个基本前提条件: 一是产业资本的三种职能形式必须在空间上同时并存,也就是说,产业资本必须按照一定比例同时并存于货币资本、生产资本和商品资本三种形式中。 二是产业资本的三种职能形式必须在时间上继起,也就是说,产业资本循环的三种职能形式必须保持时间上的依次连续性。 资本周转是资本反复不断的循环运动所形成的周期性运动。 影响资本周转最重要的两个要素是:一是资本周转的时间;二是生产资本的固定资本和流动资本的构成。要加快资本周转的时间,获得更多的剩余价值,就要缩短资本周转时间,加快流动资本周转速度。 第五章 2.垄断条件下竞争的特点 竞争目的上,垄断竞争是获取高额利润,并不断巩固和扩大自己的垄断地位和统治权力;竞争手段上,垄断组织的竞争,除采取各种形式的经济手段外,还采取非经济手段,使经济变得更加复杂、更加激烈; 在竞争范围上,国际市场的竞争越来越激烈,不仅经济领域的竞争多种多样,而且还扩大到经济领域范围以外进行竞争。 总之,垄断条件下的竞争,不仅规模大、时间长、手段残酷、程度更加激烈,而且具有更大的破坏性。 3.金融寡头如何握有话语权 金融寡头在经济领域中的统治主要通过“参与制”实现。所谓参与制,即金融寡头通过掌握

各种不同处理工艺比较

近几十年在国内外城市污水处理工程实践中,采用较多的城市污水处理工艺有传统活性污泥法,吸附再生法、分段进水法、AB法、A/O法、A/A/O法、SBR法、氧化沟法、一体化池(UNITANK)等等,而各种工艺中又有一些变化了和改进了新形态。几种不同污水处理工艺技术特点见表2。 以上列举的这些城市污水处理工艺,其核心设施—曝气池都是敞开的,一般在池底装有曝气器或者在池面装有曝气机,设施结构较为简单,便于检修和维护,其中:AB法由于采取了两次生化处理,工艺的单元构成较复杂,产生的污泥也不稳定,需要污泥处置设施对其进行稳定化处理和处置,管理环节多,建设投入比较多(1500~2000元/(m3/d)),污水处理单位成本也高(0.7~1.0元/m3)。但是,由于该工艺是针对高浓度城市污水处理而设计的,去除单位污染物的建设投入和运行消耗并不高,是一种特殊场合宜用的城市污水处理工艺。 传统活性污泥法、分段进水法、吸附再生法属于中等负荷的污水处理工艺,该工艺出水水质稳定且较好,运行管理比较简单,但是由于污泥不稳定,需要增加设施进行稳定化处理,增加了运行管理环节,加大了基建投入(1000~2000元/(m3/d)),但是污泥产生的沼气可用来发电或直接驱动鼓风机,使污水处理总能耗低(0.15~0.20 kWh/m3),运行成本低(0.25元/m3左右),由于其明显的经济性,特别是在大型城市污水处理项目建设中(>20万m3/d),是国内外广泛采用的城市污水处理工艺。 氧化沟、序批池(SBR)、一体化(UNITANK)都是属于低负荷污水处理工艺,出水

水质非常好。由于负荷低、一般不再设置初沉池,而二沉池也往往和曝气池组合为一;由于泥龄长、污泥较为稳定,一般可以不再作稳定化处理而直接处置或者应用,省去了污泥稳定化设施,大大简化了工艺构成,使运行管理非常简单,但是负荷低、泥龄长也使生化部分大大增加,增加了污水处理设施的建设投入,提高了能耗(0.28 kWh/m3左右),提高了运行消耗成本。这一类工艺还有一个特点是负荷变化范围宽,在需要的时候也可以按中等负荷运行,适应城市水污染治理的阶段需要。这一类工艺比较适合规模较小(<20万m3/d),技术力量较薄弱的中小城市的城市污水处理。 2/ 由于抗生素污水在处理上有相当的难度,处理装置投资大,技术比较复杂,运行费用也相当可观,为此,作一小结,期望能起到抛砖引玉之效果。1污水处理工程简介在建本污水处理工程前,在“七五”期间,该厂的6.6kg/a阿霉素工程曾建有一套60m3/d规模的污水处理装置,其处理方法为:臭氧氧化-生物接触氧化法。在实际运行中,装置好氧生化部分已无余量,臭氧氧化解毒处理部分还尚有每天处理能力十几m3污水的余量。由于该厂“八五”项目:500kg/a妥布霉素、10kg/a丝裂霉素、1 000kg/a阿佛菌素工程的相继建设,有关专家和省、地、市环保部门建议:在新厂区应综合规划,几个项目的污水进行集中统一治理。经与厂方反复研究,总结阿霉素工程污水处理的成功经验,决定利用阿霉素工程污水处理站的余量处理设施,再设计一套处理污水量为240m3/d,处理COD Cr进量为 2 500kg/d 的污水处理装置。 根据该厂生产工艺特点和水质情况,对于各股污水进行仔细分析和计算,为了使生化处理系统能顺利运行及降低基建投资,本设计采用如下预处理措施:(1)用臭氧氧化法预处理丝裂霉素污水,使抗生素的环状母体结构断裂。(2)用生物水解工艺预处理混合污水,使钢制厌氧反应器容积减少,以降低基建投资。[1] [2] [3] [4] [下一页] 2污水处理工艺流程丝裂霉素车间污水用泵送至已建的阿霉素污水处理站臭氧氧化塔处理,经处理的污水与妥布霉素等车间的污水一道自流入污水集水池,平均每月 1.2批,每批28t的发酵倒罐液由工艺物料泵送至设在集水池顶上的倒罐液贮存池,经自然沉淀的上清液慢慢加入污水集水池中,沉淀物用泵送到污泥浓缩塔,再经高速离心分离机处理,此泥饼可回收做复合饲料或作农肥,滤液返回到污水集水池,此池中的污水由潜污泵送到污水调节池。由于各车间的污水排放不均匀,所以潜污泵开停只得由集水池中的高低水位来控制(即高水位时开泵,低水位时停泵)。污水调节池容积设有1天之设计水量,以利于水质均化。污水调节池出水自流入本池下面的生物水解反应池,在此池中装有半软性组合填料,在厌氧菌的作用下,能将较复杂的有机物分解为小分子化合物。经生物水解反应池处理的污水,用污水泵均匀地将水送到旋流式浮腾厌氧反应器处理。厌氧反应器出水再自流到菌液分离池、预曝气池、生物接触氧化池及气浮净水器处理。为控制生物接触氧化池的进水浓度,从而保证处理的污水达标排放,本设计特设清下水集水池1座,用泵将清下水送往预曝气池。 为使厌氧反应器工作效率较佳和稳定,本设计在水解反应池的进口处设有蒸汽加温措施,温度自动控制在35±2℃,并还设有温度指示和报警装置。 生化处理的沉淀污泥和气浮净水器的浮渣均经高速离心机处理后运出作农肥。 厌氧处理所产生的沼气,根据有关资料计算,每天约1 025m3,本设计设有200m3气柜1台,经水封罐后,送到锅炉房作辅助燃料之用。3主要处理构筑物和设备设计参数 3.1生物水解反应池 为使池中有较高的厌氧微生物存在,以将进水中颗粒物质和胶体物质迅速截留和吸附,在此池中放置了半软性组合填料。污水停留时间为8h。 3.2旋流式浮腾厌氧反应器

功能和特点的区别Excel的主要功能和特点

功能和特点的区别Excel的主要功能和特点 Excel的主要功能和特点 Excel电子表格是office系列办公软的-种,实现对日常生活、工作中的表格的数据处理。它通过友好的人机界面,方便易学的智能化操作方式,使用户轻松拥有实用美观个性十足的实时表格,是工作、生活中的得力助手。 一、Excel功能概述; 1、功能全面:几乎可以处理各种数据 2、操作方便:菜单、窗口、对话框、工具栏 3、丰富的数据处理函数 4、丰富的绘制图表功能:自动创建各种统计图表 5、丰富的自动化功能:自动更正、自动排序、自动筛选等 6、运算快速淮确: 7、方便的数据交换能力 8、新增的Web工具 二、电子数据表的特点Excel 电子数据表软工作于Windows平台,具有Windows环境软的所有优点。而在图形用户界面、表格处理、数据分析、图表制作和网络信息共享等方面具有更突出的特色。工.图形用户界面Excel 的图形用户界面是标准的Windows的窗口形式,有控制菜单、最大化、最小化按钮、标题栏、菜单栏等内容。其中的

菜单栏和工具栏使用尤为方便。菜单栏中列出了电子数据表软的众多功能,工具栏则进一步将常用命令分组,以工具按钮的形式列在菜单栏的下方。而且用户可以根据需要,重组菜单栏和工具栏。在它们之间进行复制或移动操作,向菜单栏添加工具栏按钮或是在工具栏上添加菜单命令,甚至定义用户自己专用的菜单和工具栏。当用户操作将鼠标指针停留在菜单或工具按钮时,菜单或按钮会以立体效果突出显示,并显示出有关的提示。而当用户操作为单击鼠标右键时,会根据用户指示的操作对象不同,自动弹出有关的快捷菜单,提供相应的最常用命令。为了方便用户使用工作表和建立公式,Excel 的图形用户界面还有编辑栏和工作表标签。. 2.表格处理 Excel的另-个突出的特点是采用表格方式管理数据,所有的数据、信息都以二维表格形式(工作表)管理,单元格中数据间的相互关系一目了然。从而使数据的处理和管理更直观、更方便、更易于理解。对于曰常工作中常用的表格处理操作,例如,增加行、删除列、合并单元格、表格转置等操作,在Excel中均只需询单地通过菜单或工具按钮即可完成。此外Excel还提供了数据和公式的自动填充,表格格式的自动套用,自动求和,自动计算,记忆式输入,选择列表,自动更正,拼写检查,审核,排序和筛选等众多功能,可以帮助用户快速高效地建立、编辑、编排和管理各种表格。

方案违背和方案偏离的定义、区别和处理资料

方案违背和方案偏离的定义、区别和处理 方案违背(Protocol Violation)和方案偏离(Protocol Deviation)的差别在于严重程度不同,但是关于PD和PV的定义、记录及通报过程,在不同的试验方案或不同的申办方,要求也不尽相同。 方案偏离:研究者管理下,任何的改变和不遵循临床试验方案设计或流程的,且没有得到IRB批准的行为。只要没有严重影响受试者的权益、安全性和获益,或研究数据的完整性,精确性和可靠性,这种属于轻微的方案偏离。 方案违背:方案违背是偏离IRB批准的方案的一种,它可影响到受试者的权益,安全性和获益,或研究数据的完整性,精确性和可靠性。 方案违背是方案偏离的一种,PV比PD严重,就像SAE和AE一样的关系。 PV一般需要在临床总结报告中报告,而轻微的PD可以不在临床总结报告中报告。 1偏离方案分类 按发生的责任主体可分为:研究者/研究机构不依从的PD,受试者不依从导致的PD,申办者方面不依从的PD; 2常见的方案偏离 ?访视/观察/检查在时间窗外,但不影响受试者按方案继续使用研究药 物,或不影响对主要疗效和关键的次要疗效指标评价的有效性。 ?方案规定观察的数据点或实验室参数缺失而导致数据的指缺失,但不影 响主要疗效或关键的次要疗效或安全性指标结果。如方案中规定收集的 指标没有设计在病例报告表中,某研究机构不具备某实验室指标的检查 条件等。 ?观察/评价不全,但不影响主要或次要关键疗效或安全结果,如在非高 血压的临床试验中,忘记测量血压。 3以下情况不属于方案偏离 ?因为提前中止试验(患者撤销同意,或因其他原因决定中止患者参加试 验),中止后的检查未做。

Linux 操作系统查看服务器系统信息命令(linux系统)

Linux 操作系统查看服务器系统信息命令(linux 系统系统: # uname -a # 查看内核 /操作系统 /CPU信息 # head -n 1 /etc/issue # 查看操作系统版本 # cat /proc/cpuinfo # 查看 CPU 信息 # hostname # 查看计算机名 # lspci -tv # 列出所有 PCI 设备 # lsusb -tv # 列出所有 USB 设备 # lsmod # 列出加载的内核模块 # env # 查看环境变量 资源 : # free -m # 查看内存使用量和交换区使用量 # df -h # 查看各分区使用情况 # du -sh <目录名 > # 查看指定目录的大小 # grep MemTotal /proc/meminfo # 查看内存总量 # grep MemFree /proc/meminfo # 查看空闲内存量 # uptime # 查看系统运行时间、用户数、负载 # cat /proc/loadavg # 查看系统负载 磁盘和分区 :

# mount | column -t # 查看挂接的分区状态 # fdisk -l # 查看所有分区 # swapon -s # 查看所有交换分区 # hdparm -i /dev/hda # 查看磁盘参数 (仅适用于 IDE 设备 # dmesg | grep IDE # 查看启动时 IDE 设备检测状况 网络 : # ifconfig # 查看所有网络接口的属性 # iptables -L # 查看防火墙设置 # route -n # 查看路由表 # netstat -lntp # 查看所有监听端口 # netstat -antp # 查看所有已经建立的连接 # netstat -s # 查看网络统计信息 用户 : # w # 查看活动用户 # id <用户名 > # 查看指定用户信息 # last # 查看用户登录日志 # cut -d: -f1 /etc/passwd # 查看系统所有用户 # cut -d: -f1 /etc/group # 查看系统所有组 # crontab -l # 查看当前用户的计划任务

各类格式的特点区分

在用各类软件设计时相信大家肯定存在着这样的问题,各种各样的格式让大家很是迷惑。没关系,福利来了,这里就给大家介绍了各种格式的特点应用。 TIFF格式 标签图像文件格式(Tagged Image File Format,简写为TIFF) 是一种主要用来存储包括照片和艺术图在内的图像的文件格式。它最初由Aldus公司与微软公司一起为PostScript 打印开发.TIFF文件格式适用于在应用程序之间和计算机平台之间的交换文件,它的出现使得图像数据交换变得简单。 TIFF是最复杂的一种位图文件格式。TIFF是基于标记的文件格式,它广泛地应用于对图像质量要求较高的图像的存储与转换。由于它的结构灵活和包容性大,它已成为图像文件格式的一种标准,绝大多数图像系统都支持这种格式。用Photoshop 编辑的TIFF文件可以保存路径和图层。 应用广泛 (1)TIFF可以描述多种类型的图像;(2)TIFF拥有一系列的压缩方案可供选择;(3)TIFF 不依赖于具体的硬件;(4)TIFF是一种可移植的文件格式。 可扩展性 在TIFF 6.0中定义了许多扩展,它们允许TIFF提供以下通用功能:(1)几种主要的压缩方法;(2)多种色彩表示方法;(3)图像质量增强;(4)特殊图像效果;(5)文档的存储和检索帮助。 格式复杂 TIFF文件的复杂性给它的应用带来了一些问题。一方面,要写一种能够识别所有不同标记的软件非常困难。另一方面,一个TIFF文件可以包含多个图像,每个图像都有自己的IFD 和一系列标记,并且采用了多种压缩算法。这样也增加了程序设计的复杂度。 文档图像中的TIFF TIFF格式是文档图像和文档管理系统中的标准格式。在这种环境中它通常使用支持黑白(也称为二值或者单色)图像的CCITT Group IV 2D压缩。在大量生产的环境中,文档通常扫描成黑白图像(而不是彩色或者灰阶图像)以节约存储空间。A4大小200dpi(每英寸点数分辨率)扫描结果平均大小是30KB,而300dpi的扫描结果是50KB。300dpi比200dpi更

如何查询centos查看系统内核版本,系统版本,32位还是64位

【转】如何查询centos查看系统内核版本,系统版本,32位还是64位 查看centos内核的版本: 1)[root@localhost ~]# cat /proc/version Linux version 2.6.18-194.el5 (mockbuild@https://www.360docs.net/doc/8e17977250.html,) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Fri Apr 2 14:58:14 EDT 2010 2) [root@localhost ~]# uname -a Linux localhost.localdomain 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux 3) [root@localhost ~]# uname -r 2.6.18-194.el5 2. 查看linux版本: 1) 列出所有版本信息, [root@localhost ~]# lsb_release -a LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics -3.1-ia32:graphics-3.1-noarch Distributor ID: CentOS Description: CentOS release 5.5 (Final) Release: 5.5 Codename: Final 注:这个命令适用于所有的linux,包括Redhat、SuSE、Debian等发行版。 2) 执行cat /etc/issue,例如如下: [root@localhost ~]# cat /etc/issue CentOS release 5.5 (Final) Kernel r on an m 3) 执行cat /etc/redhat-release ,例如如下: [root@localhost ~]# cat /etc/redhat-release CentOS release 5.5 (Final) 查看系统是64位还是32位: 1、getconf LONG_BIT or getconf WORD_BIT [root@localhost ~]# getconf LONG_BIT 64 2、file /bin/ls [root@localhost ~]# file /bin/ls /bin/ls: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped 3、lsb_release -a [root@localhost ~]# lsb_release -a

认清维也纳华尔兹中的重要区别

认清维也纳华尔兹中的重要区别 维也纳华尔兹中的重要区别: 1、左转步与右转步不相同。左转步反身,右转步摆荡; 2、男士步法与女士步法不相同。男士前进摆荡,女士前进无摆荡; 3、前进小节与后退小节不相同。男士前进小节大步向前,后退小节小步调整; 4、节拍长短不相同。每一拍时间值长短不相同,不是平均占一拍。具体来说: 1、维也纳华尔兹左转步与右转步不相同。 在维也纳华尔兹中,右转和左转的跳法是不对称的,右旋转是横并式结构,右转步强调向前流动,强调摆荡,有倾斜,有起伏,步幅大,以单侧拉腰为主;左旋转是锁式结构,左转步强调拧腰胯,反身,无摆荡,无升降,锁步,步幅小,要不停地反身。 2、维也纳华尔兹男士步法与女士步法不相同。

在维也纳华尔兹中,男士与女士步法不相同,男士的前进转身小节是女士的后退转身小节,男士前进右转摆荡,女士后退右转也摆荡;男士后退右转无摆荡,女士前进右转也无摆荡。 3、维也纳华尔兹前进小节与后退小节跳法不相同。 在维也纳华尔兹中,前进与后退小节跳法不相同,男士前进小节大步向前,后退小节小步调整。右转男士后退(女士前进)那个小节不摆荡,步子也较小,相当于休息。 4、维也纳华尔兹中节拍长短不相同。 在维也纳华尔兹中,每两小节六步为一组,每一节拍时间值长短不相同,不都是平均占一拍。六个节拍时间值分别是:1.5、0.75、0.75、1.5、0.75、0.75,第一、四拍最长,第三、六拍最短,口令:慢、快、快、慢、快、快 跳快三的要领 (2011-11-14 10:18:09) 转载▼ 标签:

杂谈

维也纳华尔兹俗称快三,它是舞中之王,跳快三是很难跳得好的,我虽然跳舞多年,长期以来被错误的观点支配,也是最近才掌握到跳快三的要领。 快三看似简单,只有四种基本步法,左转、右转、左换步、右换步,但如果不掌握要领,光靠看视频,听舞友指点,不容易领会关键的要领,舞就跳不好。 很多人以为快三就是比慢三转快一些,这就错了,这也是跳不好快三的原因。我以前也是用这种思维去跳的,结果一直转不好,转起来不畅顺,不能绕舞池转。开始还以为对方没跳好,但与多个人跳过也不好,最近才发现,是自己没跳对,不会带舞伴,跳和带的方法不对。 不久前,在网上无意间找到了2句跳好快三的要决,原来快三的转与慢三的转完全不一样,慢三是转园圈,像车轮那样。而快三的转是折转或翻转,像蛇爬行时一样。其次,快三不是以3拍为一小节,而是以6拍为一小节。一小节中跳半个大圈和半个小圈,不是两个半圈相同的,跳时男女互相错开,男跳大半圈时女跳小半圈,只有跳大半圈时才发力。这就是对快三的新认识,是跳快三的要领。 从以上认识入手,还需要学会用力的方法,以前我和很多人一样用手发力来带对方转,这显然不能到位。其实,关键是要从腰发力,用侧腰的力去带动身体前进,以前进带动转动。 快三的左转和右转也很不一样,很多人右转不错,但左转就不妥,这也是上面说的原因,没有认识快三的转的实质。在跳快三过

产品特性与过程特性的区别

产品特性与过程特性得区别 如果说产品特性从安全、法规、性能、尺寸、外观、装配等方面考虑,过程特性仅从产品形成过程中得参数(温度、压力、电压、电流)等考虑就是不就是很准确呢??欢迎大家讨论,敬请指教! 简单得讲,产品特性就是随着产品走,如过程加工中产品得尺寸、材料等,?过程特性就是在过程上不随产品走得东西,如工艺参数温度、压力等、 我一般就是作这样得区分、 产品特性能做spc,过程特性不能 产品特性一般就是指产品工程规范得要求;过程特性可以指工艺(过程)参数 过程特性保证产品特性 虽然大家说得都对,但就是怎样确定产品与过程得特殊特性呢?就是不就是特殊特性都要采用SPC控制或100%控制或防差错系统? ?通过fmea来确定得!根据过程得风险以及顾客得呼声来确定控制方法! 特性矩阵分析-初始特殊特性清单-FMEA-控制计划? 还就是:特性矩阵分析-FMEA-初始特殊特性清单--控制计划? 第一阶段: 确定初始过程特殊特性清单FMA分析 第二阶段?样件控制计划产品与过程特殊特性 第三阶段 特性矩阵图试生产控制计划PFMEA?第四阶段:?控制计划 产品特性,随着产品走,就是在过程中形成得,而过程特性不随产品走,我们只有通过过程特性来控制产品特性。而控制产品特性包括人、机、法、环、测与过程规范,故这些都就是过程特性;产品特性可以从料、技术要求、技术规范进行考虑。谁有更深层次得讨论,请指教。 更正一下。?初始特殊特性清单-特性矩阵分析-PFMEA-控制计划先有特殊特性,才有特性矩阵分析。体现特性与过程之间得相互关系及特性之间得影响。 产品特性与过程特性得区别:用过程特性去保证产品特性啊!产品特性就是要带到最总顾客得手里啊!而过程特性就是在过程中为保证产品得特性而对过程设置得特性,过程控制主要控制“过程特性啊” 特殊特性释义? 以下就是我对特殊特性得一些见解,希望能够得到大家得评论!也就是为了“特殊特性清单就是越来越长还就是越来越短”得讨论而作 特殊特性就是APQP得核心。无论就是QS9000还就是TS16949,其实对于特殊特性得解释与理解就是一样得。不同得就是QS9000着重阐明了通用、福特、克莱斯勒三大车厂得特殊要求。如对特性得等级分类以及特性符号标记。而TS16949则体现得就是大众化得,灵活得,可根据顾客而定得特性要求。?现在就以TS16949体系中对于特殊特性得理解来展开说明,一直推广到QS9000中得特殊要求。 TS16949中特殊特性得出处说明!? TS16949有两处地方出现过特殊特性。 第一处: 7.2.1、1顾客指定得特殊特性?组织必须在特殊特性得指定、文件化、与控制方面符合客户得所有要求。 解释:也就就是说凡就是客户指定得特殊特性,应在相关文件中体现。?相关文件有:设计FMEA、过程FMEA、控制计划、作业指导书、检验规范等 在上述文件中应作特殊特性符号得标记。

查看linux系统版本,内核,CPU,MEM,位数的相关命令

查看linux系统版本,内核,CPU,MEM,位数的相关命令 1.查看版本,内核 [oracle@svr15 ~]$ cat /etc/issue Red Hat Enterprise Linux AS release 4 (Nahant) Kernel \r on an \m [oracle@svr15 ~]$ cat /proc/version Linux version 2.6.9-5.ELsmp (bhcompile@https://www.360docs.net/doc/8e17977250.html,) (gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)) #1 SMP Wed Jan 5 19:30:39 EST 2005 [oracle@svr15 ~]$ uname -r 2.6.9-5.ELsmp 2.查看cpu,mem [oracle@svr15 ~]$ grep "model name" /proc/cpuinfo model name : Intel(R) Xeon(R) CPU 5130 @ 2.00GHz model name : Intel(R) Xeon(R) CPU 5130 @ 2.00GHz model name : Intel(R) Xeon(R) CPU 5130 @ 2.00GHz model name : Intel(R) Xeon(R) CPU 5130 @ 2.00GHz [oracle@svr15 ~]$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 5130 @ 2.00GHz stepping : 6 cpu MHz : 1995.006 cache size : 64 KB physical id : 0 siblings : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes

消息与通讯的特点与区别

消息与通讯的特点与区别 1、消息的特点 什么是消息。消息主要告诉人们发生什么事情(包括新的情况、经验、问题等),往往只报道事情的概貌而不讲详细的经过和情节,是以简要的语言文字迅速传播新近事实的新闻体裁,也是最广泛、最经常采用的新闻基本体裁。 消息按事实性质分类,可分为事件性新闻和非事件性新闻;按报道内容分,可以分为经济新闻、社会新闻、人物新闻和政治新闻;按写作特点分,可分为特写式消息、目击新闻、解释性报道和背景报道;按篇幅长短分,可分为简讯、一句话新闻、标题新闻;按写作形式分,可以分为动态消息、经验性消息、综合消息和述评性消息;其他的消息形式还有公报式消息,答记者问等。 消息体裁的特征: 一是比较短,多为几百字,内容简明扼要,文字干净利落; 二是常有一段导语,开门见山,吸引读者(听众、观众); 三是叙事朴实,实在,通常一事一报,讲究用事实说话; 四是时间性强,注重时效,报道快速及时; 五是基本表达方法是叙述,而且多为概括的叙述,但不能概念化。 六是结构严密,层次分明。一般是按照事物的内在联系,把最重要、最新鲜的事实写在最前面,然后再写次要的,更次要的;也可以依照事物的产生、发展、变化的顺序来写,但要突出主要部分。 七是交代必要的背景。写清楚被报道事物的历史背景,事件发生、发展、变化的环境,条件以及与其它事物的联系。目的是通过比较、衬托,更鲜明的阐述事物的意义。 在写作过程中,经验性消息实用价值比较大。经验性消息是反映某地区或某单位在执行党和国家路线、方针政策中,所取得的典型经验、成功做法及其显著效果的一种新闻体裁。它是典型报道的一种,用以推动全局,指导工作。 2、通讯的特点 通讯也是一种常用的新闻体裁,是对新闻事件、人物和各种见闻的比较详尽的生动报道。它不仅告诉人们发生了什么事,而且交待事情的来龙去脉,以及情节、细节和有关的环境气氛。 通讯常分为人物通讯、事件通讯、工作通讯、风貌通讯等。我们用得较多的是人物通讯和工作通讯。人物通讯是写先进工作者、劳动模范以影响大家带动大家的一种通讯,工作通讯是反映并指导实际工作的一种通讯,它通过事实的报道,分析当前

与非的一个重要区别在于作为公众公司

与非的一个重要区别在 于作为公众公司 Company Document number:WTUT-WT88Y-W8BBGB-BWYTT-19998

上市公司与非上市公司的一个重要区别在于上市公司作为公众公司,其公司股权交易公开化、市场化,上市公司的股份可以在二级市场转让,非上市公司的股权也可以转让,所不同的是缺乏较规范的股权市场作为交易场所。非上市公司依然遵循市场经济的原则,当业绩不断提升时,股权转让价格亦将上升,这正是非上市企业股权激励的基础。 随着国内产权交易体系的不断完善,非上市公司施行股权激励的外部条件更加成熟,越来越多的企业准备推行股权激励。岚顶咨询结合多年的股权激励咨询经验,总结出适用的“一四六”股权激励设计法,即选择一套股权激励工具组合,坚持四项基本激励原则,确定六个股权激励要素。 一、选择一套股权激励工具组合 股权激励工具有很多,不同企业可以根据企业的行业特性与企业客观情况选择适合的激励工具或激励工具组合。股权激励工具根据企业是上市公司还是非上市公司划分为两大类。上市公司股权激励工具主要有股票期权、股票增值权等,其收益来源是股票的增值部分。非上市公司的股权激励主要有股票赠与计划、股票购买计划、期股计划、虚拟股份等,其收益来源是企业的利润。 股票赠与计划是指公司现有股东拿出部分股份,一次性或分批赠与被激励对象,可以设置赠与附加条件,比如签订一定期限的劳动合同、完成约定的业绩指标等,也可以不设置附加条件,无偿赠送。股票赠与计划激励成本较高,不痛不痒的激励还容易导致被激励者不在乎,约束效果较差。股票赠与计划一般赠与股份占总股本的比例一般不会太高,并且通常会一次性授予,分批赠与。股票购买计划是指公司现有股东拿出一部分股份授予被激励者,但被激励者需要出资或用知识产权交换获得股份。被激励者获得是完整的股权,拥有股份所

[试论秘书工作的性质和特点] 性质和特点的区别

[试论秘书工作的性质和特点] 性质和特点 的区别 秘书工作的性质、特点和作用是个旧题。自秘书学诞生以来,接连问世的论著几乎都要论及,相关的单篇论文亦屡见不鲜。但时至今日,旧题缘何新做呢?首先,是性质同特点两个概念重叠混淆,它们的关系没有作出科学的阐释。 再者,性质、特点与作用相关的提法,也有重叠之感。 出现上述现象的原因何在呢?1.用日常概念或直观感性经验来代替科学的理论概念。 2.从秘书部门的单项任务去相应地提出单个的性。这是一种就事论事的思想方法,缺乏必要的概括和抽象,其结果,秘书工作的性自然很多了。3.对性质、特点的联系和区别及其相互关系缺乏科学的理解,甚至出现了本末倒置的现象。这里有两个问题,其一,是性质决定特点,还是特点决定性质?其二,承办事务是秘书工作的基本性质吗?4.作者的主观随意性,移植管理科学的有关概念,缺乏必要的正确的阐释。 二、旧题新做的基本依据1.考察秘书工作的性质、特点和作用要以行政组织法为指导。 2.从国家行政机关的系统性宏观地考察秘书工作的性质、特点和作用。3.要把日常观念或直观经验概念提炼上升为科学的理论概念。 三、旧题新做之我见秘书工作的性质、特点和作用属

于秘书学的基本概念,而基本概念正是奠定概念体系的理论基础。 本质和特点是既有联系又有区别的两个概念:本质概括了事物特点的主要方面,而特点是事物某一方面的本质表现。是本质决定特点而不是特点决定本质,对于秘书工作的特点,我以为提以下四个就可以了: 1.政策性。2.综合性。3.服务性。 4.机要性。上述四个主要特点,都是从辅助性那个主要的东西派生出来,既与本质相通,又是某一方面的本质反映。

相关文档
最新文档