flyinweb's blog - 网络文摘

诺基亚手机S60系统证书申请、软件签名图文教程

shanyiwan@live.com() — Thu, 20 May 2010 06:42:14 GMT

证书申请流程

1、手机上输入*#06#查询手机串号

2、访问http://cer.s603rd.cn/index.php，在下图所在位置输入刚才查询到的串号，并输入验证码提交，提交后会提示“您的证书将在12小时之内完成,您可以随时再次输入串号查询完成情况”

3、等待七八个小时

4、再次访问http://cer.s603rd.cn/index.php，再次输入第一步查询到的手机串号，并输入验证码提交，提交后会看到“下载”字样链接，点击后即可下载证书。如果没有出现下载，多等几个小时后再试。

软件签名教程

1、首先要通过上面的证书申请流程取得证书，然后在http://cer.s603rd.cn/index.php上找到signtools2.2(下图所示)，并点击here下载

2、将下载的证书压缩包和signtools压缩包解压缩，将证书文件、key.key文件和signtools2.2.exe文件放到同一个文件夹下，并将所要签名的软件一同放入这个文件夹下（以字体驱动.sis为例，如下图所示）

3、运行signtools2.2.exe，分别选择证书和需签名软件，然后点击“执行签名”按钮，提示签名成功，即生成已签名的软件，如图所示生成“字体驱动-已签名.sis”。

　　4、将已签名的软件放到手机上进行安装。

猎人、兔子和狗的故事

shanyiwan@live.com() — Tue, 27 Apr 2010 00:52:29 GMT

猎人、兔子和狗的故事

一、

图解： 一条猎狗将兔子赶出了窝，一直追赶他，追了很久仍没有捉到。牧羊看到此种情景，讥笑猎狗说"你们两个之间小的反而跑得快得多。"猎狗回答说："你不知道我们两个的跑是完全不同的！我仅仅为了一顿饭而跑，他却是为了性命而跑呀！"
启示：目标不同

二、

图解：这话被猎人听到了,猎人想:猎狗说的对啊,那我要想得到更多的猎物,得想个好法子.于是,猎人又买来几条猎狗,凡是能够在打猎中捉到兔子的,就可以得到几根骨头,捉不到的就没有饭吃.这一招果然有用,猎狗们纷纷去努力追兔子,因为谁都不愿意看着别人有骨头吃,自已没的吃.就这样过了一段时间,问题又出现了.大兔子非常难捉到,小兔子好捉.但捉到大兔子得到的奖赏和捉到小兔子得到的骨头差不多,猎狗们善于观察,发现了这个窍门,专门去捉小兔子.慢慢的,大家都发现了这个窍门.猎人对猎狗说:最近你们捉的兔子越来越小了,为什么?猎狗们说:反正没有什么大的区别,为什么费那么大的劲去捉那些大的呢?
启示：动力

三、

图解：猎人经过思考后,决定不将分得骨头的数量与是否捉到兔子挂钩,而是采用每过一段时间,就统计一次猎狗捉到兔子的总重量.按照重量来评价猎狗,决定一段时间内的待遇. 于是猎狗们捉到兔子的数量和重量都增加了.猎人很开心.
但是过了一段时间,猎人发现,猎狗们捉兔子的数量又少了,而且越有经验的猎狗,捉兔子的数量下降的就越利害.于是猎人又去问猎狗.猎狗说"我们把最好的时间都奉献给了您,主人,但是我们随着时间的推移会老,当我们捉不到兔子的时候,您还会给我们骨头吃吗?"

启示：长期的骨头

四、

图解：猎人做了论功行赏的决定.分析与汇总了所有猎狗捉到兔子的数量与重量,规定如果捉到的兔子超过了一定的数量后,即使捉不到兔子,每顿饭也可以得到一定数量的骨头. 猎狗们都很高兴,大家都努力去达到猎人规定的数量.一段时间过后,终于有一些猎狗达到了猎人规定的数量.这时,其中有一只猎狗说:我们这么努力,只得到几根骨头,而我们捉的猎物远远超过了这几根骨头.我们为什么不能给自己捉兔子呢?"于是,有些猎狗离开了猎人,自己捉兔子去了.
启示：骨头与肉兼而有之

五
猎人意识到猎狗正在流失，并且那些流失的猎狗像野狗一般和自己的猎狗抢兔子。情况变得越来越糟，猎人不得已引诱了一条野狗，问他到底野狗比猎狗强在那里。野狗说：“猎狗吃的是骨头，吐出来的是肉啊！”，接着又道：“也不是所有的野狗都顿顿有肉吃，大部分最后骨头都没的舔！不然也不至于被你诱惑。”于是猎人进行了改革，使得每条猎狗除基本骨头外，可获得其所猎兔肉总量的n，而且随着服务时间加长，贡献变大，该比例还可递增，并有权分享猎人总兔肉的m。就这样，猎狗们与猎人一起努力，将野狗们逼得叫苦连天，纷纷强烈要求重归猎狗队伍。

