当前位置：文档库 › rfc5322.Internet Message Format

rfc5322.Internet Message Format

Network Working Group P. Resnick, Ed. Request for Comments: 5322 Qualcomm Incorporated Obsoletes: 2822 October 2008 Updates: 4021

Category: Standards Track

Internet Message Format

Status of This Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited. Abstract

This document specifies the Internet Message Format (IMF), a syntax

for text messages that are sent between computer users, within the

framework of "electronic mail" messages. This specification is a

revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA

Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. Resnick Standards Track [Page 1]

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.

2. Notational Conventions . . . . . . . . . . . . . . . . . . 5 1.2.1. Requirements Notation . . . . . . . . . . . . . . . . 5 1.2.2. Syntactic Notation . . . . . . . . . . . . . . . . . . 5

1.2.3. Structure of This Document . . . . . . . . . . . . . . 5

2. Lexical Analysis of Messages . . . . . . . . . . . . . . . . . 6 2.1. General Description . . . . . . . . . . . . . . . . . . . 6 2.1.1. Line Length Limits . . . . . . . . . . . . . . . . . . 7 2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1. Unstructured Header Field Bodies . . . . . . . . . . . 8 2.2.2. Structured Header Field Bodies . . . . . . . . . . . . 8 2.2.

3. Long Header Fields . . . . . . . . . . . . . . . . . . 8

2.3. Body . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Lexical Tokens . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Quoted characters . . . . . . . . . . . . . . . . . . 10 3.2.2. Folding White Space and Comments . . . . . . . . . . . 11 3.2.3. Atom . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.

4. Quoted Strings . . . . . . . . . . . . . . . . . . . . 13 3.2.

5. Miscellaneous Tokens . . . . . . . . . . . . . . . . . 14 3.3. Date and Time Specification . . . . . . . . . . . . . . . 14 3.4. Address Specification . . . . . . . . . . . . . . . . . . 16 3.4.1. Addr-Spec Specification . . . . . . . . . . . . . . . 17 3.5. Overall Message Syntax . . . . . . . . . . . . . . . . . . 18 3.

6. Field Definitions . . . . . . . . . . . . . . . . . . . . 19 3.6.1. The Origination Date Field . . . . . . . . . . . . . . 22 3.6.2. Originator Fields . . . . . . . . . . . . . . . . . . 22 3.6.3. Destination Address Fields . . . . . . . . . . . . . . 23 3.6.4. Identification Fields . . . . . . . . . . . . . . . . 25 3.6.5. Informational Fields . . . . . . . . . . . . . . . . . 27 3.6.6. Resent Fields . . . . . . . . . . . . . . . . . . . . 28 3.6.

7. Trace Fields . . . . . . . . . . . . . . . . . . . . . 30

3.6.8. Optional Fields . . . . . . . . . . . . . . . . . . . 30

4. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 31 4.1. Miscellaneous Obsolete Tokens . . . . . . . . . . . . . . 32 4.2. Obsolete Folding White Space . . . . . . . . . . . . . . . 33 4.3. Obsolete Date and Time . . . . . . . . . . . . . . . . . . 33 4.4. Obsolete Addressing . . . . . . . . . . . . . . . . . . . 35 4.

5. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 35 4.5.1. Obsolete Origination Date Field . . . . . . . . . . . 36 4.5.2. Obsolete Originator Fields . . . . . . . . . . . . . . 36 4.5.3. Obsolete Destination Address Fields . . . . . . . . . 37 4.5.4. Obsolete Identification Fields . . . . . . . . . . . . 37 4.5.5. Obsolete Informational Fields . . . . . . . . . . . . 37 Resnick Standards Track [Page 2]

4.5.6. Obsolete Resent Fields . . . . . . . . . . . . . . . . 38 4.5.7. Obsolete Trace Fields . . . . . . . . . . . . . . . . 38

4.5.8. Obsolete optional fields . . . . . . . . . . . . . . . 38

5. Security Considerations . . . . . . . . . . . . . . . . . . . 38

6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 Appendix A. Example Messages . . . . . . . . . . . . . . . . . 43 Appendix A.1. Addressing Examples . . . . . . . . . . . . . . . 44 Appendix A.1.1. A Message from One Person to Another with

Simple Addressing . . . . . . . . . . . . . . . . 44 Appendix A.1.2. Different Types of Mailboxes . . . . . . . . . . . 45 Appendix A.1.3. Group Addresses . . . . . . . . . . . . . . . . . 45 Appendix A.2. Reply Messages . . . . . . . . . . . . . . . . . . 46 Appendix A.3. Resent Messages . . . . . . . . . . . . . . . . . 47 Appendix A.4. Messages with Trace Fields . . . . . . . . . . . . 48 Appendix A.5. White Space, Comments, and Other Oddities . . . . 49 Appendix A.6. Obsoleted Forms . . . . . . . . . . . . . . . . . 50 Appendix A.6.1. Obsolete Addressing . . . . . . . . . . . . . . . 50 Appendix A.6.2. Obsolete Dates . . . . . . . . . . . . . . . . . . 50 Appendix A.6.3. Obsolete White Space and Comments . . . . . . . . 51 Appendix B. Differences from Earlier Specifications . . . . . 52 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . 53 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 7.1. Normative References . . . . . . . . . . . . . . . . . . . 55 7.2. Informative References . . . . . . . . . . . . . . . . . . 55 Resnick Standards Track [Page 3]

1. Introduction

1.1. Scope

This document specifies the Internet Message Format (IMF), a syntax

for text messages that are sent between computer users, within the

framework of "electronic mail" messages. This specification is an

update to [RFC2822], which itself superseded [RFC0822], updating it

to reflect current practice and incorporating incremental changes

that were specified in other RFCs such as [RFC1123].

This document specifies a syntax only for text messages. In

particular, it makes no provision for the transmission of images,

audio, or other sorts of structured data in electronic mail messages. There are several extensions published, such as the MIME document

series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms

for the transmission of such data through electronic mail, either by extending the syntax provided here or by structuring such messages to conform to this syntax. Those mechanisms are outside of the scope of this specification.

In the context of electronic mail, messages are viewed as having an

envelope and contents. The envelope contains whatever information is needed to accomplish transmission and delivery. (See [RFC5321] for a discussion of the envelope.) The contents comprise the object to be delivered to the recipient. This specification applies only to the

format and some of the semantics of message contents. It contains no specification of the information in the envelope.

However, some message systems may use information from the contents

to create the envelope. It is intended that this specification

facilitate the acquisition of such information by programs.

This specification is intended as a definition of what message

content format is to be passed between systems. Though some message systems locally store messages in this format (which eliminates the

need for translation between formats) and others use formats that

differ from the one specified in this specification, local storage is outside of the scope of this specification.

Note: This specification is not intended to dictate the internal

formats used by sites, the specific message system features that

they are expected to support, or any of the characteristics of

user interface programs that create or read messages. In

addition, this document does not specify an encoding of the

characters for either transport or storage; that is, it does not

specify the number of bits used or how those bits are specifically transferred over the wire or stored on disk.

Resnick Standards Track [Page 4]

1.2. Notational Conventions

1.2.1. Requirements Notation

This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD

NOT", and "MAY" appear capitalized, they are being used to indicate

particular requirements of this specification. A discussion of the

meanings of these terms appears in [RFC2119].

1.2.2. Syntactic Notation

This specification uses the Augmented Backus-Naur Form (ABNF)

[RFC5234] notation for the formal definitions of the syntax of

messages. Characters will be specified either by a decimal value

