【转】编写 iPhone Friendly 的 Web 应用程序 (Part 5 - 交互入门)

编写 iPhone Friendly 的 Web 应用程序 (Part 5 - 交互入门)

Posted: 28 Dec 2007 11:41 PM CST

我们已经研究过XHTML和CSS了，现在开始看看最后一部分，也就是JavaScript，以及它所提供的交互能力。

无AJAX交互

第一种我们要看的交互，是完全不使用JavaScript，这其中一个例子就是GMail。GMail的iPhone版其实就是由普通的GMail移动版修改过来的，界面上更贴近桌面版GMail了，然而交互性并没有怎么提高，每一个点击都对应一次刷新，没有任何AJAX可言。

事实上，不用任何AJAX效果并不会让你的iPhone Web App低人一等，如果有人讥笑你的应用没有引入任何AJAX功能，你可以直接跟他说"GMail也没有"。因此，如果你在开发的过程中决定不把任何时间投入到AJAX相关技术的研究，这是没问题的，确保你的服务器响应速度，并且交互设计得当，那就行了。

以服务器端为中心的AJAX

接下来我们看看另外一些应用，例如之前说到的几个，就拿最简单的AppMarks来说说吧。首先，使用User Agent Switch更改你的Firefox的user-agent属性，伪装为iPhone，然后打开AppMarks，并且打开Firebug。接着点Menu -> Add -> Browse，看到出现AJAX请求了吧？猜猜这个请求是什么类型的，面向内容（传输更新上去的XHTML）、面向脚本（传输进行更新操作的JavaScript）还是面向数据（传输更新相关的JSON）？答案是——面向内容的！

这可是Web App哦，不是一般带有一点点AJAX的网页哦，我们要MVC，我们要"先进"的面向数据，为什么要"落后"的面向内容呢？至今为止，我们能够看到的大部分iPhone Web Apps，都将MVC保留在服务器端了，客户端唯一需要知道的就是内容更新，不存在任何的客户端MVC模型。暂时我还没看到有面向脚本或者面向数据的，如果你见到有应用这样做了，请告诉我。

我们继续说MVC的事情。现在大多应用的设计方式是这样的：每一个应拥有一个view framework，然后每一次点击所作的操作就是切换view。例如刚才说到的AppMarks，从Menu进入Add是一个view切换，不过因为Add这个view的内容是固定的，因此一早就包含在页面里，不用AJAX请求直接加载就行了。另外一种情况，就是好像加载Browse那样，是需要AJAX把view请求过来才能加载的。除了切换view，我们还需要action，例如提交数据就一定需要action的。说到这里，感觉是不是和RoR或者类似框架扯上关系了？事实上，RoR，或者类似框架，确实很适合用来做iPhone Web Apps。

以客户端为中心的AJAX

那么除了RoR，我们还有别的选择吗？我们可以选择使用一些客户端框架来实现类似的效果。这样说吧，类似RoR那样每一个view都是一个模板，但不是rhtml，而是普通的html，没有复杂逻辑，点击连接后不是由RoR引擎调在服务器端用rhtml，而是客户端自己直接拦截了链接点击并用AJAX的方法去请求该html然后更新内容。这样一个框架，可以在Wrox的 Professional iPhone and iPod touch Programming : Building Applications for Mobile Safari一书中见到。这本书写着2008年1月出版，但实际上已经出版，并且可以下载源代码。我暂时还没办法买到这本书，但源代码中就包括了这样一个客户端框架。

然而，这种以客户端为中心的做法并没有真正在客户端引入一个MVC，它只是简单地把服务器端的MVC裁减掉了，服务器端只能简单的发送内容或响应提交，因此只适用于比上面的以服务器端为中心的模型更简单的情景。如果你正在编写的应用不涉及大量的提交操作，或者根本就是Web1.0网站，我的意思是，单向传递信息不接受任何用户提交的网站，那么这种轻量级的模型就非常适用了。

小结

在这次的文章里，我们介绍了三种常见的iPhone Web Apps交互方案，没有哪一个是绝对更好或者更坏的，按照你当前开发的应用做出选择吧。将来我们写文章深入探讨其中的一些实现细节，或者是交互模式，但前提是我先完成了几个iPhone Web Apps。欢迎订阅本系列文章：

• Cat in Chinese ( feed)
• Cat in dotNET ( feed)

【转】编写 iPhone Friendly 的 Web 应用程序 (Part 4 - CSS)

编写 iPhone Friendly 的 Web 应用程序 (Part 4 - CSS)

Posted: 27 Dec 2007 12:54 AM CST