只有永远的利益，没有永远的朋友

日子一天一天地过去，冬天到了，兔子越来越少，猎人们的收成也一天不如一天。而那些服务时间长的老猎狗们老得不能捉到兔子，但仍然在无忧无虑地享受着那些他们自以为是应得的大份食物。终于有一天猎人再也不能忍受，把他们扫地出门，因为猎人更需要身强力壮的猎狗……

键盘上的那点“歪理”

shanyiwan@live.com() — Sat, 20 Mar 2010 16:02:55 GMT

键盘上的那点“歪理”

曾经听一位老人家说过，很多人一辈子在寻求哲理，思考自己的道路，而哲理在何处？它蕴藏在我们平静如水的生活中，不经意之间一些事物，也许就是上苍对我们的提示。如同下面这些键盘的图片，也许这些键对你来说，是平常得不能再平常了，但你可有想过它们代表什么？要告诉我们什么？

Michael Jackson 经典作品 Earth song

shanyiwan@live.com() — Tue, 07 Jul 2009 04:53:00 GMT

Architecture Skills Framework

shanyiwan@live.com() — Mon, 22 Jun 2009 03:47:51 GMT

http://www.opengroup.org/architecture/togaf8-doc/arch/chap30.html

This chapter provides a set of role, skill, and experience norms for staff undertaking enterprise architecture work.

Introduction

Skills frameworks provide a view of the competency levels required for specific roles. They define:

The roles within a work area
The skills required by each role
The depth of knowledge required to fulfil the role successfully

They are relatively common for defining the skills required for a consultancy and/or project management assignment, to deliver a specific project or work package. They are also widely used by recruitment and search agencies to match candidates and roles.

Their value derives from their ability to provide a means of rapidly identifying skill matches and gaps. Successfully applied, they can ensure that candidates are fit for the jobs assigned to them.

Their value in the context of enterprise architecture arises from the immaturity of the enterprise architecture discipline, and the problems that arise from this.

The Need for an IT Architecture Skills Framework

Definitional Rigor

"IT Architecture" and "IT Architect" are widely used but poorly defined terms in the IT industry today. They are used to denote a variety of practices and skills applied in a wide variety of IT domains. There is a need for better classification to enable more implicit understanding of what type of architect/architecture is being described.

This lack of uniformity leads to difficulties for organizations seeking to recruit or assign/promote staff to fill positions in the architecture field. Because of the different usages of terms, there is often misunderstanding and miscommunication between those seeking to recruit for, and those seeking to fill, the various roles of the architect.

The Basis of an Internal Architecture Practice

Despite the lack of uniform terminology, architecture skills are in increasing demand, as the discipline of architecture gains increasing attention within the IT industry.

Many enterprises have set up, or are considering setting up, an IT architecture practice, as a means of fostering development of the necessary skills and experience among in-house staff to undertake the various architecting tasks required by the enterprise.

An IT architecture practice is a formal program of development and certification, by which an enterprise formally recognizes the skills of its practicing IT architects, as demonstrated by their work. Such a program is essential in order to ensure the alignment of staff skills and experience with the IT architecture tasks that the enterprise wishes to be performed.

The role and skill definitions on which such a program needs to be based are also required, by both recruiting and supplying organizations, in cases where external personnel are to be engaged to perform architecture work (for example, as part of a consultancy engagement).

An IT architecture practice is both difficult and costly to set up. It is normally built around a process of peer review, and involves the time and talent of the strategic technical leadership of an enterprise. Typically it involves establishment of a peer review board, and documentation of the process, and of the requirements for internal certification. Time is also required of candidates to prepare for peer review, by creating a portfolio of their work to demonstrate their skills, experiences, and contributions to the profession.

The TOGAF Architecture Skills Framework attempts to address this need by providing definitions of the architecting skills and proficiency levels required of personnel, internal or external, who are to perform the various architecting roles defined within the TOGAF Framework.

Because of the complexity, time, and cost involved, many enterprises do not have an internal IT architect certification program, preferring instead to simply interview and recruit architecture staff on an ad hoc basis. There are serious risks associated with this approach:

Communication between recruiting organizations, consultancies, and employment agencies is very difficult.
Time is wasted interviewing staff who may have applied in all good faith, but still lack the skills and/or experience required by the employer.
Staff who are capable of filling architecture roles may be overlooked, or may not identify themselves with advertised positions and hence not even apply.
There is increased risk of unsuitable personnel being employed or engaged, through no-one's fault, and despite everyone involved acting in good faith. This in turn can:
- Increase personnel costs, through the need to rehire or reassign staff
- Adversely impact the time, cost, and quality of operational IT systems, and the projects that deliver them