(e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by a case-insensitive literal value enclosed in quotation marks (e.g.,

"A" for either uppercase or lowercase A).

1.2.3. Structure of This Document

This document is divided into several sections.

This section, section 1, is a short introduction to the document.

Section 2 lays out the general description of a message and its

constituent parts. This is an overview to help the reader understand some of the general principles used in the later portions of this

document. Any examples in this section MUST NOT be taken as

specification of the formal syntax of any part of a message.

Section 3 specifies formal ABNF rules for the structure of each part of a message (the syntax) and describes the relationship between

those parts and their meaning in the context of a message (the

semantics). That is, it lays out the actual rules for the structure of each part of a message (the syntax) as well as a description of

the parts and instructions for their interpretation (the semantics). This includes analysis of the syntax and semantics of subparts of

messages that have specific structure. The syntax included in

section 3 represents messages as they MUST be created. There are

also notes in section 3 to indicate if any of the options specified

in the syntax SHOULD be used over any of the others.

Both sections 2 and 3 describe messages that are legal to generate

for purposes of this specification.

Resnick Standards Track [Page 5]

Section 4 of this document specifies an "obsolete" syntax. There are references in section 3 to these obsolete syntactic elements. The

rules of the obsolete syntax are elements that have appeared in

earlier versions of this specification or have previously been widely used in Internet messages. As such, these elements MUST be

interpreted by parsers of messages in order to be conformant to this specification. However, since items in this syntax have been

determined to be non-interoperable or to cause significant problems

for recipients of messages, they MUST NOT be generated by creators of conformant messages.

Section 5 details security considerations to take into account when

implementing this specification.

Appendix A lists examples of different sorts of messages. These

examples are not exhaustive of the types of messages that appear on

the Internet, but give a broad overview of certain syntactic forms.

Appendix B lists the differences between this specification and

earlier specifications for Internet messages.

Appendix C contains acknowledgements.

2. Lexical Analysis of Messages

2.1. General Description

At the most basic level, a message is a series of characters. A

message that is conformant with this specification is composed of

characters with values in the range of 1 through 127 and interpreted as US-ASCII [ANSI.X3-4.1986] characters. For brevity, this document sometimes refers to this range of characters as simply "US-ASCII

characters".

Note: This document specifies that messages are made up of

characters in the US-ASCII range of 1 through 127. There are

other documents, specifically the MIME document series ([RFC2045], [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), that

extend this specification to allow for values outside of that

range. Discussion of those mechanisms is not within the scope of this specification.

Messages are divided into lines of characters. A line is a series of characters that is delimited with the two characters carriage-return and line-feed; that is, the carriage return (CR) character (ASCII

value 13) followed immediately by the line feed (LF) character (ASCII value 10). (The carriage return/line feed pair is usually written in this document as "CRLF".)

Resnick Standards Track [Page 6]

A message consists of header fields (collectively called "the header section of the message") followed, optionally, by a body. The header section is a sequence of lines of characters with special syntax as

defined in this specification. The body is simply a sequence of

characters that follows the header section and is separated from the header section by an empty line (i.e., a line with nothing preceding the CRLF).

Note: Common parlance and earlier versions of this specification

use the term "header" to either refer to the entire header section or to refer to an individual header field. To avoid ambiguity,

this document does not use the terms "header" or "headers" in

isolation, but instead always uses "header field" to refer to the individual field and "header section" to refer to the entire

collection.

2.1.1. Line Length Limits

There are two limits that this specification places on the number of characters in a line. Each line of characters MUST be no more than

998 characters, and SHOULD be no more than 78 characters, excluding

the CRLF.

The 998 character limit is due to limitations in many implementations that send, receive, or store IMF messages which simply cannot handle more than 998 characters on a line. Receiving implementations would do well to handle an arbitrarily large number of characters in a line for robustness sake. However, there are so many implementations that (in compliance with the transport requirements of [RFC5321]) do not

accept messages containing more than 1000 characters including the CR and LF per line, it is important for implementations not to create

such messages.

The more conservative 78 character recommendation is to accommodate

the many implementations of user interfaces that display these

messages which may truncate, or disastrously wrap, the display of

more than 78 characters per line, in spite of the fact that such

implementations are non-conformant to the intent of this

specification (and that of [RFC5321] if they actually cause

information to be lost). Again, even though this limitation is put

on messages, it is incumbent upon implementations that display

messages to handle an arbitrarily large number of characters in a

line (certainly at least up to the 998 character limit) for the sake of robustness.

Resnick Standards Track [Page 7]

2.2. Header Fields

Header fields are lines beginning with a field name, followed by a

colon (":"), followed by a field body, and terminated by CRLF. A

field name MUST be composed of printable US-ASCII characters (i.e.,

characters that have values between 33 and 126, inclusive), except

colon. A field body may be composed of printable US-ASCII characters as well as the space (SP, ASCII value 32) and horizontal tab (HTAB,

ASCII value 9) characters (together known as the white space

characters, WSP). A field body MUST NOT include CR and LF except

when used in "folding" and "unfolding", as described in section

2.2.

3. All field bodies MUST conform to the syntax described in

sections 3 and 4 of this specification.

2.2.1. Unstructured Header Field Bodies

Some field bodies in this specification are defined simply as

"unstructured" (which is specified in section 3.2.5 as any printable US-ASCII characters plus white space characters) with no further

restrictions. These are referred to as unstructured field bodies.

Semantically, unstructured field bodies are simply to be treated as a single line of characters with no further processing (except for

"folding" and "unfolding" as described in section 2.2.3).

2.2.2. Structured Header Field Bodies

Some field bodies in this specification have a syntax that is more

restrictive than the unstructured field bodies described above.

These are referred to as "structured" field bodies. Structured field bodies are sequences of specific lexical tokens as described in

sections 3 and 4 of this specification. Many of these tokens are

allowed (according to their syntax) to be introduced or end with

comments (as described in section 3.2.2) as well as the white space

characters, and those white space characters are subject to "folding" and "unfolding" as described in section 2.2.3. Semantic analysis of structured field bodies is given along with their syntax.

2.2.

3. Long Header Fields

Each header field is logically a single line of characters comprising the field name, the colon, and the field body. For convenience

however, and to deal with the 998/78 character limitations per line, the field body portion of a header field can be split into a

multiple-line representation; this is called "folding". The general rule is that wherever this specification allows for folding white

space (not simply WSP characters), a CRLF may be inserted before any WSP.

Resnick Standards Track [Page 8]

For example, the header field:

Subject: This is a test

can be represented as:

Subject: This

is a test

Note: Though structured field bodies are defined in such a way

that folding can take place between many of the lexical tokens

(and even within some of the lexical tokens), folding SHOULD be

limited to placing the CRLF at higher-level syntactic breaks. For instance, if a field body is defined as comma-separated values, it is recommended that folding occur after the comma separating the

structured items in preference to other places where the field

could be folded, even if it is allowed elsewhere.

The process of moving from this folded multiple-line representation

of a header field to its single line representation is called

"unfolding". Unfolding is accomplished by simply removing any CRLF

that is immediately followed by WSP. Each header field should be

treated in its unfolded form for further syntactic and semantic

evaluation. An unfolded header field has no length restriction and

therefore may be indeterminately long.

2.3. Body

The body of a message is simply lines of US-ASCII characters. The

only two limitations on the body are as follows:

o CR and LF MUST only occur together as CRLF; they MUST NOT appear

independently in the body.

o Lines of characters in the body MUST be limited to 998 characters, and SHOULD be limited to 78 characters, excluding the CRLF.

Note: As was stated earlier, there are other documents,

specifically the MIME documents ([RFC2045], [RFC2046], [RFC2049], [RFC4288], [RFC4289]), that extend (and limit) this specification to allow for different sorts of message bodies. Again, these

mechanisms are beyond the scope of this document.

Resnick Standards Track [Page 9]

3. Syntax

3.1. Introduction

The syntax as given in this section defines the legal syntax of

Internet messages. Messages that are conformant to this

specification MUST conform to the syntax in this section. If there

are options in this section where one option SHOULD be generated,

that is indicated either in the prose or in a comment next to the

syntax.

For the defined expressions, a short description of the syntax and

use is given, followed by the syntax in ABNF, followed by a semantic analysis. The following primitive tokens that are used but otherwise unspecified are taken from the "Core Rules" of [RFC5234], Appendix

B.1: CR, LF, CRLF, HTAB, SP, WSP, DQUOTE, DIGIT, ALPHA, and VCHAR.

In some of the definitions, there will be non-terminals whose names

start with "obs-". These "obs-" elements refer to tokens defined in the obsolete syntax in section 4. In all cases, these productions

are to be ignored for the purposes of generating legal Internet

messages and MUST NOT be used as part of such a message. However,

when interpreting messages, these tokens MUST be honored as part of

the legal syntax. In this sense, section 3 defines a grammar for the generation of messages, with "obs-" elements that are to be ignored, while section 4 adds grammar for the interpretation of messages.

3.2. Lexical Tokens

The following rules are used to define an underlying lexical

analyzer, which feeds tokens to the higher-level parsers. This

section defines the tokens used in structured header field bodies.

Note: Readers of this specification need to pay special attention to how these lexical tokens are used in both the lower-level and

higher-level syntax later in the document. Particularly, the

white space tokens and the comment tokens defined in section 3.2.2 get used in the lower-level tokens defined here, and those lower- level tokens are in turn used as parts of the higher-level tokens defined later. Therefore, white space and comments may be allowed in the higher-level tokens even though they may not explicitly

appear in a particular definition.

3.2.1. Quoted characters

Some characters are reserved for special interpretation, such as

delimiting lexical tokens. To permit use of these characters as

uninterpreted data, a quoting mechanism is provided.

Resnick Standards Track [Page 10]

quoted-pair = ("\" (VCHAR / WSP)) / obs-qp

Where any quoted-pair appears, it is to be interpreted as the

character alone. That is to say, the "\" character that appears as

part of a quoted-pair is semantically "invisible".

Note: The "\" character may appear in a message where it is not

part of a quoted-pair. A "\" character that does not appear in a quoted-pair is not semantically invisible. The only places in

this specification where quoted-pair currently appears are

ccontent, qcontent, and in obs-dtext in section 4.

3.2.2. Folding White Space and Comments

White space characters, including white space used in folding

(described in section 2.2.3), may appear between many elements in

header field bodies. Also, strings of characters that are treated as comments may be included in structured field bodies as characters

enclosed in parentheses. The following defines the folding white

space (FWS) and comment constructs.

Strings of characters enclosed in parentheses are considered comments so long as they do not appear within a "quoted-string", as defined in section 3.2.4. Comments may nest.

There are several places in this specification where comments and FWS may be freely inserted. To accommodate that syntax, an additional

token for "CFWS" is defined for places where comments and/or FWS can occur. However, where CFWS occurs in this specification, it MUST NOT be inserted in such a way that any line of a folded header field is

made up entirely of WSP characters and nothing else.

FWS = ([*WSP CRLF] 1*WSP) / obs-FWS

; Folding white space

ctext = %d33-39 / ; Printable US-ASCII

%d42-91 / ; characters not including

%d93-126 / ; "(", ")", or "\"

obs-ctext

ccontent = ctext / quoted-pair / comment

comment = "(" *([FWS] ccontent) [FWS] ")"

CFWS = (1*([FWS] comment) [FWS]) / FWS

Resnick Standards Track [Page 11]

Throughout this specification, where FWS (the folding white space

token) appears, it indicates a place where folding, as discussed in

section 2.2.3, may take place. Wherever folding appears in a message (that is, a header field body containing a CRLF followed by any WSP), unfolding (removal of the CRLF) is performed before any further

semantic analysis is performed on that header field according to this specification. That is to say, any CRLF that appears in FWS is

semantically "invisible".

A comment is normally used in a structured field body to provide some human-readable informational text. Since a comment is allowed to

contain FWS, folding is permitted within the comment. Also note that since quoted-pair is allowed in a comment, the parentheses and

backslash characters may appear in a comment, so long as they appear as a quoted-pair. Semantically, the enclosing parentheses are not

part of the comment; the comment is what is contained between the two parentheses. As stated earlier, the "\" in any quoted-pair and the

CRLF in any FWS that appears within the comment are semantically

"invisible" and therefore not part of the comment either.

Runs of FWS, comment, or CFWS that occur between lexical tokens in a structured header field are semantically interpreted as a single

space character.

3.2.3. Atom

Several productions in structured header field bodies are simply

strings of certain basic characters. Such productions are called

atoms.

Some of the structured header field bodies also allow the period

character (".", ASCII value 46) within runs of atext. An additional "dot-atom" token is defined for those purposes.

Note: The "specials" token does not appear anywhere else in this

specification. It is simply the visible (i.e., non-control, non- white space) characters that do not appear in atext. It is

provided only because it is useful for implementers who use tools that lexically analyze messages. Each of the characters in

specials can be used to indicate a tokenization point in lexical

analysis.

Resnick Standards Track [Page 12]

"!" / "#" / ; characters not including

"$" / "%" / ; specials. Used for atoms. "&" / "’" /

"*" / "+" /

"-" / "/" /

"=" / "?" /

"^" / "_" /

"‘" / "{" /

"|" / "}" /

"?"

atom = [CFWS] 1*atext [CFWS]

dot-atom-text = 1*atext *("." 1*atext)

dot-atom = [CFWS] dot-atom-text [CFWS]

specials = "(" / ")" / ; Special characters that do

"<" / ">" / ; not appear in atext

"[" / "]" /

":" / ";" /

"@" / "\" /

"," / "." /

DQUOTE

Both atom and dot-atom are interpreted as a single unit, comprising

the string of characters that make it up. Semantically, the optional comments and FWS surrounding the rest of the characters are not part of the atom; the atom is only the run of atext characters in an atom, or the atext and "." characters in a dot-atom.

3.2.

4. Quoted Strings

Strings of characters that include characters other than those

allowed in atoms can be represented in a quoted string format, where the characters are surrounded by quote (DQUOTE, ASCII value 34)

characters.

Resnick Standards Track [Page 13]

%d35-91 / ; characters not including

%d93-126 / ; "\" or the quote character obs-qtext

qcontent = qtext / quoted-pair

quoted-string = [CFWS]

DQUOTE *([FWS] qcontent) [FWS] DQUOTE

[CFWS]

A quoted-string is treated as a unit. That is, quoted-string is

identical to atom, semantically. Since a quoted-string is allowed to contain FWS, folding is permitted. Also note that since quoted-pair is allowed in a quoted-string, the quote and backslash characters may appear in a quoted-string so long as they appear as a quoted-pair.

Semantically, neither the optional CFWS outside of the quote

characters nor the quote characters themselves are part of the

quoted-string; the quoted-string is what is contained between the two quote characters. As stated earlier, the "\" in any quoted-pair and the CRLF in any FWS/CFWS that appears within the quoted-string are

semantically "invisible" and therefore not part of the quoted-string either.

3.2.5. Miscellaneous Tokens

Three additional tokens are defined: word and phrase for combinations of atoms and/or quoted-strings, and unstructured for use in

unstructured header fields and in some places within structured

header fields.

word = atom / quoted-string

phrase = 1*word / obs-phrase

unstructured = (*([FWS] VCHAR) *WSP) / obs-unstruct

3.3. Date and Time Specification

Date and time values occur in several header fields. This section

specifies the syntax for a full date and time specification. Though folding white space is permitted throughout the date-time

specification, it is RECOMMENDED that a single space be used in each place that FWS appears (whether it is required or optional); some

older implementations will not interpret longer sequences of folding white space correctly.

Resnick Standards Track [Page 14]

date-time = [ day-of-week "," ] date time [CFWS]

day-of-week = ([FWS] day-name) / obs-day-of-week

day-name = "Mon" / "Tue" / "Wed" / "Thu" /

"Fri" / "Sat" / "Sun"

date = day month year

day = ([FWS] 1*2DIGIT FWS) / obs-day

month = "Jan" / "Feb" / "Mar" / "Apr" /

"May" / "Jun" / "Jul" / "Aug" /

"Sep" / "Oct" / "Nov" / "Dec"

year = (FWS 4*DIGIT FWS) / obs-year

time = time-of-day zone

time-of-day = hour ":" minute [ ":" second ]

hour = 2DIGIT / obs-hour

minute = 2DIGIT / obs-minute

second = 2DIGIT / obs-second

zone = (FWS ( "+" / "-" ) 4DIGIT) / obs-zone

The day is the numeric day of the month. The year is any numeric

year 1900 or later.

The time-of-day specifies the number of hours, minutes, and

optionally seconds since midnight of the date indicated.

The date and time-of-day SHOULD express local time.

The zone specifies the offset from Coordinated Universal Time (UTC,

formerly referred to as "Greenwich Mean Time") that the date and

time-of-day represent. The "+" or "-" indicates whether the time-of- day is ahead of (i.e., east of) or behind (i.e., west of) Universal

Time. The first two digits indicate the number of hours difference

from Universal Time, and the last two digits indicate the number of

additional minutes difference from Universal Time. (Hence, +hhmm

means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)

minutes). The form "+0000" SHOULD be used to indicate a time zone at Universal Time. Though "-0000" also indicates Universal Time, it is Resnick Standards Track [Page 15]

used to indicate that the time was generated on a system that may be in a local time zone other than Universal Time and that the date-time contains no information about the local time zone.

A date-time specification MUST be semantically valid. That is, the

day-of-week (if included) MUST be the day implied by the date, the

numeric day-of-month MUST be between 1 and the number of days allowed for the specified month (in the specified year), the time-of-day MUST be in the range 00:00:00 through 23:59:60 (the number of seconds

allowing for a leap second; see [RFC1305]), and the last two digits

of the zone MUST be within the range 00 through 59.

3.4. Address Specification

Addresses occur in several message header fields to indicate senders and recipients of messages. An address may either be an individual

mailbox, or a group of mailboxes.

address = mailbox / group

mailbox = name-addr / addr-spec

name-addr = [display-name] angle-addr

angle-addr = [CFWS] "<" addr-spec ">" [CFWS] /

obs-angle-addr

group = display-name ":" [group-list] ";" [CFWS]

display-name = phrase

mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list

address-list = (address *("," address)) / obs-addr-list

group-list = mailbox-list / CFWS / obs-group-list

A mailbox receives mail. It is a conceptual entity that does not

necessarily pertain to file storage. For example, some sites may

choose to print mail on a printer and deliver the output to the

addressee’s desk.

Normally, a mailbox is composed of two parts: (1) an optional display name that indicates the name of the recipient (which can be a person or a system) that could be displayed to the user of a mail

application, and (2) an addr-spec address enclosed in angle brackets Resnick Standards Track [Page 16]

("<" and ">"). There is an alternate simple form of a mailbox where the addr-spec address appears alone, without the recipient’s name or the angle brackets. The Internet addr-spec address is described in

section 3.4.1.

Note: Some legacy implementations used the simple form where the

addr-spec appears without the angle brackets, but included the

name of the recipient in parentheses as a comment following the

addr-spec. Since the meaning of the information in a comment is

unspecified, implementations SHOULD use the full name-addr form of the mailbox, instead of the legacy form, to specify the display

name associated with a mailbox. Also, because some legacy

implementations interpret the comment, comments generally SHOULD

NOT be used in address fields to avoid confusing such

implementations.

When it is desirable to treat several mailboxes as a single unit

(i.e., in a distribution list), the group construct can be used. The group construct allows the sender to indicate a named group of

recipients. This is done by giving a display name for the group,

followed by a colon, followed by a comma-separated list of any number of mailboxes (including zero and one), and ending with a semicolon.

Because the list of mailboxes can be empty, using the group construct is also a simple way to communicate to recipients that the message

was sent to one or more named sets of recipients, without actually

providing the individual mailbox address for any of those recipients.

3.4.1. Addr-Spec Specification

An addr-spec is a specific Internet identifier that contains a

locally interpreted string followed by the at-sign character ("@",

ASCII value 64) followed by an Internet domain. The locally

interpreted string is either a quoted-string or a dot-atom. If the

string can be represented as a dot-atom (that is, it contains no

characters other than atext characters or "." surrounded by atext

characters), then the dot-atom form SHOULD be used and the quoted-

string form SHOULD NOT be used. Comments and folding white space

SHOULD NOT be used around the "@" in the addr-spec.

Note: A liberal syntax for the domain portion of addr-spec is

given here. However, the domain portion contains addressing

information specified by and used in other protocols (e.g.,

[RFC1034], [RFC1035], [RFC1123], [RFC5321]). It is therefore

incumbent upon implementations to conform to the syntax of

addresses for the context in which they are used.

Resnick Standards Track [Page 17]

addr-spec = local-part "@" domain

local-part = dot-atom / quoted-string / obs-local-part

domain = dot-atom / domain-literal / obs-domain

domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]

dtext = %d33-90 / ; Printable US-ASCII

%d94-126 / ; characters not including

obs-dtext ; "[", "]", or "\"

The domain portion identifies the point to which the mail is

delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a host name or a mail exchanger name) as