说到编写CSS，大家的第一反应肯定是——有没有选择性CSS。有！我们可以设计一个CSS，使得只有iPhone上的Safari会采用它，其他浏览器都会无视它，这样我们就可能可以复用现有的XHTML页面代码，仅仅为它们引入新的CSS就能够适用于iPhone，无须重新编写页面。这个选择性CSS链接语句如下：

<link media="only screen and (max-device-width: 480px)" href="small-device.css" type= "text/css" rel="stylesheet" />

Safari是支持media选择的，only screen声明该CSS仅用于屏幕显示（不用于打印），同时Safari还支持max-device-width这样的选项，限定屏幕宽度小于480的设备才采用该样式表，这就把iPhone与桌面浏览器划分开来了。

另一个做法是在服务器端就判断当前浏览器是否是iPhone上的Safari，从而选择返回哪个CSS文件，这可以通过user-agent进行判断，iPhone的如下：

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543 Safari/419.3

判断了浏览器之后，就可以开始针对Safari编写CSS了。Safari比较爽的一点是对CSS3的支持，设计PC端网页时总是要兼顾那个"后进"的IE，从而避免使用CSS3，或者需要确保IE在无视CSS3规则后仍然正确显示，现在不用为此而头痛啦，只要是Safari支持的就能用，针对一个浏览器设计就是比针对一堆浏览器设计要爽！

CSS3

接下来我们就列举一下Safari支持的CSS3属性吧：

边框

• -webkit-border-image - 让边框支持图片（iPhone上支持存在bug）
• -webkit-border-radius - 让边框支持远角
• -webkit-box-shadow - 让盒区域支持阴影（iPhone上不支持）

背景

• -webkit-background-origin / -webkit-background-clip - 控制背景的定位与剪裁
• -webkit-background-size - 控制背景的大小
• background - 多背景，如同单背景一样定义一个背景图片，多个图片定义之间用逗号分隔（未经测试）

色彩

• HSL - HSL色彩
• HSLA - 带Alpha通道的HSL色彩
• opacity - 透明度
• RGBA - 带Alpha通道的RGB色彩

文本特效

• text-shadow - 让文本支持阴影
• text-overflow - 控制文本溢出时的裁剪与视觉反馈
• word-wrap - 控制长单词换行

用户界面

• -webkit-box-sizing - 可以让盒模型变得基于边框而非内容
• resize - 让用户可以更改盒的大小（iPhone上不支持）
• outline - 设置盒的外边框

选择器

Safari支持大部分的CSS3选择器，你可以自己使用桌面端或iPhone上的Safari打开CSS Selectors Test进行测试，桌面端与iPhone上的Safari测试结果是一致的。Safari完全通过测试的CSS3选择器包括：

*, E, .class, #id, E F, E > F, E + F, E[attribute], :link, :visited, :before, ::before, :after, ::after, :first-letter , ::first-letter, :first-line, ::first-line, E - F, :root, :not(), :target, :enabled, :disabled, :checked

其它

• media - 根据media选择性加载CSS
• multi-column - 内容分栏支持（iPhone上不支持）

还有一些Safari自己做的CSS扩展没有列举出来。Safari完整的CSS属性支持列表请看这里：Supported CSS Properties 。

表单

Safari支持对<input />元素比较高自由度的CSS定义，例如这样的：

实现所需的CSS属性上面已经列举了，所以不再详细说明，灵活运用就是了。值得注意的是，某些<input />的默认背景并非纯白色的，而是半透明的，这使得这些元素能够更好地和不同的背景颜色进行颜色混合。为了说明这一点，请先看白色背景下的示例：

然后再看看蓝色背景下的：

小结

CSS相关的话题也说完了，很简单是不是？大部分针对桌面浏览器进行符合Web Standards页面设计的设计师都能轻易掌握这部分内容，然而这只是实现设计的手段，到底如何设计一个界面，在iPhone上才算是拥有高度易用性的，这才是真正的问题。这个问题我们将在以后探讨，至少现在你能够将你自己的设计在iPhone上准确无误的实现出来了，那么我们下一步就进入JavaScript的讨论环节了。

本iPhone Friendly专题的订阅地址如下：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

【转】编写 iPhone Friendly 的 Web 应用程序 (Part 3 - XHTML)

编写 iPhone Friendly 的 Web 应用程序 (Part 3 - XHTML)

Posted: 26 Dec 2007 11:11 PM CST

在接下来的两篇文章中，我们将探讨iPhone上的Safari所支持的XHTML与CSS，之后才进入JavaScript的讨论。作为一款现代化的浏览器，Safari当然是基于标准的，那就让我们看看Safari支持哪些标准吧：

