博客园_白天有雨

心理课堂：对付拖延症(转)

2011-10-08T08:49:00Z

谨以此文，与小站所有童鞋共勉。^_^

上大学以后，我开始有了拖延的毛病。立下目标无数，但时常却动力奇缺，常常在网上浏览着各色的小说和帖子，或是玩很无聊的弱智在线小游戏，却不愿碰专业书本或文献一下，甚至哪怕deadline就在几天之后，只有在deadline之前一点点时间才会因紧迫感而开始着手学习任务。这样下来，学业上总体来说算是马马虎虎，但却离自己的理想越来越远。总之，就是无法完全地上进，又不愿彻底地堕落。

拖延的基础，实际上是对自身很高甚至不切实际的期望。如果说完成任务是走过一块一人宽、十米长的厚木板，那么当它放在地面上时，几乎人人都可以轻松地走过。但对结果的高期望则像是将这块木板架到了两座高楼间十层楼高的地方，于是我们会害怕掉下去，即害怕失败或害怕成功（比如我有时偷偷希望实验不要成功，这样我就可以不用面对之后更大强度的后续实验，其实是害怕失败的一种变体），于是我们甚至不敢向前迈上一步。而deadline则是身后的一团火，当它离我们足够近时，害怕被烧着的恐惧感战胜了对掉下去的恐惧感，于是我们一下子冲了过去，在deadline前赶完了任务，尽管质量很难说。

更可怕的是，很多拖延的人（包括我自己）甚至很享受那种deadline过后突然一下放松的感觉，而且拖延的结果有时反而挺好（比如我本科时写实验报告，如果我拖到最后，我往往可能因为能够和其他人讨论并参考其他人的观点而比我先完成要写得更全面更好）。这种时候，我会在心里表扬自己很有“效率”。同时，长期这样下来，尽管我不愿承认，但我潜意识里确实觉得自己如果花了很多时间成绩却平平，会是一件非常丢脸的事情。于是这一切的一切，都再次强化的拖延—— 即使结果不好，我也可以说，那是因为我没尽全力，如果我真正努力，肯定会结果很好的（心理学上的高自尊人格）。

但我们不能永远靠放火来逼自己走过木板，那样的话，总会有烧着自己的一天；而且，那种压抑的焦虑感和对自己不满意的感觉也并不令人愉快。因此，最好的办法是将木板的高度降低——不要对自己的结果（比如分数）太高的要求，认真完成就好。由于我们的天资和其它能力的限制，也许即使我们竭尽全力也无法像某些出众人物一样做得那么好，但不管怎么样，绝大多数情况下，尽力的结果都会比我们不去努力要来得好得多，不是吗？

对此在豆瓣的那个帖子里有一个非常有趣的方法。那位作者将一篇论文拖了几个月之久都不愿开写，她的心理师让她不要管好坏，以她可以写出的最差的论文为目标写一篇出来作为试验。作者照做了，然后惊讶地发现她写出来的“最差”的文章竟然挺让自己满意的，感觉稍做修改就可以交给导师过目了。当然，有时写出来的初稿和论文要求还是有差距的，比如要求12页但初稿只有5页。这种情况下作者就用了心理师教她的另一个方法：每次工作一个小时，目标是让论文多一页，同样以“最差”为目标。这个方法实际就是大大降低了拖延者做事的心理成本和负担，相当于把“木板”放到了“地面”上。不妨一试。

人的完美倾向，严重点就是完美主义，在拖延中也起了很大作用。当我想起幼时的远大理想并希望为之努力时，我只要想起我的同学中无处不在的“牛人”，便会觉得自己已经浪费了太多时间，而且别人现在不仅比我强得多，更因为他自身的优势而占有了比我更好的资源，所以我现在即使努力估计也赶不上他了，更别提什么远大的理想了，于是就又开始了拖延。

事实上，这就像是一场马拉松，你在开始因为种种原因落后于别人不少，于是你就开始纠结自己到底有没有跑下去的必要，却不努力去跑，于是被拉得更远。这时，你望着遥远的终点，感觉很绝望，都不想跑下去了。这时，如果你不去看不去想重点，也不去想别人，只看着自己的脚下跑——“管它呢，我先跑过这个小土丘再说。”就这样一个小目标一个小目标地跑，最终你一定会跑到终点线，那时你也许会发现，你并不是最慢的，甚至是很不错的。所以，专注于你努力的过程而非最后的结果，为你认真学习了一个下午或认真做了一个实验而不是最后考试的那个A或一个漂亮的实验结果而表扬自己，你会发现完成工作其实不怎么难。

另外，专注于当下对拖延者来说也是很需要注意的一个地方。这里说的专注于当下，不是指专注于你现在脑子里的想法和情绪，而是专注于你现在在做的或选择要做的事情。其实，很多拖延的人恰恰就是太过关注自己一时的情绪，比如觉得自己不开心了，得放松一下，上上网……然后就开始了拖延。其实从心理学角度来说，过于关注自己一时的情绪是不懂得推迟满足感的一种表现，就像小孩子想要一个玩具就非要马上得到不可一样，这样的做法会大大削弱一个人的自制力。而且，心理学实验表明，满足自己一时的情绪需求并非最佳策略，从长期角度上来讲，它会降低一个人的自我满足感和幸福感而非增加，想想因为玩乐休闲而拖延了工作后自己的负罪感和焦虑感就知道了。

在这个方面，我个人认为森田疗法的理念是很适用的。具体而言，就是不去理会那些打搅你的情绪波动（比如对自己说：“你要郁闷就郁闷吧，不管你了。”然后就不理会了），顺其自然，专心做你要做的事情。就像一颗小石子投入湖中，会泛起一圈圈涟漪，你若不理，湖面最终会自己平静下来；倘若你过于注意那颗小石子，试图把它捞出来，反而会激起更大的波澜，使湖面不得平静。豆瓣那个帖子的作者提供了一个方法，我觉得也是很有用的：把你当时因为一时情绪想要做的事情（比如上网、玩游戏、看电影、看小说等等）记下来，告诉自己等你做完工作就去做那些事情，然后就专心工作，等到工作结束再去做记下的事情。

此外，不要为未来过度操心也是专注当下的一个方面。这点很容易理解，我就不在此赘言了。

同时，对于已经发生的不愉快的事情，或是对自己过去行为的不满，面对和接受好了，不必逃避。但面对和接受不是放任自流，而是不再沉浸于自责、痛苦等负面情绪中，客观地更好地理解当下的状况，进而为以后做打算。这一点可以和前文提到的“马拉松”的例子联系起来，只有真正面对和接受了你落后于别人的事实，你才不会为“我想得第一可是却落后别人那么多”之类的想法而纠结，进而才能以现实为基础，踏踏实实地努力去跑。

另外，在看书的时候（当然也有其它时候），很多人都常有“刚才看了好几页却不知道讲了些什么”的“不自主飞翔”的神游体验。对此，养成发现新事物的习惯，像初生的婴儿一样去看世界，是很有好处的。无论在什么环境中，时刻注意那些熟悉的东西有什么变化，比如看书，就可以注意想想这书里讲的和我以前知道的有什么不同又有什么联系、有什么很有意思的地方等等，慢慢地，就能做到专注于当下而不至于迷失。

战胜拖延，追根究底，还是要改变自己的思维方式。这并不容易，但不是不可能。改变思维方式，尤其是改变潜意识，最重要的是要改变自我对话的方式。下面是一些自我对话的tips（括号里是要丢弃的自我对话方式）：

1.我选择/我想要…… （vs.我必须/我一定得……）

2.这个任务我可以每次做一小步（vs.这个任务太大了）

3.我今天要开始做…… （vs.我今天必须完成……）

4.我也可以是平凡人（vs.我必须完美/出类拔萃）

5.我一定要休息娱乐/休息娱乐是正常生活的一部分（vs.我没空休息娱乐/休息娱乐就是偷懒）

我想大多数有拖延情况的人也许都还没到严重成“症”的地步，但也或多或少地被它影响了生活，影响了对心中理想的追寻。克服一个问题并不简单，需要自己给自己很多的支持与鼓励，期间也许会有许多的反复，但只要我们的大方向是好的，我们就该肯定自己。

“认识到眼前残酷（这个词程度太深，但我想不出换什么好）的现实，同时又看到未来的光明与希望。”这是我一直很欣赏的对生活的态度。

本文链接

Ado方式导入excel混用数据类型引起数据缺失问题解决方法

2011-09-26T02:01:00Z

1.设置HDR=NO; IMEX=1

参数HDR的值：

HDR=Yes，这代表第一行是标题，不做为数据使用，如果用HDR=NO，则表示第一行不是标题，做为数据来使用。系统默认的是YES

参数 IMEX

IMEX ( IMport EXport mode )设置

当 IMEX=0 时为“汇出模式”，这个模式开启的 Excel 档案只能用来做“写入”用途。

当 IMEX=1 时为“汇入模式”，这个模式开启的 Excel 档案只能用来做“读取”用途。

当 IMEX=2 时为“连結模式”，这个模式开启的 Excel 档案可同时支援“读取”与“写入”用途。

2. 修改注册表，设置 TypeGuessRows 为 0

默认情况下，驱动程序会扫描前 8 行数据，来对数据类型进行采样。设置为 0 ，将对列的所有行进行扫描，如果前八行采样数据都是数值类型的话，设置 IMEX = 1 也不会将剩下的行的默认数据类型转换为文本，它将保留数值类型，也就是把整个列当成数字类型对待。因此，要想得到完整的数据，需要修改注册表的设置 TypeGuessRows 为 0。TypeGuessRows 在注册表的位置：

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel]

Windows 7等 64 系统：

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Jet\4.0\Engines\Excel]

3. 在单元格前面加'

设置 TypeGuessRows 为 0 将会导致性能的下降。IMEX=1 数据内容也能出现不正常的现象，比如长数字可能会出现科学计数法的格式显示。比较好的做法是导出前，对所有单元格进行处理，在单元格内容前面加 '。

本文链接

深入分析 Java 中的中文编码问题(转)

2011-09-09T06:08:00Z

许令波, Java 工程师, 淘宝网

简介： 编码问题一直困扰着开发人员，尤其在 Java 中更加明显，因为 Java 是跨平台语言，不同平台之间编码之间的切换较多。本文将向你详细介绍 Java 中编码问题出现的根本原因，你将了解到：Java 中经常遇到的几种编码格式的区别；Java 中经常需要编码的场景；出现中文问题的原因分析；在开发 Java web 程序时可能会存在编码的几个地方，一个 HTTP 请求怎么控制编码格式？如何避免出现中文问题？

本文的标签： encoding, java, 中的中文编码, 字符, 编码

标记本文！

发布日期： 2011 年 7 月 06 日
级别： 中级
访问情况 10468 次浏览
建议： 9 (查看或添加评论)

几种常见的编码格式

为什么要编码

不知道大家有没有想过一个问题，那就是为什么要编码？我们能不能不编码？要回答这个问题必须要回到计算机是如何表示我们人类能够理解的符号的，这些符号也就是我们人类使用的语言。由于人类的语言有太多，因而表示这些语言的符号太多，无法用计算机中一个基本的存储单元—— byte 来表示，因而必须要经过拆分或一些翻译工作，才能让计算机能理解。我们可以把计算机能够理解的语言假定为英语，其它语言要能够在计算机中使用必须经过一次翻译，把它翻译成英语。这个翻译的过程就是编码。所以可以想象只要不是说英语的国家要能够使用计算机就必须要经过编码。这看起来有些霸道，但是这就是现状，这也和我们国家现在在大力推广汉语一样，希望其它国家都会说汉语，以后其它的语言都翻译成汉语，我们可以把计算机中存储信息的最小单位改成汉字，这样我们就不存在编码问题了。

所以总的来说，编码的原因可以总结为：

计算机中存储信息的最小单元是一个字节即 8 个 bit，所以能表示的字符范围是 0~255 个
人类要表示的符号太多，无法用一个字节来完全表示
要解决这个矛盾必须需要一个新的数据结构 char，从 char 到 byte 必须编码

如何“翻译”

明白了各种语言需要交流，经过翻译是必要的，那又如何来翻译呢？计算中提拱了多种翻译方式，常见的有 ASCII、ISO-8859-1、GB2312、GBK、UTF-8、UTF-16 等。它们都可以被看作为字典，它们规定了转化的规则，按照这个规则就可以让计算机正确的表示我们的字符。目前的编码格式很多，例如 GB2312、GBK、UTF-8、UTF-16 这几种格式都可以表示一个汉字，那我们到底选择哪种编码格式来存储汉字呢？这就要考虑到其它因素了，是存储空间重要还是编码的效率重要。根据这些因素来正确选择编码格式，下面简要介绍一下这几种编码格式。

ASCII 码

学过计算机的人都知道 ASCII 码，总共有 128 个，用一个字节的低 7 位表示，0~31 是控制字符如换行回车删除等；32~126 是打印字符，可以通过键盘输入并且能够显示出来。

ISO-8859-1

