CPU编号是什么意思

UTF8其实和Unicode是同类，就是在编码方式上不同！

首先UTF8编码后的大小是不一定，不像Unicode编码后的大小是一样的！

我们先来看Unicode的编码：一个英文字母 “a” 和 一个汉字 “好”，编码后都是占用的空间大小是一样的，都是两个字节！

而UTF8编码：一个英文字母“a” 和 一个汉字 “好”，编码后占用的空间大小就不样了，前者是一个字节，后者是三个字节！

现在就让我们来看看UTF8编码的原理吧：

因为一个字母还有一些键盘上的符号加起来只用二进制七位就可以表示出来，而一个字节就是八位，所以UTF8就用一个字节来表式字母和一些键盘上的符号。然而当我们拿到被编码后的一个字节后怎么知道它的组成？它有可能是英文字母的一个字节，也有可能是汉字的三个字节中的一个字节！所以，UTF8是有标志位的！

当要表示的内容是 7位 的时候就用一个字节：0 第一个0为标志位，剩下的空间正好可以表示ASCII 0－127 的内容。

当要表示的内容在 8 到 11 位的时候就用两个字节：110 10 第一个字节的110和第二个字节的10为标志位。

当要表示的内容在 12 到 16 位的时候就用三个字节：1110 10 10 和上面一样，第一个字节的1110和第二、三个字节的10都是标志位，剩下的占湔�每梢员硎竞鹤帧BR>

以此类推：

四个字节：11110 10 10 10

五个字节：111110 10 10 10 10

六个字节：1111110 10 10 10 10 10

UTF-7：A Mail-Safe Transformation Format of Unicode(RFC1642)。这是一种使用 7 位 ASCII 码对 Unicode 码进行转换的编码。它的设计目的仍然是为了在只能传递 7 为编码的邮件网关中传递信息。 UTF-7 对英语字母、数字和常见符号直接显示，而对其他符号用修正的 Base64 编码。符号 + 和 - 号控制编码过程的开始和暂停。所以乱码中如果夹有英文单词，并且相伴有 + 号和 - 号，这就有可能是 UTF-7 编码。

关于UTF7的更多资料如下（都是英语的，如果想具体了解再看）：

UTF-7

A Mail-Safe Transformation Format of Unicode

Status of this Memo

This memo provides information for the Internet community This memo

does not specify an Internet standard of any kind Distribution of

this memo is unlimited

Abstract

The Unicode Standard, version 20, and ISO/IEC 10646-1:1993(E) (as

amended) jointly define a character set (hereafter referred to as

Unicode) which encompasses most of the world's writing systems

However, Internet mail (STD 11, RFC 822) currently supports only 7-

bit US ASCII as a character set MIME (RFC 2045 through 2049) extends

Internet mail to support different media types and character sets,

and thus could support Unicode in mail messages MIME neither defines

Unicode as a permitted character set nor specifies how it would be

encoded, although it does provide for the registration of additional

character sets over time

This document describes a transformation format of Unicode that

contains only 7-bit ASCII octets and is intended to be readable by

humans in the limiting case that the document consists of characters

from the US-ASCII repertoire It also specifies how this

transformation format is used in the context of MIME and RFC 1641,

"Using Unicode with MIME"

Motivation

Although other transformation formats of Unicode exist and could

conceivably be used in this context (most notably UTF-8, also known

as UTF-2 or UTF-FSS), they suffer the disadvantage that they use

octets in the range decimal 128 through 255 to encode Unicode

characters outside the US-ASCII range Thus, in the context of mail,

those octets must themselves be encoded This requires putting text

through two successive encoding processes, and leads to a significant

expansion of characters outside the US-ASCII range, putting non-

English speakers at a disadvantage For example, using UTF-8 together

with the Quoted-Printable content transfer encoding of MIME

represents US-ASCII characters in one octet, but other characters may

require up to nine octets

Overview

UTF-7 encodes Unicode characters as US-ASCII octets, together with

shift sequences to encode characters outside that range For this

purpose, one of the characters in the US-ASCII repertoire is reserved

for use as a shift character

Many mail gateways and systems cannot handle the entire US-ASCII

character set (those based on EBCDIC, for example), and so UTF-7

contains provisions for encoding characters within US-ASCII in a way

that all mail systems can accomodate

UTF-7 should normally be used only in the context of 7 bit

transports, such as mail In other contexts, straight Unicode or

UTF-8 is preferred

See RFC 1641, "Using Unicode with MIME" for the overall specification

on usage of Unicode transformation formats with MIME

Definitions

First, the definition of Unicode:

The 16 bit character set Unicode is defined by "The Unicode

Standard, Version 20" This character set is identical with the

character repertoire and coding of the international standard

ISO/IEC 10646-1:1993(E); Coded Representation Form=UCS-2;

Subset=300; Implementation Level=3, including the first 7

amendments to 10646 plus editorial corrections

Note Unicode 20 further specifies the use and interaction of

these character codes beyond the ISO standard However, any valid

10646 sequence is a valid Unicode sequence, and vice versa;

Unicode supplies interpretations of sequences on which the ISO

standard is silent as to interpretation

Next, some handy definitions of US-ASCII character subsets:

Set D (directly encoded characters) consists of the following

characters (derived from RFC 1521, Appendix B, which no longer

appears in RFC 2045): the upper and lower case letters A through Z

and a through z, the 10 digits 0-9, and the following nine special

characters (note that "+" and "=" are omitted):

Character ASCII & Unicode Value (decimal)

' 39

( 40

) 41

, 44

- 45

46

/ 47

: 58

63

Set O (optional direct characters) consists of the following

characters (note that "\" and "~" are omitted):

Character ASCII & Unicode Value (decimal)

! 33

" 34

# 35

$ 36

% 37

& 38

42

; 59

< 60

= 61

> 62

@ 64

[ 91

] 93

^ 94

_ 95

' 96

{ 123

| 124

} 125

Rationale The characters "\" and "~" are omitted because they are

often redefined in variants of ASCII

Set B (Modified Base 64) is the set of characters in the Base64

alphabet defined in RFC 2045, excluding the pad character "="

(decimal value 61)

Rationale The pad character = is excluded because UTF-7 is designed

for use within header fields as set forth in RFC 2047 Since the only

readable encoding in RFC 2047 is "Q" (based on RFC 2045's Quoted-

Printable), the "=" character is not available for use (without a lot

of escape sequences) This was very unfortunate but unavoidable The

"=" character could otherwise have been used as the UTF-7 escape

character as well (rather than using "+")

Note that all characters in US-ASCII have the same value in Unicode

when zero-extended to 16 bits

UTF-7 Definition

A UTF-7 stream represents 16-bit Unicode characters using 7-bit US-

ASCII octets as follows:

Rule 1: (direct encoding) Unicode characters in set D above may be

encoded directly as their ASCII equivalents Unicode characters in

Set O may optionally be encoded directly as their ASCII

equivalents, bearing in mind that many of these characters are

illegal in header fields, or may not pass correctly through some

mail gateways

Rule 2: (Unicode shifted encoding) Any Unicode character sequence

may be encoded using a sequence of characters in set B, when

preceded by the shift character "+" (US-ASCII character value

decimal 43) The "+" signals that subsequent octets are to be

interpreted as elements of the Modified Base64 alphabet until a

character not in that alphabet is encountered Such characters

include control characters such as carriage returns and line

feeds; thus, a Unicode shifted sequence always terminates at the

of a line As a special case, if the sequence terminates with the

character "-" (US-ASCII decimal 45) then that character is

absorbed; other terminating characters are not absorbed and are

processed normally

Note that if the first character after the shifted sequence is "-"

then an extra "-" must be present to terminate the shifted

sequence so that the actual "-" is not itself absorbed

Rationale A terminating character is necessary for cases where

the next character after the Modified Base64 sequence is part of

character set B or is itself the terminating character It can

also enhance readability by delimiting encoded sequences

Also as a special case, the sequence "+-" may be used to encode

the character "+" A "+" character followed immediately by any

character other than members of set B or "-" is an ill-formed

sequence

Unicode is encoded using Modified Base64 by first converting

Unicode 16-bit quantities to an octet stream (with the most

significant octet first) Surrogate pairs (UTF-16) are converted

by treating each half of the pair as a separate 16 bit quantity

(ie, no special treatment) Text with an odd number of octets is

ill-formed ISO 10646 characters outside the range addressable via

surrogate pairs cannot be encoded

Rationale ISO/IEC 10646-1:1993(E) specifies that when characters

the UCS-2 form are serialized as octets, that the most significant

octet appear first This is also in keeping with common network

practice of choosing a canonical format for transmission

Rationale The policy for code point allocation within ISO 10646

and Unicode is that the repertoires be kept synchronized No code

points will be allocated in ISO 10646 outside the range

addressable by surrogate pairs

Next, the octet stream is encoded by applying the Base64 content

transfer encoding algorithm as defined in RFC 2045, modified to

omit the "=" pad character Instead, when encoding, zero bits are

added to pad to a Base64 character boundary When decoding, any

bits at the end of the Modified Base64 sequence that do not

constitute a complete 16-bit Unicode character are discarded If

such discarded bits are non-zero the sequence is ill-formed

Rationale The pad character "=" is not used when encoding

Modified Base64 because of the conflict with its use as an escape

character for the Q content transfer encoding in RFC 2047 header

fields, as mentioned above

Rule 3: The space (decimal 32), tab (decimal 9), carriage return

(decimal 13), and line feed (decimal 10) characters may be

directly represented by their ASCII equivalents However, note

that MIME content transfer encodings have rules concerning the use

of such characters Usage that does not conform to the

restrictions of RFC 822, for example, would have to be encoded

using MIME content transfer encodings other than 7bit or 8bit,

such as quoted-printable, binary, or base64

Given this set of rules, Unicode characters which may be encoded via

rules 1 or 3 take one octet per character, and other Unicode

characters are encoded on average with 2 2/3 octets per character

plus one octet to switch into Modified Base64 and an optional octet

to switch out

Example The Unicode sequence "A<NOT IDENTICAL TO><ALPHA>"

(hexadecimal 0041,2262,0391,002E) may be encoded as follows:

A+ImIDkQ

Example The Unicode sequence "Hi Mom -<WHITE SMILING FACE>-!"

(hexadecimal 0048, 0069, 0020, 004D, 006F, 006D, 0020, 002D, 263A,

002D, 0021) may be encoded as follows:

Hi Mom -+Jjo--!

Example The Unicode sequence representing the Han characters for

the Japanese word "nihongo" (hexadecimal 65E5,672C,8A9E) may be

encoded as follows:

+ZeVnLIqe-

看一下这篇东东，相信会解决的。

消除邮件乱码

有很多朋友都被Windows系统中各式各样的乱码所困惑。特别是收到的一些十分重要的邮件程序、文件时会遇到乱码，登上港台网站时会看到乱码，还有原先显示正常的Windows桌面、菜单中的汉字形如天书，本来显示正常的各种应用程序、游戏中的汉字也成了乱码等等，真的很是急人误事！那怎么办呢？

汉字乱码分类

汉字乱码现象有4种类型：

1文本乱码：是Windows系统显示乱码，如：菜单、桌面、提示框等。这是由于注册表中有关字体部分的设置不当引起的；

2文档乱码：是各种应用程序、游戏本来显示中文的地方出现乱码。这种乱码形成的原因比较复杂，有第1类的乱码原因，也可能是软件中用到的中文动态链接库被英文动态链接库覆盖所造成的；

3文件乱码：主要是指邮件乱码；

4网页乱码：是由于港台的繁体中文大五码（BIG5）与大陆简体中文（GB2312）不通用而造成的。

消除各类乱码的方法

一 系统乱码的消除方法

这类乱码是由于在Windows注册表中，关于字体部分配置不正常造成的，即使你用内码翻译软件处理也不会消除这类乱码。那怎么办呢？请跟我来：

方法一：找一台与你的Windows版本相同且显示正常的机器，依下列步骤进行：

1在正常机器上选择“开始”→“运行”，在对话框中键入“regedit”，打开注册表编辑器；

2请你将光标定位到“HKEY_LOCAL_MACHINE\ system\CurrentControlSet\Control\Fontassoc”，然后选择“注册表”→“导出注册表文件”，再选择“分支”，导出该分支注册表信息到文件（如ZTREG）中；

3把ZTREG文件拷贝到你那显示乱码的机器上，方法是：在显示乱码的机器上运行“regedit”，打开注册表编辑器,选择“注册表”→“导入注册注册表”，把ZTREG文件导入注册表中即可。

方法二：如果你找不到一台与你的Windows版本相同且显示正常的机器，则需要手工恢复字体部分的注册表

项，其步骤是：

1首先在显示乱码的机器上选择“开始”→“运行”，在对话框中键入“regedit”，打开注册表编辑器；

2选择“HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Control\Fontassoc”，正常情况下，会有Associated DeaultFonts、Associated CharSet两个文件夹，其正确的内容应是：

子目录内容

中文Win98

中文Win98（OEM版）

中文Win2000

Associated CharSet

ANSI（00）=“yes”

GB2312（86）=“yes”

DEN（FF）=“yes”

SYMBOL（02）=“no”

ANSI（00）=“yes”

GB2312（86）=“yes”

OEM（FF）=“yes”

SYMBOL（02）=“no”

ANSI（00）=“yes”

OEM（FF）=“yes”

SYMBOL（02）=“no”

Associated DefaultFonts

AssocSystemFont=“simsunttf”

FontPackageDecorative=“宋体”

FontPackageDontcare=“宋体”

FontPackageModern=“宋体”

FontPackageRoman=“宋体”

FontPackageScript=“宋体”

FontPackageSwiss=“宋体”

或

AssocSystemFont=“simsunttf”

FontPackage=“新宋体”

FontPackageDecorative=“新宋体”

FontPackageDontcare=“新宋体”

FontPackageModern=“新宋体”

FontPackageRoman=“新宋体”

FontPackageScript=“新宋体”

FontPackageSwiss=“新宋体”

3当出现汉字乱码时，上述两个文件夹中的内容就会不完整，有的没有Associated CharSet文件夹或其中的内容残缺不全；有的Associated DefaulFonts下的内容残缺。如果遇到这种情况怎么办呢？其实你只要打开注册表编辑器，在“HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Fonassoc”下，根据以上的正确内容恢复即可。

二 应用程序、游戏乱码的消除方法

明明是中文软件，可显示界面上却出现乱码，这可能是由于注册表中关于字体设置的信息不正确地被改变而造成的，一般是因为软件的中文链接库被英文链接库覆盖而引起的，这种现象经常发生在用微软开发工具，例如VB、VC开发的中文软件上。在这类软件中，菜单等显示界面上的汉字都是受一个动态链接库“DLL文件”控制，而软件的这个动态链接库一般是安装在Win 98/2000的System目录下的，如果以后你安装了某个英文软件也使用同名的动态链接库，则英文软件的动态链接库就会覆盖掉你原先的Windows\System下的中文软件的动态链接库。这样，当你运行中文软件时就会调用英文的动态链接库，因此出现乱码。解决办法是重新安装中文软件，恢复中文动态链接库即可。

三 电子邮件乱码的消除方法

1造成电子邮件乱码的原因很多，主要有以下几个方面：

（1） *** 作系统语种不同。对于中文电子邮件，如果收信方所用的 *** 作系统是英文环境而且没有外挂中文系统或未切换为中文编码方式，也会无法看到中文，只见到乱码。所有的双字节字符（如中文简/繁体的GB和BIG5码及日文的JIS、 EUC和朝鲜文的 KSC码等）在非本语种 *** 作系统下都会出现乱码。同样在中文简体的GB码环境下看其他双字节字符时也只能看到乱码。

解决方法：安装多语言支持包或使用多内码显示平台，对收到的邮件，根据其使用的语种切换到相应的编码方式即可消除乱码。

（2）邮件服务器不支持8位（非ASCII码格式）。传输邮件的传输机制或邮件编码的不同，可能造成邮件服务器不支持8位（非ASCII码格式）传输而形成邮件乱码。例如直接发送中文或二进制等非ASCII码格式的邮件（如中文双字节文件、文件jpg、可执行文件exe或压缩文件zip等二进制文件）时，邮件服务器有可能无法处理，便把信件中每个字符的第8位都过滤掉，从而造成邮件信息的失真或损坏，在收到邮件时就是一堆乱码。

解决方法：在发送8位格式的文本文件时，必须事先进行编码，将文件转换为7位ASCII码或更少位数的格式，然后才能保证文件的正确传送。收件人收到7位或更少位格式的邮件后，可以再转换为8位的格式，这样就可避免乱码。

（3）收发端使用的E-mail软件和设置不同。一般E-mail软件的“附件”功能都可以自动对信件先进行编码，然后再送出。这样，只要收信人使用E-mail软件就能区别信件的编码方式，就可以自动将信件解码。然而由于收发件人所用的E-mail软件默认配置不同或收发件人自己定制的一些选项不同，所以在收到编码的信件后，系统不一定能识别出信件所用的编码方法，自然无法自动解码，这样就会出现乱码。

解决方法：

①可以用WinZip+IE来解码，请你把乱码邮件的内容，拷贝到剪贴板中，然后将其粘贴到记事本中，存为文本文件（例如YJtxt），再将其后缀改为uue（改为YJuue），点击此文件，会启动WinZip，然后启动IE，把WinZip中的001txt 文件拖到IE窗口中，就会显示邮件原来的内容，而不会看到乱码。

②可以根据邮件中的关键字符判断编码方法，选取合适的解码软件进行解码。邮件的编码方式主要有：UUENCODE、 Base64 encode、QPencode、BINHEX等。 UUENCODE：这是UNIX环境下使用的编码方式，目前已经很少用，大体格式为：

begin 644 kkzip M1G)O;2!I;&EN＋F)B3T!C(VEE＋FYC='4N961U＋G1W(%=E9"!;W8@(#8@,3(ZM,SDZ,C4@,3DY－ @I296－E:79E9#H@9G)O;2!F;&%B;6%I;"end

特征：乱码前面含有“begin xxx”，后面是编码前的原始文件名（如kkzip），接着是已经过编码的信件内容（如上述的乱码部分），最后一行为“end”。

解码办法：可用BECKY！EUDORA等E-mail软件，选择编码中相应的选项就可解码，也可以在E-mail软件中保存乱码邮件，存为后缀为“UUE”格式的文件，然后用Winzip 解码展开。解码后就会消除乱码。

MIME/BASE64 encode：该编码方式将3个字节用4个字节表示，由于编码后的内容是6位的，因此可避免第8位被截掉，大体格式为：

MIME－Version：10

Content－Type：text/plain; charset="us－ascii"

Content－Transfer－Encoding:base64

Status：R

SGmhQbF6pm6hSafapmK69Lj0pFexb6q＋sXqsT6Skp OWrSKXzsN3DRLFNrmGhQQ0Kq1＋sTqq6vdCx

0LF6tFit07D

dw0ShRw0KD QqtuqX9p2m2RLF6p9qoz6XOIE 1Py3Jvc29mdCuiB

JbnRlcm5ldCBN……

特征：乱码前一般有如下几部分“信头”：Content－ Type(内容类型)、CharSet(字符集)和Content－Transfer－Encoding(内容传输乱码方式)。

解码办法：用E-mail软件，选择编码中Base64 选项就可解码，解码后会消除乱码。

QpencodeQp:全称“Quoted－Printable Content－Transfer－Encoding”。因为这种格式邮件的内容都是 ASCII字符集中可以打印的字符，所以名称中含有Printable。大体格式为：

=A1A=B1z=A6n=A1I=A7=DA=A6b=BA=F4=B8=F4=A4W

=B1o

=E5==ABH=A5=F3=B0=DD=C3D=B1M=Aea=A1A

特征：内容通常有很多等号“=”，因此不需要看“信头” 也可以判断是否为QP编码。

解码办法：把邮件中类似A1A=B1z=A6n的部分编码全部复制下来，贴到一个新的纯文本文件中，然后在文件头部加入Quoted-Pintable格式的文件头：

Contenet-Type:text/plain;Charset="GB2312"

Content-Transfer-Encoding;Quoted-Pintable

然后以“EML”为后缀保存文件，用资源管理器双击打开文件即可显示正确的内容。如果还有部分汉字乱码，可以用WinZip对存盘后的EML文件进行解压，即可看到正确的内容。

BINHEX:这种编码方式大体格式为：

(This file must be converted with Binhex40)

SGmhQbF6pm6hSafapmK69Lj0pFexb6qssTqq6vdCx

0LF6tFit07Ddw0ShRw0KDQqtuqX9p2m2RLF6p9q

oz6XOIE……

解码办法：用E-mail软件对它解码；也可在E-mail软件中保存乱码邮件，存为后缀为“HQX”格式的文件，然后用WinZip解码展开，解码后会消除乱码。

UTIF-7/UTIF-8：它们是UNICODE的两种转换码。

UTIF-7编码方式大体格式为：

+SGmhQbF/6pm6hSafapmK69L/j0pFexb6q＋sXqsT6Skp OWrSKXzsN3DRLFNrmGhQQ0Kq1－sTqq6vdCx

0LF6tFit07Ddw0

ShRw0KD QqtuqX9p2m2RLF6p9qoz6XOIE 1Py3Jvc29mdCuiBJbn

Rlcm5ldCBN……

解码办法：在原E-mail头加入以下信息：

MIME－Version：10

Content－Type：text/plain; charset="utf-7"

Content－Transfer－Encoding:7bit

插入后与字符留一空行，将邮件存为“EML”后缀，然后用Outlook即可解码，消除乱码。

UTIF-8

解码办法：在原E-mail头加入以下信息：

MIME－Version：10

Content－Type：text/plain; charset="utf-8"

Content－Transfer－Encoding:8bit

将邮件存为“EML”后缀，然后用Outlook即可解码，消除乱码。

另外，还可以采用以下方法解决：

A请你在Outlook Express 中，把“查看”→“编码”选为“简体中文”；

B更改IE的设置：在IE浏览器中，打开“工具” →“Internet选项(o)”→“高级”，将“浏览”中“始终以 UTF-8 发送URL”选项前面的勾去掉；

C或将文件下载到本地硬盘里面再打开（点击鼠标右键选择“文件另存为…”）。保存文件时，文件名可能会是乱码，只需更改该文件名即可；

D或直接使用文件名为英文的附件，可以直接在IE中打开。

但有时仍不能奏效。

③无意中，笔者近日在网上冲浪时发现了一个好东西：很酷的CodeView“乱码察看器”！好事共享，不敢独吞！这就赶紧介绍给朋友们：

大名：乱码察看器

小名：CodeView

版本：250

系统平台：Win 95/98/NT/2000

CodeView“乱码察看器”顾名思义就是用来察看各种乱码的工具软件，目前已经可以支持MIME/BASE64，Quoted-Printable、HZ和UUCode 4种形式的编码和解码，通过一些特殊的算法，此程序还可以解开部分由于字节高位被屏蔽而形成的死乱码（使用其他方式的解码），另外还提供了很多附加的功能，比如单键解码功能和混合乱码识别功能，使得使用本程序解码变得非常容易和轻松，CodeView是绿色软件，无需安装，只要将得到的压缩文件解开到一个目录中即可运行。它有两种使用方法：

方法一：在有乱码的窗口中直接按下单键解码热键，默认为F7，如果窗口中的乱码能被识别，就会有一个窗口覆盖当前的乱码窗口，你可以直接在这个窗口中阅解码后的内容。在大多数情况下，笔者建议你使用这个方式。

方法二：将乱码的内容通过剪贴板复制到CodeView“乱码察看器”的源窗口中，然后你可以试着用不同的解码方式进行解码。这种方式解码将给你更多的选择自由，并且可以使用一些在单键解码中无法实现的解码方式（主要是其他方式解码和UUCode解码），对于一些单键解码无法解决的乱码，你就可以使用此方式来试试解码。

下载地址：

2避免别人收到乱码邮件的方法：

（1）发送前将邮件按7位格式重新编码

在发送8位格式的文本文件时，必须事先进行编码，将文件转换为7位ASCII码或更少位数的格式，然后才能保证文件的正确传送。收件人收到7位或更少位格式的邮件之后，可以再转换为8位的格式，这样就可以正确阅读了。在邮件客户端软件中的书写选项中，设定默认自动为7位编码。

（2）E-mail软件中的正确设置

使用英文E-mail软件应设置成：

文字设定Default CHARSET：ISO 8859-1（Latin1）

编码方式Encoding：Quoted-Printable，不可选择7位（因为7位不支持中文）

字码页Code Page（可选）：936或HZ-GB-2312

以支持整字识别邮件格式：MIME

字体：宋体

中文E-mail软件应设置成：

文字设定Default CHARSET：简体中文GB2312

编码方式Encoding：Quoted-Printable邮件格式：MIME

字体：宋体

Outlook Express中应把“简体中文（GB2312）”作为

默认的邮件使用语言，选择“国际设置”为接收的所有邮件使用默认的编码。

（3）发送重要信息时先发测试

当你需要发送重要信息时，为了确认是否无须编码即可发送正文，应该先发送测试信。而且还应确定收件人能否对附件文件进行解码。如果发送已经编码的邮件，则最好添加足够的“信头”信息，以便收件人知道所需的解码方法。建议你对UUENCODE/UUDeview编码方式用UUENCODING作信头，对Mpack编码方式用Base64 encoding作信头。

（4）转换成合适的内码

在E-mail软件的书写选项中，设定默认自动为7位编码。对用汉字系统编辑的中文邮件在发送前，最好在固定的签字栏中注明自己所使用的汉字码标准(如：GB2312、中文 HZ、GBK)；港澳台及东南亚地区邮件作者在使用BIG5码撰写完邮件、向内地发送前要转换成上述3种简体国标码中的一种形式并在签字栏中注明。如不转换则可能无法阅读，因为国内用户使用的邮件系统有很多是不支持BIG5码的。

（5）利用“附件”功能发送重要的文件

邮件系统附加这类非标准 ASCII码格式的文件时，附加文件通常可以自动进行“Base64”方式编码（仅对附件部分进行编码）。在用“附件”方式发送邮件之前，无需进行编码，否则适得其反。因为邮件软件能够自动成功解码这类 “附加”文件，因此在发送中文类邮件时应该首选这种方法。

如果无法以附件方式发送文件，则必须在正文中发送中文或二进制文件。如果发/收件人之间远隔万里，则传送过程中，第8位将可能被截掉。这时最好先在正文中用中文给收件人发一封测试信，并了解对方能否正确收到邮件正文。如果第8位被截掉，则收件人将会看到一些乱码，而不是上述的uu/b64/Qp等格式，而且这种信件几乎不可恢复。

解决方法：在你所使用的邮件系统中，选择其首选项或选项配置中的“Quoted Printalbe”或“MIME encoding”即可。

3非中文平台上，使中文电子邮件不出现乱码方法

当对方在没有中文平台的情况下打开你发的中文电子邮件时，就会出现乱码。解决办法有两种：

（1）用E-mail AID之类的工具。UCWIN GOLD 10附带的工具E-mail AID可把文本文件转换为AID格式文件，大小只比原TXT文件增加几K。写好中文邮件后，用文本格式存盘，然后用E-mail AID以AID格式保存，最后把此文件连同E-mail AID一起作为附件插在信中。对方收到信后，只需运行E-mail AID打开AID格式文件即可看到汉字，不管对方在何种语言平台下，都不会出现乱码。

（2）把中文电子邮件以图形格式保存。用画笔等绘图软件书写中文邮件，在中输入文字，用默认的BMP格式保存，将属性置为黑白模式（以减少BMP体积），然后用 WinZip把它压缩成ZIP格式，作为附件在邮件中发送，这样不管对方在何种语言平台下，都不会出现乱码。这种方法的缺点是生成的BMP中文邮件的体积比较大。

4收信方排除乱码的方法

请你在“查看(V)”下拉菜单中选中“语言”，随后出现的菜单中会包括本系统所能支持的全部汉字标准，在其中单击邮件中所指明的一种。如果收到的邮件中没有指明其所使用的汉字标准，则只可按顺序单击，直到邮件正文显示正确为止（数个汉字标准中必有一个前面有“”标记，此即你编辑器所用的汉字标准）。若使用的是Netscape,可在Option菜单的Document Encode中选择相应的项目即可。

四 关于网页、文本和文档文件乱码的消除方法

大家知道，网页乱码是浏览器对HTML网页解释时形成的。如果在网页的代码中有形如：

〈HTML〉〈HEAD〉〈META CONTENT=“text/html；charset=ISO-8859-1”〉〈/HEAD〉〈/HTML〉的语句，浏览器在显示此页时，就会出现乱码。因为浏览器会将此页语种辨认为“欧洲语系”。

解决办法：

1将语种“ISO-8859-1”改为GB2312，如果是繁体网页则改为BIG5。

2不修改网页代码，事先为浏览器安装多语言支持包（例如在安装IE时要安装多语言支持包），这样在浏览网页出现乱码时，就可以在浏览器中选择菜单栏下的“查看”→ “编码”→“自动选择””→“简体中文（GB2312），如为繁体中文，则选择“查看”→“编码”→“自动选择””→“ 繁体中文（BIG5），其他语言依此类推选择相应的语系，这样可消除网页乱码现象。

3利用多内码显示平台来转换内码。

4网页无乱码保存的方法是：用浏览器打开网页时，在 “查看”→“编码”中选择“自动选择”，存盘时保存类型选 “Web页”，编码选择“UNICOD”，这样保存过的网页再次打开时，在浏览器菜单“查看”→“编码”中不管选择简体中文（GB2312）、简体中文（HZ）还是UNICODE（UTF-8）或繁体中文（BIG5），最终显示都不会出现乱码。

Win 9x/2000中文本、文档文件的乱码，一般是繁体中文显示在简体中文系统下，或者是在相反的情况造成的。只要把原本是繁体的内码转换为简体内码（或者相反）就可消除乱码。Word 2000就能胜任这类工作，例如要把繁体中文转换为简体中文，方法是：选择要转换内码的文件，在d出的对话框中，选择“其他编码”中的“繁体中文（BIG5）”一项，打开此文件时就不会出现乱码。无乱码保存的方法：在保存时选择“文件”中的“另存为”，先存为 “Word文档”，存盘后打开再存为纯文本等其他格式；你也可以用Word 2000的“中文简繁转换”工具实现无乱码保存，方法是在菜单栏中选择“工具 ”→“语言”→“中文简繁转换”，内码转换后再保存。金山公司的WPS 2000也能转换内码，支持GB2312、BIG5、GBK等3种主要的汉字编码，并可在输出RTF、TXT、HTM格式文件时对内码进行转换。除此之外，消除这类乱码还可用内码转换工具，可以对BIG5（繁体中文）和GB2312（国标码、简体中文）进行相互转换来消除乱码。

最后,台湾出的繁体游戏一般会出现乱码,用w2kxpcjk2这个工具就可以解决了~300多K的一个东西，可以去网上搜索下载~

在我们使用电脑特别是用电脑上网的时候，往往会碰到电脑显示乱码的情况，这些乱码让人摸不着头脑，给使用者带来了极大的不便，下面针对几个不同的情况分析如何消除电脑显示中的乱码。

1、电子邮件中的乱码问题

在使用电子邮件的时候，接收方往往会碰到乱码，那么如何处理这些乱码呢？

首先，从接收方来说，如果用户没有安装中文Windows *** 作平台，则可以加载中文之星这一类的软件。这样，由于缺乏中文支持环境而引起的乱码现象就可以迎刃而解了，对于因使用不同字符集而引起的乱码现象，可以通过选择另外一种字符集而解决。以Outlook为例，其可供选择的字符集有简体中文（GB2312）、简体中文（HZ）等多种，可以依次试着选择其中一种字符集，看能否解决乱码问题。

其次，从发送方来说，可以将信函的内容存为其它格式的文件，如Word格式、文本文件格式、超文本文件格式等作为附件发送给对方。如果对方是海外亲友，而又没有安装中文Windows *** 作系统，则可以将信函内容制作成位图格式（bmp）以图形的方式发送给对方，这样对方即使没有中文 *** 作系统，也可以阅读中文电子邮件了。具体的方法如下:选择Windows的画图程序，再选择工具栏中的文字，这时就可以输入中文内容了，整封信写好后，存为bmp格式，然后在邮件中将这一文件插入邮件正文或作为附件发送出去均可。这样对方收到作为图形的中文邮件后就会一目了然。这里需要说明的是，由于图形文件较大，为了传输更快捷，最好在选择颜色时，选择单一的颜色以尽可能地减少文件的长度；另一种方法是，先用记事本录入信件的内容，然后存为文本文件格式。再用文本文件转换软件txt2exe将文本文件转达成可执行文件，将这一可执行文件作为附件发送给收件人，对方收到邮件后，只需执行这个文件即可阅读中文函件。

2、浏览网页时碰到乱码

由于在制作网页的过程中所使用的字符集的不同，由此带来的在阅读网页时碰到乱码现象的解决方法如下:若使用的是Netscape浏览器，则选“查看”菜单中的“代码”项，其中有繁体中文（BIG5）、繁体中文（EUC-TW）、简体中文（GB2312）等多种代码可供选择；若用户使用的是IE浏览器，则选“查看”菜单中的“字体”选项，其中有简体中文（GB2312）、简体中文（HZ）等多种字体可供选择。试着选用其中一种汉字字符，一般来说即可解决问题。

3、中文Windows乱码

使用中文Windows时，偶尔会出现一些乱码（只是某些情况下出现），这是由于不同的软件使用的汉字字符集不同而造成的，具体的解决办法是修改注册表中的相关内容，步骤是:运行Windows目录中的注册表编辑器regeditexe，选择“我的电脑\HKEY_ LOCAL_MACHINE\System\CurrentControlSet \control\fontassoc\AssociatedCharset”。将ANSI（00）的键值设为yes,将GB2312（86）的键值设为yes，将OEM（FF）的键值设为Yes，将SYMBOL（02）的键值设为No。部分汉字显示的乱码问题即可解决。

4、其它亚洲文字的乱码问题

在碰到日文、韩文及汉字BIG5码等编码集时，可以运行东方快车2000、 RichWin97等软件，这类软件均可识别多种编码，从而达到消除乱码的目的。

参考资料：

我家的电脑有几次都是安装新程序出现乱码，第一次是按照PS，在笔记本上安装完全没有问题，换台式机就乱码了；昨天又安装一个游戏，结果又是乱码了，这是怎么回事呢？哪出毛病了？

请大家指教哦！

谢谢！

可以说是用于区分CPU性能的重要标识，但是对于超频爱好者来说。

1：CPU编号的意义就变得十分重要了，因为通过这些编号可以辨认一块CPU是否具有出色的超频能力。当然对于普通的电脑用户来说，CPU编号同样具有不可替代的意义。当我们接触散装CPU时，完全可以通过编号来了解CPU的真正身份！

2：通常情况下，电脑用户可以在CPU的表面看到编号。根据CPU外壳材质的不同，这个编号有可能是印在标贴上的，也可能是刻在外壳上的。如果CPU采用了利于散热的金属外壳封装，编号就会刻在金属外壳上。如果CPU采用了普通封装，编号则会印在CPU表面的标贴上。接下来，笔者以AMD的Sempron 2600+为例进行介绍，帮助各位读者完全了解其编号的含义。

以上就是关于关于 UTF7 和 UTF8编码的问题全部的内容，包括:关于 UTF7 和 UTF8编码的问题、计算机管理 服务 乱码是怎么回事！、CPU编号是什么意思等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！