• HTML 4.01
• XHTML 1.0
• CSS 2.1 以及部分 CSS 3
• JavaScript (ES3)
• DOM (Level 2)
• AJAX (XMLHttpRequest)

熟 悉这些标准并且平常也坚持Web Standards实践的朋友估计要笑出来了——就这些吗？我们天天在用啊，还有必要专门写文章来说明吗？事实上，Safari之前作为一款无PC版的浏 览器，一直用户数量就不高，因此对它的研究也就不多，然而Safari其实有不少自己的扩展，因此还是很值得研究的。既然我们是针对iPhone设置，其 实就是针对Safari设计，无需考虑兼容其它浏览器，这时候为什么不好好利用这些扩展增强自己的应用程序的可用性呢？

好吧，不说废话了，进入Safari对XHTML支持的介绍吧！

链接

iPhone对一下这样一些链接有特殊支持：

邮件

传统的mailto:地址iPhone将能自动使用内含的邮件程序处理，直接进入编写邮件的界面。完整的mailto:格式请参考RFC 2368。

电话

iPhone上的Safari会自动对看起来像是电话号码的数字串（包括已经加入连字符或括号格式化过的）添加电话链接，点击之后会询问用户是否想要拨打该号码。如果你不希望开启这个自动识别，可以将它关闭：

<meta name="format-detection" content="telephone=no" />

如果你关闭自动识别后，又希望某些电话号码能够链接到iPhone的拨号功能，那么可以通过这样来声明电话链接：

<a href="tel:13800138000">13800138000</a>

Google Maps

Google Maps的地图链接会自动调用内置的Google Maps客户端软件打开，而非在浏览器内浏览。链接可以是一个地点查询：

<a href="http://maps.google.com/maps?q=cupertino">Cupertino</a>

也可以是一个路线查询：

<a href="http://maps.google.com/maps?daddr=San+Francisco,+CA&saddr=cupertino">Directions</a>

YouTube

如果链接是指向YouTube视频地址的，将会自动调用内置的YouTube客户端打开播放。能够识别的YouTube地址格式为：

http://www.youtube.com/watch?v=<video identifier>

http://www.youtube.com/v/<video identifier>

其中<video identifier>替换为视频的id。

图片

由于用户浏览时有可能使用Wi-Fi，也有可能使用EDGE(GPRS)，因此你必须优化你的图片以确保即使是在使用EDGE访问你的网站的用户也能流畅的打开页面。因此你必须优化页面上的图片，尽量减少它们占用的传输带宽。另外Safari本身还对图片有如下的限制：

• GIF（包括GIF动画）、PNG与TIFF解压后的体积小于2m。意思是，原图的长度乘以宽度再乘以每一个像素的位数，得出来的大小要小于2m。
• JPEG解压后最大的体积是32m。解压体积大于2m的JPG会被进行二次抽样，最终显示给用户的是二次抽样后的结果。这使得Safari能够显示数码相机直接拍摄出来的照片，但显示时实际上是降低了精度的，以提高程序的执行效率。

为了尽量提高效率，例如你要将100*100的图片显示为10*10，就要在服务器端执行压缩操作，而不要直接用10*10的<img />来引用100*100的原始图片。

表单

text, password, textarea

在设计文本框的时候，必须记住用户点击后会出现软键盘，这时候可视区域就减少了：

另 外在文本框中输入时，iPhone提供了自动大写与自动更正两项功能。自动大写的意思是，在输入开始的时候，以及在一个句号并空一个格后，自动会启用 shift，输入一个字母后该shift自动消失。自动修正的意思是，iPhone会自动根据词库，包括自带的以及从你过往输入分析而来的，来对你的输入 进行自动更正。我们都知道用手指点击那么小一个软键盘很容易误按旁边的键，这时候你可以不用忙于修正，只要iPhone提示的自动修正的词正是你想要的， 你就可以按空格然后输入下一个词，iPhone会自动修正前面那个词。

要关闭这两项功能，可以通过autocapitalize与autocorrect这两个选项：

<input type="text" autocapitalize="off" autocorrect="off" />

select

必须留意到的是，iPhone上的<select />以不同的方式显示，以便于用户操作：

upload

iPhone不支持任何的文件上传下载，因此<input type="upload" />总是会显示出来，并且是……disabled的！

多媒体内容

iPhone上支持显示的多媒体内容，除了图片还包括QuickTime音频视频以及PDF。