Goals/Rationale

Enterprise Certification of IT Architects

The main purpose behind an enterprise setting up an internal IT architect certification program are twofold:

To formally recognize the skill of its practicing IT architects, as part of the task of establishing and maintaining a professional IT architecting organization
To ensure the alignment of necessary staff skills and experience with the IT architecture tasks that the enterprise wishes to be performed, whether these are to be performed internally to the enterprise or externally; for example, as part of a consultancy engagement

Specific Benefits

Specific benefits anticipated from use of the TOGAF Architecture Skills Framework include:

Reduced time, cost, and risk in training, hiring, and managing IT architecture professionals, both internal and external:
- Simplifies communication between recruiting organizations, consultancies, and employment agencies
- Avoids wasting time interviewing staff who may have applied in all good faith, but still lack the skills and/or experience required by the employer
- Avoids staff who are capable of filling IT architecture roles being overlooked, or not identifying themselves with advertised positions and hence not even applying
Reduced time and cost to set up an internal IT architecture practice:
- Many enterprises do not have an internal IT architecture practice due to the complexity involved in setting one up, preferring instead to simply interview and recruit architecture staff on an ad hoc basis.
- By providing definitions of the architecting skills and proficiency levels required of personnel who are to perform the various architecting roles defined within TOGAF, the Architecture Skills Framework greatly reduces the time, cost, and risk of setting up a practice from scratch, and avoids "re-inventing wheels".
- Enterprises that already have an internal IT architecture practice are able to set enterprise-wide norms, but still experience difficulties as outlined above in recruiting staff, or engaging consultants, from external sources, due to the lack of uniformity between different enterprises. By aligning its existing skills framework with the industry-accepted definitions provided by The Open Group, an enterprise can greatly simplify these problems.
Reduced time and cost to implement an IT architect practice helps reduce the time, cost, and risk of overall IT development:
- Enterprises that do not have an internal IT architecture practice run the risk of unsuitable personnel being employed or engaged, through no-one's fault, and despite everyone involved acting in good faith. The resultant time and cost penalties far outweigh the time and cost of having an internal IT architecture practice:
  - Personnel costs are increased, through the occasional need to rehire or reassign staff.
  - Even more important is the adverse impact on the time, cost, and quality of operational IT systems, and the projects to deliver them, resulting from poor staff assignments.

IT Architecture Role and Skill Categories

Overview

This section describes the role of an IT architect, the fundamental skills required, and some possible disciplines in which an IT architect might specialize.

TOGAF Version 8 delivers an enterprise architecture, and therefore requires both business and IT-trained professionals to develop the enterprise architecture.

The TOGAF Architecture Skills Framework provides a view of the competency levels for specific roles within the enterprise architecture team. The Framework defines:

The roles within an enterprise architecture work area
The skills required by those roles
The depth of knowledge required to fulfil each role successfully

The value is in providing a rapid means of identifying skills and gaps. Successfully applied, the Framework can be used as a measure for:

Staff development
Ensuring that the right person does the right job

TOGAF Roles

A typical IT architecture team undertaking the development of an enterprise architecture as described in TOGAF would comprise the following roles:

Architecture Board Members
Architecture Sponsor
IT Architecture Manager
IT Architects for:
- Enterprise Architecture
- Business Architecture
- Data Architecture
- Applications Architecture
- Technology Architecture
Program and/or Project Managers
IT Designer
And many others ...

The tables that follow show, for each of these roles, the skills required and the desirable level of proficiency in each skill.

Of all the roles listed above, the one that needs particularly detailed analysis and definition is of course the central role of IT architect. As explained above, "IT Architecture" and "IT Architect" are terms that are very widely used but very poorly defined in the IT industry today, denoting a wide variety of practices and skills applied in a wide variety of IT domains. There is often confusion between the role of an IT architect and that of an IT designer or IT builder. Many of the skills required by an IT architect are also required by the IT designer, who delivers the solutions. While their skills are complimentary, those of the IT designer are primarily technology focussed and translate the architecture into deliverable components.

The final subsection below therefore explores in some detail the generic characteristics of the role of IT architect, and the key skill requirements, whatever the particular IT domain (Enterprise Architecture, Business Architecture, Data Architecture, Applications Architecture, Technology Architecture, etc.).

Categories of Skills

The TOGAF team skill set will need to include the following main categories of skills:

Generic Skills: - typically comprising leadership, teamworking, inter-personal skills, etc.
Business Skills and Methods: - typically comprising business cases, business process, strategic planning, etc.
Enterprise Architecture Skills: - typically comprising modeling, building block design, applications and role design, systems integration, etc.
Program or Project Management Skills: - typically comprising managing business change, project management methods and tools, etc.
IT General Knowledge Skills: - typically comprising brokering applications, asset management, migration planning, SLAs, etc.
Technical IT Skills: - typically comprising software engineering, security, data interchange, data management, etc.
Legal Environment: - typically comprising data protection laws, contract law, procurement law, fraud, etc.