described in [RFC1034], [RFC1035], and [RFC1123]. In the domain-

literal form, the domain is interpreted as the literal Internet

address of the particular host. In both cases, how addressing is

used and how messages are transported to a particular host is covered in separate documents, such as [RFC5321]. These mechanisms are

outside of the scope of this document.

The local-part portion is a domain-dependent string. In addresses,

it is simply interpreted on the particular host as a name of a

particular mailbox.

3.5. Overall Message Syntax

A message consists of header fields, optionally followed by a message body. Lines in a message MUST be a maximum of 998 characters

excluding the CRLF, but it is RECOMMENDED that lines be limited to 78 characters excluding the CRLF. (See section 2.1.1 for explanation.) In a message body, though all of the characters listed in the text

rule MAY be used, the use of US-ASCII control characters (values 1

through 8, 11, 12, and 14 through 31) is discouraged since their

interpretation by receivers for display is not guaranteed.

message = (fields / obs-fields)

[CRLF body]

body = (*(*998text CRLF) *998text) / obs-body

text = %d1-9 / ; Characters excluding CR

%d11 / ; and LF

%d12 /

%d14-127

Resnick Standards Track [Page 18]

The header fields carry most of the semantic information and are

defined in section 3.6. The body is simply a series of lines of text that are uninterpreted for the purposes of this specification.

