搜档网
当前位置:搜档网 › rfc3557.RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Stand

rfc3557.RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Stand

rfc3557.RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Stand
rfc3557.RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Stand

Network Working Group Q. Xie, Ed. Request for Comments: 3557 Motorola, Inc. Category: Standards Track July 2003 RTP Payload Format for

European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding

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. Copyright Notice

Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract

This document specifies an RTP payload format for encapsulating

European Telecommunications Standards Institute (ETSI) European

Standard (ES) 201 108 front-end signal processing feature streams for distributed speech recognition (DSR) systems.

Xie Standards Track [Page 1]

Table of Contents

1. Conventions and Acronyms . . . . . . . . . . . . . . . . . . . 2

2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. ETSI ES 201 108 DSR Front-end Codec. . . . . . . . . . . 3

2.2. Typical Scenarios for Using DSR Payload Format . . . . . 4

3. ES 201 108 DSR RTP Payload Format. . . . . . . . . . . . . . . 5 3.1. Consideration on Number of FPs in Each RTP Packet. . . . 6

3.2. Support for Discontinuous Transmission . . . . . . . . . 6

4. Frame Pair Formats . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Format of Speech and Non-speech FPs. . . . . . . . . . . 7 4.2. Format of Null FP. . . . . . . . . . . . . . . . . . . . 8

4.3. RTP header usage . . . . . . . . . . . . . . . . . . . . 8

5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 9

5.1. Mapping MIME Parameters into SDP . . . . . . . . . . . . 10

6. Security Considerations. . . . . . . . . . . . . . . . . . . . 11

7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11

8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 11

9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11

9.2. Informative References . . . . . . . . . . . . . . . . . 12

10. IPR Notices. . . . . . . . . . . . . . . . . . . . . . . . . . 12

11. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 13

12. Editor’s Address . . . . . . . . . . . . . . . . . . . . . . . 14

13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 1. Conventions and Acronyms

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

The following acronyms are used in this document:

DSR - Distributed Speech Recognition

ETSI - the European Telecommunications Standards Institute

FP - Frame Pair

DTX - Discontinuous Transmission

2. Introduction

Motivated by technology advances in the field of speech recognition, voice interfaces to services (such as airline information systems,

unified messaging) are becoming more prevalent. In parallel, the

popularity of mobile devices has also increased dramatically.

Xie Standards Track [Page 2]

However, the voice codecs typically employed in mobile devices were

designed to optimize audible voice quality and not speech recognition accuracy, and using these codecs with speech recognizers can result

in poor recognition performance. For systems that can be accessed

from heterogeneous networks using multiple speech codecs, recognition system designers are further challenged to accommodate the

characteristics of these differences in a robust manner. Channel

errors and lost data packets in these networks result in further

degradation of the speech signal.

In traditional systems as described above, the entire speech

recognizer lies on the server. It is forced to use incoming speech

in whatever condition it arrives after the network decodes the

vocoded speech. To address this problem, we use a distributed speech recognition (DSR) architecture. In such a system, the remote device acts as a thin client, also known as the front-end, in communication with a speech recognition server, also called a speech engine. The

remote device processes the speech, compresses the data, and adds

error protection to the bitstream in a manner optimal for speech

recognition. The speech engine then uses this representation

directly, minimizing the signal processing necessary and benefiting

from enhanced error concealment.

To achieve interoperability with different client devices and speech engines, a common format is needed. Within the "Aurora" DSR working group of the European Telecommunications Standards Institute (ETSI), a payload has been defined and was published as a standard [ES201108] in February 2000.

For voice dialogues between a caller and a voice service, low latency is a high priority along with accurate speech recognition. While

jitter in the speech recognizer input is not particularly important, many issues related to speech interaction over an IP-based connection are still relevant. Therefore, it is desirable to use the DSR

payload in an RTP-based session.

2.1 ETSI ES 201 108 DSR Front-end Codec

The ETSI Standard ES 201 108 for DSR [ES201108] defines a signal

processing front-end and compression scheme for speech input to a

speech recognition system. Some relevant characteristics of this

ETSI DSR front-end codec are summarized below.

The coding algorithm, a standard mel-cepstral technique common to

many speech recognition systems, supports three raw sampling rates: 8 kHz, 11 kHz, and 16 kHz. The mel-cepstral calculation is a frame-

based scheme that produces an output vector every 10 ms.

Xie Standards Track [Page 3]

After calculation of the mel-cepstral representation, the

representation is first quantized via split-vector quantization to

reduce the data rate of the encoded stream. Then, the quantized

vectors from two consecutive frames are put into an FP, as described in more detail in Section 4.1.

2.2 Typical Scenarios for Using DSR Payload Format

The diagrams in Figure 1 show some typical use scenarios of the ES

201 108 DSR RTP payload format.

+--------+ +----------+

|IP USER | IP/UDP/RTP/DSR |IP SPEECH |

|TERMINAL|-------------------->| ENGINE |

| | | |

+--------+ +----------+

a) IP user terminal to IP speech engine

+--------+ DSR over +-------+ +----------+

| Non-IP | Circuit link | | IP/UDP/RTP/DSR |IP SPEECH |

| USER |:::::::::::::::>|GATEWAY|--------------->| ENGINE |

|TERMINAL| ETSI payload | | | |