128 个字符显然是不够用的，于是 ISO 组织在 ASCII 码基础上又制定了一些列标准用来扩展 ASCII 编码，它们是 ISO-8859-1~ISO-8859-15，其中 ISO-8859-1 涵盖了大多数西欧语言字符，所有应用的最广泛。ISO-8859-1 仍然是单字节编码，它总共能表示 256 个字符。

GB2312

它的全称是《信息交换用汉字编码字符集基本集》，它是双字节编码，总的编码范围是 A1-F7，其中从 A1-A9 是符号区，总共包含 682 个符号，从 B0-F7 是汉字区，包含 6763 个汉字。

全称叫《汉字内码扩展规范》，是国家技术监督局为 windows95 所制定的新的汉字内码规范，它的出现是为了扩展 GB2312，加入更多的汉字，它的编码范围是 8140~FEFE（去掉 XX7F）总共有 23940 个码位，它能表示 21003 个汉字，它的编码是和 GB2312 兼容的，也就是说用 GB2312 编码的汉字可以用 GBK 来解码，并且不会有乱码。

GB18030

全称是《信息交换用汉字编码字符集》，是我国的强制标准，它可能是单字节、双字节或者四字节编码，它的编码与 GB2312 编码兼容，这个虽然是国家标准，但是实际应用系统中使用的并不广泛。

UTF-16

说到 UTF 必须要提到 Unicode（Universal Code 统一码），ISO 试图想创建一个全新的超语言字典，世界上所有的语言都可以通过这本字典来相互翻译。可想而知这个字典是多么的复杂，关于 Unicode 的详细规范可以参考相应文档。Unicode 是 Java 和 XML 的基础，下面详细介绍 Unicode 在计算机中的存储形式。

UTF-16 具体定义了 Unicode 字符在计算机中存取方法。UTF-16 用两个字节来表示 Unicode 转化格式，这个是定长的表示方法，不论什么字符都可以用两个字节表示，两个字节是 16 个 bit，所以叫 UTF-16。UTF-16 表示字符非常方便，每两个字节表示一个字符，这个在字符串操作时就大大简化了操作，这也是 Java 以 UTF-16 作为内存的字符存储格式的一个很重要的原因。

UTF-8

UTF-16 统一采用两个字节表示一个字符，虽然在表示上非常简单方便，但是也有其缺点，有很大一部分字符用一个字节就可以表示的现在要两个字节表示，存储空间放大了一倍，在现在的网络带宽还非常有限的今天，这样会增大网络传输的流量，而且也没必要。而 UTF-8 采用了一种变长技术，每个编码区域有不同的字码长度。不同类型的字符可以是由 1~6 个字节组成。

UTF-8 有以下编码规则：

如果一个字节，最高位（第 8 位）为 0，表示这是一个 ASCII 字符（00 - 7F）。可见，所有 ASCII 编码已经是 UTF-8 了。
如果一个字节，以 11 开头，连续的 1 的个数暗示这个字符的字节数，例如：110xxxxx 代表它是双字节 UTF-8 字符的首字节。
如果一个字节，以 10 开始，表示它不是首字节，需要向前查找才能得到当前字符的首字节

回页首

Java 中需要编码的场景

前面描述了常见的几种编码格式，下面将介绍 Java 中如何处理对编码的支持，什么场合中需要编码。

I/O 操作中存在的编码

我们知道涉及到编码的地方一般都在字符到字节或者字节到字符的转换上，而需要这种转换的场景主要是在 I/O 的时候，这个 I/O 包括磁盘 I/O 和网络 I/O，关于网络 I/O 部分在后面将主要以 Web 应用为例介绍。下图是 Java 中处理 I/O 问题的接口：

Reader 类是 Java 的 I/O 中读字符的父类，而 InputStream 类是读字节的父类，InputStreamReader 类就是关联字节到字符的桥梁，它负责在 I/O 过程中处理读取字节到字符的转换，而具体字节到字符的解码实现它由 StreamDecoder 去实现，在 StreamDecoder 解码过程中必须由用户指定 Charset 编码格式。值得注意的是如果你没有指定 Charset，将使用本地环境中的默认字符集，例如在中文环境中将使用 GBK 编码。

写的情况也是类似，字符的父类是 Writer，字节的父类是 OutputStream，通过 OutputStreamWriter 转换字符到字节。如下图所示：

同样 StreamEncoder 类负责将字符编码成字节，编码格式和默认编码规则与解码是一致的。

如下面一段代码，实现了文件的读写功能：

清单 1.I/O 涉及的编码示例

String file = "c:/stream.txt"; 
 String charset = "UTF-8"; 
 // 写字符换转成字节流
 FileOutputStream outputStream = new FileOutputStream(file); 
 OutputStreamWriter writer = new OutputStreamWriter( 
 outputStream, charset); 
 try { 
    writer.write("这是要保存的中文字符"); 
 } finally { 
    writer.close(); 
 } 
 // 读取字节转换成字符
 FileInputStream inputStream = new FileInputStream(file); 
 InputStreamReader reader = new InputStreamReader( 
 inputStream, charset); 
 StringBuffer buffer = new StringBuffer(); 
 char[] buf = new char[64]; 
 int count = 0; 
 try { 
    while ((count = reader.read(buf)) != -1) { 
        buffer.append(buffer, 0, count); 
    } 
 } finally { 
    reader.close(); 
 }

在我们的应用程序中涉及到 I/O 操作时只要注意指定统一的编解码 Charset 字符集，一般不会出现乱码问题，有些应用程序如果不注意指定字符编码，中文环境中取操作系统默认编码，如果编解码都在中文环境中，通常也没问题，但是还是强烈的不建议使用操作系统的默认编码，因为这样，你的应用程序的编码格式就和运行环境绑定起来了，在跨环境下很可能出现乱码问题。

内存中操作中的编码

在 Java 开发中除了 I/O 涉及到编码外，最常用的应该就是在内存中进行字符到字节的数据类型的转换，Java 中用 String 表示字符串，所以 String 类就提供转换到字节的方法，也支持将字节转换为字符串的构造函数。如下代码示例：

String s = "这是一段中文字符串"; 
 byte[] b = s.getBytes("UTF-8"); 
 String n = new String(b,"UTF-8");

另外一个是已经被被废弃的 ByteToCharConverter 和 CharToByteConverter 类，它们分别提供了 convertAll 方法可以实现 byte[] 和 char[] 的互转。如下代码所示：

ByteToCharConverter charConverter = ByteToCharConverter.getConverter("UTF-8"); 
 char c[] = charConverter.convertAll(byteArray); 
 CharToByteConverter byteConverter = CharToByteConverter.getConverter("UTF-8"); 
 byte[] b = byteConverter.convertAll(c);

这两个类已经被 Charset 类取代，Charset 提供 encode 与 decode 分别对应 char[] 到 byte[] 的编码和 byte[] 到 char[] 的解码。如下代码所示：

Charset charset = Charset.forName("UTF-8"); 
 ByteBuffer byteBuffer = charset.encode(string); 
 CharBuffer charBuffer = charset.decode(byteBuffer);

编码与解码都在一个类中完成，通过 forName 设置编解码字符集，这样更容易统一编码格式，比 ByteToCharConverter 和 CharToByteConverter 类更方便。

Java 中还有一个 ByteBuffer 类，它提供一种 char 和 byte 之间的软转换，它们之间转换不需要编码与解码，只是把一个 16bit 的 char 格式，拆分成为 2 个 8bit 的 byte 表示，它们的实际值并没有被修改，仅仅是数据的类型做了转换。如下代码所以：

ByteBuffer heapByteBuffer = ByteBuffer.allocate(1024); 
 ByteBuffer byteBuffer = heapByteBuffer.putChar(c);

以上这些提供字符和字节之间的相互转换只要我们设置编解码格式统一一般都不会出现问题。

回页首

Java 中如何编解码

前面介绍了几种常见的编码格式，这里将以实际例子介绍 Java 中如何实现编码及解码，下面我们以“I am 君山”这个字符串为例介绍 Java 中如何把它以 ISO-8859-1、GB2312、GBK、UTF-16、UTF-8 编码格式进行编码的。

清单 2.String 编码

public static void encode() { 
        String name = "I am 君山"; 
        toHex(name.toCharArray()); 
        try { 
            byte[] iso8859 = name.getBytes("ISO-8859-1"); 
            toHex(iso8859); 
            byte[] gb2312 = name.getBytes("GB2312"); 
            toHex(gb2312); 
            byte[] gbk = name.getBytes("GBK"); 
            toHex(gbk); 
            byte[] utf16 = name.getBytes("UTF-16"); 
            toHex(utf16); 
            byte[] utf8 = name.getBytes("UTF-8"); 
            toHex(utf8); 
        } catch (UnsupportedEncodingException e) { 
            e.printStackTrace(); 
        } 
 }

我们把 name 字符串按照前面说的几种编码格式进行编码转化成 byte 数组，然后以 16 进制输出，我们先看一下 Java 是如何进行编码的。

下面是 Java 中编码需要用到的类图

图 1. Java 编码类图

首先根据指定的 charsetName 通过 Charset.forName(charsetName) 设置 Charset 类，然后根据 Charset 创建 CharsetEncoder 对象，再调用 CharsetEncoder.encode 对字符串进行编码，不同的编码类型都会对应到一个类中，实际的编码过程是在这些类中完成的。下面是 String. getBytes(charsetName) 编码过程的时序图

图 2.Java 编码时序图

从上图可以看出根据 charsetName 找到 Charset 类，然后根据这个字符集编码生成 CharsetEncoder，这个类是所有字符编码的父类，针对不同的字符编码集在其子类中定义了如何实现编码，有了 CharsetEncoder 对象后就可以调用 encode 方法去实现编码了。这个是 String.getBytes 编码方法，其它的如 StreamEncoder 中也是类似的方式。下面看看不同的字符集是如何将前面的字符串编码成 byte 数组的？

如字符串“I am 君山”的 char 数组为 49 20 61 6d 20 541b 5c71，下面把它按照不同的编码格式转化成相应的字节。

按照 ISO-8859-1 编码

字符串“I am 君山”用 ISO-8859-1 编码，下面是编码结果：

从上图看出 7 个 char 字符经过 ISO-8859-1 编码转变成 7 个 byte 数组，ISO-8859-1 是单字节编码，中文“君山”被转化成值是 3f 的 byte。3f 也就是“？”字符，所以经常会出现中文变成“？”很可能就是错误的使用了 ISO-8859-1 这个编码导致的。中文字符经过 ISO-8859-1 编码会丢失信息，通常我们称之为“黑洞”，它会把不认识的字符吸收掉。由于现在大部分基础的 Java 框架或系统默认的字符集编码都是 ISO-8859-1，所以很容易出现乱码问题，后面将会分析不同的乱码形式是怎么出现的。

按照 GB2312 编码

字符串“I am 君山”用 GB2312 编码，下面是编码结果：

GB2312 对应的 Charset 是 sun.nio.cs.ext. EUC_CN 而对应的 CharsetDecoder 编码类是 sun.nio.cs.ext. DoubleByte，GB2312 字符集有一个 char 到 byte 的码表，不同的字符编码就是查这个码表找到与每个字符的对应的字节，然后拼装成 byte 数组。查表的规则如下：

c2b[c2bIndex[char >> 8] + (char & 0xff)]

如果查到的码位值大于 oxff 则是双字节，否则是单字节。双字节高 8 位作为第一个字节，低 8 位作为第二个字节，如下代码所示：

if (bb > 0xff) {    // DoubleByte 
            if (dl - dp < 2) 
                return CoderResult.OVERFLOW; 
            da[dp++] = (byte) (bb >> 8); 
            da[dp++] = (byte) bb; 
 } else {                      // SingleByte 
            if (dl - dp < 1) 
                return CoderResult.OVERFLOW; 
            da[dp++] = (byte) bb; 
 }

从上图可以看出前 5 个字符经过编码后仍然是 5 个字节，而汉字被编码成双字节，在第一节中介绍到 GB2312 只支持 6763 个汉字，所以并不是所有汉字都能够用 GB2312 编码。

按照 GBK 编码

字符串“I am 君山”用 GBK 编码，下面是编码结果：

你可能已经发现上图与 GB2312 编码的结果是一样的，没错 GBK 与 GB2312 编码结果是一样的，由此可以得出 GBK 编码是兼容 GB2312 编码的，它们的编码算法也是一样的。不同的是它们的码表长度不一样，GBK 包含的汉字字符更多。所以只要是经过 GB2312 编码的汉字都可以用 GBK 进行解码，反过来则不然。

按照 UTF-16 编码

字符串“I am 君山”用 UTF-16 编码，下面是编码结果：