3.6. Field Definitions

The header fields of a message are defined here. All header fields

have the same general syntactic structure: a field name, followed by a colon, followed by the field body. The specific syntax for each

header field is defined in the subsequent sections.

Note: In the ABNF syntax for each field in subsequent sections,

each field name is followed by the required colon. However, for

brevity, sometimes the colon is not referred to in the textual

description of the syntax. It is, nonetheless, required.

It is important to note that the header fields are not guaranteed to be in a particular order. They may appear in any order, and they

have been known to be reordered occasionally when transported over

the Internet. However, for the purposes of this specification,

header fields SHOULD NOT be reordered when a message is transported

or transformed. More importantly, the trace header fields and resent header fields MUST NOT be reordered, and SHOULD be kept in blocks

prepended to the message. See sections 3.6.6 and 3.6.7 for more

information.

The only required header fields are the origination date field and

the originator address field(s). All other header fields are

syntactically optional. More information is contained in the table

following this definition.

Resnick Standards Track [Page 19]

fields = *(trace

*optional-field /

*(resent-date /

resent-from /

resent-sender /

resent-to /

resent-cc /

resent-bcc /

resent-msg-id))

*(orig-date /

from /

sender /

reply-to /

to /

cc /

bcc /

message-id /

in-reply-to /

references /

subject /

comments /

keywords /

optional-field)

The following table indicates limits on the number of times each

field may occur in the header section of a message as well as any

special limitations on the use of those fields. An asterisk ("*")

next to a value in the minimum or maximum column indicates that a

special restriction appears in the Notes column.

Resnick Standards Track [Page 20]

详解硬盘低格操作方法

全面认识硬盘格式化详解硬盘低格操作方法低格, 详解, 硬盘, 格式化, 认识一、认识硬盘格式化 “格式化”这个词对于一个电脑用户而言绝对不应该陌生。当我们在进行一个全新的WINDOWS安装时，或是对一个硬盘上的所有数据进行“干净”的处理时，往往都会祭出“格式化”这招“杀手锏”，来彻底清除硬盘各个分区上的数据。“硬盘格式化目前可以在WINDOWS和DOS两种不同环境下进行。一般我们在进行全新安装操作系统时会使用DOS下的“FORMAT”命令来完成系统盘的格式化，而单独对除系统盘以外的其它分区进行格式化时，我们一般会在WINDOWS下来完成，而在Windows下的操作会更加简单，只需要在对需要格式化的硬盘上右击鼠标，选择“格式化”选项即可，选择快速格式化，所需耗费的时间则更短。虽然两者的操作方式和格式化所需的时间都有所不同。但它们实际上都是对硬盘进行同一种操作，那就是清除硬盘上的数据、生成引导区信息、初始化FAT表、标注逻辑坏道等。我们将这些操作统称为“高级格式化”。认识了硬盘的“高级格式化”，那么我们再来看一下硬盘的低级化过程。所谓低级格式化，就是将空白的磁盘划分出柱面和磁道，再将磁道划分为若干个扇区，每个扇区又划分出标识部分ID、间隔区GAP和数据区DATA等。硬盘的低级格式化是高级格式化之前的一件工作，目前所有硬盘厂商在产品出厂前，已经对硬盘进行了低格化的处理，因此我们新购买的硬盘在装系统时只需要进行高级格化的过程，来初始化FAT表，进行分区操作。与高级格式化操作不同的是，硬盘的低级格式化过程只能够在DOS环境来完成。我们在DOS下对一张软盘进行全面格式化操作的过程便可以看作是对软盘的低级格式化。需要说明的是，硬盘的低级格式化过程是一种损耗性操作，对硬盘的使用寿命会产生一定的负面作用。因此，除非是硬盘出现了较大的错误，如硬盘坏道等，否则一定要慎重低级格式化操作。当硬盘受到外部强磁体、强磁场的影响，或因长期使用，硬盘盘片上由低级格式化划分出来的扇区格式磁性记录部分丢失，从而出现大量“坏扇区”时，可以通过低级格式化来重新划分“扇区”。但是前提是硬盘的盘片没有受到物理性划伤。笔者认为，只有在硬盘多次分区均告失败或在高级格式化中发现大量“坏道”时，方可通过低级格式化来进行修复。而硬盘的硬性损伤，如硬盘出现物理坏道时，则是无法通过低级格式化来修复的。可以想象当一张软盘的盘片表面被划伤之后，还能修复吗？二、低级格式化对硬盘所做的操作

几秒种分区格式化500G大硬盘

几秒种分区格式化500G大硬盘近日陪好友去装机，在大容量硬盘盛行的今天，他毫不犹豫地选择了一块500GB的硬盘。看着他得意的眼神，我除了羡慕外，也暗自“窃喜”：这么大的容量，待会儿分区格式化够你受的！凭我的经验，500GB的硬盘分区格式化少则半个小时多则一个小时，再加上装系统的时间…… 所有硬件安装完毕后，装机人员在主板BIOS中设置好相关选项，这时我发现他并没有用常见的Fdisk、Format进行分区格式化，也不是用大名鼎鼎的PartitionMagic或DM，而是取出一张软盘在上面敲了一个命令（没看清），几秒钟后，重启计算机，500GB的硬盘已然分区格式化完毕，可以装系统了！我惊奇的看着他，难道有什么“特异软件”？！在随后与他的闲聊中，我“套”出了其中的“秘密”。其实，他用的根本不是什么专用软件，而是我们最常见的硬盘对拷工具：Ghost，再加上些技巧而已。由于Ghost具有克隆整块硬盘的功能，在还原备份时，Ghost会对目标盘按照被克隆硬盘的分区比例重新分配并复制文件。如果是新硬盘还将事先自动完成格式化。按照上述的原理，可用一块已分区格式化好的硬盘为“模板”（该硬盘不装任何文件），利用Ghost备份并还原到新硬盘上，这样就能快速对大硬盘分区格式化了。具体做法：找一块任意容量大小的硬盘，对它用Fdisk、Format按照你想要对大硬盘分区的比例分区格式化好，注意不要在上面安装任何文件；然后用带有Ghost程序的启动盘启动计算机，运行Ghost，利用“Local-Disk-To Image”命令将刚刚分区格式化好的硬盘镜像成一个软件，把这个文件保存在启动盘上（放心，这个文件应该很小），并起个名字如myfdisk.gho；接着，在启动盘上制作一个DOS批处理文件（用edit命令可编辑），内容为：ghost.exe-clone,mode=load,src=a:myfdisk.gho, dst=1，把它保存成bat文件，并起个名字如myfdisk.bat。这样以后哪个硬盘要分区格式化，用这张启动盘启动电脑，然后执行myfdisk.bat，用不了一分钟，不论多大的硬盘都可以顺利完成分区和格式化了。如果你想改变分区比例，只要修改myfdisk.bat文件就可以了，如分了4个区并想把比例变为1∶3∶3∶3，只需修改myfdisk.bat内容为：“ghost.exe-clone,mode=load,src=a:myfdisk.gho, dst=1,size1=10P,size2=30P,sze3=30P,sze4 =30P”即可。如果你还有更多的要求，还可在DOS状态下键入“ghost.exe -h”来查看命令帮助。当然，你也完全可以键入“ghost.exe”进入Ghsot的主界面来对镜像文件进行恢复操作，不过这样你就要多敲几次键了。我个人认为这种分区格式化的方法十分实用，特别适用于那些经常要分区格式化大容量硬盘的朋友，如装机商、电脑维修者、电脑发烧友等，因此写下此文，希望能对包括他们在内的所有电脑爱好者有所帮助。