如 果需要创建视频，可以使用QuickTime Pro。如果你正在使用一台MacBook或者iMac，并且已经将QuickTime升级为QuickTime Pro，可以马上就试一试！你需要做的就是打开QuickTime Pro，然后开始录像，（接着请对着镜头傻笑3秒，或者做点别的），最后选择"Export for Web"。其中iPhone格式与iPhone (cellular)格式分别适用于Wi-Fi与EDGE环境，iPhone在播放时会自动根据当前的环境选择适合的流媒体文件进行下载与播放，另外 poster是指影片播放之前在页面上显示的那一帧静态图片。 导出后文件夹里ReadMe.html说明了如何将这些文件添加到XHTML中。

（事实上，导出结果中QuickTime控件引用的那个mov文件不包含任何视频数据，它只是一个引用，类似我们编程时所说的引用，用于指向真正的视频文件。不过这个引用指向的是多个视频文件，客户端根据当前的状态自动选择正确的视频文件来播放。）

其他琐事

虽然说是琐事，但也必须注意到，这样才能让你的页面更好地受到Safari的支持。这包括：

• 声明正确的doctype
• 避免使用frameset
• 每一个独立的资源文件，HTML、CSS、JavaScript、以及非流媒体的其他多媒体文件，限制在10m之内
• 顶级入口的JavaScript执行时间限制为5秒，超时将自动终止。
• JavaScript分配内存上限为10m。
• 同一时间最多在Safari内打开8个子窗口（同时浏览的页面）。

小结

XHTML部分到这里就讲完了，可以看出iPhone对XHTML的支持与桌面端的Safari是类似的，只是加入了更多扩展功能而已。下一期将开始讲CSS，欢迎订阅：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

【转】编写 iPhone Friendly 的 Web 应用程序 (Part 2 - Viewport)

编写 iPhone Friendly 的 Web 应用程序 (Part 2 - Viewport)

Posted: 26 Dec 2007 03:48 AM CST

在了解到iPhone的一些常见布局法后，我们就可以开始着手编写一个真正能在iPhone上跑的页面了。小声说一句，之前我说要布局讨论完了，要进入交互逻辑开发，后来细心一想发现不行，有些东西不讲的话将会对布局带来问题，绕过去的话并不怎么优雅，因此继续讲布局。

首先要说的就是viewport，也就是可视区域。对于桌面浏览器，我们都很清楚viewport是什么，就是出去了所有工具栏、状态栏、滚动条等等之后用于看网页的区域，这是真正有效的区域。（无论你屏幕多大，如果你装足够多的toolbar，你的viewport最终也会消失掉。）在桌面浏览器中，viewport的大小是与浏览器窗口大小直接相关的，窗口大了viewport自然就大，同时随着viewport的改变，页面布局可能也跟着变。例如 width: 100%的页面宽度就总是和viewport宽度一致。

然而iPhone的Safari不是这样理解viewport的，它基于viewport呈现页面，然后用户缩放页面后viewport保持不变，仅仅是页面内容按比例缩放了。举个例子，在不设置viewport的情况下，默认viewport为宽度980（单位是像素），这时候页面的呈现出来的布局和在桌面短viewport宽度为980时呈现的结果一致，然而因为iPhone屏幕宽度为320，因此按比例缩小了。因此，一张宽度为320的图片，在默认viewport下会这样显示：

可以看到，图片按比例缩小了，这对于传统Web页面直接在iPhone上面显示来说是很好的事情，因为如果传统Web页面在980宽度的桌面浏览器viewport中显示正常的话，iPhone上显示也绝对正常。然而这对于Web应用程序来说则不是好事，因为我们需要按照980宽度来设计将来会以320宽度显示的页面，一个应该显示为320*80的元素，必须设计为980*245，这多麻烦！

因此我们需要改变viewport，让它变成这样：

实际上应该怎么做呢？我们有几个选择，因此先让我们看看到底我们能够设置哪些属性吧。我们可以操作的属性有4个：

• width - viewport的宽度
• height - viewport的高度
• initial-scale - 初始的缩放比例
• minimum-scale - 允许用户缩放到的最小比例
• maximum-scale - 允许用户缩放到的最大比例
• user-scalable - 用户是否可以手动缩放

这6个属性，我们可以设置其中的一个或者多个，iPhone会根据你设置的属性自动推算其他属性值，而非直接采用默认值。这点很重要，在完全不设置的时候有默认viewport，在你设置一个属性后其它值是自动推算出来的，不再是默认的。

如果你把initial-scale=1，那么width和height在竖屏时自动为320*356（不是320*480因为地址栏等都占据空间），横屏时自动为480*208。

类似地，如果你仅仅设置了width，就会自动推算出initial-scale以及height。例如你设置了width=320，竖屏时initial-scale就是1，横屏时则变成1.5了。

那么到底这些设置如何让Safari知道？其实很简单，就一个meta，形如：

<meta id="viewport" name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;"/>