用 UTF-16 编码将 char 数组放大了一倍，单字节范围内的字符，在高位补 0 变成两个字节，中文字符也变成两个字节。从 UTF-16 编码规则来看，仅仅将字符的高位和地位进行拆分变成两个字节。特点是编码效率非常高，规则很简单，由于不同处理器对 2 字节处理方式不同，Big-endian（高位字节在前，低位字节在后）或 Little-endian（低位字节在前，高位字节在后）编码，所以在对一串字符串进行编码是需要指明到底是 Big-endian 还是 Little-endian，所以前面有两个字节用来保存 BYTE_ORDER_MARK 值，UTF-16 是用定长 16 位（2 字节）来表示的 UCS-2 或 Unicode 转换格式，通过代理对来访问 BMP 之外的字符编码。

按照 UTF-8 编码

字符串“I am 君山”用 UTF-8 编码，下面是编码结果：

UTF-16 虽然编码效率很高，但是对单字节范围内字符也放大了一倍，这无形也浪费了存储空间，另外 UTF-16 采用顺序编码，不能对单个字符的编码值进行校验，如果中间的一个字符码值损坏，后面的所有码值都将受影响。而 UTF-8 这些问题都不存在，UTF-8 对单字节范围内字符仍然用一个字节表示，对汉字采用三个字节表示。它的编码规则如下：

清单 3.UTF-8 编码代码片段

private CoderResult encodeArrayLoop(CharBuffer src, 
 ByteBuffer dst){ 
            char[] sa = src.array(); 
            int sp = src.arrayOffset() + src.position(); 
            int sl = src.arrayOffset() + src.limit(); 
            byte[] da = dst.array(); 
            int dp = dst.arrayOffset() + dst.position(); 
            int dl = dst.arrayOffset() + dst.limit(); 
            int dlASCII = dp + Math.min(sl - sp, dl - dp); 
            // ASCII only loop 
            while (dp < dlASCII && sa[sp] < '\u0080') 
                da[dp++] = (byte) sa[sp++]; 
            while (sp < sl) { 
                char c = sa[sp]; 
                if (c < 0x80) { 
                    // Have at most seven bits 
                    if (dp >= dl) 
                        return overflow(src, sp, dst, dp); 
                    da[dp++] = (byte)c; 
                } else if (c < 0x800) { 
                    // 2 bytes, 11 bits 
                    if (dl - dp < 2) 
                        return overflow(src, sp, dst, dp); 
                    da[dp++] = (byte)(0xc0 | (c >> 6)); 
                    da[dp++] = (byte)(0x80 | (c & 0x3f)); 
                } else if (Character.isSurrogate(c)) { 
                    // Have a surrogate pair 
                    if (sgp == null) 
                        sgp = new Surrogate.Parser(); 
                    int uc = sgp.parse(c, sa, sp, sl); 
                    if (uc < 0) { 
                        updatePositions(src, sp, dst, dp); 
                        return sgp.error(); 
                    } 
                    if (dl - dp < 4) 
                        return overflow(src, sp, dst, dp); 
                    da[dp++] = (byte)(0xf0 | ((uc >> 18))); 
                    da[dp++] = (byte)(0x80 | ((uc >> 12) & 0x3f)); 
                    da[dp++] = (byte)(0x80 | ((uc >>  6) & 0x3f)); 
                    da[dp++] = (byte)(0x80 | (uc & 0x3f)); 
                    sp++;  // 2 chars 
                } else { 
                    // 3 bytes, 16 bits 
                    if (dl - dp < 3) 
                        return overflow(src, sp, dst, dp); 
                    da[dp++] = (byte)(0xe0 | ((c >> 12))); 
                    da[dp++] = (byte)(0x80 | ((c >>  6) & 0x3f)); 
                    da[dp++] = (byte)(0x80 | (c & 0x3f)); 
                } 
                sp++; 
            } 
            updatePositions(src, sp, dst, dp); 
            return CoderResult.UNDERFLOW; 
 }

UTF-8 编码与 GBK 和 GB2312 不同，不用查码表，所以在编码效率上 UTF-8 的效率会更好，所以在存储中文字符时 UTF-8 编码比较理想。

几种编码格式的比较

对中文字符后面四种编码格式都能处理，GB2312 与 GBK 编码规则类似，但是 GBK 范围更大，它能处理所有汉字字符，所以 GB2312 与 GBK 比较应该选择 GBK。UTF-16 与 UTF-8 都是处理 Unicode 编码，它们的编码规则不太相同，相对来说 UTF-16 编码效率最高，字符到字节相互转换更简单，进行字符串操作也更好。它适合在本地磁盘和内存之间使用，可以进行字符和字节之间快速切换，如 Java 的内存编码就是采用 UTF-16 编码。但是它不适合在网络之间传输，因为网络传输容易损坏字节流，一旦字节流损坏将很难恢复，想比较而言 UTF-8 更适合网络传输，对 ASCII 字符采用单字节存储，另外单个字符损坏也不会影响后面其它字符，在编码效率上介于 GBK 和 UTF-16 之间，所以 UTF-8 在编码效率上和编码安全性上做了平衡，是理想的中文编码方式。

回页首

Java Web 涉及到的编码

对于使用中文来说，有 I/O 的地方就会涉及到编码，前面已经提到了 I/O 操作会引起编码，而大部分 I/O 引起的乱码都是网络 I/O，因为现在几乎所有的应用程序都涉及到网络操作，而数据经过网络传输都是以字节为单位的，所以所有的数据都必须能够被序列化为字节。在 Java 中数据被序列化必须继承 Serializable 接口。

这里有一个问题，你是否认真考虑过一段文本它的实际大小应该怎么计算，我曾经碰到过一个问题：就是要想办法压缩 Cookie 大小，减少网络传输量，当时有选择不同的压缩算法，发现压缩后字符数是减少了，但是并没有减少字节数。所谓的压缩只是将多个单字节字符通过编码转变成一个多字节字符。减少的是 String.length()，而并没有减少最终的字节数。例如将“ab”两个字符通过某种编码转变成一个奇怪的字符，虽然字符数从两个变成一个，但是如果采用 UTF-8 编码这个奇怪的字符最后经过编码可能又会变成三个或更多的字节。同样的道理比如整型数字 1234567 如果当成字符来存储，采用 UTF-8 来编码占用 7 个 byte，采用 UTF-16 编码将会占用 14 个 byte，但是把它当成 int 型数字来存储只需要 4 个 byte 来存储。所以看一段文本的大小，看字符本身的长度是没有意义的，即使是一样的字符采用不同的编码最终存储的大小也会不同，所以从字符到字节一定要看编码类型。

另外一个问题，你是否考虑过，当我们在电脑中某个文本编辑器里输入某个汉字时，它到底是怎么表示的？我们知道，计算机里所有的信息都是以 01 表示的，那么一个汉字，它到底是多少个 0 和 1 呢？我们能够看到的汉字都是以字符形式出现的，例如在 Java 中“淘宝”两个字符，它在计算机中的数值 10 进制是 28120 和 23453，16 进制是 6bd8 和 5d9d，也就是这两个字符是由这两个数字唯一表示的。Java 中一个 char 是 16 个 bit 相当于两个字节，所以两个汉字用 char 表示在内存中占用相当于四个字节的空间。

这两个问题搞清楚后，我们看一下 Java Web 中那些地方可能会存在编码转换？

用户从浏览器端发起一个 HTTP 请求，需要存在编码的地方是 URL、Cookie、Parameter。服务器端接受到 HTTP 请求后要解析 HTTP 协议，其中 URI、Cookie 和 POST 表单参数需要解码，服务器端可能还需要读取数据库中的数据，本地或网络中其它地方的文本文件，这些数据都可能存在编码问题，当 Servlet 处理完所有请求的数据后，需要将这些数据再编码通过 Socket 发送到用户请求的浏览器里，再经过浏览器解码成为文本。这些过程如下图所示：

图 3. 一次 HTTP 请求的编码示例（查看大图）

如上图所示一次 HTTP 请求设计到很多地方需要编解码，它们编解码的规则是什么？下面将会重点阐述一下：

URL 的编解码

用户提交一个 URL，这个 URL 中可能存在中文，因此需要编码，如何对这个 URL 进行编码？根据什么规则来编码？有如何来解码？如下图一个 URL：

图 4.URL 的几个组成部分

上图中以 Tomcat 作为 Servlet Engine 为例，它们分别对应到下面这些配置文件中：

Port 对应在 Tomcat 的 <Connector port="8080"/> 中配置，而 Context Path 在 <Context path="/examples"/> 中配置，Servlet Path 在 Web 应用的 web.xml 中的