+--------+ format +-------+ +----------+

b) non-IP user terminal to IP speech engine via a gateway

+--------+ +-------+ DSR over +----------+

|IP USER | IP/UDP/RTP/DSR | | circuit link | Non-IP |

|TERMINAL|----------------->|GATEWAY|::::::::::::::::>| SPEECH |

| | | | ETSI payload | ENGINE |

+--------+ +-------+ format +----------+

c) IP user terminal to non-IP speech engine via a gateway

Figure 1: Typical Scenarios for Using DSR Payload Format.

For the different scenarios in Figure 1, the speech recognizer always resides in the speech engine. A DSR front-end encoder inside the

User Terminal performs front-end speech processing and sends the

resultant data to the speech engine in the form of "frame pairs"

(FPs). Each FP contains two sets of encoded speech vectors

representing 20ms of original speech.

Xie Standards Track [Page 4]

3. ES 201 108 DSR RTP Payload Format

An ES 201 108 DSR RTP payload datagram consists of a standard RTP

header [RFC3550] followed by a DSR payload. The DSR payload itself

is formed by concatenating a series of ES 201 108 DSR FPs (defined in Section 4).

FPs are always packed bit-contiguously into the payload octets

beginning with the most significant bit. For ES 201 108 front-end,

the size of each FP is 96 bits or 12 octets (see Sections 4.1 and

4.2). This ensures that a DSR payload will always end on an octet

boundary.

The following example shows a DSR RTP datagram carrying a DSR payload containing three 96-bit-long FPs (bit 0 is the MSB):

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

\ \

/ RTP header in [RFC3550] /

\ \

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

| |

+ +

| FP #1 (96 bits) |

+ +

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

+ +

| FP #2 (96 bits) |

+ +

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

+ +

| FP #3 (96 bits) |

+ +

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2. An example of an ES 201 108 DSR RTP payload.

Xie Standards Track [Page 5]

3.1 Consideration on Number of FPs in Each RTP Packet

The number of FPs per payload packet should be determined by the

latency and bandwidth requirements of the DSR application using this payload format. In particular, using a smaller number of FPs per

payload packet in a session will result in lowered bandwidth

efficiency due to the RTP/UDP/IP header overhead, while using a

larger number of FPs per packet will cause longer end-to-end delay

and hence increased recognition latency. Furthermore, carrying a

larger number of FPs per packet will increase the possibility of

catastrophic packet loss; the loss of a large number of consecutive

FPs is a situation most speech recognizers have difficulty dealing

with.

It is therefore RECOMMENDED that the number of FPs per DSR payload

packet be minimized, subject to meeting the application’s

requirements on network bandwidth efficiency. RTP header compression techniques, such as those defined in [RFC2508] and [RFC3095], should be considered to improve network bandwidth efficiency.

3.2 Support for Discontinuous Transmission

The DSR RTP payloads may be used to support discontinuous

transmission (DTX) of speech, which allows that DSR FPs are sent only when speech has been detected at the terminal equipment.

In DTX a set of DSR frames coding an unbroken speech segment

transmitted from the terminal to the server is called a transmission segment. A DSR frame inside such a transmission segment can be

either a speech frame or a non-speech frame, depending on the nature of the section of the speech signal it represents.

The end of a transmission segment is determined at the sending end

equipment when the number of consecutive non-speech frames exceeds a pre-set threshold, called the hangover time. A typical value used

for the hangover time is 1.5 seconds.

After all FPs in a transmission segment are sent, the front-end

SHOULD indicate the end of the current transmission segment by

sending one or more Null FPs (defined in Section 4.2).

Xie Standards Track [Page 6]

4. Frame Pair Formats

4.1 Format of Speech and Non-speech FPs

The following mel-cepstral frame MUST be used, as defined in

[ES201108]:

As defined in [ES201108], pairs of the quantized 10ms mel-cepstral

frames MUST be grouped together and protected with a 4-bit CRC,

forming a 92-bit long FP:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Frame #1 (44 bits) |

+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| | Frame #2 (44 bits) |

+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+

| | CRC |0|0|0|0|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The length of each frame is 44 bits representing 10ms of voice. The

following mel-cepstral frame formats MUST be used when forming an FP: Frame #1 in FP:

===============

(MSB) (LSB)

0 1 2 3 4 5 6 7

+-----+-----+-----+-----+-----+-----+-----+-----+

: idx(2,3) | idx(0,1) | Octet 1

+-----+-----+-----+-----+-----+-----+-----+-----+

: idx(4,5) | idx(2,3) (cont) : Octet 2

+-----+-----+-----+-----+-----+-----+-----+-----+

| idx(6,7) |idx(4,5)(cont) Octet 3

+-----+-----+-----+-----+-----+-----+-----+-----+

idx(10,11) | idx(8,9) | Octet 4

+-----+-----+-----+-----+-----+-----+-----+-----+

: idx(12,13) | idx(10,11) (cont) : Octet 5

+-----+-----+-----+-----+-----+-----+-----+-----+

| idx(12,13) (cont) : Octet 6/1

+-----+-----+-----+-----+

Xie Standards Track [Page 7]

Frame #2 in FP:

===============

(MSB) (LSB)

0 1 2 3 4 5 6 7

+-----+-----+-----+-----+

: idx(0,1) | Octet 6/2