在设置了initial-scale=1之后，我们终于可以以1:1的比例进行页面设计了。下一步我们就可以正式进入页面布局的细节设计了，如果你想继续关注iPhone开发话题的话，欢迎订阅：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

【转】Wii+电脑+电视=头部跟踪三维显示器

【转】编写 iPhone Friendly 的 Web 应用程序 (Part 1 - 布局入门)

写 iPhone Friendly 的 Web 应用程序 (Part 1 - 布局入门)

Posted: 25 Dec 2007 07:47 AM CST

用 过iPhone的朋友应该知道，iPhone上面的一些应用程序是能够随机器转动自动适应的，也就是说竖着拿的时候就竖着显示，横着拿的话就横着显示， iPhone中至关重要的Safari浏览器当然也支持这一点了，因此我们考虑设计iPhone friendly的应用程序时，首先要考虑兼容这种情况，不能把页面定死在一个宽度上。且慢，我们不是说设计自己的应用程序吗？这和内置的Safari有 何关系？iPhone被设计为不允许安装任何第三方应用程序（破解不在讨论范围之内），一切第三方应用程序必须以Web的形式来跑，小到一个国际象棋的游 戏也如此，因此我们现在说的应用程序就是指Web，但是与传统意义上以提供信息为核心的Web又不同，我们所说的是以提供交互操作为主的应用。

好吧，在我们正是进入布局的讨论之前，先来赏析一下已有的iPhone应用：

Facebook iPhone Edition

Facebook 的iPhone版。如果你已经习惯了在iPhone上使用过Facebook，第一次在PC上浏览这个页面会被它的"肥大"吓坏的。从这个页面我们能够得 知，让页面自动适应iPhone屏幕的方法就是尽量使用百分比来定义宽度，特别是全页宽度一律用100%，如果是导航栏里面4个项目并排的就每个25%。

AppMarks

AppMarks 可以说是一个应用程序的书签，当然也有人把它作为Safari的首页，那就相当于桌面了，因为你收藏的应用程序就在这个页面直接显示，以大图标的方式。 AppMarks以前是可以直接在PC上浏览的，现在已经自动将非iPhone的请求重定向到介绍页了，不过这里有一个AppMarks Demo能 在PC上看看。我们能够看得到图片是4个一行地排列的，共12个，然而横屏会怎样了？当然是变成6个一行，仍然能够在一屏内显示完，并且不会有不满行的图 标。其实这是一个很tricky的做法，12是4和6的公倍数，因此虽然竖屏和横屏的显示方式不一样，但你不会觉得有什么缺陷。

Newsgator Mobile iPhone Edition

终 于有一个ASP.NET写的iPhone应用了，其实和上面的Facebook看起来差不多，同样采用了宽度为100%的做法，同时页面上的元素要么向左 对齐要么向右对齐。这听起来很废话，其实意思是，中间尽管留空，不要想把整个宽度为100%的块区都利用起来，说明性文字可以放左边，操作及视觉反馈放右 边，这样无论屏幕怎么旋转都好看。如果中间塞满了内容，只会让Safari进行比例缩放操作，把页面整个缩小，这其实是不利于操作的。

GMail

这不是普通的GMail吗？怎样才能看到iPhone版？这就需要通过修改user-agent属性欺骗它了。iPhone上的Safari所用的user-agent如下所示：

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3

使用Firefox的User Agent Switcher修改一下user-agent就行了，然后你就能看到iPhone上看到的GMail了。仍然和上面的网站一样，可点击区域是一大个宽度为100%的块区。

总结

实 际上，设计iPhone friendly的界面，在CSS的层面上来说一点也不难，甚至可以说是非常简单，因为基本上就是宽度为100%的块区，少数时候要用到按百分比划分的块 区，但实际上我们也应该避免这种情况。为什么呢？别忘记了，iPhone的用户是没有鼠标的，他们必须通过手指来操作页面上的一切，因此可点击区域必须尽 量大。

既然他们看不到鼠标指针，你也就不用考虑可点击区域必须是链接或者cursor: pointer，因为用户无法通 过鼠标指针的改变来判断一个区域是否能点击。然而这同时也就引入了另一个问题，如何让用户了解一个区域能否点击呢？这时候你必须给出明确的视觉暗示，例如 看起来是链接的文本，蓝色的文本有无下划线通常都挺诱惑人去点，这方面Facebook是一个例子。另一种做法是让界面看起来是菜单式的，好像 AppsMarker和Newsgator那样，菜单右侧的符号让人挺熟悉不是吗？只要我点击这个菜单项，就会展开下一级菜单。最后一种做法就是基于用户 已经熟悉的独创暗示来提示用户，习惯使用GMail的用户一看到邮件标题那个大大的蓝色区域，就知道点击是打开邮件，这是不需要任何指引的，最坏的情况 下，用户不知道点击什么还是会点击邮件标题，之后他也就会用了。