Proe中的常用函数关系

Proe中的部分函数关系一、函数关系 sin 正弦Cos 余弦tan 正切asin 反正弦acos 反余弦atan 反正切sinh 双曲线余弦cosh 双曲线正弦tanh 双曲线正切spar 平方根exp e的幂方根abs 绝对值log 以10为底的对数ln 自然对数 ceil 不小于其值的最小整数floor 不超过其值的最大整数二、齿轮公式 alpha=20 m=2 z=30 c=0.25 ha=1 db=m*z*cos(alpha) r=(db/2)/cos(t*50) theta=(180/pi)*tan(t*50)-t*50 z=0 三、蜗杆的公式da=8为蜗杆外径m=0.8 为模数angle=20压力角 L=30长度q直径系数d分度圆直径f齿根圆直径n实数

其中之间的关系 q=da/m-2 d=q*m df=(q-2.4)*m n=ceil(2*l/(pi*m)) 在可变剖面扫描的时候运用公式sd4=trajpar*360*n 在扫描切口的时候绘制此图形,其中红色的高的计算公式是sd5=pi*m/2 五、方向盘的公式sd4=sd6*(1-(sin(trajpar*360*36)+1)/8) 其中sd4是sd6的（3/4或者7/8），sin(trajpar*360*36的意思是转过360度且有36个振幅似的六、凸轮的公式sd5=evalgraph("cam2",trajpar*360) r=150 theta=t*360 z=9*sin(10*t*360) 在方向按sin(10*t*360)的函数关系，9为高的9倍10为10个振幅似的七、锥齿轮公式 m=4模数z =50齿轮齿数z-am=40与之啮合的齿轮齿数angle=20压力角b=30齿厚long分度圆锥角 d分度圆直径da齿顶圆直径df齿根圆直径db基圆直径关系：long=atan(z/z-am) d=m*z da=d+2*m*cos(long)

硬盘分区与格式化教案(DOC)

江苏省徐州技师学院理论授课教案（首页）授课日期2016.11.7 2016.11.8 任课老师班级16程序2,16信管2 16程序1,16媒体赵启辉课程：计算机组装与维护课题：硬盘分区与格式化教学目的要求：1、使学生了解硬盘使用过程；2、使学生掌握硬盘分区的步骤；3、使学生掌握分区工具的使用方法；4、提高学生的动手能力及实际操作能力教学重点：掌握多种硬盘配置的方法。教学难点：掌握在不同的条件下对硬盘分区格式化的方法。授课方法：讲授法、列举法、引入法、分析法等教学参考及教具（含多媒体教学设备）投影、多媒体计算机授课执行情况及分析：板书设计或授课提纲 1、硬盘使用过程 2、硬盘分区的步骤 3、分区工具的使用方法

教学环节及时间分配教学内容教学方法组织教学10’ 讲授主课40’一、课前提问 1. 描述计算机主机的基本部件。 2. 组装计算机主机的步骤。二、导入新课在安装操作系统之前首先要对硬盘进行分区格式化。对硬盘分区格式化会破坏硬盘中的数据。所以在此之前一定要对硬盘中的数据进行备份。提问学生：你们是否有过对硬盘进行分区格式化操作的经验？你喜欢用什么方法对硬盘进行分区格式化？引导学生思考、回答并相互补充。教师总结归纳同学们的回答，进入教学课题。三、新课教学硬盘的分区与格式化 1 基本知识：硬盘的数据结构 1.1 硬盘的分区与格式化提问：硬盘的格式化有低级格式化和高级格式化两种，它们之间有什么区别？学生思考、看书、回答；教师总结：现在制造的硬盘在出厂时均做过低级格式化，用户一般不必重做。除非所用硬盘坏道较多或染上无法清除的病毒，不得不做一次低级格式化。低级格式化的主要目的是划分磁柱面（磁道），建立扇区数和选择扇区的间隔比，即为每个扇区标注地址和扇区头标志，并以硬盘能识别的方式进行数据编码。讲授多媒体教学

硬盘物理坏道隔离软件使用详解

硬盘物理坏道隔离软件使用详解硬盘是电脑极重要的一部分，所有的资料和数据都会保存在硬盘中，一旦硬盘出现错误，有时数据的损失会比整个电脑报废的损失还要大。不过，作为电脑的硬件之一，许多人总以为硬盘轻易不容易损坏，一旦坏了就是不能启动的情况，还有人认为坏道是很容易识别的，发现了用什么磁盘医生之类的软件修理就行了，再不行就低格吧!其实硬盘坏道，几乎可以称为硬盘的致命伤。笔者见识过许多因为延误时机，自己乱用各种软件修理，最后把偌大个硬盘整成一块废铁的例子。修理硬盘坏道对于逻辑坏道，我们可以修复，对于物理坏道，我们应采用隔离的办法，以最大程度减少损失，防止坏道进一步扩散为目标。我见过有些人在报纸上吹说用某个特殊软件能修理物理坏道，最要命的是许多人对低格硬盘的迷信，实在是误人之语。所谓低级格式化，指的是将空白的磁盘划分出柱面和磁道，然后再将磁道划分为若干个扇区，每个扇区又划分出标识部分ID、间隔区GAP和数据区DATA等。低级格式化只能在DOS环境下完成，而且只能针对—块硬盘而不能支持单独的某一个分区。有些坏磁道和坏扇区能够通过低级格式化来修复，但对于真正的硬盘磁盘表面物理划伤则无法进行修复，这只有通过各种办法标出坏扇区的位置，以便让操作系统不去使用，以防止扩大坏道进而延长硬盘使用。特别想强调，低级格式化是一种损耗性操作，对硬盘的寿命有一定的负面影响，所以，如无必要，用户们尽量不要低级格式化硬盘。对于逻辑坏道，一般情况下我们用操作系统自带的工具和一些专门的硬盘检查工具就能发现并修复。如：Windows自带的Scandisk磁盘扫描程序就是发现硬盘逻辑坏道最常用的工具，而我们常见的Format命令不能对任何硬盘坏道起到修补作用，这点大家要明白。我们可在Windows系统环境下，在“我的电脑”中选中要处理的硬盘盘符，选

教您如何修复硬盘坏道和低级格式化硬盘

教您如何修复硬盘坏道和低级格式化硬盘硬盘工作声音怪异电脑在打开、运行或拷贝某一文件、程序时，硬盘的操作速度相比以前变得很慢，并且长时间反复读盘，然后出错，或Windows提示“无法读取或无法写入文件”，严重时出现蓝屏等现象，打开机箱时可以听到硬盘读写的声音由原来的“嚓嚓”的摩擦声变为不正常的声音。使用系统下的硬盘扫描时出现红色的“B”的标记，格式化硬盘时，到某一进度停滞不前，最后报错退出。对硬盘用“Fdisk”命令进行分区时，到某一进度会反复进进退退，不能完成，询问朋友后得知可能是硬盘出现了坏道，但是不知道可不可以修复。首先应该确认硬盘的坏道是逻辑坏道还是物理坏道，方法很简单，使用启动盘启动到DOS下，执行“scandisk x:”（X为盘符），Scandisk 程序便会检查硬盘，对产生的逻辑坏道会自行弹出对话框，选择“Fix it”对逻辑坏道进行初级修复。如扫描程序在某一进度停滞不前，那么硬盘就有了物理坏道。逻辑坏道，小问题对于物理坏道，我们应采用隔离的办法，以最大程度减少损失，防止坏道进一步扩散为目，对于逻辑坏道，我们可以尝试修复一下，

看看能不能解决问题，逻辑坏道的修复相对简单，我们自己就可以进行了。正常启动后回到Windows下，进入“我的电脑”中选择有逻辑坏道的硬盘，单击鼠标右键，选择“属性”→“工具”→“开始检查”就弹出“磁盘扫描程序”，选中“完全”并将“自动修复错误”打上勾，单击“开始”，就开始对该分区进行扫描和修复。如果系统在启动时不进行磁盘扫描或已不能进入Windows系统，我们也可用软盘或光盘启动盘启动电脑后，在相应的盘符下，如“A：”下运行Scandisk *：(注：*为要扫描的硬盘盘符)，回车后来对相应需要扫描修复的硬盘分区进行修理，对于一般的逻辑坏道，以上方法基本上都是可以修复的。损失空间,求稳定如果是物理坏道的话可能要麻烦一点，但是如果硬盘还在保修的话，我么可以直接去找销售商解决，如果已经没有质保，那么就需要我们自己动手了，最常见要数分区魔术师软件修复了。通过对硬盘的重新分区，隐藏有物理坏道的硬盘空间，对其实行隔离。具体的作法：启动PM，选中“Operations”菜单下的“Check”命令，对硬盘进行直接扫描，标记坏簇后，选中“Operations”菜单下的“Advanced”→“bad sector retset”，最后把坏簇分成一个独立的分区，再通过“Hide partiton”命令将分区隐藏。

第三讲DOS环境下磁盘管理

第三讲DOS环境下磁盘管理本讲的目的；目标：磁盘管理命令 DOS命令对磁盘的管理编辑命令EDIT的使用重新定向命令理解msdos.sys配置文件教学的重点和难点：磁盘管理命令重新定向命令技巧 Edit命令的使用知识点回顾/习问题：文件管理命令回顾功能相似文件管理命令的区别比较文件管理和磁盘管理命令，区别不同一、磁盘格式化format 1．功能：对磁盘进行格式化，划分磁道和扇区；同时检查出整个磁盘上有无带缺陷的磁道，对坏道加注标记；建立目录区和文件分配表，使磁盘作好接收DOS的准备。 2．类型：外部命令 3．格式：formAT〈盘符：〉[/S][/4][/Q] 4．使用说明：（1）命令后的盘符不可缺省，若对硬盘进行格式化，则会如下列提示：WARNING:ALL DATA ON NON ——REMOVABLE DISK DRIVE C:WILL BE LOST ！ Proceed with format (Y/N)？（警告：所有数据在C盘上，将会丢失，确实要继续格式化吗？）（2）若是对软盘进行格式化，则会如下提示：Insert mew diskette for drive A; and press ENTER when ready… （在A驱中插入新盘，准备好后按回车键）。（3）选用[/S]参数，将把DOS系统文件IO.SYS 、MSDOS.SYS及https://www.wendangku.net/doc/9513840287.html,复制到磁盘上，使该磁盘可以做为DOS启动盘。若不选用/S参数，则格式化后的磙盘只能读写信息，而不能做为启动盘；（4）选用[/4]参数，在1.2MB的高密度软驱中格式化360KB的低密度盘；（5）选用[/Q]参数，快速格式化，这个参数并不会重新划分磁盘的磁道貌岸然和扇区，只能将磁盘根目录、文件分配表以及引导扇区清成空白，因此，格式化的速度较快。（6）选用[/u]参数，表示无条件格式化，即破坏原来磁盘上所有数据。不加/U，则为安全格式化，这时先建立一个镜象文件保存原来的FAT表和根目录，必要时可用UNFORRMAT恢复原来的数据。二、恢复格式化命令Unformat 1．功能：对进行过格式化误操作丢失数据的磁盘进行恢复。 2．类型：外部命令

高中常用函数性质及图像汇总

高中常用函数性质及图像一次函数（一）函数 1、确定函数定义域的方法：（1）关系式为整式时，函数定义域为全体实数；（2）关系式含有分式时，分式的分母不等于零；（3）关系式含有二次根式时，被开放方数大于等于零；（4）关系式中含有指数为零的式子时，底数不等于零；（5）实际问题中，函数定义域还要和实际情况相符合，使之有意义。（二）一次函数 1、一次函数的定义一般地，形如y kx b =+（k ，b 是常数，且0k ≠）的函数，叫做一次函数，其中x 是自变量。当0b =时，一次函数y kx =，又叫做正比例函数。 ⑴一次函数的解析式的形式是y kx b =+，要判断一个函数是否是一次函数，就是判断是否能化成以上形式． ⑵当0b =，0k ≠时，y kx =仍是一次函数． ⑶当0b =，0k =时，它不是一次函数． ⑷正比例函数是一次函数的特例，一次函数包括正比例函数． 2、正比例函数及性质一般地，形如y=kx(k 是常数，k≠0)的函数叫做正比例函数，其中k 叫做比例系数. 注：正比例函数一般形式 y=kx (k 不为零) ① k 不为零 ② x 指数为1 ③ b 取零当k>0时，直线y=kx 经过三、一象限，从左向右上升，即随x 的增大y 也增大；当k<0时，?直线y=kx 经过二、四象限，从左向右下降，即随x 增大y 反而减小． (1) 解析式：y=kx （k 是常数，k ≠0） (2) 必过点：（0，0）、（1，k ） (3) 走向：k>0时，图像经过一、三象限；k<0时，?图像经过二、四象限 (4) 增减性：k>0，y 随x 的增大而增大；k<0，y 随x 增大而减小 (5) 倾斜度：|k|越大，越接近y 轴；|k|越小，越接近x 轴 3、一次函数及性质一般地，形如y=kx ＋b(k,b 是常数，k≠0)，那么y 叫做x 的一次函数.当b=0时，y=kx ＋b 即y=kx ，所以说正比例函数是一种特殊的一次函数. 注：一次函数一般形式 y=kx+b (k 不为零) ① k 不为零 ②x 指数为1 ③ b 取任意实数一次函数y=kx+b 的图象是经过（0，b ）和（- k b ，0）两点的一条直线，我们称它为直线y=kx+b,它可以看作由直线y=kx 平移|b|个单位长度得到.（当b>0时，向上平移；当b<0时，向下平移）

Matlab之print,fprint,fscanf,disp函数的用法

print： print函数可以把函数图形保存成图片： minbnd = -4*pi; maxbnd = 4*pi; t = minbnd:0.1*pi:maxbnd; plot(t, sin(t), 'g', 'Linewidth', 2); line([minbnd, maxbnd], [0, 0]); %绘制x轴 axis([-10, 10, -2, 2]) %定义显示的坐标区间:x在(-10,10)之间，y在(-2,2)之间 grid on; title('sin(x)'); xlabel('x'); ylabel('sin(x)'); print('-dpng','sin.png'); %保存为png图片，在Matlab当前的工作目录下如下：打开Matlab当前的工作目录下可以看到有sin.png图片了 print('-dpng', 'sin.png')表示保存为png图片，文件名为sin.png，其中第一个参数可以是： -dbmp：保存为bmp格式 -djpeg：保存为jpeg格式 -dpng：保存为png格式 -dpcx：保存为pcx格式 -dpdf：保存为pdf格式 -dtiff：保存为tiff格式

fprintf： fprintf函数可以将数据按指定格式写入到文本文件中： data = [5, 1, 2; 3, 7, 4]; [row, col] = size(data); for i=1:row for j=1:col fprintf('data(%d, %d) = %d\n', i, j, data(i, j)); %直接输出到屏幕；类似于C语言的输出格式end end fprintf(fid, format, data)中的fid表示由fopen函数打开的文件句柄，如果fid 省略，则直接输出在屏幕上，format是字符串形式的输出格式，data是要输出的数据。其中format可以为： %c 单个字符 %d 有符号十进制数（%i也可以） %u 无符号十进制数 %f 浮点数（%8.4f表示对浮点数取8位宽度，同时4位小数） %o 无符号八进制数 %s 字符串 %x 小写a-f的十六进制数 %X 大小a-f的十六进制数输出到文件： data = [5, 1, 2; 3, 7, 4]; [row, col] = size(data); %求出矩阵data的行数和列数 %加t表示按Windows格式输出换行，即0xOD 0x0A，没有t表示按Linux格式输出换行，即0x0A fid=fopen('test.txt', 'wt'); %打开文件 for i=1:row

谈硬盘的低级格式化、填零、Erase、SelfScan

熟悉硬盘恢复的人都知道，在必要的时候需要对数据做"低级格式化"（下面简称"低格"）。进行低格所使用的工具也有多种：有用厂家专用设备做的低格，有用厂家提供的软件工具做的低格，有用DM工具做的低格，有用主板BIOS中的工具做的低格，有用Debug工具做的低格，还有用专业软件做低格...... 不同的工具所做的低格对硬盘修复的作用各不一样。有些人觉得低格可以修复一部分数据，有些人则觉得低格十分危险，会严重损害数据。本人用过多种低格工具，认为低格是修复数据的一个有效手段。下面总结一些关于低格的看法，与广大网友交流。大家关心的一个问题："低格过程到底对数据进行了什么操作？"实践表明低格过程有可能进行下列几项工作，不同的硬盘修复的低格过程相差很大，不同的软件的低格过程也相差很大。 A. 对扇区清零和重写校验值。低格过程中将每个扇区的所有字节全部置零，并将每个扇区的校验值也写回初始值，这样可以将部分缺陷纠正过来。譬如，由于扇区数据与该扇区的校验值不对应，通常就被报告为校验错误（ECC Error）。如果并非由于磁介质损伤，清零后就很有可能将扇区数据与该扇区的校验值重新对应起来，而达到"修复"该扇区的功效。这是每种低格工具和每种数据的低格过程最基本的操作内容，同时这也是为什么通过低格能"修复大量坏道"的基本原因。另外，DM中的Zero Fill（清零）操作与IBM DFT工具中的Erase操作，也有同样的功效。 B. 对扇区的标识信息重写。在多年以前使用的老式硬盘修复（如采用ST506接口的数据），需要在低格过程中重写每个扇区的标识（ID）信息和某些保留磁道的其他一些信息，当时低格工具都必须有这样的功能。但现在的数据结构已经大不一样，如果再使用多年前的工具来做低格会导致许多令人痛苦的意外。难怪经常有人在痛苦地高呼："危险！切勿低格硬盘修复！我的数据已经毁于低格！" C. 对扇区进行读写检查，并尝试替换缺陷扇区。有些低格工具会对每个扇区进行读写检查，如果发现在读过程或写过程出错，就认为该扇区为缺陷扇区。然后，调用通用的自动替换扇区（Automatic reallocation sector）指令，尝试对该扇区进行替换，也可以达到"修复"的功效。 D. 对所有物理扇区进行重新编号。编号的依据是P-list中的记录及区段分配参数（该参数决定各个磁道划分的扇区数），经过编号后，每个扇区都分配到一个特定的标识信息（ID）。编号时，会自动跳过P-list中所记录的缺陷扇区，使用户无法访问到那些缺陷扇区（用户不必在乎永远用不到的地方的好坏）。如果这个过程半途而废，有可能导致部分甚至所有扇区被报告为标识不对（Sector ID not found, IDNF）。要特别注意的是，这个编号过程是根据真正的物理参数来进行的，如果某些低格工具按逻辑参数（以 16heads 63sector为最典型）来进行低格，是不可能进行这样的操作。 E. 写磁道伺服信息，对所有磁道进行重新编号。有些硬盘修复允许将每个磁道的伺服信息重写，并给磁道重新赋予一个编号。编号依据P-list或TS记录来跳过缺陷磁道（defect

用Gdisk快速搞定大容量硬盘分区格式化

用Gdisk快速搞定大容量硬盘分区格式化发表：2004-6-5 6:05:21 出处：你的博客网(https://www.wendangku.net/doc/9513840287.html,) ▲▲用Gdisk快速搞定大容量硬盘分区格式化▲▲ 假设是一块80GB的新硬盘，主分区为5GB，扩展分区依次划为4个逻辑盘：10GB、10GB、20GB、35GB。我们可以做成这样一个批处理文件： gdisk 1 /cre /pri /sz:5000 /for /q gdisk 1 /cre /ext gdisk 1 /cre /log /sz:10000/for /q gdisk 1 /cre /log /sz:10000 /for /q gdisk 1 /cre /log /sz:20000/for /q gdisk 1 /cre /log /for /q 这样一张快速分区格式化磁盘的工具盘就做好了。将新硬盘挂到电脑上(注意哟，一定要挂在主板第一个IDE接口上，因为我们指定的硬盘号为1，否则就需要修改批处理文件)，设置好从A盘启动。插入刚刚做好的工具盘，启动，执行批处理文件FD.bat。瞧瞧吧，再也不需要漫长的格式化等待了，不要你烦心，海量硬盘分区、格式化立马搞定。硬盘容量不同，我们只需修改批处理文件中分区的个数和每个分区容量大小就可以同样轻松搞定。如果是手头已有的硬盘想重新安排分区、格式化，只需先执行一下下列命令： gdisk /del /all (删除所有硬盘分区)。再执行分区格式化批处理命令，同样不需要花多少时间即可重新搞定。不过在动手之前一定要把硬盘上重要的数据备份出来，不然，两三分钟后可就欲哭无泪了。参数说明： 1——指的是第一块硬盘。如果挂有多块硬盘，就要相应的指明其硬盘号1、2…… /cre——当前工作模式为创建分区 /pri——创建主分区 /sz:5000——创建分区大小为5000MB即5GB。 /for——格式化磁盘 /q——快速格式化磁盘(这是Gdisk.exe的一大优势所在，新分区的硬盘一样可以快速格式化，这可是Windows 9x系列自带的format命令所望尘莫及的哟)。 /ext——创建扩展分区 /log——创建逻辑分区自定义分区大小，请键入gdisk [参数]5GB---5000 gdisk 1 /cre /pri /sz:%1 /for /q gdisk 1 /cre /ext gdisk 1 /cre /log /sz:%2 /for /q gdisk 1 /cre /log /sz:%3 /for /q gdisk 1 /cre /log /sz:%4 /for /q gdisk 1 /cre /log /sz:%5 /for /q gdisk 1 /cre /log /sz:%6 /for /q gdisk 1 /cre /log /sz:%7 /for /q gdisk 1 /cre /log /sz:%8 /for /q

全面认识硬盘格式化详解硬盘低格操作方法

在以前的文章中，我们曾向朋友们介绍了一些硬盘的使用技巧及维护保养方法，相信朋友们还记得曾给大家介绍过一篇关于硬盘坏道的文章吧。详细请点击《从保养做起解析硬盘坏道的原因及修复办法》，在这篇文章中，我们曾向大家介绍了硬盘坏道的一些简单的修复方法，其中提到了对硬盘的低级格式化的一些内容。也许有很多朋友会将DOS中利用FORMAT命令对硬盘进行格式化当成了是对硬盘的低级格式化过程。其实这样看法是错误的。那么今天通过本文朋友介绍一下硬盘的低级格式化的一些常识、低格格式化过程及与高级格式化的区别。一、认识硬盘格式化 “格式化”这个词对于一个电脑用户而言绝对不应该陌生。当我们在进行一个全新的WINDOWS安装时，或是对一个硬盘上的所有数据进行“干净”的处理时，往往都会祭出“格式化”这招“杀手锏”，来彻底清除硬盘各个分区上的数据。“硬盘格式化目前可以在WINDOWS和DOS两种不同环境下进行。一般我们在进行全新安装操作系统时会使用DOS下的“FORMAT”命令来完成系统盘的格式化，而单独对除系统盘以外的其它分区进行格式化时，我们一般会在WINDOWS下来完成，而在Windows下的操作会更加简单，只需要在对需要格式化的硬盘上右击鼠标，选择“格式化”选项即可，选择快速格式化，所需耗费的时间则更短。虽然两者的操作方式和格式化所需的时间都有所不同。但它们实际上都是对硬盘进行同一种操作，那就是清除硬盘上的数据、生成引导区信息、初始化FAT表、标注逻辑坏道等。我们将这些操作统称为“高级格式化”。认识了硬盘的“高级格式化”，那么我们再来看一下硬盘的低级化过程。所谓低级格式化，就是将空白的磁盘划分出柱面和磁道，再将磁道划分为若干个扇区，每个扇区又划分出标识部分ID、间隔区GAP和数据区DATA等。硬盘的低级格式化是高级格式化之前的一件工作，目前所有硬盘厂商在产品出厂前，已经对硬盘进行了低格化的处理，因此我们新购买的硬盘在装系统时只需要进行高级格化的过程，来初始化FAT表，进行分区操作。与高级格式化操作不同的是，硬盘的低级格式化过程只能够在DOS环境来完成。我们在DOS下对一张软盘进行全面格式化操作的过程便可以看作是对软盘的低级格式化。需要说明的是，硬盘的低级格式化过程是一种损耗性操作，对硬盘的使用寿命会产生一定的负面作用。因此，除非是硬盘出现了较大的错误，如硬盘坏道等，否则一定要慎重低级格式化操作。当硬盘受到外部强磁体、强磁场的影响，或因长期使用，硬盘盘片上由低级格式化划分出来的扇区格式磁性记录部分丢失，从而出现大量“坏扇区”时，可以通过低级格式化来重新划分“扇区”。但是前提是硬盘的盘片没有受到物理性划伤。笔者认为，只有在硬盘多次分区均告失败或在高级格式化中发现大量“坏道”时，方可通过低级格式化来进行修复。而硬盘的硬性损伤，如硬盘出现物理坏道时，则是无法通过低级格式化来修复的。可以想象当一张软盘的盘片表面被划伤之后，还能修复吗？二、低级格式化对硬盘所做的操作有不少朋友会问，硬盘的低级化过程到底对硬盘做了那些操作呢？因为硬盘的低级格式化过程是借助第三方软件来实现的，因此不同的软件对硬盘所做操作也会不尽相同，总结归纳一下，硬盘的低级格式化过程主要是对硬盘做了以下几项工作。

Excel常用函数详解

计算机二级考试MS_Office应用Excel函数 =公式名称（参数1，参数2，。。。。。） =sum(计算范围) =average(计算范围) =sumifs(求和范围，条件范围1，符合条件1，条件范围2，符合条件2，。。。。。。) =vlookup(翻译对象，到哪里翻译，显示哪一种，精确匹配) =rank(对谁排名，在哪个范围里排名) =max(范围) =min(范围) =index(列范围，数字) =match(查询对象，范围，0) =mid(要截取的对象，从第几个开始，截取几个) =int(数字) =weekda y(日期，2) =if(谁符合什么条件，符合条件显示的内容，不符合条件显示的内容) =if(谁符合什么条件，符合条件显示的内容，if(谁符合什么条件，符合条件显示的内容，不符合条件显示的内容)) SUM函数简单求和。函数用法 SUM(number1,[number2],…) =SUM(A1:A5)是将单元格 A1 至 A5 中的所有数值相加； =SUM(A1,A3,A5)是将单元格 A1,A3,A5 中的数字相加。 SUMIFS函数根据多个指定条件对若干单元格求和。函数用法 SUMIFS(sum_range, criteria_range1, criteria1, [criteria_range2, criteria2], ...) 1） sum_range 是需要求和的实际单元格。包括数字或包含数字的名称、区域或单元格引用。忽略空白值和文本值。 2) criteria_range1为计算关联条件的第一个区域。 3) criteria1为条件1，条件的形式为数字、表达式、单元格引用或者文本，可用来定义将对criteria_range1参数中的哪些单元格求和。例如，条件可以表示为32、“>32”、B4、"苹果"、或"32"。 4）criteria_range2为用于条件2判断的单元格区域。 5) criteria2为条件2，条件的形式为数字、表达式、单元格引用或者文本，可用来定义将对criteria_range2参数中的哪些单元格求和。 4）和5）最多允许127个区域/条件对，即参数总数不超255个。 VLOOKUP函数是Excel中的一个纵向查找函数，按列查找，最终返回该列所需查询列序所对应的值。