+-----+-----+-----+-----+-----+-----+-----+-----+

| idx(2,3) |idx(0,1)(cont) Octet 7

+-----+-----+-----+-----+-----+-----+-----+-----+

: idx(6,7) | idx(4,5) | Octet 8

+-----+-----+-----+-----+-----+-----+-----+-----+

: idx(8,9) | idx(6,7) (cont) : Octet 9

+-----+-----+-----+-----+-----+-----+-----+-----+

| idx(10,11) |idx(8,9)(cont) Octet 10

+-----+-----+-----+-----+-----+-----+-----+-----+

| idx(12,13) | Octet 11

+-----+-----+-----+-----+-----+-----+-----+-----+

Therefore, each FP represents 20ms of original speech. Note, as

shown above, each FP MUST be padded with 4 zeros to the end in order to make it aligned to the 32-bit word boundary. This makes the size of an FP 96 bits, or 12 octets. Note, this padding is separate from padding indicated by the P bit in the RTP header.

The 4-bit CRC MUST be calculated using the formula defined in 6.2.4

in [ES201108]. The definition of the indices and the determination of their value are also described in [ES201108].

4.2 Format of Null FP

A Null FP for the ES 201 108 front-end codec is defined by setting

the content of the first and second frame in the FP to null (i.e.,

filling the first 88 bits of the FP with 0’s). The 4-bit CRC MUST be calculated the same way as described in 6.2.4 in [ES201108], and 4

zeros MUST be padded to the end of the Null FP to make it 32-bit word aligned.

4.3 RTP header usage

The format of the RTP header is specified in [RFC3550]. This payload format uses the fields of the header in a manner consistent with that specification.

The RTP timestamp corresponds to the sampling instant of the first

sample encoded for the first FP in the packet. The timestamp clock

frequency is the same as the sampling frequency, so the timestamp

unit is in samples.

Xie Standards Track [Page 8]

As defined by ES 201 108 front-end codec, the duration of one FP is

20 ms, corresponding to 160, 220, or 320 encoded samples with

sampling rate of 8, 11, or 16 kHz being used at the front-end,

respectively. Thus, the timestamp is increased by 160, 220, or 320

for each consecutive FP, respectively.

The DSR payload for ES 201 108 front-end codes is always an integral number of octets. If additional padding is required for some other

purpose, then the P bit in the RTP in the header may be set and

padding appended as specified in [RFC3550].

The RTP header marker bit (M) should be set following the general

rules defined in [RFC3551].

The assignment of an RTP payload type for this new packet format is

outside the scope of this document, and will not be specified here.

It is expected that the RTP profile under which this payload format

is being used will assign a payload type for this encoding or specify that the payload type is to be bound dynamically.

5. IANA Considerations

One new MIME subtype registration is required for this payload type, as defined below.

This section also defines the optional parameters that may be used to describe a DSR session. The parameters are defined here as part of

the MIME subtype registration. A mapping of the parameters into the Session Description Protocol (SDP) [RFC2327] is also provided in 5.1 for those applications that use SDP.

Media Type name: audio

Media subtype name: dsr-es201108

Required parameters: none

Optional parameters:

rate: Indicates the sample rate of the speech. Valid values include: 8000, 11000, and 16000. If this parameter is not present, 8000

sample rate is assumed.

maxptime: The maximum amount of media which can be encapsulated in

each packet, expressed as time in milliseconds. The time shall be calculated as the sum of the time the media present in the packet represents. The time SHOULD be a multiple of the frame pair size (i.e., one FP <-> 20ms).

Xie Standards Track [Page 9]

If this parameter is not present, maxptime is assumed to be 80ms. Note, since the performance of most speech recognizers are

extremely sensitive to consecutive FP losses, if the user of the

payload format expects a high packet loss ratio for the session,

it MAY consider to explicitly choose a maxptime value for the

session that is shorter than the default value.

ptime: see RFC2327 [RFC2327].

Encoding considerations : This type is defined for transfer via RTP

[RFC3550] as described in Sections 3 and 4 of RFC 3557.

Security considerations : See Section 6 of RFC 3557.

Person & email address to contact for further information:

Qiaobing.Xie@https://www.sodocs.net/doc/d65132334.html,

Intended usage: COMMON. It is expected that many VoIP applications

(as well as mobile applications) will use this type.

Author/Change controller:

Qiaobing.Xie@https://www.sodocs.net/doc/d65132334.html,

IETF Audio/Video transport working group

5.1 Mapping MIME Parameters into SDP

The information carried in the MIME media type specification has a

specific mapping to fields in the Session Description Protocol (SDP) [RFC2327], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing ES 201 018 DSR codec, the

mapping is as follows:

o The MIME type ("audio") goes in SDP "m=" as the media name.

o The MIME subtype ("dsr-es201108") goes in SDP "a=rtpmap" as the

encoding name.

o The optional parameter "rate" also goes in "a=rtpmap" as clock

rate.

o The optional parameters "ptime" and "maxptime" go in the SDP

"a=ptime" and "a=maxptime" attributes, respectively.

Xie Standards Track [Page 10]

Example of usage of ES 201 108 DSR:

m=audio 49120 RTP/AVP 101

a=rtpmap:101 dsr-es201108/8000

a=maxptime:40