到此为止，就已经把设计iPhone friendly应用界面的一些布局因素解释清楚了，我们下一步就要进入交互的环节，让我们的应用程序真正执行起来，并且是在客户端JavaScript环境中执行起来。如果你想继续关注本话题的话，欢迎订阅：

• Cat in Chinese (feed)
• Cat in dotNET (feed)

【转】任天堂、索尼、微软三家游戏主机之间的对决

Gmail的新界面

用了几天Gmail最新版本的界面——页面顶部有个链接可以在“Newer Version”/“Older version”（这里似乎有一个文本不统一的bug）之间切换——发表一些个人看法：

1. 首次进入Gmail时页面打开的速度比以前慢了（如果在Firefox里用了Firebug插件，还有一些兼容性问题，暂时关闭Firebug比较好）
2. 不同的文件夹、标签及邮件时都有各自的URL了，过去刷新页面总是会跳回到收件箱，现在可以保持当前浏览状态
3. 各种操作的弹出对话框（比如“Apply Label”时“New Label”）不再是默认样式而是Google特有的风格
4. 在邮件会话顶部，提供了其所属Label的快速链接和删除功能
5. 可以对标签进行自定义颜色了（邮件醒目）

暂时就这些吧

数学之美 系列二十三 - 输入一个汉字需要敲多少个键 — 谈谈香农第一定律

数学之美 系列二十三 - 输入一个汉字需要敲多少个键 — 谈谈香农第一定律

作者：Google（谷歌）研究员，吴军

今天各种汉字输入法已经很成熟了，随便挑出一种主要的输入法比十几年前最好的输入法都要快、要准。现在抛开具体的输入法，从理论上分析一下，输入汉字到底能有多快。

我 们假定常用的汉字在二级国标里面，一共有 6700 个作用的汉字。如果不考虑汉字频率的分布，用键盘上的 26 个字母对汉字编码，两个字母的组合只能对 676 个汉字编码，对 6700 个汉字编码需要用三个字母的组合，即编码长度为三。当然，聪明的读者马上发现了我们可以对常见的字用较短的编码对不常见的字用较长的编码，这样平均起来每 个汉字的编码长度可以缩短。我们假定每一个汉字的频率是
p1, p2, p3, ..., p6700
它们编码的长度是
L1, L2, L3, ..., L6700
那么，平均编码长度是
p1×L1 + p2×L2 + ... + p6700×L6700

香 农第一定理指出：这个编码的长度的最小值是汉字的信息熵，也就是说任何输入方面不可能突破信息熵给定的极限。当然，香农第一定理是针对所有编码的，不但是 汉字输入编码的。这里需要指出的是，如果我们将输入法的字库从二级国标扩展到更大的字库 GBK，由于后面不常见的字频率较短，平均编码长度比针对国标的大不了多少。让我们回忆一下汉字的信息熵（见 http://www.googlechinablog.com/2006/04/4.html），
H = -p1 * log p1 - ... - p6700 log p6700。
我们如果对每一个字进行统计，而且不考虑上下文相关性，大致可以估算出它的值在十比特以内，当然这取决于用什么语料库来做估计。如果我们假定输入法只能用 26 个字母输入，那么每个字母可以代表 log26=
4.7 比特的信息，也就是说，输入一个汉字平均需要敲 10/4.7= 2.1 次键。

聪 明的读者也许一经发现，如果我们把汉字组成词，再以词为单位统计信息熵，那么，每个汉字的平均信息熵将会减少。这样，平均输入一个字可以少敲零点几次键 盘。不考虑词的上下文相关性，以词为单位统计，汉字的信息熵大约是8比特作用，也就是说，以词为单位输入一个汉字平均只需要敲 8/4.7=1.7 次键。这就是现在所有输入法都是基于词输入的内在原因。当然，如果我们再考虑上下文的相关性，对汉语建立一个基于词的统计语言模型（见http://www.googlechinablog.com/2006/04/blog-post.html），我们可以将每个汉字的信息熵降到 6 比特作用，这时，输入一个汉字只要敲 6/4.7=1.3 次键。如果一种输入方法能做到这一点，那么汉字的输入已经比英文快的多了。