The tables that follow illustrate each of these categories of skills.

The tables that follow show, for each of these skills, the roles to which they are relevant and the desirable level of proficiency in each skill.

Proficiency Levels

The TOGAF Architecture Skills Framework identifies four levels of knowledge or proficiency in any area:

IT Architecture Role and Skill Definitions

Generic Skills

Business Skills & Methods

Enterprise Architecture Skills

Program or Project Management Skills

IT General Knowledge Skills

Technical IT Skills

Legal Environment

Generic Role and Skills of the IT Architect

Of all the roles listed above, the one that needs particularly detailed analysis and definition is, of course, the central role of IT architect. As explained above, "IT Architecture" and "IT Architect" are terms that are very widely used but very poorly defined in the IT industry today, denoting a wide variety of practices and skills applied in a wide variety of IT domains.

This section therefore explores in some detail the generic characteristics of the role of IT architect, and some key skill requirements, whatever the particular IT domain (Enterprise Architecture, Business Architecture, Data Architecture, Applications Architecture, Technology Architecture, etc.).

Generic Role

IT architects are visionaries, coaches, team leaders, business-to-technical liaisons, computer scientists, and industry experts.

The following is effectively a job description for an IT architect:

"The architect has a responsibility for ensuring the completeness (fitness-for-purpose) of the architecture, in terms of adequately addressing all the pertinent concerns of its stakeholders; and the integrity of the architecture, in terms of connecting all the various views to each other, satisfactorily reconciling the conflicting concerns of different stakeholders, and showing the trade-offs made in so doing (as between security and performance, for example).
The choice of which particular architecture views to develop is one of the key decisions that the IT architect has to make. The choice has to be constrained by considerations of practicality, and by the principal of fitness-for-purpose (i.e., the architecture should be developed only to the point at which it is fit-for-purpose, and not reiterated ad infinitum as an academic exercise)."

The role of the IT architect is more like that of a city planner than that of a building architect, and the product of the IT architect is more aptly characterized as a planned community (as opposed to an unconstrained urban sprawl), rather than as a well-designed building or set of buildings.

An IT architect does not create the technical vision of the enterprise, but has professional relationships with executives of the enterprise to gather and articulate the technical vision, and to produce the strategic plan for realizing it. This plan is always tied to the business plans of the enterprise, and design decisions are traceable to the business plan.

The strategic plan of the IT architect is tied to the architecture governance process (see Architecture Governance) for the enterprise, so design decisions are not circumvented for tactical convenience.

The IT architect produces documentation of design decisions for application development teams or product implementation teams to execute.

An architect is involved in the entire process, beginning with working with the customer to understand real needs, as opposed to wants, and then throughout the process to translate those needs into capabilities verified to meet the needs. Additionally, the architect may present different models to the customer that communicate how those needs may be met, and is therefore an essential participant in the consultative selling process.

However, the architect is not the builder, and must remain at a level of abstraction necessary to ensure s/he does not get in the way of practical implementation.

The following excerpt from The Art of Systems Architecting depicts this notion:

"It is the responsibility of the architect to know and concentrate on the critical few details and interfaces that really matter, and not to become overloaded with the rest."

The architect's focus is on understanding what it takes to satisfy the client, where qualitative worth is used more than quantitative measures. The architect uses more inductive skills than the deductive skills of the builder. The architect deals more with guidelines, rather than rules that builders use as a necessity.

It also must be clear that the role of an architect may be performed by an engineer. A goal of this document is to describe the role - what should be done, regardless of who is performing it.

Thus, the role of the architect can be summarized as to:

Understand and interpret requirements: probe for information, listen to information, influence people, facilitate consensus building, synthesize and translate ideas into actionable requirements, articulate those ideas to others. Identify use or purpose, constraints, risks, etc. The architect participates in the discovery and documentation of the customer's business scenarios that are driving the solution. The architect is responsible for requirements understanding and embodies that requirements understanding in the architecture specification.
Create a useful model: take the requirements and develop well-formulated models of the components of the solution, augmenting the models as necessary to fit all of the circumstances. Show multiple views through models to communicate the ideas effectively. The architect is responsible for the overall architecture integrity and maintaining the vision of the offering from an architectural perspective. The architect also ensures leverage opportunities are identified, using building blocks, and is a liaison between the functional groups (especially development and marketing) to ensure that the leverage opportunities are realized. The architect provides and maintains these models as a framework for understanding the domain(s) of development work, guiding what should be done within the organization, or outside the organization. The architect must represent the organization view of the architecture by understanding all the necessary business components.
Validate, refine, and expand the model: verify assumptions, bring in subject matter experts, etc. in order to improve the model and to further define it, adding as necessary new ideas to make the result more flexible and more tightly linked to current and expected requirements. The architect additionally should assess the value of solution-enhancing developments emanating from field work and incorporate these into the architecture models as appropriate.
Manage the architecture: continuously monitor the models and update them as necessary to show changes, additions, and alterations. Represent architecture and issues during development and decision points of the program. The architect is an "agent of change", representing that need for the implementation of the architecture. Through this development cycle, the architect continuously fosters the sharing of customer, architecture, and technical information between organizations.