6. Security Considerations

Implementations using the payload defined in this specification are

subject to the security considerations discussed in the RTP

specification [RFC3550] and the RTP profile [RFC3551]. This payload does not specify any different security services.

7. Contributors

The following individuals contributed to the design of this payload

format and the writing of this document: Q. Xie (Motorola), D. Pearce (Motorola), S. Balasuriya (Motorola), Y. Kim (VerbalTek), S. H. Maes (IBM), and, Hari Garudadri (Qualcomm).

8. Acknowledgments

The design presented here benefits greatly from an earlier work on

DSR RTP payload design by Jeff Meunier and Priscilla Walther. The

authors also wish to thank Brian Eberman, John Lazzaro, Magnus

Westerlund, Rainu Pierce, Priscilla Walther, and others for their

review and valuable comments on this document.

9. References

9.1 Normative References

[ES201108] European Telecommunications Standards Institute (ETSI)

Standard ES 201 108, "Speech Processing, Transmission

and Quality Aspects (STQ); Distributed Speech

Recognition; Front-end Feature Extraction Algorithm;

Compression Algorithms," Ver. 1.1.2, April 11, 2000.

[RFC3550] Schulzrinne, H., Casner, S., Jacobson, V. and R.

Frederick, "RTP: A Transport Protocol for Real-Time

Applications", RFC 3550, July 2003.

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

Requirement Levels", BCP 14, RFC 2119, March 1997.

Xie Standards Track [Page 11]