Creo常用函数

Creo（PROE）中关系式的理解一）关系式中可以用下列数学函数式表达： 1）、正弦 sin( ) 2）、余弦 cos( ) 3)、正切 tan( ) 4)、反正弦 asin( ) 5)、反余弦 acos( ) 6)、反正切 atan( ) 7)、双曲线正弦 sinh( ) 8)、双曲线余弦 cosh( ) 9)、双曲线正切 tanh( ) 以上九种三角函数式所使用的单位均为“度”。 10）、平方根 sqrt( ) 11)、以10为底的对数 log( ) 12)、自然对数 ln( ) 13)、e的幂 exp( ) 14)、绝对值 abs( ) 15)、不小于其值的最小整数（上限值） ceil( ) 16)、不超过其值的最大整数（下限值） floor( ) 可以给函数ceil和floor加一个可选的自变量，用它指定要圆整的小数位数。带有圆整参数的这些函数的语法是： ceil(parameter_name或number, number_of_dec_places) floor (parameter_name 或 number, number_of_dec_places) 其中的parameter_name或number意为参数名称或者一个带小数位的精确数值后面跟随着的number_of_dec_places意为十进位的小数位数，是可选值： A）可以被表示为一个数或一个使用者自定义参数。如果该参数值是一个实数，则被截尾成为一个整数。 B）它的最大值是8。如果超过8，则不会舍入要舍入的数（第一个自变量），并使用其初值。C）如果不指定它，则功能同前期版本一样。使用不指定小数部分位数的ceil和floor函数，其举例如下： ceil (10.2) 值为11 floor (10.2) 值为 10