但 是，事实上没有一种输入方法接近这个效率。这里面主要有两个原因。首先，要接近信息论给的这个极限，就要对汉字的词组根据其词频进行特殊编码。事实上像王 码这类的输入方法就是这么做到，只不过它们第一没有对词组统一编码，第二没有有效的语言模型。这种编码方法理论上讲有效，实际上不实用。原因有两个，第 一，很难学；第二，从认知科学的角度上讲，人一心无二用，人们在没有稿子边想边写的情况下不太可能在回忆每个词复杂的编码的同时又不中断思维。我们过去在 研究语言识别时做过很多用户测试，发现使用各种复杂编码输入法的人在脱稿打字时的速度只有他在看稿打字时的一半到四分之一。因此，虽然每个字平均敲键次数 少，但是打键盘的速度也慢了很多，总的并不快。这也就是为什么基于拼音的简单输入法占统治地位的原因。事实上，汉语全拼的平均长度为 2.98，只要基于拼音的输入法能利用上下文彻底解决一音多字的问题，平均每个汉字输入的敲键次数应该在三次左右，每分钟输入 100 个字完全有可能达到。

另外一个不容易达到信息论极限的输入速度的原因在于，这个理论值是根据一个很多的语言模型计算出来的。在产品中，我 们不可能占有用户太多的内存空间，因此各种输入方法提供给用户的是一个压缩的很厉害的语音模型，而有的输入方法为了减小内存占用，根本没有语言模型。拼音 输入法的好坏关键在准确而有效的语言模型。

另一方面，由于现有输入方法离信息论给的极限还有很大的差距，汉语输入方法可提升的空间很大，会有越来越好用的输入方法不断涌现。当然，输入速度只是输入法的一项而不是唯一的衡量标准。我们也会努力把谷歌的输入法做的越来越好。大家不妨先试试现在的版本，http://tools.google.com/pinyin/，半年后再看看我们有没有提高。

数学之美 系列二十二 - 由电视剧《暗算》所想到的 — 谈谈密码学的数学原理

数学之美 系列二十二 - 由电视剧《暗算》所想到的 — 谈谈密码学的数学原理

作者：Google（谷歌）研究员，吴军

前一阵子看了电视剧《暗算》，蛮喜欢它的构思和里面的表演。其中有一个故事提到了密码学，故事本身不错，但是有点故弄玄虚。不过有一点是对的，就是当今的密码学是以数学为基础的。（没有看过暗算的读者可以看一下介绍，http://ent.sina.com.cn/v/2005-10-17/ba866985.shtml
因为我们后面要多次提到这部电视剧。）

密码学的历史大致可以推早到两千年前，相传名将凯撒为了防止敌方截获情报，用密码传送情报。凯撒的做法很简单，就是对二十几个罗马字母建立一张对应表，比如说



这 样，如果不知道密码本，即使截获一段信息也看不懂，比如收到一个的消息是 EBKTBP，那么在敌人看来是毫无意义的字，通过密码本解破出来就是 CAESAR 一词，即凯撒的名字。这种编码方法史称凯撒大帝。当然，学过信息论的人都知道，只要多截获一些情报，统计一下字母的频率，就可以解破出这种密码。柯蓝道尔 在他的“福尔摩斯探案集”中“跳舞的小人”的故事里已经介绍了这种小技巧。在很长时间里，人们试图找到一些好的编码方法使得解密者无法从密码中统计出明码 的统计信息，但是，基本上靠经验。有经验的编码者会把常用的词对应成多个密码， 使得破译者很难统计出任何规律。比如，如果将汉语中的“是”一词对应于唯一一个编码 0543，那么破译者就会发现 0543 出现的特别多。但如果将它对应成十个密码 0543，3737，2947 等等，每次随机的挑一个使用，每个密码出现的次数就不会太多，而且破译者也无从知道这些密码其实对应一个字。这里面虽然包含着朴素的概率论的原理，但是并 不科学化。另外，好的密码必须做到不能根据已知的明文和密文的对应推断出新的密文的内容。历史上有很多在这方面设计得不周到的密码的例子。在第二次世界大 战中，日本军方的密码设计就很成问题。美军破获了日本很多密码。在中途岛海战前，美军截获的日军密电经常出现 AF 这样一个地名，应该是太平洋的某个岛屿，但是美军无从知道是哪个。于是，美军就逐个发表自己控制的每个岛屿上的假新闻。当美军发出“中途岛供水系统坏了” 这条假新闻后，从截获的日军情报中又看到 AF 供水出来问题的电文，美军就断定中途岛就是 AF。事实证明判断正确，美军在那里成功地伏击了日本主力舰队。

