1、使用UltraEdit修改当前编辑的文本的编码
第一种方式：File -> Conversion
第二种方式：View -> Set Code Page
如果要在十六进制模式下编辑可以按Ctrl+H
2、对GBK编码的一个普遍误解
根据维基百科上的说明，GBK编码字符的方式包括一字节和双字节编码，00–7F范围内是一位，和ASCII保持一致，此范围内严格上说有96个文字和32个控制符号。之后的双字节中，前一字节是双字节的第一位。总体上说第一字节的范围是81–FE（也就是不含80和FF），第二字节的一部分领域在40–7E，其他领域在80–FE。即：
高字节：0x81~0xFE 低字节：0x40~0x7E 0x80~0xFE（即排除了xx7F）
GBK的编码范围如下表：
| 范围 | 第1字节 | 第2字节 | 编码数 | 字数 |
|---|---|---|---|---|
| 水准 GBK/1 | A1–A9 |
A1–FE |
846 | 717 |
| 水准 GBK/2 | B0–F7 |
A1–FE |
6,768 | 6,763 |
| 水准 GBK/3 | 81–A0 |
40–FE (7F除外) |
6,080 | 6,080 |
| 水准 GBK/4 | AA–FE |
40–A0 (7F除外) |
8,160 | 8,160 |
| 水准 GBK/5 | A8–A9 |
40–A0 (7F除外) |
192 | 166 |
| 用户定义 | AA–AF |
A1–FE |
564 | |
| 用户定义 | F8–FE |
A1–FE |
658 | |
| 用户定义 | A1–A7 |
40–A0 (7F除外) |
672 | |
| 合计: | 23,940 | 21,886 |
GBK汉字是双字节编码，而ASCII字符是单字节编码。网上有人这样说：
GBK的文字编码是双字节来表示的，即不论中、英文字符均使用双字节来表示，只不过为区分中文，将其最高位都定成1。
它对英文使用8位（即一个字节），中文使用24为（三个字节）来编码。
这段话我感觉读得费劲，逻辑好像也有矛盾。于是在UltraEdit中查看“汉字编码hi”这段GBK文本，其编码如下：
可以看出"汉字编码"对应"BA BA D7 D6 B1 E0 C2 EB"这8个字节（2个十六进制对应一个字节），即每个汉字对应2个字节。而"hi"对应"68 69"两个字节，即每个ASCII字符对应1个字节。
GBK编码的汉字的特征是：占两个字节，并且第一个字节的值小于0。所以网上找出一段GBK文本中的汉字的C语言代码实现如下：
#include <stdio.h> int main(void) { char a[10]="C语言"; int i; for (i = 0; a[i]; i++) if (a[i]<0) { printf("Chinese :%c%c\n",a[i],a[i+1]); i++; } else printf("Not Chinese:%c\n",a[i]); return 0; }
3、Unicode BOM（Byte Order Mark）
Unicode几种编码的BOM如下:
UTF-32, big-endian 文件的前4个byte是:00 00 FE FF
UTF-32, little-endian文件的前4个byte是:FF FE 00 00
UTF-16, big-endian文件的前2个byte是:FE FF
UTF-16, little-endian文件的前2个byte是:FF FE
UTF-8文件的前3个byte是:EF BB BF
UTF-7的规律特殊一点,不是前几个byte,而是所有的byte转换为十进制都小于127.
但BOM没有得到广泛支持，所以不是一定的。
各种编辑软件在保存文件并指定编码为UTF8时是否带BOM情况：
1. notepad notepad 在保存时，选择UTF-8 格式，会在文件头写上BOM header.读取文件时，会分析BOM和文件中是否有中文字符，进而做出正确的选择。 2. notepad++ 可以设置各种格式，有无BOM都支持。 3. editplus 文件保存时，选择UTF-8 格式，不会在文件头写上 BOM header.读取可以识别UTF-8 4. ultraedit ultraedit在advanced->configuration中可以选择文件保存时是否写上BOM header.或者另存为中选择。读取是，如果没有设置自动检测UTF-8或者部分无BOM文件会无法正常显示。 5. Eclipse 如果设置了文件的编码问UTF-8，那么文件保存为无BOM格式。读取正常。 6. vi 指的是Linux下的vim, 如果UTF-8 文件开头有BOM header, 其能够正常显示UTF-8 编码，否则，显示为乱码。
比如用notepad编辑文本"UTF8编码"，然后指定编码为UTF8，保存，再用MadEdit打开如下：
可以看到U对应的十六进制55之前还有3个字节 EF BB BF，这就是UTF8编码对应的BOM头。而不带BOM头的UTF8编码的情况如下图：
所以如果处理一段UTF8编码的字符串的字节流时，必须先判断前三个字节是否EF BB BF，即UTF8编码对应的BOM头。
4、UltraEdit下查看UTF8文本出现“奇怪文字”解决
在UltraEdit 18.20专业版下查看UTF8文本出现“奇怪文字”，如下（内容正常情况应该是"UTF8编码"）：
搜索了好一会，发现可能是UltraEdit对文件编码类型检测错误导致。于是装了一个新软件MadEdit（与PsPad一起号称可以替代UltraEdit），打开后，就正常了，如下（Alt+3切换到十六进制模式）：
5、为什么记事本选择ANSI编码保存中文，也可以正常显示中文而不乱码？
在简体中文系统下，ANSI 编码代表 GB2312 编码,《信息交换用汉字编码字符集》是由我国国家标准总局1980年发布，1981年5月1日开始实施的一套国家 汉字编码字符标准，标准号是GB 2312—1980。它是计算机可以识别的编码，适用于汉字处理、汉字通信等系统之间的信息交换。基本集共收入汉字6763个和非汉字图形字符682个。整个字符集分成94个区，每区有94个位。每个区位上只有一个字符，因此可用所在的区和位来对汉字进行编码。
6、一个小实验
用记事本写 连通 两个字，另存为liantong.txt，并选择编码方式为ANSI。然后再用记事本打开liantong.txt可以发现乱码了。
而用EmEditor、EditPlus、UltraEdit、Notepad++、Word等打开就能正常显示，原因就是记事本软件在检测文件字符编码上很弱。
上面的liantong.txt文件采用的是GB2312编码，如果你再另存为liantong2.txt，并选择编码方式为UTF-8，那么之后用EmEditor、EditorPlus等软件打开也乱码了。然后再打开liantong2.txt，另存为liantong3.txt，又选择ANSI编码，你猜结果会如何？结果是liantong3.txt用EmEditor、EditorPlus打开也乱码，因为在你另存liantong2.txt时，附加了UTF-8 BOM头。导致将liantong2.txt另存为liantong3.txt时信息丢失。是不是很混乱，来几张图就明白了：
最初liantong.txt采用GB2312编码，十六进制表示如下：
随后liantong2.txt采用UTF-8编码，十六进制表示如下：
最后liantong3.txt又采用GB2312编码，十六进制表示如下（在用GB2312编码liantong2.txt中的字节时，发现GB2312中无对应，就用全部用3F代替了）：
7、为什么UTF-8编码的文件不加BOM头也可以正常识别？（http://www.cnblogs.com/chengmo/archive/2010/10/30/1864004.html）
这个问题估计很多朋友都会产生疑问，为什么utf-16不指定就读乱码，而utf-8可以。我们可以从下面的例子看下： utf-8是怎么样从unicode转换而来了
Unicode编码(16进制) ║ UTF-8 字节流(二进制) 000000 - 00007F ║ 0xxxxxxx 000080 - 0007FF ║ 110xxxxx 10xxxxxx 000800 - 00FFFF ║ 1110xxxx 10xxxxxx 10xxxxxx 010000 - 10FFFF ║ 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
从上面看，发现规律没有？第一个自己开头有几个”1”,后面就对应有几个10开头字节了。 这样我们都可以通过正则进行检测了.
[\x09\x0A\x0D\x20-\x7E] # ASCII
|[\xC2-\xDF][\x80-\xBF] # non-overlong 2-byte
|\xE0[\xA0-\xBF][\x80-\xBF] # excluding overlongs
|[\xE1-\xEC\xEE\xEF][\x80-\xBF]{2} # straight 3-byte
|\xED[\x80-\x9F][\x80-\xBF] # excluding surrogates
|\xF0[\x90-\xBF][\x80-\xBF]{2} # planes 1-3
|[\xF1-\xF3][\x80-\xBF]{3} # planes 4-15
|\xF4[\x80-\x8F][\x80-\xBF]{2} # plane 16
由于它独特的编码存储特点，因此目前常见文本处理软件就能够自动分析出来。（editplus、notepad++等)