关系中常用函数详解

在ProE中，我们的关系可以直接很多系统已经预定义好的函数，通过这些函数我们可以来进行一些特定的运算得到所期望的值，下面我们就对一些常用函数进行一个概括和总结，方便大家在使用的时候查阅。 1.数学函数在proe中，我们可以使用丰富的数学函数，常用的函数列表如下： sin()、cos()、tan()函数这三个都是数学上的三角函数，分别使用角度的度数值来求得角度对应的正弦、余弦和正切值，比如： A=sin(30) A=0.5? B=0.866?B=cos(30) ?C=tan(30) C=0.577 asin()、acos()、atan()函数这三个是上面三个三角函数的反函数，通过给定的实数值求得对应的角度值，如：A=asin(0.5) A=30? B=60?B=acos(0.5) C=26.6?C=atan(0.5)

sinh()、cosh()、tanh()函数在数学中，双曲函数类似于常见的（也叫圆函数的）三角函数。基本双曲函数是双曲正弦“sinh”，双曲余弦“cosh”，从它们导出双曲正切“tanh”等。 sinh / 双曲正弦：sinh(x) = [e^x - e^(-x)] / 2 cosh / 双曲余弦：cosh(x) = [e^x + e^(-x)] / 2 tanh / 双曲正切：tanh(x) = sinh(x) / cosh(x)=[e^x - e^(-x)] / [e^x + e^(-x)] 函数使用实数作为输入值 log()函数求得10为底的对数值，如： A=log(1) A=0;? A=1;?A=log(10) ?A=log(5) A=0.6989...; ln()函数求得以自然数e为底的对数值，e是自然数，值是2.718...;如： A=ln(1) A=0;? ?A=ln(5) A=1.609...;