Characterization in Terms of the Enterprise Continuum

Under certain circumstances, the complexity of a solution may require additional architects to support the architecture effort. The different categories of architects are described below, but as they are architects, they all perform the tasks described above. Any combination of foundation, systems, solutions, and customer architects may be utilized, as a team. In such cases each member may have a specific focus, if not specific roles and responsibilities, within the phases of the development process. In cases where a team of architects is deemed necessary, a Lead Architect should be assigned to manage and lead the team members.

The Foundation Architect has the responsibility for architectural design and documentation at a technical reference model level. The Foundation Architect often leads a group of the System and/or Industry Architects related to a given program. The focus of the Foundation Architect is on enterprise-level business functions required.
The System Architect has the responsibility for architectural design and documentation at a system or subsystem level, such as management or security. A System Architect may shield the Foundation Architect from the unnecessary details of the systems, products, and/or technologies. The focus of the System Architect is on system technology solutions; for example, a component of a solution such as enterprise data warehousing.
The Industry Architect has the responsibility for architectural design and documentation at an industry level. The focus of the Industry Architect is on industry problems and solutions; for example, Petrochemical solutions, Banking solutions, Retail solutions.
The Organization Architect has the responsibility for architectural design and documentation of specific organizations. An Organization Architect re-uses the output from all other architects. The focus of the Organization Architect is on enterprise-level business solutions in a given domain, such as finance, human resources, sales, etc.

Key Characteristics of an IT Architect

Skills and Experience in Producing Designs

An IT architect must be proficient in the techniques that go into producing designs of complex IT systems, including requirements discovery and analysis, formulation of solution context, identification of solution alternatives and their assessment, technology selection, and design configuration.

Extensive Technical Breadth, with Technical Depth in One or a Few Disciplines

An IT architect should possess an extensive technical breadth through experience in the IT industry. This breadth should be in areas of application development and deployment, and in the areas of creation and maintenance of the infrastructure to support the complex application environment. Current IT environments are heterogeneous by nature, and the experienced IT architect will have skills across multiple platforms, including distributed systems and traditional mainframe environments. IT architects will have, as a result of their careers, skills in at least one discipline that is considered to be at the level of a subject matter expert.

Method-Driven Approach to Execution

The IT architect approaches his or her job through the consistent use of recognized design methods such as the TOGAF Architecture Development Method (ADM). The IT architect should have working knowledge of more than one design method and be comfortable deploying parts of methods appropriate to the situation in which s/he is working. This should be seen in the body of design work the IT architect has produced through repeated successful use of more than one design method. Proficiency in methodology use is in knowing what parts of methods to use in a given situation, and what methods not to use.

Full Project Scope Experience

While the IT architect is responsible for design and hand-off of the project to implementors, it is vital that s/he have experience with all aspects of a project from design through development, testing, implementation, and production. This scope of experience will serve to keep IT architects grounded in the notion of fitness-for-purpose and the practical nature of system implementation. The impact of full project scope experience should lead the IT architect to make better design decisions, and better inform the trade-offs made in those decisions.

Leadership

Communication and team building are key to the successful role of the IT architect. The mix of good technical skill and the ability to lead are crucial to the job. S/he should be viewed as a leader in the enterprise by the IT organization, the clients they serve, and management.

Personal and Professional Skills

The IT architect must have strong communications and relationship skills. A major task of the IT architect is to communicate complex technical information to all stakeholders of the project, including those who do not have a technical background. Strong negotiation and problem-solving skills are also required. The IT architect must work with the project management team to make decisions in a timely manner to keep projects on track.

Skills and Experience in One or More Industries

Industry skill and experience will make the task of gathering requirements and deciding priorities easier and more effective for the IT architect. The IT architect must understand the business processes of the enterprise in which he works, and how those processes work with other peer enterprises in the industry. S/he should also be able to spot key trends and correct flawed processes, giving the IT organization the capability to lead the enterprise, not just respond to requests. The mission of the IT architect is strategic technical leadership.

Conclusions

The TOGAF Architecture Skills Framework provides an assessment of the skills required to deliver a successful enterprise architecture.