事实上，在第二次世界大战中，很多顶尖的科学家包括提出信息论的香农都在 为美军情报部门工作，而信息论实际上就是情报学的直接产物。香农提出信息论后，为密码学的发展带来了新气象。根据信息论，密码的最高境界是使得敌人在截获 密码后，对我方的所知没有任何增加，用信息论的专业术语讲，就是信息量没有增加。一般来讲，当密码之间分布均匀并且统计独立时，提供的信息最少。均匀分布 使得敌人无从统计，而统计独立能保证敌人即使看到一段密码和明码后，不能破译另一段密码。这也是《暗算》里传统的破译员老陈破译的一份密报后，但无法推广 的原因，而数学家黄依依预见到了这个结果，因为她知道敌人新的密码系统编出的密文是统计独立的。有了信息论后，密码的设计就有了理论基础，现在通用的公开 密钥的方法，包括《暗算》里的“光复一号”密码，就是基于这个理论。

公开密钥的原理其实很简单，我们以给上面的单词 Caesar 加解密来说明它的原理。我们先把它变成一组数，比如它的 Ascii 代码 X=099097101115097114（每三位代表一个字母）做明码。现在我们来设计一个密码系统，对这个明码加密。

1，找两个很大的素数（质数）P 和 Q，越大越好，比如 100 位长的, 然后计算它们的乘积 N=P×Q，M=（P-1）×（Q-1）。

2，找一个和 M 互素的整数 E，也就是说 M 和 E 除了 1 以外没有公约数。

3，找一个整数 D，使得 E×D 除以 M 余 1，即 E×D mod M = 1。

现在，世界上先进的、最常用的密码系统就设计好了，其中 E 是公钥谁都可以用来加密，D 是私钥用于解密，一定要自己保存好。乘积 N 是公开的，即使敌人知道了也没关系。

现在，我们用下面的公式对 X 加密，得到密码 Y。



好了，现在没有密钥 D，神仙也无法从 Y 中恢复 X。如果知道 D，根据费尔马小定理，则只要按下面的公式就可以轻而易举地从 Y 中得到 X。



这个过程大致可以概况如下：



公开密钥的好处有：

1.简单。

2. 可靠。公开密钥方法保证产生的密文是统计独立而分布均匀的。也就是说，不论给出多少份明文和对应的密文，也无法根据已知的明文和密文的对应来破译下一份密 文。更重要的是 N,E 可以公开给任何人加密用，但是只有掌握密钥 D 的人才可以解密, 即使加密者自己也是无法解密的。这样，即使加密者被抓住叛变了，整套密码系统仍然是安全的。（而凯撒大帝的加密方法有一个知道密码本的人泄密，整个密码系 统就公开了。）

3.灵活，可以产生很多的公开密钥E和私钥D的组合给不同的加密者。

最后让我们看看破解这种密码的难度。 首先，要声明，世界上没有永远破不了的密码，关键是它能有多长时间的有效期。要破公开密钥的加密方式，至今的研究结果表明最好的办法还是对大字 N 进行因数分解，即通过 N 反过来找到 P 和 Q，这样密码就被破了。而找 P 和 Q 目前只有用计算机把所有的数字试一遍这种笨办法。这实际上是在拼计算机的速度，这也就是为什么 P 和 Q 都需要非常大。一种加密方法只有保证 50 年计算机破不了也就可以满意了。前几年破解的 RSA-158 密码是这样因数分解的

395058745832651445264197678006144819960207764603049364541393760515793556265294
50683609727842468219535093544305870490251995655335710209799226484977949442955603
= 3388495837466721394368393204672181522815830368604993048084925840555281177 ×11658823406671259903148376558383270818131012258146392600439520994131344334162924536139

现 在，让我们回到《暗算》中，黄依依第一次找的结果经过一系列计算发现无法归零，也就是说除不尽，我猜她可能试图将一个大数 N 做分解，没成功。第二次计算的结果是归零了，说明她找到的 N=P×Q 的分解方法。当然，这件事能不能用算盘完成，我就不知道了，但我觉得比较夸张。另外我对该电视剧还有一个搞不懂的问题就是里面提到的“光复一号”密码的误 差问题。一个密码是不能有误差的，否则就是有的密钥也无法解码了。我想可能是指在构造密码时，P 和 Q 之一没找对，其中一个（甚至两个都）不小心找成了合数，这时密码的保密性就差了很多。如果谁知道电视剧里面讲的“误差”是指什么请告诉我。另外，电视剧里 提到冯∙诺依曼，说他是现代密码学的祖宗，我想是弄错了，应该是香农。冯∙诺依曼的贡献在发明计算机和提出博弈论（game theory）。

不管怎么样，我们今天用的所谓最可靠的加密方法的数学原理其实就这么简单，一点也不神秘，无非是找几个大素数做一些乘除和乘方运算就可以了。