手把手教你硬盘分区格式化

手把手教你硬盘分区格式化你从商场买来的硬盘并不能直接使用，必须对它进行分区并进行格式化的才能储存数据。如果把新买来的硬盘比喻成白纸，你要把它变成写文章的稿纸的话，分区就好像给它规定可以写字的范围，格式化就好像给它画出写每一个字的格子。在建立磁盘区以前，你必须对“物理磁盘(Phys-ical Disk)”和“逻辑磁盘(Logical Disk)”有点概念才行。物理磁盘就是你购买的磁盘实体，逻辑磁盘则是经过分割所建立的磁盘区。如果你在一个物理磁盘上建立了3个磁盘区，每一个磁盘区就是一个逻辑磁盘，你的物理硬盘上就存在了3个逻辑磁盘。在建立分区以前，最好先规划你要如何配置，也就是要先解决以下问题: 1.这个硬盘要分割成几个区？ 2.每个分区占有大多的容量？ 3.每个分区都使用什么文件系统？要分割成几个分区以及第一个分区所占有的容量，取决于使用者自己的想法，有些人喜欢将整个硬盘规划单一分区，有些人则认为分割成几个分区比较利于管理。例如，分割成两个分区，一个储存操作系统文件，另一个储存应用程序文件;或者一个储存操作系统和应用程序档案，另一个储存个人和备份的资料。至于分区所使用的文件系统，则取决于你要安装的操作系统，操作系统分区所能使用的文件系统如表一所示。如果你要安装的是Windows 98，可以选择的文件系统则有FAT16和 FAT32，使用FAT16的分区大小不能超过2GB，而且会浪费较多的硬盘空间。如果你打算执行一些DOS工具程序，可以考虑将操作系统分区规划成FAT16文件系统，如果没有特别的打算，还是建议使用FAT32文件系统。整块硬盘规划成单一分区的做法 1、使用Windows 98的启动盘开机，选择开机选单的第一个选项。 2、在DOS命令行输入“fdisk”，按下Enter键执行。 3、屏幕上出现信息问你是否要启用FAT32支持，回答“Y”会建立FAT32分区，回答“N”则会使用FAT16,决定以后按Enter键。

初中常用函数及其性质

一.正比例函数的性质 1.定义域：R（实数集） 2.值域：R（实数集） 3.奇偶性：奇函数 4.单调性：当k>0时，图像位于第一、三象限，y随x的增大而增大（单调递增）；当k<0时，图像位于第二、四象限，y随x的增大而减小（单调递减） 5.周期性：不是周期函数。 6.对称轴：直线，无对称轴。、二.一次函数图像和性质一般地，形如y=kx+b（k、b是常数，且k≠0?）的函数，?叫做一次函数（?linear function）．一次函数的定义域是一切实数. 当b=0时，y=kx+b即y=kx（k是常数，且k≠0?）．所以说正比例函数是一种特殊的一次函数. 当k=0时，y等于一个常数，这个常数用c来表示，一般地，我们把函数y=c（c是常数）叫做常值函数（constant function）它的定义域由所讨论的问题确定．一般来说, 一次函数y=kx+b(其中k、b是常数,且k≠0)的图像是一条直线. 一次函数y=kx+b的图像也称为直线y=kx+b. 一次函数解析式y=kx+b称为直线的表达式. 一条直线与y轴的交点的纵坐标叫做这条直线在y轴上的截距，简称直线的截距. 一般地，直线y=kx+b(k0)与y轴的交点坐标是(0,b).直线y=kx+b(k0)的截距是b. 一次函数的图像： k>0 b>0 函数经过一、三、二象限 k>0 b<0 函数经过一、二、三象限 k<0 b>0 函数经过一、二、四象限

k<0 b<0 函数经过二、三、四象限上面性质反之也成立 1．b 的作用在坐标平面上画直线y=kx+b (k≠0)，截距b 相同的直线经过同一点(0,b). 2．k 的作用 k 值不同，则直线相对于x 轴正方向的倾斜程度不同. (1)k>0时，K 值越大，倾斜角越大 (2)k<0时，K 值越大，倾斜角越大说明（1）倾斜角是指直线与x 轴正方向的夹角；（2）常数k 称为直线的斜率.关于斜率的确切定义和几何意义，将在高中数学中讨论. 3．直线平移一般地，一次函数y=kx+b(b0)的图像可由正比例函数y=kx 的图像平移得到.当b>0时，向上平移b 个单位；当b<0时，向下平移|b|个单位. 4．直线平行如果k1=k2 ,b1b2，那么直线y=k1x+b1与直线y=k2x+b2平行. 如果直线y=k1x+b1与直线y=k2x+b2平行，那么k1=k2 ,b1b2 . 1．一次函数与一元一次方程的关系一次函数 y=kx+b 的图像与x 轴交点的横坐标就是一元一次方程kx+b=0的解；反之，一元一次方程kx+b=0的解就是一次函数 y=kx+b 的图像与x 轴交点的横坐标.两者有着密切联系,体现数形结合的数学思想. 2．一次函数与一元一次不等式的关系由一次函数 y=kx+b 的函数值y 大于0（或小于0），就得到关于x 的一元一次不等式kx+b>0（或kx+b<0）.在一次函数 y=kx+b 的图像上且位于x 轴上方(或下方)的所有点,它们的横坐标的取值范围就是不等式kx+b>0（或kx+b<0）的解. 三.二次函数图像及其性质 1.定义：一般地，如果c b a c bx ax y ,,(2 ++=是常数，)0≠a ，那么y 叫做x 的一元二次函数. 2.二次函数2 ax y =的性质 (1)抛物线2ax y =）（0≠a 的顶点是原点，对称轴是y 轴. (2)函数2ax y =的图像与a 的符号关系： ①当0>a 时?抛物线开口向上?顶点为其最低点；②当0