It is hoped that the provision of this Architecture Skills Framework will help reduce the time, cost, and risk involved in training, recruiting, and managing IT architecture professionals, and at the same time enable and encourage more organizations to institute an internal IT architecture practice, hopefully based on (or at least leveraging) the role and skill definitions provided.
return to top of page

Navigation

The TOGAF document set is designed for use with frames. To navigate around the document:

In the main Contents frame at the top of the page, click the relevant hyperlink (Part I, Part II, etc.) to load the Contents List for that Part of the TOGAF document into the Secondary Index frame in the left margin.
Then click in that Contents List to load a page into this main frame.

return to top of page

Downloads

Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A hardcopy book is also available from The Open Group Bookstore as document G063.

一步一步做网线

shanyiwan@live.com() — Wed, 17 Jun 2009 14:04:50 GMT

通过本篇内容的学习，你可以全面掌握双绞线网线和细同轴电缆网线的制作方法。特别是双绞线网线的制作，因为这类网络目前应用最广，还要注意不同用途的双绞线网线制作方法（如直连线线和交叉线）。

一、双绞线网线的制作

　　双绞线网线的制作其实非常简单，就是把双绞线的4对8芯网线按一定规则插入到水晶头中，所以这类网线的制作所需材料仅需双绞线和水晶头；所需工具也较简单，通常仅需一把专用压线钳即可，这在上一篇已作详细介绍，在此就不再赘述了。双绞线网线的制作其实就是网线水晶头的制作。

　　这类网线制作的难点就是不同用途的网线跳线规则不一样，下面先来看最基本的直通五类线（不用跳线）的制作方法，其它类型网线的制作方法类似，不同的只是跳线方法不一样而已。

1. 直通RJ-45接头的制作

　　为了方便读者理解，下面以Step-By-Step方式一步步向大家介绍这类网线的制作方法，后面的章节及内容也尽量按这一方式进行。

　　第1步：用双绞线网线钳（当然也可以用其它剪线工具）把五类双绞线的一端剪齐（最好先剪一段符合布线长度要求的网线），然后把剪齐的一端插入到网线钳用于剥线的缺口中，注意网线不能弯，直插进去，直到顶住网线钳后面的挡位，稍微握紧压线钳慢慢旋转一圈（无需担心会损坏网线里面芯线的包皮，因为剥线的两刀片之间留有一定距离，这距离通常就是里面4对芯线的直径），让刀口划开双绞线的保护胶皮，拔下胶皮。如图1所示。当然也可使用专门的剥线工具来剥皮线。

　　【小提示】网线钳挡位离剥线刀口长度通常恰好为水晶头长度，这样可以有效避免剥线过长或过短。剥线过长一则不美观，另一方面因网线不能被水晶头卡住，容易松动；剥线过短，因有包皮存在，太厚，不能完全插到水晶头底部，造成水晶头插针不能与网线芯线完好接触，当然也不能制作成功了。

图1

　　第2步：剥除外包皮后即可见到双绞线网线的4对8条芯线，并且可以看到每对的颜色都不同。每对缠绕的两根芯线是由一种染有相应颜色的芯线加上一条只染有少许相应颜色的白色相间芯线组成。四条全色芯线的颜色为：棕色、橙色、绿色、蓝色。

　　先把4对芯线一字并排排列，然后再把每对芯线分开（此时注意不跨线排列，也就是说每对芯线都相邻排列），并按统一的排列顺序（如左边统一为主颜色芯线，右边统一为相应颜色的花白芯线）排列。注意每条芯线都要拉直，并且要相互分开并列排列，不能重叠。然后用网线钳垂直于芯线排列方向剪齐（不要剪太长，只需剪齐即可），如图2所示。自左至右编号的顺序我们定为“1.2.3.4.5.6.7.8”。

图2

　　第3步：左手水平握住水晶头（塑料扣的一面朝下，开口朝右），然后把剪齐、并列排列的8条芯线对准水晶头开口并排插入水晶头中，注意一定要使各条芯线都插到水晶头的底部，不能弯曲（因为水晶头是透明的，所以可以从水晶头有卡位的一面可以清楚地看到每条芯线所插入的位置）。

　　第4步：确认所有芯线都插到水晶头底部后，即可将插入网线的水晶头直接放入网线钳压线缺口中，如图3所示。因缺口结构与水晶头结构一样，一定要正确放入才能使后面压下网线钳手柄时所压位置正确。水晶头放好后即可压下网线钳手柄，一定要使劲，使水晶头的插针都能插入到网线芯线之中，与之接触良好。然后再用手轻轻拉一下网线与水晶头，看是否压紧，最好多压一次，最重要的是要注意所压位置一定要正确。

图3

　　至此，这个RJ-45头就压接好了。按照相同的方法制作双绞线的另一端水晶头，要注意的是芯线排列顺序一定要与另一端的顺序完全一样，这样整条网线的制作就算完成了。