<servlet-mapping> 
        <servlet-name>junshanExample</servlet-name> 
        <url-pattern>/servlets/servlet/*</url-pattern> 
 </servlet-mapping>

<url-pattern> 中配置，PathInfo 是我们请求的具体的 Servlet，QueryString 是要传递的参数，注意这里是在浏览器里直接输入 URL 所以是通过 Get 方法请求的，如果是 POST 方法请求的话，QueryString 将通过表单方式提交到服务器端，这个将在后面再介绍。

上图中 PathInfo 和 QueryString 出现了中文，当我们在浏览器中直接输入这个 URL 时，在浏览器端和服务端会如何编码和解析这个 URL 呢？为了验证浏览器是怎么编码 URL 的我们选择 FireFox 浏览器并通过 HTTPFox 插件观察我们请求的 URL 的实际的内容，以下是 URL：HTTP://localhost:8080/examples/servlets/servlet/ 君山 ?author= 君山在中文 FireFox3.6.12 的测试结果

图 5. HTTPFox 的测试结果

君山的编码结果分别是：e5 90 9b e5 b1 b1，be fd c9 bd，查阅上一届的编码可知，PathInfo 是 UTF-8 编码而 QueryString 是经过 GBK 编码，至于为什么会有“%”？查阅 URL 的编码规范 RFC3986 可知浏览器编码 URL 是将非 ASCII 字符按照某种编码格式编码成 16 进制数字然后将每个 16 进制表示的字节前加上“%”，所以最终的 URL 就成了上图的格式了。

默认情况下中文 IE 最终的编码结果也是一样的，不过 IE 浏览器可以修改 URL 的编码格式在选项 -> 高级 -> 国际里面的发送 UTF-8 URL 选项可以取消。

从上面测试结果可知浏览器对 PathInfo 和 QueryString 的编码是不一样的，不同浏览器对 PathInfo 也可能不一样，这就对服务器的解码造成很大的困难，下面我们以 Tomcat 为例看一下，Tomcat 接受到这个 URL 是如何解码的。

解析请求的 URL 是在 org.apache.coyote.HTTP11.InternalInputBuffer 的 parseRequestLine 方法中，这个方法把传过来的 URL 的 byte[] 设置到 org.apache.coyote.Request 的相应的属性中。这里的 URL 仍然是 byte 格式，转成 char 是在 org.apache.catalina.connector.CoyoteAdapter 的 convertURI 方法中完成的：

protected void convertURI(MessageBytes uri, Request request) 
 throws Exception { 
        ByteChunk bc = uri.getByteChunk(); 
        int length = bc.getLength(); 
        CharChunk cc = uri.getCharChunk(); 
        cc.allocate(length, -1); 
        String enc = connector.getURIEncoding(); 
        if (enc != null) { 
            B2CConverter conv = request.getURIConverter(); 
            try { 
                if (conv == null) { 
                    conv = new B2CConverter(enc); 
                    request.setURIConverter(conv); 
                } 
            } catch (IOException e) {...} 
            if (conv != null) { 
                try { 
                    conv.convert(bc, cc, cc.getBuffer().length - 
 cc.getEnd()); 
                    uri.setChars(cc.getBuffer(), cc.getStart(), 
 cc.getLength()); 
                    return; 
                } catch (IOException e) {...} 
            } 
        } 
        // Default encoding: fast conversion 
        byte[] bbuf = bc.getBuffer(); 
        char[] cbuf = cc.getBuffer(); 
        int start = bc.getStart(); 
        for (int i = 0; i < length; i++) { 
            cbuf[i] = (char) (bbuf[i + start] & 0xff); 
        } 
        uri.setChars(cbuf, 0, length); 
 }

从上面的代码中可以知道对 URL 的 URI 部分进行解码的字符集是在 connector 的 <Connector URIEncoding=”UTF-8”/> 中定义的，如果没有定义，那么将以默认编码 ISO-8859-1 解析。所以如果有中文 URL 时最好把 URIEncoding 设置成 UTF-8 编码。

QueryString 又如何解析？ GET 方式 HTTP 请求的 QueryString 与 POST 方式 HTTP 请求的表单参数都是作为 Parameters 保存，都是通过 request.getParameter 获取参数值。对它们的解码是在 request.getParameter 方法第一次被调用时进行的。request.getParameter 方法被调用时将会调用 org.apache.catalina.connector.Request 的 parseParameters 方法。这个方法将会对 GET 和 POST 方式传递的参数进行解码，但是它们的解码字符集有可能不一样。POST 表单的解码将在后面介绍，QueryString 的解码字符集是在哪定义的呢？它本身是通过 HTTP 的 Header 传到服务端的，并且也在 URL 中，是否和 URI 的解码字符集一样呢？从前面浏览器对 PathInfo 和 QueryString 的编码采取不同的编码格式不同可以猜测到解码字符集肯定也不会是一致的。的确是这样 QueryString 的解码字符集要么是 Header 中 ContentType 中定义的 Charset 要么就是默认的 ISO-8859-1，要使用 ContentType 中定义的编码就要设置 connector 的 <Connector URIEncoding=”UTF-8” useBodyEncodingForURI=”true”/> 中的 useBodyEncodingForURI 设置为 true。这个配置项的名字有点让人产生混淆，它并不是对整个 URI 都采用 BodyEncoding 进行解码而仅仅是对 QueryString 使用 BodyEncoding 解码，这一点还要特别注意。

从上面的 URL 编码和解码过程来看，比较复杂，而且编码和解码并不是我们在应用程序中能完全控制的，所以在我们的应用程序中应该尽量避免在 URL 中使用非 ASCII 字符，不然很可能会碰到乱码问题，当然在我们的服务器端最好设置 <Connector/> 中的 URIEncoding 和 useBodyEncodingForURI 两个参数。

HTTP Header 的编解码

当客户端发起一个 HTTP 请求除了上面的 URL 外还可能会在 Header 中传递其它参数如 Cookie、redirectPath 等，这些用户设置的值很可能也会存在编码问题，Tomcat 对它们又是怎么解码的呢？

对 Header 中的项进行解码也是在调用 request.getHeader 是进行的，如果请求的 Header 项没有解码则调用 MessageBytes 的 toString 方法，这个方法将从 byte 到 char 的转化使用的默认编码也是 ISO-8859-1，而我们也不能设置 Header 的其它解码格式，所以如果你设置 Header 中有非 ASCII 字符解码肯定会有乱码。

我们在添加 Header 时也是同样的道理，不要在 Header 中传递非 ASCII 字符，如果一定要传递的话，我们可以先将这些字符用 org.apache.catalina.util.URLEncoder 编码然后再添加到 Header 中，这样在浏览器到服务器的传递过程中就不会丢失信息了，如果我们要访问这些项时再按照相应的字符集解码就好了。

POST 表单的编解码

在前面提到了 POST 表单提交的参数的解码是在第一次调用 request.getParameter 发生的，POST 表单参数传递方式与 QueryString 不同，它是通过 HTTP 的 BODY 传递到服务端的。当我们在页面上点击 submit 按钮时浏览器首先将根据 ContentType 的 Charset 编码格式对表单填的参数进行编码然后提交到服务器端，在服务器端同样也是用 ContentType 中字符集进行解码。所以通过 POST 表单提交的参数一般不会出现问题，而且这个字符集编码是我们自己设置的，可以通过 request.setCharacterEncoding(charset) 来设置。

另外针对 multipart/form-data 类型的参数，也就是上传的文件编码同样也是使用 ContentType 定义的字符集编码，值得注意的地方是上传文件是用字节流的方式传输到服务器的本地临时目录，这个过程并没有涉及到字符编码，而真正编码是在将文件内容添加到 parameters 中，如果用这个编码不能编码时将会用默认编码 ISO-8859-1 来编码。

HTTP BODY 的编解码

当用户请求的资源已经成功获取后，这些内容将通过 Response 返回给客户端浏览器，这个过程先要经过编码再到浏览器进行解码。这个过程的编解码字符集可以通过 response.setCharacterEncoding 来设置，它将会覆盖 request.getCharacterEncoding 的值，并且通过 Header 的 Content-Type 返回客户端，浏览器接受到返回的 socket 流时将通过 Content-Type 的 charset 来解码，如果返回的 HTTP Header 中 Content-Type 没有设置 charset，那么浏览器将根据 Html 的 <meta HTTP-equiv="Content-Type" content="text/html; charset=GBK" /> 中的 charset 来解码。如果也没有定义的话，那么浏览器将使用默认的编码来解码。

其它需要编码的地方

除了 URL 和参数编码问题外，在服务端还有很多地方可能存在编码，如可能需要读取 xml、velocity 模版引擎、JSP 或者从数据库读取数据等。

xml 文件可以通过设置头来制定编码格式

<?xml version="1.0" encoding="UTF-8"?>

Velocity 模版设置编码格式：

services.VelocityService.input.encoding=UTF-8

JSP 设置编码格式：

<%@page contentType="text/html; charset=UTF-8"%>

访问数据库都是通过客户端 JDBC 驱动来完成，用 JDBC 来存取数据要和数据的内置编码保持一致，可以通过设置 JDBC URL 来制定如 MySQL：url="jdbc:mysql://localhost:3306/DB?useUnicode=true&characterEncoding=GBK"。

回页首

常见问题分析

在了解了 Java Web 中可能需要编码的地方后，下面看一下，当我们碰到一些乱码时，应该怎么处理这些问题？出现乱码问题唯一的原因都是在 char 到 byte 或 byte 到 char 转换中编码和解码的字符集不一致导致的，由于往往一次操作涉及到多次编解码，所以出现乱码时很难查找到底是哪个环节出现了问题，下面就几种常见的现象进行分析。

中文变成了看不懂的字符

例如，字符串“淘！我喜欢！”变成了“Ì Ô £ ¡Î Ò Ï²»¶ £ ¡”编码过程如下图所示

字符串在解码时所用的字符集与编码字符集不一致导致汉字变成了看不懂的乱码，而且是一个汉字字符变成两个乱码字符。

一个汉字变成一个问号

例如，字符串“淘！我喜欢！”变成了“？？？？？？”编码过程如下图所示

将中文和中文符号经过不支持中文的 ISO-8859-1 编码后，所有字符变成了“？”，这是因为用 ISO-8859-1 进行编解码时遇到不在码值范围内的字符时统一用 3f 表示，这也就是通常所说的“黑洞”，所有 ISO-8859-1 不认识的字符都变成了“？”。

一个汉字变成两个问号

例如，字符串“淘！我喜欢！”变成了“？？？？？？？？？？？？”编码过程如下图所示

这种情况比较复杂，中文经过多次编码，但是其中有一次编码或者解码不对仍然会出现中文字符变成“？”现象，出现这种情况要仔细查看中间的编码环节，找出出现编码错误的地方。

一种不正常的正确编码

还有一种情况是在我们通过 request.getParameter 获取参数值时，当我们直接调用

String value = request.getParameter(name);

会出现乱码，但是如果用下面的方式

String value = String(request.getParameter(name).getBytes("
 ISO-8859-1"), "GBK");

解析时取得的 value 会是正确的汉字字符，这种情况是怎么造成的呢？

看下如所示：

这种情况是这样的，ISO-8859-1 字符集的编码范围是 0000-00FF，正好和一个字节的编码范围相对应。这种特性保证了使用 ISO-8859-1 进行编码和解码可以保持编码数值“不变”。虽然中文字符在经过网络传输时，被错误地“拆”成了两个欧洲字符，但由于输出时也是用 ISO-8859-1，结果被“拆”开的中文字的两半又被合并在一起，从而又刚好组成了一个正确的汉字。虽然最终能取得正确的汉字，但是还是不建议用这种不正常的方式取得参数值，因为这中间增加了一次额外的编码与解码，这种情况出现乱码时因为 Tomcat 的配置文件中 useBodyEncodingForURI 配置项没有设置为”true”，从而造成第一次解析式用 ISO-8859-1 来解析才造成乱码的。

回页首

总结

本文首先总结了几种常见编码格式的区别，然后介绍了支持中文的几种编码格式，并比较了它们的使用场景。接着介绍了 Java 那些地方会涉及到编码问题，已经 Java 中如何对编码的支持。并以网络 I/O 为例重点介绍了 HTTP 请求中的存在编码的地方，以及 Tomcat 对 HTTP 协议的解析，最后分析了我们平常遇到的乱码问题出现的原因。

综上所述，要解决中文问题，首先要搞清楚哪些地方会引起字符到字节的编码以及字节到字符的解码，最常见的地方就是读取会存储数据到磁盘，或者数据要经过网络传输。然后针对这些地方搞清楚操作这些数据的框架的或系统是如何控制编码的，正确设置编码格式，避免使用软件默认的或者是操作系统平台默认的编码格式。

参考资料

学习

Unicode 编码规范，详细描述了 Unicode 如何编码。
ISO-8859-1 编码，详细介绍了 ISO-8859-1 的一些细节。
RFC3986 规范，详细描述了 URL 编码规范
HTTP 协议，W3C 关于 HTTP 协议的详细描述。
查看文章《 Tomcat 系统架构与设计模式》（developerWorks，2010 年 5 月）：了解 Tomcat 中容器的体系结构，基本的工作原理，以及 Tomcat 中使用的经典的设计模式介绍。
Servlet 工作原理解析，（developerWorks，2011 年 2 月）：以 Tomcat 为例了解 Servlet 容器是如何工作的？一个 Web 工程在 Servlet 容器中是如何启动的？ Servlet 容器如何解析你在 web.xml 中定义的 Servlet ？用户的请求是如何被分配给指定的 Servlet 的？ Servlet 容器如何管理 Servlet 生命周期？你还将了解到最新的 Servlet 的 API 的类层次结构，以及 Servlet 中一些难点问题的分析。
developerWorks Java 技术专区：这里有数百篇关于 Java 编程各个方面的文章。

讨论

加入 developerWorks 中文社区。查看开发人员推动的博客、论坛、组和维基，并与其他 developerWorks 用户交流。

关于作者

许令波，developerWorks 中国网站最佳作者，现就职于淘宝网，是一名 Java 开发工程师。对大型互联网架构设计颇感兴趣，喜欢钻研开源框架的设计原理。有时间将学到的知识整理成文章，也喜欢记录下工作和生活中的一些思考。个人网站是：http://xulingbo.net。

本文链接

轻松实现坐标转换(转)

2011-09-09T06:06:00Z

不同地理位置系统转换入门

Sami Salkosuo, 应用程序架构师, EMC

简介： 很多流行的应用程序可以提供基于位置的服务，但是计算机如何识别真实世界中的位置呢？很多方法都涉及到地理坐标系统，并且在实际应用中存在不同的此类系统。在本文中，应用程序架构师 Sami Salkosuo 演示了使用 Java™ 代码在两种流行的系统之间转换位置数据：人们较为熟悉的经纬度系统和统一横轴墨卡托投影（Universal Transverse Mercator）系统。

标记本文！

发布日期： 2007 年 9 月 07 日
级别： 初级
访问情况 7901 次浏览
建议： 0 (添加评论)

位置服务 —— 包括基于 GPS 的导航系统和地图站点（如 Google Maps 和 Yahoo! Maps）—— 现在深受客户欢迎。很多企业已经利用了某些位置感知服务，而更多的用户将加入到这个行列中来，因为他们已认识到该服务带来的优势和潜能。在 2006 年，Garter 就曾表示，“位置感知服务在未来两到五年内将成为主流”，并且已经有 “越来越多的组织部署了位置感知移动业务应用程序。”（请参阅参考资料，获得该报告的链接）。

当企业决定实现某种位置感知应用程序时，编写此类应用程序的任务最终都落在开发人员的身上。构建位置感知服务涉及多种任务，或大或小，其中一项任务（相对较小）可能要将一种系统坐标转换为另一种系统坐标。本文将演示执行此类转换的代码，从而帮助您节省大量的工作。

两种不同的坐标系统

在详细研究本文代码之前，首先需要讨论即将处理的代码所属的坐标系统：较为熟悉的经纬度系统和统一横轴墨卡托投影系统（Universal Transverse Mercator，UTM）。我们还要提到以 UTM 为基础的军事格网参考系 (MGRS)。

经纬度系统

经纬度系统可能是最为人熟知的地理坐标设计方法。它使用两个数值表示位置。纬度表示从地球中心到地球表面东西方向线之间的角度。经度指从地球中心到地球表面南北方向线之间的角度。经纬度可以表示为十进制角度（DD），或表示为度、分、和秒（DMS）；后者的格式可表示为诸如 49°30'00" S 12°30'00" E。这是 GPS 设备使用的典型格式。

地球以赤道（0° 纬线）为界，分为南半球和北半球，又以 0° 经线（从南极到北极的假想线，通过英国的格林威治市）为界分为东西半球。北半球的纬度从 0 度到 90 度，而南半球的纬度从 0 度到 -90 度。东半球的经度范围从 0 度到 180 度，西半球的经度范围为 0 度到 -180 度。

举例说明，坐标 61.44，25.40（使用 DD 单位）或 61°26'24''N，25°23'60''E（使用 DMS 单位）位于芬兰南部。坐标 -47.04, -73.48（使用 DD 单位）或 47°02'24''S，73°28'48''W（使用 DMS 单位）位于智利南部。图 1 展示了表面覆盖经纬线的地球：

图 1. 地球表面覆盖了经纬线

请参阅参考资料，获得更详细的内容。

统一横轴墨卡托投影

UTM 坐标系统使用基于网格的方法表示坐标。UTM 系统将地球分为 60 个区，每个区基于横轴墨卡托投影。绘图法中的地图投影方法可以在平面中表示一个两维的曲面，例如一个标准地图。图 2 展示了一个横轴墨卡托投影：

图 2. 横轴墨卡托投影

UTM 经度区范围为 1 到 60；其中 58 个区的东西跨度为 6°（稍后详细讨论另外两个区）。经度区涵盖了地球中纬度范围从 80°S 到 84°N 之间的所有区域。

一共有 20 个 UTM 纬度区，每个区的南北跨度为 8°；使用字母 C 到 X 标识（其中没有字母 I 和 O）。A、B、Y、Z 区不在系统范围以内；它们覆盖了南极和北极区。图 3 展示了欧洲的 UTM 区。从图 3 中可看到两个非标准的经度区：32V 区被扩展为覆盖整个挪威的南部，而 31V 区被缩小，所以只覆盖了一片汪洋大海。

图 3. 欧洲地区的 UTM 区

UTM 坐标的表示格式为：经度区纬度区以东以北，其中以东表示从经度区的中心子午线的投影距离，而以北表示距离赤道的投影距离。这个两个值的单位均为米。举例来说，使用 UTM 表示经/纬度坐标 61.44，25.40 的结果就是 35 V 414668 6812844；而经/纬度坐标 -47.04，-73.48 的表示结果为 18 G 615471 4789269。

请参阅参考资料，获取更多有关 UTM 和 Traverse Mercator 投影的信息。

军事格网参考系

MGRS 是北约（NATO）军事组织使用的标准坐标系统。MGRS 以 UTM 为基础并进一步将每个区划分为 100 km × 100 km 的小方块。这些方块使用两个相连的字母标识：第一个字母表示经度区的东西位置，而第二个字母表示南北位置。

例如，UTM 点 35 V 414668 6812844 等价于 MGRS 点 35VMJ1466812844。该 MGRS 点精度为米，使用 15 个字符表示，其中最后 10 个字符表示指定网格中的以东和以北的值。可以使用 15 个字符表示 MGRS 值（如前例），也可表示为 13、11、9 或 7 个字符；因此，所表示的值的精度分别为 1 米、10 米、100 米、1,000 米或 10,000 米。

本文并未对 MGRS 进行详细说明，但是本文的下载代码包含了经纬度坐标和 MGRS 坐标之间的转换。请参阅参考资料，获得更多信息。

回页首

坐标转换

确定地球上某个位置的经度和纬度坐标的最低需求是，你至少能够看到星星和太阳，并具备一个六分仪和能够显示 GMT 时间的时钟 T。根据空中某个物体与地平线之间的角度可以确定纬度，然后根据地球旋转计算出经度。本文并未详细讨论这些细节（想要了解更多请参阅参考资料），相反，我们假设您已经具有 DD、DMS 或 UTM 格式的坐标。

在十进制角度和度/分/秒格式之间进行转换

DD 和 DMS 坐标格式之间的转换非常简单。下面给出了 DD 到 DMS 的转换公式：

DD: dd.ff
DMS: dd mm ss

dd=dd
mm.gg=60*ff
ss=60*gg

这里的 gg 代表计算的小数部分。负纬度表示位于南半球（S）的位置而负经度表示西半球（W）的位置。例如，假设您具有一个 DD 格式的坐标 61.44，25.40。按照下面的公式将其转换：

lat dd=61
lat mm.gg=60*0.44=26.4
lat ss=60*0.4=24

以及：

lon dd=25
lon mm.gg=60*0.40=24.0
lon ss=60*0.0=0

因此，转换为 DMS 格式的坐标变成了 61°26'24''N 25°24'00''E。

将 DMS 转换为 DD 格式的公式如下所示：

DD: dd.ff
DMS: dd mm ss

dd.ff=dd + mm/60 + ss/3600

注意，南半球（S）的位置为负纬度，西半球（W）位置为负经度。

现在将 DMS 格式坐标 47°02'24''S 和 73°28'48''W 转换为 DD 格式的坐标：

lat dd.ff= - (47 + 2/60 + 24/3600 )=-47.04
lon dd.ff= - (73 + 28/60 + 48/3600)=-73.48

转换后的 DD 格式的坐标为 -47.04 和 -73.48。

在经纬度和 UTM 坐标之间进行转换

十进制坐标可通过一个六分仪和一个记时计确定，与此不同的是，必须通过计算才能确定 UTM 坐标。虽然这些计算无非是最基本的三角形和代数计算，但是所使用的公式非常复杂。如果您阅读了 “The Universal Grids: Universal Transverse Mercator (UTM) and Universal Polar Stereographic (UPS)”（参阅参考资料获得链接），就知道它有多复杂了。

本文没有给出 UTM 转换公式，但是可从下面一节中给出的源代码中窥探一二，更多信息请参阅参考资料提供的链接。

回页首

使用 Java 代码转换坐标

本节介绍了执行坐标转换（十进制角度和 UTM）的库类的源代码。该 Java 类名为 com.ibm.util.CoordinateConversion；其思想是构建一个提供转换方法的类。该类包含实际执行转换的内部类；如果需要的话，可以从 CoordinateConversion 类中重构内部类，从而创建一个库包或向现有包添加类。该类执行的转换精度低于 1 米。

CoordinateConversion 的源代码包含大约 750 行代码，因此本文没有全部显示。以下小节描述了有关方法，本文的下载小节中附带了完整的源代码。

CoordinateConversion

CoordinateConversion 是主类，它被实例化为在需要是执行坐标转换。清单 1 展示了相关的公共方法，以及 CoordinateConversion类中包含的私有内部类：

清单 1. CoordinateConversion

public class CoordinateConversion
{

  public CoordinateConversion()
  {

  }
  
  public double[] utm2LatLon(String UTM)
  {
    UTM2LatLon c = new UTM2LatLon();
    return c.convertUTMToLatLong(UTM);
  }

  public String latLon2UTM(double latitude, double longitude)
  {
    LatLon2UTM c = new LatLon2UTM();
    return c.convertLatLonToUTM(latitude, longitude);

  }

  //..implementation omitted

  private class LatLon2UTM
  {
    public String convertLatLonToUTM(double latitude, double longitude)
    {
      //..implementation omitted
    }
    //..implementation omitted
  }
  
  private class LatLon2MGRUTM extends LatLon2UTM
  {
    public String convertLatLonToMGRUTM(double latitude, double longitude)
    {
      //..implementation omitted
    }
    //..implementation omitted
  }


  private class MGRUTM2LatLon extends UTM2LatLon
  {
    public double[] convertMGRUTMToLatLong(String mgrutm)
    {
      //..implementation omitted
    }
    //..implementation omitted
  }
 
 
  private class UTM2LatLon
  {
    public double[] convertUTMToLatLong(String UTM)
    {
      //..implementation omitted
    }
    //..implementation omitted
  }

  private class Digraphs
  {
    //used to get digraphs when doing conversion between
    //lat/long and MGRS
    //..implementation omitted
  }

  private class LatZones
  {
    //include methods to determine latitude zones
    //..implementation omitted
  }

下一节将进一步探讨经纬度与 UTM 之间的转换。

将经纬度转换为 UTM

将经纬度坐标转换为 UTM 坐标需要使用 String latLon2UTM(double latitude, double longitude) 方法。该方法的实现创建了一个新的内部类 LatLon2UTM c = new LatLon2UTM(); 实例，并将 UTM 坐标返回为由 15 个字符组成的字符串（即精度为 1 米）。LatLon2UTM 方法的实现如清单 2 所示：

清单 2. public String convertLatLonToUTM(double latitude, double longitude)

public String convertLatLonToUTM(double latitude, double longitude)
{
  validate(latitude, longitude);
  String UTM = "";

  setVariables(latitude, longitude);

  String longZone = getLongZone(longitude);
  LatZones latZones = new LatZones();
  String latZone = latZones.getLatZone(latitude);

  double _easting = getEasting();
  double _northing = getNorthing(latitude);

  UTM = longZone + " " + latZone + " " + ((int) _easting) + " "+ ((int) _northing);

  return UTM;
}

该方法执行转换的方法为：调用各种方法获得经纬度区，然后计算以东和以北值，等等。使用 validate() 方法对输入进行验证；如果 (latitude < -90.0 || latitude > 90.0 || longitude < -180.0 || longitude >= 180.0) 子句为真，将抛出一个IllegalArgumentException。

清单 3 中的 setVariables() 方法设置计算转换所需的各种变量（请查看 “The Universal Grids” 获取更多信息；可从参考资料获取链接）：

清单 3. protected void setVariables(double latitude, double longitude)

protected void setVariables(double latitude, double longitude)
{
  latitude = degreeToRadian(latitude);
  rho = equatorialRadius * (1 - e * e) / POW(1 - POW(e * SIN(latitude), 2), 3 / 2.0);

  nu = equatorialRadius / POW(1 - POW(e * SIN(latitude), 2), (1 / 2.0));

  double var1;
  if (longitude < 0.0)
  {
    var1 = ((int) ((180 + longitude) / 6.0)) + 1;
  }
  else
  {
    var1 = ((int) (longitude / 6)) + 31;
  }
  double var2 = (6 * var1) - 183;
  double var3 = longitude - var2;
  p = var3 * 3600 / 10000;

  S = A0 * latitude - B0 * SIN(2 * latitude) + C0 * SIN(4 * latitude) - D0
      * SIN(6 * latitude) + E0 * SIN(8 * latitude);

  K1 = S * k0;
  K2 = nu * SIN(latitude) * COS(latitude) * POW(sin1, 2) * k0 * (100000000) / 2;
  K3 = ((POW(sin1, 4) * nu * SIN(latitude) * Math.pow(COS(latitude), 3)) / 24)
      * (5 - POW(TAN(latitude), 2) + 9 * e1sq * POW(COS(latitude), 2) + 4
      * POW(e1sq, 2) * POW(COS(latitude), 4))
      * k0
      * (10000000000000000L);

  K4 = nu * COS(latitude) * sin1 * k0 * 10000;

  K5 = POW(sin1 * COS(latitude), 3) * (nu / 6)
      * (1 - POW(TAN(latitude), 2) + e1sq * POW(COS(latitude), 2)) * k0
      * 1000000000000L;

  A6 = (POW(p * sin1, 6) * nu * SIN(latitude) * POW(COS(latitude), 5) / 720)
      * (61 - 58 * POW(TAN(latitude), 2) + POW(TAN(latitude), 4) + 270
      * e1sq * POW(COS(latitude), 2) - 330 * e1sq
      * POW(SIN(latitude), 2)) * k0 * (1E+24);

}

清单 4 中的 getLongZone() 方法和 LatZones 类（可从源代码获得）用来获得经纬度区。经度区通过 longitude 参数计算而来，而纬度区很难使用 LatZones 类中的数组进行编码。

清单 4. protected String getLongZone(double longitude)

protected String getLongZone(double longitude)
{
  double longZone = 0;
  if (longitude < 0.0)
  {
    longZone = ((180.0 + longitude) / 6) + 1;
  }
  else
  {
    longZone = (longitude / 6) + 31;
  }
  String val = String.valueOf((int) longZone);
  if (val.length() == 1)
  {
    val = "0" + val;
  }
  return val;
}

getNorthing() 方法（清单 5）和 getEasting() 方法（清单 6）计算以北和以东的值。两种方法都使用清单 3 中的 setVariables()方法设置的变量。

清单 5. protected double getNorthing(double latitude)

protected double getNorthing(double latitude)
{
  double northing = K1 + K2 * p * p + K3 * POW(p, 4);
  if (latitude < 0.0)
  {
    northing = 10000000 + northing;
  }
  return northing;
}

清单 6. protected double getEasting()

protected double getEasting()
{
  return 500000 + (K4 * p + K5 * POW(p, 3));
}

清单 7 包含了一些示例输出，包括一些经纬度坐标和对应的 UTM 坐标：

清单 7. Latitude/longitude-to-UTM 测试值

( 0.0000    0.0000  )     "31 N 166021 0"
( 0.1300   -0.2324  )     "30 N 808084 14385"
(-45.6456   23.3545 )     "34 G 683473 4942631"
(-12.7650  -33.8765 )     "25 L 404859 8588690"
(-80.5434  -170.6540)     "02 C 506346 1057742"
( 90.0000   177.0000)     "60 Z 500000 9997964"
(-90.0000  -177.0000)     "01 A 500000 2035"
( 90.0000    3.0000 )     "31 Z 500000 9997964"
( 23.4578  -135.4545)     "08 Q 453580 2594272"
( 77.3450   156.9876)     "57 X 450793 8586116"
(-89.3454  -48.9306 )     "22 A 502639 75072"

将 UTM 坐标转换为经纬度坐标

UTM 坐标到经纬度坐标的转换要比相反的转换过程容易一些。同样，“The Universal Grids”（请参阅参考资料）提供了转换公式。清单 8 展示了 convertUTMToLatLong() 方法的代码。该方法返回一个双数组，其中第一个元素（数组索引 [0]）表示纬度，而第二个元素（数组索引 [1]）表示经度。由于 UTM 字符串参数的精度为 1 米，因此经纬度坐标具有与之相同的精度。

清单 8. public double[] convertUTMToLatLong(String UTM)

public double[] convertUTMToLatLong(String UTM)
{
  double[] latlon = { 0.0, 0.0 };
  String[] utm = UTM.split(" ");
  zone = Integer.parseInt(utm[0]);
  String latZone = utm[1];
  easting = Double.parseDouble(utm[2]);
  northing = Double.parseDouble(utm[3]);
  String hemisphere = getHemisphere(latZone);
  double latitude = 0.0;
  double longitude = 0.0;

  if (hemisphere.equals("S"))
  {
    northing = 10000000 - northing;
  }
  setVariables();
  latitude = 180 * (phi1 - fact1 * (fact2 + fact3 + fact4)) / Math.PI;

  if (zone > 0)
  {
    zoneCM = 6 * zone - 183.0;
  }
  else
  {
    zoneCM = 3.0;
  }

  longitude = zoneCM - _a3;
  if (hemisphere.equals("S"))
  {
    latitude = -latitude;
  }

  latlon[0] = latitude;
  latlon[1] = longitude;
  return latlon;

}

convertUTMToLatLong() 方法将传入的 UTM 字符串（格式为 34 G 683473 4942631）分解，并使用 getHemisphere() 方法确定字符串表示的位置所在的半球。这种确定非常简单：纬度区 A、C、D、E、F、G、H、J、K、L 和 M 位于南半球，而其余区位于北半球。

清单 9 所示的 setVariables() 方法将设置计算所需的变量，然后立即计算纬度值。经度值则通过经度区计算。

清单 9. protected void setVariables()

protected void setVariables()
{
  arc = northing / k0;
  mu = arc
      / (a * (1 - POW(e, 2) / 4.0 - 3 * POW(e, 4) / 64.0 - 5 * POW(e, 6) / 256.0));

  ei = (1 - POW((1 - e * e), (1 / 2.0)))
      / (1 + POW((1 - e * e), (1 / 2.0)));

  ca = 3 * ei / 2 - 27 * POW(ei, 3) / 32.0;

  cb = 21 * POW(ei, 2) / 16 - 55 * POW(ei, 4) / 32;
  cc = 151 * POW(ei, 3) / 96;
  cd = 1097 * POW(ei, 4) / 512;
  phi1 = mu + ca * SIN(2 * mu) + cb * SIN(4 * mu) + cc * SIN(6 * mu) + cd
      * SIN(8 * mu);

  n0 = a / POW((1 - POW((e * SIN(phi1)), 2)), (1 / 2.0));

  r0 = a * (1 - e * e) / POW((1 - POW((e * SIN(phi1)), 2)), (3 / 2.0));
  fact1 = n0 * TAN(phi1) / r0;

  _a1 = 500000 - easting;
  dd0 = _a1 / (n0 * k0);
  fact2 = dd0 * dd0 / 2;

  t0 = POW(TAN(phi1), 2);
  Q0 = e1sq * POW(COS(phi1), 2);
  fact3 = (5 + 3 * t0 + 10 * Q0 - 4 * Q0 * Q0 - 9 * e1sq) * POW(dd0, 4) / 24;

  fact4 = (61 + 90 * t0 + 298 * Q0 + 45 * t0 * t0 - 252 * e1sq - 3 * Q0
          * Q0)
          * POW(dd0, 6) / 720;

  lof1 = _a1 / (n0 * k0);
  lof2 = (1 + 2 * t0 + Q0) * POW(dd0, 3) / 6.0;
  lof3 = (5 - 2 * Q0 + 28 * t0 - 3 * POW(Q0, 2) + 8 * e1sq + 24 * POW(t0, 2))
          * POW(dd0, 5) / 120;
  _a2 = (lof1 - lof2 + lof3) / COS(phi1);
  _a3 = _a2 * 180 / Math.PI;

}

setVariables() 使用以东和以北值设置所需的变量。这些都是类变量并且在 convertUTMToLatLong(String UTM) 方法中进行设置（参见清单 8）。

其他方法

源代码还提供了其他公共和私有方法以及类。例如，提供了可对经纬度和 MGRS 进行坐标转换的方法和类，以及执行度和弧度之间转换的辅助方法，还提供了各种数学操作函数（例如 POW、SIN、COS 和 TAN）。

回页首

结束语

本文简单介绍了有关世界坐标系统的一些知识，并提供了执行坐标转换的 Java 类。尽管没有详细介绍所有的坐标转换公式，您可以从参考资料小节了解详细内容。一般来说，日常的开发工作并不需要了解这些理论 —— 只有极少数情况下需要，正如我最近遇到的坐标转换任务一样。

我需要在经纬度、UTM 和 MGRS 之间进行坐标转换，因此我做了些基础研究并使用 Java 类实现了转换。开发工作花费了我好几个小时的时间，我希望本文能帮助您在执行其他任务时节省时间，并且 CoordinateConversion 类能为您提供帮助。

回页首

下载

描述	名字	大小	下载方法
坐标转换源代码	j-coordconvert.zip	4KB	HTTP

关于下载方法的信息

参考资料

学习

您可以参阅本文在 developerWorks 全球站点上的英文原文。
“Gartner's 2006 emerging technologies hype cycle highlights key technology themes”：这份来自 Gartner 的新闻简报包含了有关流行的位置服务的有趣信息。
“The Universal Grids: Universal Transverse Mercator (UTM) and Universal Polar Stereographic (UPS)”：该文档包含了 UTM 公式以及有关 UTM 的其他内容（文档格式为 PDF）。
“Location-based services”（Valerie Bennett 和 Andrew Capella，developerWorks，2002 年 3 月）：介绍了基于位置服务背后的原理。
“DB2 和开放源代码: 在 Linux 上使用 Google Maps API、DB2/Informix 和 PHP 创建地图”（Marty Lurie 和 Aron Y. Lurie，developerWorks，2006 年 3 月）：本文包含了将 ZIP 代码转换为经纬度坐标的代码。
“利用 Spatial Extender：从纬度和经度列数据创建自动维护的空间表（DB2 版本）”（Robert Uleman，developerWorks，2006 年 4 月）：了解 DB2 如何帮助您将原始的坐标数据转换为有用的信息。
Wikipedia 是学习本文所介绍概念的好起点，包括：
浏览技术书店，查阅有关本文所述主题及其他技术主题的图书。
developerWorks Java 技术专区：提供了几百篇有关 Java 编程各个方面的文章。

讨论

查看 developerWorks blogs 并加入 developerWorks 社区。

关于作者

Sami Salkosuo 从 1999 年起一直在 IBM 工作。他是 Sun 认证的 Java 程序员，IBM 认证的 WebSphere Message Broker 解决方案开发人员，还是 IBM 认证的 WebSphere MQ 的解决方案设计师。

本文链接

WIN2003系统远程桌面多连接数设置终极大法

2011-08-10T11:30:00Z

①:启动终端服务：在”运行”里输入 gpedit.msc 后按回车键,选择”计算机配置”——”管理模板”——”windows组件”——”终端服务”，把“限制连接数量”设置为”已启动”，最大连接数设为100，把”允许用户使用终

①:启动终端服务：在”运行”里输入 gpedit.msc 后按回车键,选择”计算机配置”——”管理模板”——”windows组件”——”终端服务”，把“限制连接数量”设置为”已启动”，最大连接数设为100，把”允许用户使用终端服务远程连接”设置为”已启动”.

②:安装终端服务器：首先打开”控制面板”——找到”添加／删除程序”——右边”添加／删除windows组件”,看到WINDOWS组件向导后,往下拉到倒数第一,二,在”终端服务”和”终端服务授权”前打上钩,然后选择下一步。

③：选择“宽松安全模式”，进入下一步。

④：选择“我将在120天内指定许可证服务器（I）”，进入下一步

⑤：选择“每用户授权模式”，进入下一步

⑥：选择下一步，完成安装，重启电脑.

⑦：选择：”开始”—”程序”—”管理工具”—-”终端服务配置”——“服务器设置”

⑧：双击“限制每个用户使用一个会话”，把“限制每个用户使用一个会话”勾选掉：否则有可能会被提出已登陆用户。

⑨：选择：”开始”—”程序”—”管理工具”—-”终端服务配置”——“连接”，双机“RDP-Tcp”，在弹出对话框中选择“会话”，选择“结束已断开的会话”为1分钟：

以下操作可以忽略：

⑩：使用3个远程桌面连接到本机，要输入用户名和密码登录进去，测试下是否连接成功，默认只能连接2个。

⑾：建立一个远程桌面连接，输入用户名和密码，保存为test.rdp。

⑿：新建一个批处理文件test，代码如下：

FOR /L %%i IN (1,1,%1) DO start /b mstsc test.rdp

在命令行窗口中运行批处理文件：test 3，3代表开启的远程桌面连接数量。

come from:http://neti.wyww.net/html/JiShuWenDang/WoDeDianNao/345.html

本文链接

GIS理论（墨卡托投影、地理坐标系、地面分辨率、地图比例尺、Bing Maps Tile System）【转载】

2011-07-21T13:04:00Z

墨卡托投影（Mercator Projection），又名“等角正轴圆柱投影”，荷兰地图学家墨卡托（Mercator）在1569年拟定，假设地球被围在一个中空的圆柱里，其赤道与圆柱相接触，然后再假想地球中心有一盏灯，把球面上的图形投影到圆柱体上，再把圆柱体展开，这就是一幅标准纬线为零度（即赤道）的“墨卡托投影”绘制出的世界地图。

一、墨卡托投影坐标系（Mercator Projection）

墨卡托投影以整个世界范围，赤道作为标准纬线，本初子午线作为中央经线，两者交点为坐标原点，向东向北为正，向西向南为负。南北极在地图的正下、上方，而东西方向处于地图的正右、左。

由于Mercator Projection在两极附近是趋于无限值得，因此它并没完整展现了整个世界，地图上最高纬度是85.05度。为了简化计算，我们采用球形映射，而不是椭球体形状。虽然采用Mercator Projection只是为了方便展示地图，需要知道的是，这种映射会给Y轴方向带来0.33%的误差。

由于赤道半径为6378137米，则赤道周长为2*PI*r = 20037508.3427892，因此X轴的取值范围：[-20037508.3427892,20037508.3427892]。当纬度φ接近两极，即90°时，Y值趋向于无穷。因此通常把Y轴的取值范围也限定在[-20037508.3427892,20037508.3427892]之间。因此在墨卡托投影坐标系（米）下的坐标范围是：最小为(-20037508.3427892, -20037508.3427892 )到最大坐标为(20037508.3427892, 20037508.3427892)。

二、地理坐标系（Geographical coordinates）

地理经度的取值范围是[-180,180]，纬度不可能到达90°，通过纬度取值范围为[20037508.3427892,20037508.3427892]反计算可得到纬度值为85.05112877980659。因此纬度取值范围是[-85.05112877980659，85.05112877980659]。因此，地理坐标系（经纬度）对应的范围是：最小地理坐标(-180,-85.05112877980659)，最大地理坐标(180, 85.05112877980659)。

三、地面分辨率（Ground Resolution）
　　地面分辨率是以一个像素(pixel)代表的地面尺寸(米)。以微软Bing Maps为例，当Level为1时，图片大小为512*512（4个Tile），那么赤道空间分辨率为：赤道周长/512。其他纬度的空间分辨率则为纬度圈长度/512，极端的北极则为0。Level为2时，赤道的空间分辨率为赤道周长/1024，其他纬度为纬度圈长度1024。很明显，Ground Resolution取决于两个参数，缩放级别Level和纬度latitude ，Level决定像素的多少，latitude决定地面距离的长短。

地面分辨率的公式为，单位：米/像素：

ground resolution = (cos(latitude * pi/180) * 2 * pi * 6378137 meters) / (256 * 2level pixels)　　

最低地图放大级别（1级），地图是512 x 512像素。每下一个放大级别，地图的高度和宽度分别乘于2：2级是1024 x 1024像素，3级是2048 x 2048像素，4级是4096 x 4096像素，等等。通常而言，地图的宽度和高度可以由以下式子计算得到：map width = map height = 256 * 2^level pixels

四、地图比例尺（Map Scale）

地图比例尺是指测量相同目标时，地图上距离与实际距离的比例。通过地图分辨率在计算可知由Level可得到图片的像素大小，那么需要把其转换为以米为单位的距离，涉及到DPI（dot per inch），暂时可理解为类似的PPI（pixelper inch），即每英寸代表多少个像素。256 * 2level / DPI 即得到相应的英寸inch，再把英寸inch除以0.0254转换为米。实地距离仍旧是：cos(latitude * pi/180) * 2 * pi * 6378137 meters; 因此比例尺的公式为：

map scale = 256 * 2level / screen dpi / 0.0254 / (cos(latitude * pi/180) * 2 * pi * 6378137)

比例尺= 1 : (cos(latitude * pi/180) * 2 * pi * 6378137 * screen dpi) / (256 * 2level * 0.0254)

地面分辨率和地图比例尺之间的关系：

map scale = 1 : ground resolution * screen dpi / 0.0254 meters/inch

缩放级别	地图宽度、高度(像素)	地面分辨率(米/像素)	地图比例尺(以96dpi为例)
1	512	78,271.5170	1 : 295,829,355.45
2	1,024	39,135.7585	1 : 147,914,677.73
3	2,048	19,567.8792	1 : 73,957,338.86
4	4,096	9,783.9396	1 : 36,978,669.43
5	8,192	4,891.9698	1 : 18,489,334.72
6	16,384	2,445.9849	1 : 9,244,667.36
7	32,768	1,222.9925	1 : 4,622,333.68
8	65,536	611.4962	1 : 2,311,166.84
9	131,072	305.7481	1 : 1,155,583.42
10	262,144	152.8741	1 : 577,791.71
11	524,288	76.4370	1 : 288,895.85
12	1,048,576	38.2185	1 : 144,447.93
13	2,097,152	19.1093	1 : 72,223.96
14	4,194,304	9.5546	1 : 36,111.98
15	8,388,608	4.7773	1 : 18,055.99
16	16,777,216	2.3887	1 : 9,028.00
17	33,554,432	1.1943	1 : 4,514.00
18	67,108,864	0.5972	1 : 2,257.00
19	134,217,728	0.2986	1 : 1,128.50
20	268,435,456	0.1493	1 : 564.25
21	536,870,912	0.0746	1 : 282.12
22	1,073,741,824	0.0373	1 : 141.06
23	2,147,483,648	0.0187	1 : 70.53

五、Bing Maps像素坐标系和地图图片编码

为了优化地图系统性能，提高地图下载和显示速度，所有地图都被分割成256 x 256像素大小的正方形小块。由于在每个放大级别下的像素数量都不一样，因此地图图片（Tile）的数量也不一样。每个tile都有一个XY坐标值，从左上角的(0, 0)至右下角的(2^level–1, 2^level–1)。例如在3级放大级别下，所有tile的坐标值范围为(0, 0)至(7, 7)，如下图：

已知一个像素的XY坐标值时，我们很容易得到这个像素所在的Tile的XY坐标值：

　　　　tileX = floor(pixelX / 256)　　tileY = floor(pixelY / 256)

为了简化索引和存储地图图片，每个tile的二维XY值被转换成一维字串，即四叉树键值（quardtree key，简称quadkey）。每个quadkey独立对应某个放大级别下的一个tile，并且它可以被用作数据库中B-tree索引值。为了将坐标值转换成quadkey，需要将Y和X坐标二进制值交错组合，并转换成4进制值及对应的字符串。例如，假设在放大级别为3时，tile的XY坐标值为（3，5），quadkey计算如下:

　　tileX = 3 = 011（二进制）

　　tileY = 5 = 101（二进制）

　　quadkey = 100111（二进制） = 213（四进制） = “213”

Quadkey还有其他一些有意思的特性。第一，quadkey的长度等于该tile所对应的放大级别；第二，每个tile的quadkey的前几位和其父tile（上一放大级别所对应的tile）的quadkey相同，下图中，tile 2是tile 20至23的父tile，tile 13是tile 130至133的父级：

最后，quadkey提供的一维索引值通常显示了两个tile在XY坐标系中的相似性。换句话说，两个相邻的tile对应的quadkey非常接近。这对于优化数据库的性能非常重要，因为相邻的tile通常被同时请求显示，因此可以将这些tile存放在相同的磁盘区域中，以减少磁盘的读取次数。

下面是微软Bing Maps的TileSystem相关算法：

using System;
using System.Text;

namespace Microsoft.MapPoint
{
    static class TileSystem
    {
        private const double EarthRadius = 6378137;
        private const double MinLatitude = -85.05112878;
        private const double MaxLatitude = 85.05112878;
        private const double MinLongitude = -180;
        private const double MaxLongitude = 180;


        /// <summary>
        /// Clips a number to the specified minimum and maximum values.
        /// </summary>
        /// <param name="n">The number to clip.</param>
        /// <param name="minValue">Minimum allowable value.</param>
        /// <param name="maxValue">Maximum allowable value.</param>
        /// <returns>The clipped value.</returns>
        private static double Clip(double n, double minValue, double maxValue)
        {
            return Math.Min(Math.Max(n, minValue), maxValue);
        }
        
        

        /// <summary>
        /// Determines the map width and height (in pixels) at a specified level
        /// of detail.
        /// </summary>
        /// <param name="levelOfDetail">Level of detail, from 1 (lowest detail)
        /// to 23 (highest detail).</param>
        /// <returns>The map width and height in pixels.</returns>
        public static uint MapSize(int levelOfDetail)
        {
            return (uint) 256 << levelOfDetail;
        }



        /// <summary>
        /// Determines the ground resolution (in meters per pixel) at a specified
        /// latitude and level of detail.
        /// </summary>
        /// <param name="latitude">Latitude (in degrees) at which to measure the
        /// ground resolution.</param>
        /// <param name="levelOfDetail">Level of detail, from 1 (lowest detail)
        /// to 23 (highest detail).</param>
        /// <returns>The ground resolution, in meters per pixel.</returns>
        public static double GroundResolution(double latitude, int levelOfDetail)
        {
            latitude = Clip(latitude, MinLatitude, MaxLatitude);
            return Math.Cos(latitude * Math.PI / 180) * 2 * Math.PI * EarthRadius / MapSize(levelOfDetail);
        }



        /// <summary>
        /// Determines the map scale at a specified latitude, level of detail,
        /// and screen resolution.
        /// </summary>
        /// <param name="latitude">Latitude (in degrees) at which to measure the
        /// map scale.</param>
        /// <param name="levelOfDetail">Level of detail, from 1 (lowest detail)
        /// to 23 (highest detail).</param>
        /// <param name="screenDpi">Resolution of the screen, in dots per inch.</param>
        /// <returns>The map scale, expressed as the denominator N of the ratio 1 : N.</returns>
        public static double MapScale(double latitude, int levelOfDetail, int screenDpi)
        {
            return GroundResolution(latitude, levelOfDetail) * screenDpi / 0.0254;
        }



        /// <summary>
        /// Converts a point from latitude/longitude WGS-84 coordinates (in degrees)
        /// into pixel XY coordinates at a specified level of detail.
        /// </summary>
        /// <param name="latitude">Latitude of the point, in degrees.</param>
        /// <param name="longitude">Longitude of the point, in degrees.</param>
        /// <param name="levelOfDetail">Level of detail, from 1 (lowest detail)
        /// to 23 (highest detail).</param>
        /// <param name="pixelX">Output parameter receiving the X coordinate in pixels.</param>
        /// <param name="pixelY">Output parameter receiving the Y coordinate in pixels.</param>
        public static void LatLongToPixelXY(double latitude, double longitude, int levelOfDetail, out int pixelX, out int pixelY)
        {
            latitude = Clip(latitude, MinLatitude, MaxLatitude);
            longitude = Clip(longitude, MinLongitude, MaxLongitude);

            double x = (longitude + 180) / 360; 
            double sinLatitude = Math.Sin(latitude * Math.PI / 180);
            double y = 0.5 - Math.Log((1 + sinLatitude) / (1 - sinLatitude)) / (4 * Math.PI);

            uint mapSize = MapSize(levelOfDetail);
            pixelX = (int) Clip(x * mapSize + 0.5, 0, mapSize - 1);
            pixelY = (int) Clip(y * mapSize + 0.5, 0, mapSize - 1);
        }



        /// <summary>
        /// Converts a pixel from pixel XY coordinates at a specified level of detail
        /// into latitude/longitude WGS-84 coordinates (in degrees).
        /// </summary>
        /// <param name="pixelX">X coordinate of the point, in pixels.</param>
        /// <param name="pixelY">Y coordinates of the point, in pixels.</param>
        /// <param name="levelOfDetail">Level of detail, from 1 (lowest detail)
        /// to 23 (highest detail).</param>
        /// <param name="latitude">Output parameter receiving the latitude in degrees.</param>
        /// <param name="longitude">Output parameter receiving the longitude in degrees.</param>
        public static void PixelXYToLatLong(int pixelX, int pixelY, int levelOfDetail, out double latitude, out double longitude)
        {
            double mapSize = MapSize(levelOfDetail);
            double x = (Clip(pixelX, 0, mapSize - 1) / mapSize) - 0.5;
            double y = 0.5 - (Clip(pixelY, 0, mapSize - 1) / mapSize);

            latitude = 90 - 360 * Math.Atan(Math.Exp(-y * 2 * Math.PI)) / Math.PI;
            longitude = 360 * x;
        }



        /// <summary>
        /// Converts pixel XY coordinates into tile XY coordinates of the tile containing
        /// the specified pixel.
        /// </summary>
        /// <param name="pixelX">Pixel X coordinate.</param>
        /// <param name="pixelY">Pixel Y coordinate.</param>
        /// <param name="tileX">Output parameter receiving the tile X coordinate.</param>
        /// <param name="tileY">Output parameter receiving the tile Y coordinate.</param>
        public static void PixelXYToTileXY(int pixelX, int pixelY, out int tileX, out int tileY)
        {
            tileX = pixelX / 256;
            tileY = pixelY / 256;
        }



        /// <summary>
        /// Converts tile XY coordinates into pixel XY coordinates of the upper-left pixel
        /// of the specified tile.
        /// </summary>
        /// <param name="tileX">Tile X coordinate.</param>
        /// <param name="tileY">Tile Y coordinate.</param>
        /// <param name="pixelX">Output parameter receiving the pixel X coordinate.</param>
        /// <param name="pixelY">Output parameter receiving the pixel Y coordinate.</param>
        public static void TileXYToPixelXY(int tileX, int tileY, out int pixelX, out int pixelY)
        {
            pixelX = tileX * 256;
            pixelY = tileY * 256;
        }



        /// <summary>
        /// Converts tile XY coordinates into a QuadKey at a specified level of detail.
        /// </summary>
        /// <param name="tileX">Tile X coordinate.</param>
        /// <param name="tileY">Tile Y coordinate.</param>
        /// <param name="levelOfDetail">Level of detail, from 1 (lowest detail)
        /// to 23 (highest detail).</param>
        /// <returns>A string containing the QuadKey.</returns>
        public static string TileXYToQuadKey(int tileX, int tileY, int levelOfDetail)
        {
            StringBuilder quadKey = new StringBuilder();
            for (int i = levelOfDetail; i > 0; i--)
            {
                char digit = '0';
                int mask = 1 << (i - 1);
                if ((tileX & mask) != 0)
                {
                    digit++;
                }
                if ((tileY & mask) != 0)
                {
                    digit++;
                    digit++;
                }
                quadKey.Append(digit);
            }
            return quadKey.ToString();
        }



        /// <summary>
        /// Converts a QuadKey into tile XY coordinates.
        /// </summary>
        /// <param name="quadKey">QuadKey of the tile.</param>
        /// <param name="tileX">Output parameter receiving the tile X coordinate.</param>
        /// <param name="tileY">Output parameter receiving the tile Y coordinate.</param>
        /// <param name="levelOfDetail">Output parameter receiving the level of detail.</param>
        public static void QuadKeyToTileXY(string quadKey, out int tileX, out int tileY, out int levelOfDetail)
        {
            tileX = tileY = 0;
            levelOfDetail = quadKey.Length;
            for (int i = levelOfDetail; i > 0; i--)
            {
                int mask = 1 << (i - 1);
                switch (quadKey[levelOfDetail - i])
                {
                    case '0':
                        break;

                    case '1':
                        tileX |= mask;
                        break;

                    case '2':
                        tileY |= mask;
                        break;

                    case '3':
                        tileX |= mask;
                        tileY |= mask;
                        break;

                    default:
                        throw new ArgumentException("Invalid QuadKey digit sequence.");
                }
            }
        }
    }
}

本文链接

两点坐标间距离的算法以及验证【转】

2011-07-21T13:00:00Z

看了通过两个点的经纬度计算距离这篇，据说是Google里扒来的算法，于是决定验证一下。
东改西改改成了个VB的代码，通过计算发现非常正确。
用30,120和31,121两个坐标点进行验证，同Mapinfo中计算的结果非常的相近。
后来又把坐标系直接当成直角坐标系来计算，发现误差很大。
于是仍然用直角坐标系方法来计算，给纬度加上了个0.86的参数，这样计算下来和结果相近。
不上传文件了，直接贴代码了。代码如下：(五个TEXT，三个Button)

Const EARTH_RADIUS = 6378.137
Const Pi = 3.1415926535898

Function rad(ByVal d As Double) As Double
rad = d * Pi / 180
End Function

Function GetDistance(lat1 As Double, lng1 As Double, lat2 As Double, lng2 As Double) As Double
Dim radlat1 As Double, radlat2 As Double
Dim a As Double, b As Double, s As Double, Temp As Double
radlat1 = rad(lat1)
radlat2 = rad(lat2)
a = radlat1 - radlat2
b = rad(lng1) - rad(lng2)
Temp = Sqr(Sin(a / 2) ^ 2 + Cos(radlat1) * Cos(radlat2) * Sin(b / 2) ^ 2)
s = 2 * Atn(Temp / Sqr(-Temp * Temp + 1)) '没有反正弦函数，网上找了个
s = s * EARTH_RADIUS
GetDistance = s
End Function

Private Sub Command1_Click()
Text5.Text = Str(GetDistance(Val(Text1.Text), Val(Text2.Text), Val(Text3.Text), Val(Text4.Text)))
End Sub

Private Sub Command2_Click()
Text5.Text = Str((Sqr((Val(Text3.Text) - Val(Text1.Text)) ^ 2 + (Val(Text4.Text) - Val(Text2.Text)) ^ 2)) * 111.3199338)
End Sub

Private Sub Command3_Click()
Text5.Text = Str((Sqr((Val(Text3.Text) * 0.86 - Val(Text1.Text) * 0.86) ^ 2 + (Val(Text4.Text) - Val(Text2.Text)) ^ 2)) * 111.3199338)
End Sub

本文链接

[转]判断一个点是否落在多边形内

2011-07-21T12:47:00Z

转自：

http://www.cnblogs.com/gis_gps/archive/2009/02/12/1389071.html

备用

一、背景:

如何判断一个指定的经纬度点是否落在一个多边形区域内？

二、实现代码(delphi)

Type
  TMyPoint = packed record
    X : double;
    Y : double;
  end;

{*------------------------------------------------------------------------------
  判断指定的经纬度坐标点是否落在指定的多边形区域内
  @param ALon   指定点的经度
  @param ALat   指定点的纬度
  @param APoints   指定多边形区域各个节点坐标
  @return True 落在范围内 False 不在范围内
------------------------------------------------------------------------------*}
function IsPtInPoly(ALon, ALat: double; APoints: array of TMyPoint): Boolean;
var
  iSum, iCount, iIndex: Integer;
  dLon1, dLon2, dLat1, dLat2, dLon: double;
begin
  Result := False;
  if (Length(APoints) < 3) then
  begin
    Result := False;
    Exit;
  end;
  iSum := 0;
  iCount := Length(APoints);
  for iIndex :=0 to iCount - 1 do
  begin
    if (iIndex = iCount - 1) then
    begin
      dLon1 := APoints[iIndex].X;
      dLat1 := APoints[iIndex].Y;
      dLon2 := APoints[0].X;
      dLat2 := APoints[0].Y;
    end
    else
    begin
      dLon1 := APoints[iIndex].X;
      dLat1 := APoints[iIndex].Y;
      dLon2 := APoints[iIndex + 1].X;
      dLat2 := APoints[iIndex + 1].Y;
    end;
    if ((ALat >= dLat1) and (ALat < dLat2)) or ((ALat>=dLat2) and (ALat < dLat1)) then
    begin
      if (abs(dLat1 - dLat2) > 0) then
      begin
        dLon := dLon1 - ((dLon1 -dLon2) * (dLat1 -ALat)) / (dLat1 - dLat2);
        if (dLon < ALon) then
          Inc(iSum);
      end;
    end;

  end;
  if (iSum mod 2 <> 0) then
    Result := True;
end;

____________________________________________________________________________________________________________________________

C#算法：

/// <summary>

/// 判断指定的经纬度坐标点是否落在指定的多边形区域内

/// </summary>

/// <param name="ALon">指定点的经度</param>

/// <param name="ALat">指定点的纬度</param>

/// <param name="APoints">指定多边形区域各个节点坐标</param>

/// <returns>True 落在范围内 False 不在范围内</returns>

public bool isPtInPoly(double ALon, double ALat, Point[] APoints)

{

int iSum, iCount, iIndex;

double dLon1, dLon2, dLat1, dLat2, dLon;

if (APoints.Length < 3)

{

return false;

}

iSum = 0;

iCount = APoints.Length;

for (iIndex = 0; iIndex < iCount - 1; iIndex++)

{

if (iIndex == iCount - 1)

{

dLon1 = APoints[iIndex].X;

dLat1 = APoints[iIndex].Y;

dLon2 = APoints[0].X;

dLat2 = APoints[0].Y;

}

else

{

dLon1 = APoints[iIndex].X;

dLat1 = APoints[iIndex].Y;

dLon2 = APoints[iIndex + 1].X;

dLat2 = APoints[iIndex + 1].Y;

}

if (((ALat >= dLat1) && (ALat < dLat2)) || ((ALat >= dLat2) && (ALat < dLat1)))

{

if (Math.Abs(dLat1 - dLat2) > 0)

{

dLon = dLon1 - ((dLon1 - dLon2) * (dLat1 - ALat)) / (dLat1 - dLat2);

if (dLon < ALon)

iSum++;

}

if ((iSum % 2) != 0)

return true;

return false;

}

本文链接

wpf \silverlight 保存控件为图片

2010-11-11T03:50:00Z

wpf:

private void SaveToImage(FrameworkElement ui, string fileName)
{
System.IO.FileStream fs

{
System.IO.FileStream fs = new System.IO.FileStream(fileName, System.IO.FileMode.Create);
RenderTargetBitmap bmp = new RenderTargetBitmap((int)ui.Width, (int)ui.Height, 96d, 96d, PixelFormats.Pbgra32);
bmp.Render(ui);
BitmapEncoder encoder = new PngBitmapEncoder();
encoder.Frames.Add(BitmapFrame.Create(bmp));
encoder.Save(fs);
fs.Close();

}

silverlight:

WriteableBitmap bitmap = new WriteableBitmap(控件名称, null);

本文链接

WPF 自定义快捷键命令（Command）(转)

2010-11-11T03:24:00Z

命令简介
WPF 中的命令是通过实现 ICommand 接口创建的。ICommand 公开两个方法（Execute 及 CanExecute）和一个事件（CanExecuteChanged）。Execute 执行与命令关联的操作。CanExecute 确定是否可以在当前命令目标上执行命令。如果集中管理命令操作的命令管理器检测到命令源中发生了更改，此更改可能使得已引发但尚未由命令绑定执行的命令无效，则将引发 CanExecuteChanged。ICommand 的 WPF 实现是 RoutedCommand 类。
WPF 中的主要输入源是鼠标、键盘、墨迹和路由命令。更加面向设备的输入使用 RoutedEvent 来通知应用程序页中的对象已发生了输入事件。RoutedCommand 没有不同。RoutedCommand 的 Execute 和 CanExecute 方法不包含命令的应用程序逻辑，而是引发这样的路由事件：沿元素树以隧道和冒泡形式传递，直到遇到具有 CommandBinding 的对象。CommandBinding 包含这些事件的处理程序，执行此命令的就是这些处理程序。
RoutedCommand 上的 Execute 方法在命令目标上引发 PreviewExecuted 和 Executed 事件。RoutedCommand 上的 CanExecute 方法在命令目标上引发 CanExecute 和 PreviewCanExecute 事件。这些事件沿元素树以隧道和冒泡形式传递，直到遇到具有该特定命令的 CommandBinding 的对象。
WPF 提供了一组常用的路由命令，这组命令分布在几个类中：MediaCommands、ApplicationCommands、NavigationCommands、ComponentCommands 和 EditingCommands。这些类仅包含 RoutedCommand 对象，而不包含命令的实现逻辑。实现逻辑由其上执行命令的对象负责。^[1]

自定义命令

除了上述WPF 自带的RoutedCommand，还可以使用RoutedUICommand 类创建用户自定义命令，下面将通过一个实例详细讲解。首先新建一个WPF 项目，在其中加入一个TextBlock。目的是通过快捷键组合“Ctrl+Alt+I”和“Ctrl+Alt+D”改变字体大小，由“Ctrl+Alt+C”随机改变字体颜色。

<Grid>
    <TextBlock x:Name="textBlock1" Text="Hello World" HorizontalAlignment="Center"
               FontSize="10" Margin="42,29,46,41" Width="293" />
        
</Grid>

首先在Window.Resources 中定义两个RoutedUICommand，分别用于增加和减小字体尺寸。

<Window.Resources>
    <RoutedUICommand x:Key="IncreaseFontSize" Text="Increase Font Size" />
    <RoutedUICommand x:Key="DecreaseFontSize" Text="Decrease Font Size" />
</Window.Resources>

通过KeyBinding 为上面两个命令绑定快捷键，按键组合可使用“+”进行连接。下面代码分别通过Modifiers+Key 和Gesture 两种方式为定义快捷键组合方式。大家可以任选其一进行使用，MSDN 中建议使用Gesture 方式定义以免发生混淆。

<Window.InputBindings>
    <KeyBinding Modifiers="Ctrl+Alt" Key="I" Command="{StaticResource IncreaseFontSize}"/>
    <KeyBinding Gesture="Ctrl+Alt+D" Command="{StaticResource DecreaseFontSize}"/>
</Window.InputBindings>

接下来就要通过CanExecute和Excuted 为命令绑定相关的事件，CanExecute 负责判断能否执行命令（即Executed 定义的事件），Executed 就负责去执行用户定义的操作命令。

<Window.CommandBindings>
    <CommandBinding Command="{StaticResource IncreaseFontSize}"
                    CanExecute="CommandBinding_Increase_CanExecute"
                    Executed="CommandBinding_Increase_Executed"/>
    <CommandBinding Command="{StaticResource DecreaseFontSize}"
                    CanExecute="CommandBinding_Decrease_CanExecute"
                    Executed="CommandBinding_Decrease_Executed"/>
</Window.CommandBindings>

至此，我们在XAML 中对命令的定义已经完成。下面进入到C# 中编写命令事件相关内容。扩大字体尺寸时通过CommandBinding_Increase_CanExecute 判断当前字体是否小于50，否则不会执行Executed 命令。若字体尺寸在50以内则通过CommandBinding_Increase_Executed 每次增加5。缩小尺寸时则不低于5。

private void CommandBinding_Increase_CanExecute(object sender, CanExecuteRoutedEventArgs e)
{
    if (textBlock1.FontSize > 50)
    {
        e.CanExecute = false;
    }
    else
    {
        e.CanExecute = true;
    }
}

private void CommandBinding_Increase_Executed(object sender, ExecutedRoutedEventArgs e)
{
    textBlock1.FontSize += 5;
}

private void CommandBinding_Decrease_CanExecute(object sender, CanExecuteRoutedEventArgs e)
{
    if (textBlock1.FontSize <= 5)
    {
        e.CanExecute = false;
    }
    else
    {
        e.CanExecute = true;
    }
}

private void CommandBinding_Decrease_Executed(object sender, ExecutedRoutedEventArgs e)
{
    textBlock1.FontSize -= 5;
}

运行程序使用“Ctrl+Alt+I”或 “Ctrl+Alt+D”改变字体大小。

除了在XAML 中定义RoutedUICommand 我们也可以直接用C#定义，下面继续完成修改字体颜色的快捷键命令。新建一个CustomCommand 类，在其中加入如下代码定义ChangeFontColor 命令。

using System.Windows.Input;

namespace WpfUserControlTest
{
    class CustomCommand
    {
        public static readonly RoutedUICommand ChangeFontColor = 
            new RoutedUICommand("Change Font Color", "ChangeFontColor", typeof(MainWindow));
    }
}

在MainWindow.xaml <Window> 中加入命名空间，以便后面调用ChangeFontColor 命令。

xmlns:c="clr-namespace:WpfUserControlTest"

在<Window.InputBindings>中为ChangeFontColor 添加快捷键组合。

<KeyBinding Modifiers="Control+Alt" Key="C" Command="c:CustomCommand.ChangeFontColor"/>

在<Window.CommandBindings>中添加CanExecute、Excuted 命令事件。

<CommandBinding Command="c:CustomCommand.ChangeFontColor"
                CanExecute="CommandBinding_Color_CanExecute"
                Executed="CommandBinding_Color_Executed"/>

当用户点击“Ctrl+Alt+C”是触发命令事件，最近改变字体颜色。

private void CommandBinding_Color_CanExecute(object sender, CanExecuteRoutedEventArgs e)
{
    e.CanExecute = true;
}

private void CommandBinding_Color_Executed(object sender, ExecutedRoutedEventArgs e)
{
    Random rd = new Random();    
    textBlock1.Foreground = new SolidColorBrush(
        Color.FromRgb(
            (byte)rd.Next(0,255),
            (byte)rd.Next(0, 255),
            (byte)rd.Next(0, 255))
            );
}

源代码下载
WpfCustomHotkeyCommand.zip
[1]引自：http://msdn.microsoft.com/zh-cn/library/ms752308.aspx
作者：李敬然（Gnie）
出处：{GnieTech} （http://www.cnblogs.com/gnielee/）
版权声明：本文的版权归作者与博客园共有。转载时须注明本文的详细链接，否则作者将保留追究其法律责任。
本文链接