[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description

Protocol", RFC 2327, April 1998.

9.2 Informative References

[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio

and Video Conferences with Minimal Control", RFC 3551,

July 2003.

[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP

Headers for Low-Speed Serial Links", RFC 2508, February 1999.

[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,

H., Hannu, H., Jonsson, L-E, Hakenberg, R., Koren, T.,

Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust

Header Compression (ROHC): Framework and four profiles", RFC 3095, July 2001.

10. IPR Notices

The IETF takes no position regarding the validity or scope of any

intellectual property or other rights that might be claimed to

pertain to the implementation or use of the technology described in

this document or the extent to which any license under such rights

might or might not be available; neither does it represent that it

has made any effort to identify any such rights. Information on the IETF’s procedures with respect to rights in standards-track and

standards-related documentation can be found in BCP-11. Copies of

claims of rights made be made available, or the result of an attempt made to obtain a general license or permission for the use of such

proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any

copyrights, patents or patent applications, or other proprietary

rights which may cover technology that may be required to practice

this standard. Please address the information to the IETF Executive Director.

Xie Standards Track [Page 12]

David Pearce

Motorola Labs

UK Research Laboratory

Jays Close

Viables Industrial Estate

Basingstoke, HANTS, RG22 4PD

Phone: +44 (0)1256 484 436

EMail: bdp003@https://www.sodocs.net/doc/d65132334.html,

Senaka Balasuriya

Motorola, Inc.

600 U.S Highway 45

Libertyville, IL 60048, USA

Phone: +1-847-523-0440

EMail: Senaka.Balasuriya@https://www.sodocs.net/doc/d65132334.html,

Yoon Kim

VerbalTek, Inc.

2921 Copper Rd.

Santa Clara, CA 95051

Phone: +1-408-768-4974

EMail: yoonie@https://www.sodocs.net/doc/d65132334.html,

Stephane H. Maes, PhD,

Oracle

500 Oracle Parkway, M/S 4op634

Redwood City, CA 94065 USA

Phone: +1-650-607-6296.

EMail: stephane.maes@https://www.sodocs.net/doc/d65132334.html,

Hari Garudadri

Qualcomm Inc.

5775, Morehouse Dr.

San Diego, CA 92121-1714, USA

Phone: +1-858-651-6383

EMail: hgarudad@https://www.sodocs.net/doc/d65132334.html,

Xie Standards Track [Page 13]

Qiaobing Xie

Motorola, Inc.

1501 W. Shure Drive, 2-F9

Arlington Heights, IL 60004, USA

Phone: +1-847-632-3028

EMail: Qiaobing.Xie@https://www.sodocs.net/doc/d65132334.html,

Xie Standards Track [Page 14]

13. Full Copyright Statement

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to

others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published

and distributed, in whole or in part, without restriction of any

kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this

document itself may not be modified in any way, such as by removing

the copyright notice or references to the Internet Society or other

Internet organizations, except as needed for the purpose of

developing Internet standards in which case the procedures for

copyrights defined in the Internet Standards process must be

followed, or as required to translate it into languages other than

English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the

Internet Society.

Xie Standards Track [Page 15]

几秒种分区格式化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的主界面来对镜像文件进行恢复操作,不过这样你就要多敲几次键了。 我个人认为这种分区格式化的方法十分实用,特别适用于那些经常要分区格式化大容量硬盘的朋友,如装机商、电脑维修者、电脑发烧友等,因此写下此文,希望能对包括他们在内的所有电脑爱好者有所帮助。

硬盘分区与格式化教案(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 硬盘的分区与格式化 提问:硬盘的格式化有低级格式化和高级格式化两 种,它们之间有什么区别? 学生思考、看书、回答; 教师总结: 现在制造的硬盘在出厂时均做过低级格式化,用户一般不必重做。除非 所用硬盘坏道较多或染上无法清除的病毒,不得不做一次低级格式化。 低级格式化的主要目的是划分磁柱面(磁道),建立扇区数和选择扇区 的间隔比,即为每个扇区标注地址和扇区头标志,并以硬盘能识别的方式进 行数据编码。 讲授 多媒 体教 学

第三讲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.sodocs.net/doc/d65132334.html,复制到磁盘上,使该磁盘可以做为DOS启动盘。若不选用/S参数,则格式化后的磙盘只能读写信息,而不能做为启动盘; (4)选用[/4]参数,在1.2MB的高密度软驱中格式化360KB的低密度盘; (5)选用[/Q]参数,快速格式化,这个参数并不会重新划分磁盘的磁道貌岸然和扇区,只能将磁盘根目录、文件分配表以及引导扇区清成空白,因此,格式化的速度较快。 (6)选用[/u]参数,表示无条件格式化,即破坏原来磁盘上所有数据。不加/U,则为安全格式化,这时先建立一个镜象文件保存原来的FAT表和根目录,必要时可用UNFORRMAT恢复原来的数据。 二、恢复格式化命令Unformat 1.功能:对进行过格式化误操作丢失数据的磁盘进行恢复。 2.类型:外部命令

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

用Gdisk快速搞定大容量硬盘分区格式化 发表:2004-6-5 6:05:21 出处:你的博客网(https://www.sodocs.net/doc/d65132334.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

最新[怎么在bios下格式化硬盘]怎么在BIOS下格式化硬盘.doc

【入党申请书格式】 如何在 BIOS 下格式化硬盘或分区?下面是收集整理关于在 BIOS 下格式化硬盘或分区的资料以供大家参考学习,希望大家喜欢。 在 BIOS 下格式化硬盘或分区的方法 一、GDISK实例 如果我告诉你80GB的硬盘分区加格式化一共只需3分钟,你或许会瞪大眼睛看着我可能吗?现在我要告诉你这是完全可以实现的,而且操作非常简单。 首先下载gdisk.exe,这个软件只有270KB,可以独立使用。不要小看它哟,我们快速分区、格式化硬盘全靠它了。找张软盘,制作成启动盘,将gdisk.exe拷到盘上,再建一个批处理文件FD.bat。假设是一块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 (删除所有硬盘分区)。 再执行分区格式化批处理命令,同样不需要花多少时间即可重新搞定。不过在动手之前一定要把硬盘上重要的数据备份出来,不然,两三分钟后可就欲哭无泪了。

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

手把手教你硬盘分区格式化 你从商场买来的硬盘并不能直接使用,必须对它进行分区并进行格式化的才能储存数据。如果把新买来的硬盘比喻成白纸,你要把它变成写文章的稿纸的话,分区就好像给它规定可以写字的范围,格式化就好像给它画出写每一个字的格子。 在建立磁盘区以前,你必须对“物理磁盘(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键。

如何编辑bat文件介绍一下语言规则

批处理文件,在中,文件是可执行文件,有一系列命令构成,其中可以包含对其他程序地调用. 首先,批处理文件是一个文本文件,这个文件地每一行都是一条命令(大部分时候就好像我们在提示符下执行地命令行一样),你可以使用下地或者地记事本()等任何文本文件编辑工具创建和修改批处理文件.个人收集整理勿做商业用途 其次,批处理文件是一种简单地程序,可以通过条件语句()和流程控制语句()来控制命令运行地流程,在批处理中也可以使用循环语句()来循环执行一条命令.当然,批处理文件地编程能力与语言等编程语句比起来是十分有限地,也是十分不规范地.批处理地程序语句就是一条条地命令(包括内部命令和外部命令),而批处理地能力主要取决于你所使用地命令.个人收集整理勿做商业用途 第三,每个编写好地批处理文件都相当于一个地外部命令,你可以把它所在地目录放到你地搜索路径()中来使得它可以在任意位置运行.一个良好地习惯是在硬盘上建立一个或者目录(例如:\),然后将所有你编写地批处理文件放到该目录中,这样只要在中设置上:\,你就可以在任意位置运行所有你编写地批处理程序.个人收集整理勿做商业用途 第四,在和系统下,:盘根目录下地批处理文件是自动运行批处理文件,每次系统启动时会自动运行该文件,你可以将系统每次启动时都要运行地命令放入该文件中,例如设置搜索路径,调入鼠标驱动和磁盘缓存,设置系统环境变量等.下面是一个运行于下地地示例:个人收集整理勿做商业用途 :\:\\:\:\:\:\:\个人收集整理勿做商业用途 :\ :\ 批处理地作用 简单地说,批处理地作用就是自动地连续执行多条命令. 这里先讲一个最简单地应用:在启动软件时,每次都必须执行(>前面内容表示提示符): :\> :\> :\>

如何写批处理文件

如何写批处理文件 扩展名是bat(在nt/2000/xp/2003下也可以是cmd)的文件就是批处理文件。首先批处理文件是一个文本文件,这个文件的每一行都是一条DOS命令(大部分时候就好象我们在DOS提示符下执行的命令行一样),你可以使用DOS下的Edit或者Windows的记事本(notepad)等任何文本文件编辑工具创建和修改批处理文件。其次,批处理文件是一种简单的程序,可以通过条件语句(if)和流程控制语句(goto)来控制命令运行的流程,在批处理中也可以使用循环语句(for)来循环执行一条命令。当然,批处理文件的编程能力与C语言等编程语句比起来是十分有限的,也是十分不规范的。批处理的程序语句就是一条条的DOS命令(包括内部命令和外部命令),而批处理的能力主要取决于你所使用的命令。第三,每个编写好的批处理文件都相当于一个DOS 的外部命令,你可以把它所在的目录放到你的DOS搜索路径(path)中来使得它可以在任意位置运行。一个良好的习惯是在硬盘上建立一个bat或者batch目录(例如C:\ BA TCH),然后将所有你编写的批处理文件放到该目录中,这样只要在path中设置上c:\batch,你就可以在任意位置运行所有你编写的批处理程序。 第四,在DOS和Win9x/Me系统下,C:盘根目录下的AUTOEXEC.BA T 批处理文件是自动运行批处理文件,每次系统启动时会自动运行该文件,你可以将系统每次启动时都要运行的命令放入该文件中,例如设置搜索路径,调入鼠标驱动和磁盘缓存,设置系统环境变量等。下面是一个运行于Windows 98下的autoexec.bat的示例: @ECHO OFF PA TH C:\WINDOWS;C:\WINDOWS\COMMAND;C:\UCDOS;C:\DOSTools; C:\SYSTOOLS;C:\WINTOOLS;C:\BA TCH LH SMARTDRV.EXE /X LH https://www.sodocs.net/doc/d65132334.html, /INSERT LH CTMOUSE.EXE SET TEMP=D:\TEMP SET TMP=D:\TEMP 批处理的作用 简单的说,批处理的作用就是自动的连续执行多条命令。 这里先讲一个最简单的应用:在启动wps软件时,每次都必须执行(>前面内容表示DOS提示符): C:\>cd wps C:\WPS>spdos

DOS命令大全(最全版)

DOS命令大全(最全版)

正文: DOS命令大全 一)MD——建立子目录 1.功能:创建新的子目录 2.类型:内部命令 3.格式:MD[盘符:][路径名]〈子目录名〉4.使用说明: (1)“盘符”:指定要建立子目录的磁盘驱动器字母,若省略,则为当前驱动器; (2)“路径名”:要建立的子目录的上级目录名,若缺省则建在当前目录下。 例:(1)在C盘的根目录下创建名为FOX的子目录;(2)在FOX子目录下再创建USER子目录。C:、>MD FOX (在当前驱动器C盘下创建子目录FOX) C:、>MD FOX \USER (在FOX 子目录下再创建USER子目录) (二)CD——改变当前目录 1.功能:显示当前目录 2.类型:内部命令 3.格式:CD[盘符:][路径名][子目录名] 4.使用说明:

除,操作如下: 第一步:先将USER子目录下的文件删空; C、>DEL C:\FOX\USER\*.* 第二步,删除USER子目录。 C、>RD C:\FOX\USER (四)DIR——显示磁盘目录命令 1.功能:显示磁盘目录的内容。 2.类型:内部命令 3.格式:DIR [盘符][路径][/P][/W] 4. 使用说明:/P的使用;当欲查看的目录太多,无法在一屏显示完屏幕会一直往上卷,不容易看清,加上/P参数后,屏幕上会分面一次显示23行的文件信息,然后暂停,并提示;Press any key to continue /W的使用:加上/W只显示文件名,至于文件大小及建立的日期和时间则都省略。加上参数后,每行可以显示五个文件名。 PATH——路径设置命令 1.功能:设备可执行文件的搜索路径,只对文件有效。 2.类型:内部命令

80GB的硬盘分区加格式化

] 80GB的硬盘分区加格式化一共只需3分钟! 80GB的硬盘分区加格式化一共只需3分钟! 找张软盘,制作成启动盘,将gdisk.exe拷到盘上,再建一个批处理文件FD.bat。 假设是一块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下载,其中有参数的英文说明!

cmd和批处理命令大全

cmd和批处理命令大全.txt心态决定状态,心胸决定格局,眼界决定境界。当你的眼泪忍不住要流出来的时候,睁大眼睛,千万别眨眼,你会看到世界由清晰到模糊的全过程。cmd和批处理命令大全 1.Echo 命令 打开回显或关闭请求回显功能,或显示消息。如果没有任何参数,echo 命令将显示当前回显设置。 语法 echo [{on|off}] [message] Sample:echo off / echo hello world 在实际应用中我们会把这条命令和重定向符号(也称为管道符号,一般用> >> ^)结合来实现输入一些命令到特定格式的文件中.这将在以后的例子中体现出来。 2.@ 命令 表示不显示@后面的命令,在入侵过程中(例如使用批处理来格式化敌人的硬盘)自然不能让对方看到你使用的命令啦。 Sample:@echo off @echo Now initializing the program,please wait a minite... @format X: /q/u/autoset (format 这个命令是不可以使用/y这个参数的,可喜的是微软留了个autoset这个参数给我们,效果和/y是一样的。) 3.Goto 命令 指定跳转到标签,找到标签后,程序将处理从下一行开始的命令。 语法:goto label (label是参数,指定所要转向的批处理程序中的行。) Sample: if {%1}=={} goto noparms if {%2}=={} goto noparms(如果这里的if、%1、%2你不明白的话,先跳过去,后面会有详细的解释。) @Rem check parameters if null show usage :noparms echo Usage: monitor.bat ServerIP PortNumber goto end 标签的名字可以随便起,但是最好是有意义的字母啦,字母前加个:用来表示这个字母是标签,goto命令就是根据这个:来寻找下一步跳到到那里。最好有一些说明这样你别人看起来才会理解你的意图啊。 4.Rem 命令 注释命令,在C语言中相当与/*--------*/,它并不会被执行,只是起一个注释的作用,便于别人阅读和你自己日后修改。 Rem Message Sample:@Rem Here is the description. 5.Pause 命令 运行 Pause 命令时,将显示下面的消息: Press any key to continue . . .

对新硬盘分区

1,FAT32转化成NTFS格式的方法: 开始--运行,输入Convert X:/fs:ntfs--回车。(转化 对文件、系统都没有影响。)X盘的fat32格式就转化成了NTFS格式。X代表要转化格式的盘符(如:C、D、E、F等) 2,但是,NTFS格式不能转化成FAT32格式。要使某盘(例如D盘)的NTFS格式变成F AT32格式,必须重新将D盘格式化。方法是:重启电脑按del进入bios设置光盘启动按f10退出。然后放入winXP安装光盘。重启电脑,当进程到格式化分区D时选择FAT32 格式把D格掉。原NTFS格式就去掉了,取而代之的就是FAT32格式了。(这里要提醒你的是在d盘重新格式化之前必须将d盘中的资料备份好。)。不过一般不会这样做,就保留NTFS格式。既然你要改成FAT32格式,那只有用这个办法。当然使用分区软件也可以。它不能采用1中所叙述的办法转化 Windows XP控制台图解教程 基础知识: xp的分区格式化功能要远远强于98的Fdisk,不但是图形界面,而且功能强大。 它的分区命令是Diskpart,是Fdisk的改进版;用Diskpart分区,你根本就不用知道什么主DOS分区、什么扩展分区、什么逻辑分区。而且不用重启,可以一气呵成。 它的格式化命令仍是Format,但已经不是98那样简单的Format命令了,它可以通过加参数直接格式化硬盘为fat/fat32/ntfs格式,灵活很多。 进入正题 一、对新硬盘分区 1.在BIOS中设置CD-ROM为第一启动,插入XP安装光盘,开始……一直到出现这个界面(等一会儿吧,会出现的)

2.按下“R”键,回车!如果是裸体盘,会出现以下界面:此主题相关图片如下: 3.按下“C”,回车!出现这个界面:

DOS格式化命令

格式化格式化指定卷中的磁盘以接受 Windows 文件。 语法 format volume [/fs:file-system] [/v:label] [/q] [/a:UnitSize] [/c] [/x] format volume [/v:label] [/q] [/f:size] format volume [/v:label] [/q] [/t:tracks /n:sectors] format volume [/v:label] [/q] format volume [/q] 参数 volume 指定要格式化的驱动器的装入点、卷名或驱动器号。如果不指定以下的任何命令行选项,format 将使用卷类型来决定磁盘的默认格式。 /fs:file-system 指定要使用的文件系统:FAT、FAT32 或 NTFS。软盘只能使用 FAT 文件系统。 /v:label 指定卷标。如果省略 /v 命令行选项或使用它而不指定卷标,format 将在格式化完成后提示输入卷标。使用语法 /v:来防止提示输入卷标。如果利用一个 format 命令格式化多个磁盘,则对所有磁盘指定相同的卷标。有关磁盘卷标的详细信息,请单击“相关主题”列表中的 Dir、Label 和 Vol。 /a:UnitSize 指定要在 FAT、FAT32 或 NTFS 卷上使用的分配单位大小。如果没有指定 UnitSize,将根据卷的大小进行选择。下表列出了 UnitSize 的有效值。值说明 512 每个簇 512 字节。 1024 每个簇 1024 字节。 2048 每个簇 2048 字节。 4096 每个簇 4096 字节。 8192 每个簇 8192 字节。 16K 每个簇 16K 字节。 32K 每个簇 32K 字节。 64K 每个簇 64K 字节。 /q 执行快速格式化。删除以前已格式化卷的文件表和根目录,但不在扇区之间扫描损坏区域。使用 /q 命令行选项应该仅格式化以前已格式化的完好的卷。 /f:size 指定要格式化的软盘大小。可能的话,使用此命令行选项取代 /t 和 /n 命令行选项。Windows 接受如下大小的值: 1440 或 1440k 或 1440kb 或 1.44 或 1.44m 或 1.44mb

你怎么写批处理

扩展名是bat(在nt/2000/xp/2003下也可以是cmd)的文件就是批处理文件。 首先批处理文件是一个文本文件,这个文件的每一行都是一条DOS命令(大部分时候就好象我们在DOS提示符下执行的命令行一样),你可以使用DOS下的Edit或者Windows的记事本(notepad)等任何文本文件编辑工具创建和修改批处理文件。 其次,批处理文件是一种简单的程序,可以通过条件语句(if)和流程控制语句(goto)来控制命令运行的流程,在批处理中也可以使用循环语句(for)来循环执行一条命令。当然,批处理文件的编程能力与C语言等编程语句比起来是十分有限的,也是十分不规范的。批处理的程序语句就是一条条的DOS命令(包括内部命令和外部命令),而批处理的能力主要取决于你所使用的命令。 第三,每个编写好的批处理文件都相当于一个DOS的外部命令,你可以把它所在的目录放到你的DOS搜索路径(path)中来使得它可以在任意位置运行。一个良好的习惯是在硬盘上建立一个bat或者batch目录(例如C:\BATCH),然后将所有你编写的批处理文件放到该目录中,这样只要在path中设置上c:\batch,你就可以在任意位置运行所有你编写的批处理程序。 第四,在DOS和Win9x/Me系统下,C:盘根目录下的AUTOEXEC.BAT批处理文件是自动运行批处理文件,每次系统启动时会自动运行该文件,你可以将系统每次启动时都要运行的命令放入该文件中,例如设置搜索路径,调入鼠标驱动和磁盘缓存,设置系统环境变量等。下面是一个运行于Windows 98下的autoexec.bat的示例: @ECHO OFF PATH C:\WINDOWS;C:\WINDOWS\COMMAND;C:\UCDOS;C:\DOSTools;C:\SYSTOOLS;C:\WINT OOLS;C:\BATCH LH SMARTDRV.EXE /X LH https://www.sodocs.net/doc/d65132334.html, /INSERT LH CTMOUSE.EXE SET TEMP=D:\TEMP SET TMP=D:\TEMP 批处理的作用 简单的说,批处理的作用就是自动的连续执行多条命令。 这里先讲一个最简单的应用:在启动wps软件时,每次都必须执行(>前面内容表示DOS 提示符):

常用DOC命令大全

DOS和Windows最大的不同在于DOS命令方式操作,所以使用者需要记住大量命令及其格式使用方法,DOS命令分为内部命令和外部命令,内部命令是随每次启动的https://www.sodocs.net/doc/d65132334.html,装入并常驻内存,而外部命令是一条单独的可执行文件。在操作时要记住的是,内部命令在任何时候都可以使用,而外部命令需要保证命令文件在当前的目录中,或在Autoexec.bat文件已经被加载了路径。 常用的内部命令 DOS的内部命令是DOS操作的基础,下面就来介绍一些常用的DOS内部命令。 1、DIR 含义:显示指定路径上所有文件或目录的信息 格式:DIR [盘符:][路径][文件名] [参数] 参数: /W:宽屏显示,一排显示5个文件名,而不会显示修改时间,文件大小等信息; /P:分页显示,当屏幕无法将信息完全显示时,可使用其进行分页显示; /A:显示具有特殊属性的文件; /S:显示当前目录及其子目录下所有的文件。 举例:DIR /P 将分屏显示当前目录下文件。在当前屏最后有一个“Press any key to continue . . .”提示,表示按任意键继续。 2、CD 含义:进入指定目录 格式:CD [路径] 举例:CD DOS CD命令只能进入当前盘符中的目录,其中“CD\”为返回到根目录,“CD..”为返回到上一层目录。 3、MD 含义:建立目录 格式:MD [盘符][路径] 举例:MD TEMP 表示在当前盘符下建立一个名为TEMP的目录。 4、RD 含义:删除目录 格式:RD [盘符][路径] 举例:RD TEMP 表示删除当前路径下的TEMP目录,需要注意的是,此命令只能删除空目录。 5、COPY 含义:拷贝文件

批处理文件BAT、CMD命令大全(20200521102020)

批处理文件BAT命令大全 一.简单批处理内部命令简介 命令 打开回显或关闭请求回显功能,或显示消息。如果没有任何参数,echo 命令将显示当前回显设置。 语法 echo [{on│off}] [message] Sample:@echo off / echo hello world 在实际应用中我们会把这条命令和重定向符号(也称为管道符号,一般用> >> ^)结合来实现输入一些命令到特定格式的文件中.这将在以后的例子中体现出来。 2.@ 命令 表示不显示@ 后面的命令,在入侵过程中(例如使用批处理来格式化敌人的硬盘)自然不能让对方看到你使用的命令啦。 Sample:@echo off @echo Now initializing the program,please wait a minite... @format X: /q/u/autoset (format 这个命令是不可以使用/y这个参数的,可喜的是微软留了个autoset这个参数给我们,效果和/y 是一样的。) 命令

指定跳转到标签,找到标签后,程序将处理从下一行开始的命令。 语法:goto label (label是参数,指定所要转向的批处理程序中 的行。) Sample: if {%1}=={} goto noparms if {%2}=={} goto noparms(如果这里的if、%1、%2就是表示变量。)@Rem check parameters if null show usage :noparms echo Usage: ServerIP PortNumber goto end 标签的名字可以随便起,但是最好是有意义的字母啦,字母前加个: 用来表示这个字母是标签, : 开头的字符行 , 在批处理中都被视作标号 , 而直接忽略其后的所有内容 , 只是为了与正常的标号相区 别 , 建议使用 goto 所无法识别的标号 , 即在 : 后紧跟一个非字母数字的一个特殊符号 . goto 命令就是根据这个:来寻找下一步跳 到到那里。最好有一些说明这样你别人看起来才会理解你的意图啊。 命令 注释命令,起一个注释的作用,便于别人阅读和你自己日后修改。 Rem Message Sample:@Rem Here is the description.

相关主题