　　两端都做好水晶头后即可用网线测试仪进行测试，如果测试仪上8个指示灯都依次为绿色闪过，证明网线制作成功。如果出现任何一个灯为红灯或黄灯，都证明存在断路或者接触不良现象，此时最好先对两端水晶头再用网线钳压一次，再测，如果故障依旧，再检查一下两端芯线的排列顺序是否一样，如果不一样，随剪掉一端重新按另一端芯线排列顺序制做水晶头。如果芯线顺序一样，但测试仪在重夺后仍显示红色灯或黄色灯，则表明其中肯定存在对应芯线接触不好。此时没办法了，只好先剪掉一端按另一端芯线顺序重做一个水晶头了，再测，如果故障消失，则不必重做另一端水晶头，否则还得把原来的另一端水晶头也剪掉重做。直到测试全为绿色指示灯闪过为止。

　　如图4所示的是一条两端都制作好水晶头的网线，当然这是一条由专业公司用机器制作的双绞线网线。

图4

二、网线的跳线规则

　　以上我们所介绍的是最简单的直通网线制作方法，这类网线通常只用于从集线器（交换机）、墙上信息模块到工作站的连接，并且并不是一种最理想的制作方法。主要原因是这种网线制作没有考虑到相互芯线之间串扰，在高速网络（如100Mbps以上网络）中影响更大。为此IEEE标准委员会制定了几种特定用途的跳线方法，下面分别介绍。

　　双绞线在网络中的接线标准有以下几种：

　　（1）一一对应接法。即双绞线的两端芯线要一一对应，即如果一端的第1脚为绿色，另一端的第1脚也必须为绿色的芯线，这样做出来的双绞线通常称之为“直连线”。但要注意的是4个芯线对通常不分开，即芯线对的两条芯线通常为相邻排列。这种网线一般是用在集线器或交换机与计算机之间的连接。

　　（2）1－3、2－6交叉接法。虽然双绞线有4对8条芯线，但实际上在网络中只用到了其中的4条，即水晶头的第1、第2和第3、第6脚，它们分别起着收、发信号的作用。这种交叉网线的芯线排列规则是：网线一端的第1脚连另一端的第3脚，网线一端的第2脚连另一头的第6脚，其他脚一一对应即可。这种排列做出来的通常称之为“交叉线”，水晶头的针脚排编号规则如图5所示。

图5

　　例如，当线的一端从左到右的芯线顺序依次为：白绿、绿、白橙、蓝、白蓝、橙、白棕、棕时，另一端从左到右的芯线顺序则应当依次为：白橙、橙、白绿、蓝、白蓝、绿、白棕、棕。当线的一端从左到右的芯线顺序依次为：白橙、橙、白绿、蓝、白蓝、绿、白棕、棕时，另一端从左到右的芯线顺序则应当依次为：白绿、绿、白橙、蓝、白蓝、橙、白棕、棕。这种网线一般用在集线器（交换机）的级连、服务器与集线器（交换机）的连接、对等网计算机的直接连接等情况下。

　　（3）100M接法。这是一种最常用的网线制作规则。所谓100M接法，是指它能满足100M带宽的通讯速率。它的接法虽然也是一一对应，但每一脚的颜色是固定的，具体是：第1脚——橙白、第2脚——橙色、第3脚——绿白、第4脚——蓝色、第5脚——蓝白、第6脚——绿色、第7脚——棕白、第8脚——棕色，从中可以看出，网线的4对芯线并不全都是相邻排列，第3脚、第4脚、第5脚和第6脚包括2对芯线，但是顺序已错乱。其实这种跳线规则与下面将要介绍的信息模块端接方式B是完全一样的，当然我们也可以按信息模块端接方式A来重新排列芯线顺序，那就是：第1脚——绿白、第2脚——绿色、第3脚——橙白、第4脚——蓝色、第5脚——蓝白、第6脚——橙色、第7脚——棕白、第8脚——棕色。只不过所选方式要与下面所介绍的信息模块端接方式一致，否则所做的网线很可能就不通了。

　　这种接线方法也是应用于集线器（交换机）与工作站计算机之间的连接，也就是“直连线”所应用的范围。

三、信息模块的跳线规则

　　上面介绍了双绞线网线的跳线规则，因为在企业网络中通常不是直接拿网线的水晶头插到集线器或交换机上，而是先把来自集线器或交换机的网线与信息模块连在一起埋在墙上，所以这就涉及到信息模块芯线排列顺序问题，也即跳线规则。

　　交换机或集线器到网络模块之间的网线接线方法是按市线EIA／TIA 568标准进行，但因其有A、 B两种端接方式（IBM公司的产品通常用端接方式A，AAT＆T公司的产品通常用端接方式B，端接方式的主要区别在下述的T568A模块和T568B模块的内部固定联线方式）。两种端接方式所对应的接线顺序如下表1所示:

　　虽然从集线器或交换机到工作站的网线可以是不经任何跳线的直连线，但为了保证网络的高性能，最好同一网络采取同一种端接方式，包括信息模块和网线水晶头。水晶头和信息模块各引脚的对应顺序如图6的左、右图所示。因为在信息模块各线槽中都有相应的颜色标注，只需要选择相应的端接方式，然后按模块上的颜色标注把相应的芯线卡入相应的线槽中即可，不必去记表1所示的颜色顺序。

图6

　　【说明】图7中的1、2、3、4、5、6、7、8顺序不是随便定的，它是在把水晶头有金属弹片的一面向上，塑料扣片向下，插入RJ-45座的一头向外，从左到右依次为1、2、3、4、5、6、7、8脚。而信息模块的引脚顺序如图6右图有明确的标注，在此就不再另叙了。

四、信息模块的制作

　　了解了以上信息模块的跳线规则后，我们就可以利用在上一篇所介绍的材料和打线工具制作信息模块了。具体的制作步骤如下：

　　第1步：用剥线工具在离双绞线一端130mm长度左右把双绞线的外包皮剥去。如图7所示。

图7

　　第2步：如果有信息模块打线保护装置，则可将信息模块嵌入在保护装置上，如图8所示。

图8

　　第3步：把剥开的4对双绞线芯线分开，但为了便于区分，此时最好不要拆开各芯线线对，只是在卡相应芯线时才拆开。按照信息模块上所指示的芯线颜色线序，两手平拉上一小段对应的芯线，稍稍用力将导线一一置入相应的线槽内，如图9所示。

图9

　　第4步：全部芯线都嵌入好后即可用打线钳再一根根把芯线进一步压入线槽中（也可在第3步操作中完成一根即用打线钳压入一根，但效率低些），确保接触良好，如图10所示。然后剪掉模块外多余的线。

图10

　　【小提示】通常情况下，信息模块上会同时标记有TIA 568-A和TIA 568-B两种芯线颜色线序，应当根据布线设计时的规定，与其他连接和设备采用相同的线序。

　　第5步：将信息模块的塑料防尘片沿缺口穿入双绞线，并固定于信息模块上，如图11所示，压紧后即可完成模块的制作全过程。然后再把制作好的信息模块放入信息插座中。

图11

　　信息模块制作好后当然也可以测试一下连接是否良好，此时可用万用表进行测量。把万用表的档位打在x10的电阻档，把万用珠的一个表针与网线的另一端相应芯线接触，另一万用表笔接触信息模块上卡入相应颜色芯线的卡线槽边缘（注意不是接触芯线），如果阻值很小，则证明信息模块连接良好，否则再用打线钳压一下相应芯线，直到通畅为止。

五、细同轴电缆网线的制作

　　在20台以内的小型局域网中，目前还有一部分企业网络仍采用细同轴电缆连接，所以在此有必要对这种网线的制作进行详细介绍。具体步骤如下：

　　第1步：用同轴电缆专用剥线钳将细缆外皮剥除，露出芯线长约3mm，白色保护层约4mm，屏蔽层约8mm，如图12所示。

图12

　　第2步，将探针套入网线的芯线上，一直要插到底，然后再把套上探针的芯线插入到同轴电缆专用压线钳中间的探针小圆孔中，压紧，使探针与网线芯线紧连，如图13所示。

图13

　　第3步：将BNC连接器金属套环套入压好镀金探针的细同轴电缆，然后再将网线连接探针的一端从BNC接头小的一端插入（也要插到底），如图14所示。

图14

　　第4步：把套在网线的金属套环推到网线与BNC连接器连接处，再把网线钳的六角缺口卡在确定好的套环位置上，紧握网线钳手柄，紧压，使网线与BNC连接器通过BNC金属套环紧紧连接起来，如图15所示。压好后的金属套环呈六角形。

图15

　　至此，细缆的一端制作完成，然后，接照上面的步骤制作另一端的BNC接头。

　　细缆制作完毕以后，应当使用上述的网线测试仪进行连通性测试。如果没有网线测试仪，也可以普通的万用电表进行测试，测量时需将万用表挡位打在x10电阻档，只要用表笔的两端分别接触探针或者连接器内壁，如果电阻很小，证明网线的制作是成功的。如果任一方测试阻值较大（表针不摆动或者摆动非常小），证明网线制作不成功，连接阻抗过高，需重新制作。

　　好了，双绞线网线和同轴电缆网线的制作方法就介绍至此，相信各位已经掌握了相应的制作方法。后面的几篇中将要介绍网络组建的下一个重要方面，即网卡的有关方面，包括网卡的基础知识及配置，在这其中将涉及网络组建的最重要方面，即通信协议的选择与配置、IP地址的分配等各方面，请各位留意！