Web框架是人们在使用某种语言编写Web应用服务端时关于架构的最佳实践。
有些Web框架是从实际的Web项目抽取出来的，也就是说，做一个具体的应用项目时，采取的架构比较理想，就把这部分和领域无关，而仅和Web的请求和响应处理有关的设计拿出来，形成一个基础，在开发别的应用项目的时候则可以从这基础做起，让开发者更关注领域问题，而不是Web的请求和响应的控制。
也有些Web框架是直接设计出来的，很多Web框架在设计的时候也都借鉴了别的框架，吸取优点，修改不足，并根据自己的框架的定位，在特定方面有自己的发挥，形成了自己的特点，比如有的web框架追求的是松耦合性，层次，结构之间都不密切绑定，有的Web框架则追求敏捷性，强调约定而不是配置。
Java的Web框架虽然各不相同，但基本也都是遵循特定的路数的：使用Servlet或者Filter拦截请求，使用MVC的思想设计架构，使用约定，XML或Annotation实现配置，运用Java面向对象的特点，面向抽象实现请求和响应的流程，支持Jsp，Freemarker，Velocity等视图。
以我使用的经验，我觉得看一个Java Web框架应看看下面几个方面：
1.设计理念
一个框架设计出来应该有一个基本的思路，它为什么要要被设计出来？有的框架的目标就是提高效率，有的框架的目标的给用户充分的选择，有的框架的目标是充分 了解实际需求，给用户一个尽量合理的默认选择，有的框架是要给使用者开发桌面程序的感觉。应该说，一个好的框架应该是实现了预期目标，体现出了自己的设计 理念的。
2.设计的合理性
设计的合理性表现在框架在一些关键问题上的处理，比如灵活性和敏捷性之间的权衡，硬编码和文本配置之间的权衡。灵活性指的是可以适应用户多样的需求，很特 殊的要求也能得到支持，有的框架的实现基于太多的约定，使得用户只能遵循。而敏捷性指的是用户在解决绝大多数常规问题的时候，能尽量少做工作，提高效率。 框架设计者只能在这两者见达到一个平衡点，权衡的怎么样，就很见水平了。硬编码和文本配置之间的权衡也很有意思，文本配置的意义在于Java是一个编译语 言，强调代码的封闭，讲究扩展而不是修改，这种情况下文本配置信息可以很方便的在不修改程序的情况下改变程序行为，但是随着一些灵活的脚本语言实现的 Web框架的出现，人们发现在这样的框架中，脚本语言即做程序编码语言，也做配置语言，还做视图上的标记语言，这使我们对Java实现的框架有了一番新的 审视，既然配置文件并没有消除对程序的修改，为什么不能在应编码上下下功夫呢？
3.设计的平衡性
设计的平衡性指的是，框架在设计流程中各阶段，各层次的实现方式时，所达到的上述权衡（灵活性和敏捷性之间的权衡等）应该是具有一致的水平。一个在控制上过分灵活，而视图上具有非常大限制的框架是不能算做一个好的框架的。
4.框架真的解放了开发者吗
框架的目的是让开发者把更多的精力放在领域问题，而非Web的请求和响应的处理问题上。而事实上框架都做到这一点了吗？不可否认，框架的使用提高代码的可 维护性，但是框架在解放开发者这点上就未必了，有时还给开发者带来了额外的负担。事实上，直接使用Servlet，只要维持好代码风格，一样可以很有效 率，当然，直接使用Servlet的灵活性就不用说了。
这里引用一篇总结各个Java Web框架优缺点的文章，原文链接是：http://www.blogjava.net/javaread/archive/2008/08/21/223561.html
JSF
优点：
Java EE标准，这意味着有很大的市场需求和更多的工作机会
上手快速并且相对容易
有大量可用的组件库
缺点：
大量的JSP标签
对REST和安全支持不好
没有一个统一的实现。既有SUN的实现，又有Apache的实现——MyFaces。
国内的OperaMasks还支持AJAX，以及有开发工具支持
Spring MVC
优点：
对覆盖绑定（overriding binding）、验证（validation）等提供生命周期管理
与许多表示层技术/框架无缝集成：JSP/JSTL、Tiles、Velocity、FreeMarker、Excel、XSL、PDF等
便于测试——归功于IoC
缺点：
大量的XML配置文件
太过灵活——没有公共的父控制器
没有内置的Ajax支持
Stripes
优点：
不需要书写XML配置文件
良好的学习文档
社区成员很热心
缺点：
社区比较小
不如其他的项目活跃
ActionBean里面的URL是硬编码的
Struts 2
优点：
架构简单——易于扩展
标记库很容易利用FreeMarker或者Velocity来定制
基于控制器或者基于页面的导航
缺点：
文档组织得很差
对新特征过分关注
通过Google搜索到的大多是Struts 1.x的文档
Tapestry
优点：
一旦学会它，将极大地提高生产率
HTML模板——对页面设计师非常有利
每出一个新版本，都会有大量的创新
缺点：
文档过于概念性，不够实用
学习曲线陡峭
发行周期长——每年都有较大的升级
Wicket
优点：
对Java开发者有利（不是Web开发者）
页面和显示绑定紧密
社区活跃——有来自创建者的支持
缺点：
HTML模板和Java代码紧挨着
需要对OO有较好的理解
Wicket逻辑——什么都用Java搞定
在Java的Web框架中，我使用过Struts1，Struts2，试用过Stripes，Wicket，了解过JSF，SpringMVC。
在我接触的Web框架中，我最推崇的是Struts2，设计优雅，偏重灵活，也基本不造成额外的负担，当然这些评价是和我参与的项目的规模有关的，其他规模的项目Struts2就未必合适了。我希望Struts2能在下面几个方面有些改善：
1.在提供文本配置方式的基础上给一个约定配置的方式，让开发者在大多数情况下可以不配置。
2.配置也支持硬编码，因为有时候维护可修改的硬编码是很有效率的。
3.在拦截请求上，能借鉴下ROR，Django的思路，适应新的Url的需求，考虑大家对“?”后添加属性的回避，支持带占位符的Url。
Windows Live是微软用域名live.com提供的一个服务集的品牌。大家可以通过http://www.live.com/?mkt=en-us和http://www.live.com/?mkt=zh-cn分别访问Windows Live的英文首页和中文首页。
微软于2005年1月完成了域名的购买和准备，并放出了Windows Live的beta版，明确了微软继其网络品牌MSN之后倾心打造一个完善和宏伟的互联网服务平台的态度。微软从msn.com到live.com绝对算是一次成功的品牌重新打造，新域名是一个很有意义的主题词，而不是一个生硬的品牌语句：MSN (Microsoft Service Network)，当然苹果的mac.com到me.com应该比微软做的更漂亮。有兴趣的可以看一看微软接手前live.com的模样，也可以看看微软是怎么收购live.cn的。
在微软推出Live之后，有一个具有巨大影响力的互联网事件是Live Mail的升级邀请，这应该说是Windows Live的对新品牌的的一次比较成功的营销。
如果说上述的过程表现出了微软的魄力，技巧，品牌运作能力以及固有的号召力的话，那么之后Windows Live的发展堪称一个失败。当然，这个失败并不是针对Windows Live的每一个成员服务，事实上Live Messager，Live Spaces可以受用户欢迎，Live Search也可以占据一定的市场份额。但是，作为一个给人无限想象的Live品牌，微软的表现很不够，或者表现的太慢了，过去了这些时间，Live成了一个没有一个确定的入口定位，域名扯不清，服务的名称扯不清，旧服务和新服务之间扯不清的东西。Live根本没有达到它应有的高度。
现在总结下Windows Live的三乱和三变。
第一乱：域名乱
微软应该在开始Live计划的时候保护性注册了包括windowslive.com，gowindowslive.com等在内的许多相关域名， 保护注册也就罢了，微软还真有兴趣的都启用了。我真是无法理解微软这一点，特别是在一个服务还处于不断的变化和调整中。对于域名的使用，我的看法是首先要区分访问的资源是否是应该对用户具有友好的地址，如果一个资源形成一个入口，那使用独立的特别是和资源含义切合的域名是很好的方案，而对不需要对用户具有友好的地址的资源，比如软件的一个辅助功能的链接，或者是一个只能从别的页面才能访问到的链接，就没有必要，甚至不要使用一个友好的域名，因为用友好的域名反而会让直接访问域名的用户困扰，也破坏其他门户域名的官方性。但是，访问微软的网站，你经常会看到你访问的一个具有首页性质的资源的地址栏是中又长又有查询字符的地址，你也经常会发现访问微软的网站地址栏不断在各式各样的域名间跳转，微软用相对多的域名起用量，构建了链接相对不大友好的网站。令人诧异。
第二乱：本地化乱
访问微软的网站，根本就弄不明白起本地化的思路，语言的翻译，客户端语言环境的判断都做了，但是国别域名的使用呢，微软为中国作了些专门的本地化网页，比如get.live.cn，但是这些页面和主站www.live.cn的关联呢？我有过访问着中文页面然后就点入了一个英文页面的体验。还有微软的网站仅仅就是从客户端判断用户的语言环境，而没有给用户选择语言的机会，也没有树立起一个中心internet站，这都应该是本地化考虑很不完善的地方。
第三乱：服务体系乱
通过观察，很艰难的理出了Windows Live中各项服务的体系。Live品牌下包括三块服务，分别是Live Search，MSN和Windows Live，Live Search是Web搜索引擎，MSN是一个信息门户，而Windows Live才是诸多服务的统称，Windows Live包括3组服务：“联系”，“共享”和“保护”，联系以Hotmail为代表，包括日历，Messager这些，共享以Spaces为代表，包括图片库等，保护则是微软自己推的杀毒软件Onecare的Web版本。应该说，这个体系还ok，突出了搜索引擎的重点，继承了旧的本户服务，也比较恰当的划分了服务，但是微软的这个划分就是不能让人很清晰都认识到，网络服务和客户端软件混在一起，而且Live中体现服务体系的地方至少有三处，get.live.com上有一个体会，home.live.com上有一个体会，那个Live页面左上方的Vista风格的菜单中也有个体会，这三处还是很不一致的。
第一变：程序变
如果说Messager是在一个个版本升级的化，那么Spaces和Hotmail则都是完全抛弃久的重新做了一个新的，个人觉得新版的Hotmail的没有突出的改善，作为Gmail之后的Web邮箱，Hotmail并不是一个好的Ajax案例，和Yahoo的新版Web电子邮件差了好几个数量级，在服务功能上，也不能与时俱进的去扩展功能，还是那么点，以为大家没了它就注不到邮箱了阿。而新版的Spaces我觉得就是一个失败，除了外感更贴近Vista之外，其他一无是处，速度依然很慢，功能很弱，体验非常糟糕，只能说勉强是个流程都通了的完成版本，和其他BSP的作品没法比。这两个代表服务这样的变化，实在让人失望。
第二变：命名变
微软推出新品牌Live，旧有的服务的名称做一些调整是很必要的，MSN Messager变成了Live Messager，MSN Spaces变成了Live Spaces，Windows Hotmail变成了Live Mail。但是现在Live Mail又恢复成Hotmail的名称了，hotmail.com又访问的是原来的hotmail的首页了，Live的一些服务就是在旧版和新版间徘徊，技术层面的新旧更替容易，品牌层面的新旧更替反而难了，当然品牌层面有品牌层面的问题，但是微软做的太不漂亮了，我都可以想象他们自己都理不清除那么多服务的新旧名字，新旧命名以及不同语言的命名的窘态。
第三变：外观变
最初Windows Live刚推出的时候，是清新的白色风格，现在在windows的各项服务都还没完善的情况下，Windows Live已经经历了一次外观的调整，现在的Windows Live应该是Vista风格的。看来微软就是不认为软件的功能的完整和体验的优越是重点，而是自己做自己的大一统最重要。
身为一个用户，在总结这些“乱”和“变”的时候，心情都能变糟糕。这么好的基础去做统一品牌，统一主题，统一风格，统一用户的Web服务，还能做的比这更失败吗？是什么原因造成的呢。我觉得有三点：
1. 微软做Web服务的动机不纯
微软的核心业务是个人电脑操作系统和桌面软件，微软设计Live的时候，不可避免会受这个因素的影响。客户端Mail，客户端Writer，客户端OneCare的优先级都被提高了，而不管这些服务对于构建统一的Web服务是否是最必要的。外观在中途调整成Vista风格，外观的统一真的比服务本身还重要吗？另外，Windows Live原本要给人留下“这里有丰富的服务”的感觉，而现在却想给人留下“这是一个搜索引擎”的感觉，这个调整的原因估计大家都很清楚。
2. 服务切换，新品牌的树立确实是比较复杂的工作，微软作为大的服务商，在注意老用户的使用上需要花费更大的经历
毕竟微软的用户有这么大一个摊子，公司形象也很重要，不能向蚂蚁网那样搞那么“华丽的转身”。微软需要在进行这些切换的过程中，老用户的使用不会受到影响，甚至老用户的使用体验也能让他们选择要不要改变，虽然这样的继承性是否必要是需要讨论的，但微软做这方面的努力表现出了一个大公司的姿态，而这些工作也确实增大了服务切换的复杂性。
3. 微软的自身能力
微软作为软件公司，我不怀疑它的应用软件的项目能力，但是根据Windows Live的表现，我不得不怀疑它的Web服务的项目能力，产品设计，程序开发，开发效率，项目生命周期，服务整合，服务互访性，服务本地化，暴露的问题太多了。按说用Live作为主题，提供网民上网的一整套信息服务方案，是多么令人振奋的计划阿，结果弄成这样，单一服务的功能是很一般的，放在一起更一般。
貌似现在的Windows Live是2.0版本，3.0版本的已经放出来测试了。在此，由衷的希望微软别让人失望。
最近第一次接触ipod nano，经过一天的试用，有一些疑问，通过在网上搜索都得到了答案，在此和大家分享一下 – ipod新用户可能会问的7个问题。
1. nano怎么关机
正确答案是退回到主菜单时，长按播放键6秒，再把键盘锁上。因为开机只要轻轻按下任何键就可以，所以一定要记得锁键盘。有人说nano不用关机，只要暂停后，锁上键盘会自动关闭，其实这样nano只是进入了睡眠状态，做任何操作，包括在键上划过都能激活机器。还有人说是长按Menu和中间的键，这个其实是nano的重启方法，相当于Windows的Ctrl+Alt+Del的组合键。
2. nano怎么停止播放
正确答案是用nano不必非要停止播放，只要暂停就行了，也就是按最下面的播放健。使用nano放歌时，和播放视频不同，用Menu和中间键导航是不会影响歌曲的播放的，如果要停止播放，确实就只要暂停就行了。如果非要追求一个停止状态，那只好重启，或者播放下视频再退出，或者在不循环播放的情况下在最后首歌时点下一首，在第一首歌是点上一首。很奇怪的办法吧，不过反过来要问，为什么非要停止呢？
3. nano怎么删除里面的歌曲，视频
正确答案是用itunes进行管理。记住啦，无法在nano上完成的操作，想想itunes。
4. nano怎么删除自己建立的播放列表
正确答案是在itunes里删除。nano很有趣，可以在上面完成创建一个播放列表这样的复杂工作，居然不能提供一个删除歌曲和视频以及播放列表的功能。不过，还是那句，无法在nano上完成的操作，想想itunes。
5. nano怎么传照片
为什么要把照片放上去呢，反正我是不用的。不过好歹是个功能，那么怎么传呢？nano的模式是你指定一个地方，可以是资源管理器里的一个文件夹，可以是iphoto中符合某些条件的照片，itunes建立起这个地方和你的nano之间的同步关系，同步的时候itunes会做一些格式转换和优化操作。怎么删除呢，既然是同步，你只要在电脑上做下取舍工作，再次同步就行了，怎么完全删除呢，在itunes里不选中“同步照片”，然后同步就行了。
6. nano怎么传视频
nano对视频是有要求的，所以nano和电脑链接后，不是所有的视频都可以传进nano的，即使格式是符合的也未必，itune也不会给你任何提示。我的办法是充分倚赖这几个好软件，Ultra ipod converter，Easy video to ipod converter和Winavi ipod video converter，一般是一个不行就换另一个，具体nano要求什么格式，什么尺寸，什么规格都不必操心，这几个软件生成的就是可以用的。
7. nano怎么存放普通文件
这个问题其实就是问，nano怎么当u盘使用，虽然有的人会问为什么要把nano当u盘使呢？在itunes里有个选项是“用作磁盘”，默认是勾选了的，开启了这个，nano就可以在资源管理器了找到了，我的macbook上是可以访问nano里的内容的，也可以把文件存进去，Windows我没有测试，应该是可以的。需要注意的是，mp3文件存进去nano是不会识别成歌曲的，传歌曲只能用itunes。
8月7日消息，据国外媒体报道，《信息周刊》（InformationWeek）日前获得的消息称，IBM和联想正在积极地讨论一项计划，拟推出一系列运行IBM的“无微软”（Microsoft-free）客户端软件的计算机。IBM今年早些时候在欧洲公布了“无微软”客户端软件计划。IBM本周二将美国市场也纳入了该计划的覆盖范围。
8月8日消息，据国外媒体报道，在周四于美国拉斯维加斯市举行的黑帽(Black Hat)技术大会上，一位IBM高管表示，如果Linux操作系统想要在个人桌面系统领域占据一席之地，就应立即停止模仿微软Windows用户界面的各种行为，而应开发出独具特色的Linux用户界面。
作为一个两年未使用微软应用软件，也不用微软技术进行开发的用户，还是很为IBM这一举措叫好的。我至少有四个理由支持这一计划。
第一，厂商买账。厂商提供的PC，微软的软件是作为成本的，虽然这些成本会转嫁到PC购买者身上，但是这提高了PC的价格。虽然软件对于硬件来说并不是必须的，用户完全可以在购买后自行安装，但是厂商需要考虑用户自己完成这一“高难度动作”的能力，并且，在中国，PC必须预装正版操作系统。而据报道，使用开源操作系统和IBM软件的PC能够降低台式机计算成本50%。加入这一计划，厂商可以提供给用户多一个选择，而这一选择意味着用户不必为自己并不需要的软件掏钱，可以享受更低的价格。
第二，客户买账。IBM此举的客户主要是中小企业。这些客户有一定的特点，一方面是对于Windows上泛滥的娱乐软件或不可信赖的共享软件并没有兴趣，另一方面对IBM Lotus Notes这样的办公软件是有需求的。IBM推出的无微软PC是和这些需求切合的。除了企业客户，还有一些有非微软软件使用经验，并能够自行完成操作系统的选择和安装的用户，他们也应该很欢迎无微软软件PC。另外，还有一些用户可以在别人的帮助下用上盗版的微软操作系统和软件，虽然这样做比较不道德，但这种情况还是相当普遍的。
第三，这不仅仅是软件间的竞争，IBM的无微软软件PC代表的是开源软件。开源软件是面向用户的好软件，但未必是面向客户的好软件。如果说开源软件缺乏什么的话，那么就是缺乏整体的运作。计算机用户并不需要过度自由，面对特定的需求，他们需要仅仅是一个可以依赖的软件和软件使用的支持，而不是让人眼花缭乱的，功能各有千秋的，并且还可以对其进行修改的一堆软件。整套PC方案源于开源的力量，又有合理的集成和运作，是开源软件寻求发展的一个绝好机会。
第四，这不是第一次平台大战，但这次平台之战确实发生在一个特别的时机。从某种意义上讲，现在的PC不仅仅是Personal Computer，而是Peer Computer。随着网络在人们生活中的深化，B/S软件模式的主流化以及“云计算”、“软件即服务”这些概念的流行，用户使用PC的方式也在悄悄的改变。现在非微软操作系统绝对处于一个抬头的时期，面对用户的新的需求和新使用方式，新的平台之战也将打响。
虽然，用户的新需求和新的使用方式是一个契机，但我认为传统软件仍然是非常重要的。据我的使用经验，即使撇去用户锁定、网络效应和微软的一些不兼容问题这些因素，用户不使用Linux也是有原因的。Ubuntu应该是非常不错的Linux桌面版本，但是我使用的体会是：1.易用性还是达不到windows的高度，特别是软件安装。2.字符显示不够细腻。3.软件的选择虽然丰富但是没有统一的规划。4.多媒体功能很不讲究。5.细小功能支持很广泛，但是太折腾人了，安装使用都非常不方便，让用户有极度的挫折感，比如蓝牙功能。
毕竟个人电脑不像商务电脑，用户还是希望能在上面方便的尝试各种东西的，而这些东西更多的是娱乐方面的，并不是仅仅提供了办公，及时通讯等软件就认为是一个完善的操作系统了。这点上苹果是一个好榜样，作为苹果用户，我不得不说，Windows绝对不是世界上最好的操作系统，苹果的操作系统同样是基于Unix，同样嵌入了许多主流的开源软件，比如Apache，但绝对做了非常多的改善用户体验的努力，这使得用户在使用苹果的软件的时候，体会到的不是挫折感，而是惊喜。Linux桌面提供还是有很大的上升空间的。
希望更多的用户用上更好的操作系统。
先解释下，什么是地址栏用中文参数。地址栏用中文参数的更确切的说法应该是，GET请求中参数直接使用中文字符串，而不做任何URLEncode。
举个例子，在www.google.com中搜索“我”，请求是用的GET方式发送的，页面打开后，地址栏（用的Safari，苹果上的网页浏览器）显示的是“http://www.google.com/search?client=safari&rls=zh-cn&q=我&ie=UTF-8&oe=UTF-8”，这就是一个GET请求参数直接用中文字符串的例子。用IE的同志注意了，上面的链接点击后到达的页面是不正常的，显示的不是搜索“我”的页面，把这个链接复制了，然后粘贴到IE的地址栏里，访问到的页面也是不正常的，问题是这次的不正常和刚才的不正常还不一样。这个例子告诉我们，地址栏用中文参数还真的有可能是“不可能的任务”。
我先分析下问题产生的原因，然后再谈一谈解决这个问题的最佳实践。
原因分析：
如果我们的用户都用的是一种浏览器，那么问题要简单的多，只要弄明白这个浏览器到底是怎么表现的，针对这个做一些编码的转换就行了，但是问题就在于，我们的用户用了至少是IE，Firefox和Safari这三种浏览器（注：奥游和腾讯TT本质都是IE），而这三个浏览器的表现很不一样。
1.首先说Firefox，在Firefox的地址栏中用中文参数，它的表现是用UTF-8编码进行URLEncode，并且把encode之后得到的字符串显示在地址栏。
2.然后是Safari，Safari和Firefox基本一致，也是用UTF-8编码进行URLEncode，但是Safari会自作聪明一点，如果参数里有它认识的URLEncode后的字符串，如“%E6%88%91”（注：这段是“我”经过URLEncode得到的），什么是Safari认识的呢，就是可以用UTF-8编码进行URLEncode得到的，它就会恢复原始中文的显示。所以开篇safari中得到的地址栏链接就是含中文的。
3.最后是IE，IE表现的最无语，上面大家都看到了，同样的链接，在页面中打开和在地址栏输入得到的都不一样。这是怎么造成的呢？IE在处理中文参数的时候，对于直接输入在地址栏里的，使用的是系统平台对应的编码，比如我们用的Windows中文版，那就是用的GB18030编码，而对于页面链接里的，使用的是页面的编码，比如这篇文章的页面编码是UTF-8，所以从这个页面打开上面的链接，中文是用UTF-8编码进行URLEncode的，而在地址栏，直接输入，使用的是GB18030的编码。处理的不同也就罢了，但是不能在地址栏里一点区别也看不出来阿，所以IE是表现的最无语的。
那么，如何解决这个问题呢？处理过浏览器兼容问题的同志应该会想到对不同浏览器区别对待，这个想法是可行的，因为用户用的什么浏览器在服务端是可以获得的。但是IE使这个问题复杂了许多，我们并不知道用户是点击的页面中的链接，还是在地址栏里直接输入的，而且我们也未必知道页面的编码和系统的语言环境。
看起来，我们只能根据原始内容“动态识别字符编码”了。其实“动态识别字符编码”对于我们来说并不陌生，我们的浏览器都是支持我们自己指定用什么编码来打开页面的，用的最多的情况是Web邮箱，有的邮件我们可能要换一个编码才能看，否则全是乱码，网页的编码在没有指定的情况下，浏览器会猜一个编码，这就是“动态识别字符编码”。另外，有些文本编辑器也是支持多种文件编码的，打开一个文件时，也会“动态识别字符编码”。
如何实现“动态识别字符编码”呢？cpdetector是一个开源项目，这个项目的主页是http://cpdetector.sourceforge.net/，这个项目提供了“动态识别字符编码”我已经适用，基本是可以识别的。
这里还需要解释一个服务器端用Java相关技术时的问题，Tomcat默认的URIEncodeing用的是ISO-8859-1编码，这造成的是在Firefox或Safari这样的不是很无语的浏览器上，对于中文数据，POST请求和GET请求也表现的不一样，如果页面用UTF-8编码，GET时是乱码的。这事实上是另一个“地址栏用中文参数”的问题，这个问题我们一般搜索到的解决办法是修改tomcat的URIEncodeing参数为UTF-8，或修改useBodyEncodingForURI为true。
当然我们不是一定要做这样一个操作，我们既然知道数据是用ISO-8859-1编码的，我们大可getBytes(”ISO-8859-1″)。但是我这样做，然后配合用cpdetector“动态识别字符编码”的方案，又发现了问题，有时候IE下对一些字符串做了一些编码转换操作之后就出现问题了，我试出来的例子是，在编码是UTF-8的页面上提供了一个包含参数为“我是谁”的链接，点击后，经过了getBytes(”ISO-8859-1″)和cpdetector“动态识别字符编码”，得到了我是口（注：口是个表示不能识别的框框），有些参数直接识别字符编码都失败，比如“你我他”被识别成了“x-EUC-TW”。这些问题基本是不可解决的。我也尝试了修改tomcat的URIEncodeing参数为UTF-8，问题依然，而且cpdetector居然也识别不出来直接输入地址栏时的编码GB18030。这终于是个名符其实的不可能的任务了。
最佳实践：
由于无语的IE，我们放弃了地址栏用中文参数，我们乖乖的使用URLEncode，但是URLEncode就可以了吗？答案是否定的，要知道，自作聪明的Safari会吧URLEncode后的字符串还原称原来的中文，那么Safari的地址栏里常常是有中文的，那么一个Safari用户把这个链接发给一个IE用户，后者不又Shit了吗？所以我们要对中文字符串进行两次URLEncode，由于服务器会自动进行一次URLDecode，所以我们在服务端编程再进行一次URLDecode。这就是最佳实践，放弃了友好的URL，放弃了简洁和清晰，技巧近乎变态，但这是唯一的能够充分避免无效链接的方法。校园网络套餐中课程的文件柜中的中文参数就采取了这种方法。
总结：
本篇基本试验了“地址栏用中文参数”的努力中的各种问题，试验证明“地址栏用中文参数”是不可能的任务，然后以一种极度为用户负责的态度提出了一个有点变态的最佳实践。
最后忍不住说一句：IE给程序开发造成的不便，绝对不仅仅是这个，下次请个做前端开发的同志谈一谈。
日前，CSDN网站对外正式发布中国IT技术指数报告第一期，共包括计算机语言、Web相关技术和基础软件设施等三部分。在计算机语言中，排名前十的语言分别是：Java、C/C++、PHP、JavaScript、SQL、C#、CSS、Visual Basic、UML和Perl。
Java的霸主地位不可撼动，毫无疑问是当今中国最主流的计算机语言，这主要归功与Java在企业应用市场和高校教育的统治地位。但是这并不意味着Java在Web技术中就处于领先地位，Web服务端技术报告中Java based居第三，占有率为28.2%。
该报告让人疑惑的是，PHP作为专门的Web服务端语言，在计算机语言报告中居于C#（排名第6，占有9.1%）和Visual BASIC（排名第8，占有4.0%），却在Web服务端技术报告位居ASP.NET之后，着实费解。难道PHP较.NET在Web服务端之外的场合更有作为？
值得注意的是动态脚本语言的角逐，Perl，Ruby，Python在计算机语言报告中分别排名10，11和13，占有率分别为2.3%，2.2%和1.6%。应该说三门语言都是非常优秀的语言，但在中国还处于非主流。他们在Web服务端技术报告中的表现是Ruby on Rails 3.0%，Python based 0.7%，Perl based 0.6%，居于ASP.NET，PHP，Java based只后，应该说能上Web服务端技术的榜本身就是不错的成绩，说明这些语言的发展是健康和完备的。
API（Application Programming Interface,应用程序编程接口）是由某一程序规定的，其他程序调用本程序的功能或访问本程序的数据的方式。开放API，就是将这种方式公布出来，其他人可以根据API开发新的程序或者调整原有程序，以实现程序间的互通或协作。
有了开放API，所以我们可以使用pidgin这样的集成的即时通讯软件，我们的MSN上可以有使用Yahoo通的好友，我们注册一些社区可以通过输入msn帐号或gmail帐号来找朋友。
互联网经历了两次开放API的浪潮。第一次是即时通讯软件开放通信协议，MSN，Yahoo通，Gtalk，AOL，Skype纷纷开放了通信协议，所以MSN和Yahoo通实现了互通，而Gtalk除了官方的客户端，我用过的可行的客户端就有3个，还有许多网页聊天工具也支持Gtalk。第二次是社区的平台API，Facebook，LinkedIn、Friendster和Bebo均发布了自己的开放平台，校内网也跟进发布了自己的开放平台。这些开放平台在程度上也有所差别，有的是提供了第三方基于站点的数据和方法调用开发小应用程序，校内网的开放平台就是这种形式，有的则更加彻底，将平台架构公布出来，其他社区运营者可以直接采用这些设计，这样使得小应用程序可以很方便的移植到使用同一开放平台的社区上。
然而，马化腾对两次开放API都说了“No”。
腾讯明确反对即时通讯软件之间的互联互通，继续封闭QQ的API和通讯协议，并且通过更改协议来打击第三方的QQ软件，最近提供的mac版和linux版，其简陋只能让人理解成是“保护性版本”，并且起诉为腾讯QQ开发插件的木子工作室。
腾讯坐拥4亿注册用户，已经是不求分享，只求独占了，如同微软对于操作系统的态度一样，为什么要跨平台呢。其他还处于“分享”阶段的众IM们，我也不认为他们处于腾讯的位置还会怀抱什么“互联网理想”。
而对于Facebook掀起的开放平台浪潮，马化腾也表示不看好，他说，他还没有看出这种开放平台能真正带来什么高价值的东西。他坚持认为，好的平台应该由自己来提供应用与服务，至少主导的部分应该由自己开发。“大家可能会不高兴，说开放总是会好一点。其实，如果是好的应用，平台开发商自己自然会做，迟早要替代；如果是它不做的，那肯定就是不好的。”
但愿腾讯这次是真的理解了开放平台的意义，开放平台不仅仅是为小应用程序的开发提供了可能，也为它们的移植提供了可能，而这些小应用程序并不是马华腾眼中的“应用与服务”，如同用户的博文不是媒体站提供的新闻稿一样。小应用程序是一些可以使用的软件或游戏，它们更是一种用户参与社区的方式，是一种文化。腾讯今天的行为就好像面对博客这样的新东西，认为好的内容应该由网站的编辑提供一样可笑。另外，在web 2.0的进程中，我非常不认为腾讯占得了先机，我能够把“用户产生内容”和新浪联系起来，和百度联系起来，和校内网联系起来，而我几乎无法和腾讯联系起来，我唯一能和腾讯联系起来的就是一堆烧钱的功能。
所以，当在SNS领域已占尽先机的Facebook在开放小应用程序接口后，面临Google的OpenSocial的挑战，再度开放平台接口以迎战新一轮的“圈地战”时，腾讯这样的表态并不明智。
据谷歌黑板报报道，谷歌和合作伙伴巨鲸音乐网开始了整合搜索中的音乐功能的尝试。用户在谷歌搜索歌手、专辑或歌曲的时候，会在搜索结果顶部找到歌手照片、专辑封面等音乐信息，可以通过链接到巨鲸音乐网试听或下载高质量的正版音乐，不需要安装任何软件，也不需要在重复的链接中选择或担心垃圾链接的存在。
这是一种新的音乐服务运作模式的实验，用户无需为正版音乐付费。在线音乐广告分成的模式让我们找到了一个提升用户体验、尊重歌手创作、尊重版权之间的平衡。
和百度mp3搜索不同，谷歌的音乐搜索的素材来自特定的内容提供商，所以内容的质量和可靠性都较有保证，正如谷歌声称“不需要在重复的链接中选择或担心垃圾链接的存在”，但这更像是内容站点的另一种提供内容的形式，而不像是一个搜索引擎了，不禁要问，问什么巨鲸不直接提供本站的内容搜索呢？合作这种事就是这样，谁让有的人有内容，有的人有广告渠道呢。
另外，谷歌的音乐搜索一开始就透着”良家“气质，音乐数据可是清清白白的。而百度的音乐数据，就算再声明，再弹出新页面显示，再把原始路径提供出来，仍然面对侵权问题的挑战。
谷歌音乐搜索的链接：www.g.cn/music
BSD开源协议
BSD开源协议是一个给于使用者很大自由的协议。可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。 当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：
1． 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
2． 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
3． 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。
Mozilla Public License
MPL License，允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者。这种授权维护了商业软件的利益，，它要求基于这种软件得修改无偿贡献版权给该软件。这样，围绕该软件得所有代码得版权都集中在发起开发人得手中。但MPL是允许修改，无偿使用得。MPL软件对链接没有要求。
Apache Licence
Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布(作为开源或商业软件)。需要满足的条件：
1． 需要给代码的用户一份Apache Licence
2． 如果你修改了代码，需要再被修改的文件中说明。
3． 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
4． 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。
Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
GPL
GPL许可证是自由软件的应用最广泛的软件许可证，人们可以修改程式的一个或几个副本或程式的任何部分，以此形成基於这些程式的衍生作品。必须在修改过的档案中附有明显的说明：您修改了此一档案及任何修改的日期。 您必须让您发布或出版的作品，包括本程式的全部或一部分，或内含本程式的全部或部分所衍生的作品，允许第三方在此许可证条款下使用，并且不得因为此项授权行为而收费。
Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。
GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用，修改后的代码或者衍生代码)GPL协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。
由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。
LGPL
LGPL许可证是LESSER GENERAL PUBLIC LICENSE的简写，也叫LIBRARY GENERAL PUBLIC LICENSE，中文译为“较宽松公共许可证”或者“函数库公共许可证”。该许可证适用于一些由自由软件基金会与其它决定使用此许可证的软件作者所特殊设计的软件软件包─比如函数库。LGPL 是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通 过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。 但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开 源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。 GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。
Common Public License
CPL是IBM 提出的并通过了OSI(Open Source Initiative)批准的开源协议。主要用于一些IBM或跟IBM相关的开源软件/项目中。如很著名的Java开发环境 Eclipse 、RIA开发平台Open Laszlo等。
CPL也是一项对商业应用友好的协议。它允许 Recipients 对源码进行任意的使用、复制、分发、传播、展示、修改以及改后做闭源的二次商业发布，这点跟 BSD 很类似，也属于自由度比较高的开源协议。但是，需要遵循：
1. 当一个Contributors将源码的整体或部分再次开源发布的时候，必须继续遵循 CPL开源协议来发布，而不能改用其他协议发布。除非你得到了原“源码”Owner 的授权。
2. CPL协议下，你可以将源码不做任何修改来商业发布。但如果你要将修改后的源码其开源，而且当你再发布的是Object Code的时候，你必须声明它的Source Code 是可以获取的，而且要告知获取方法。
3. 当你需要将CPL下的源码作为一部分跟其他私有的源码混和着成为一个 Project 发布的时候，你可以将整个Project/Product 以私人的协议发布，但要声明哪一部分代码是CPL下的，而且声明那部分代码继续遵循CPL。
4. 独立的模块(Separate Module)，不需要开源。
doubanclaim3f38f844908a2127
Eclipse可以说是我近三年几乎每天都用的软件，一直就当个Java IDE用，并没有深入了解。
之前因为要准备一个面试，被告诉说可能和Eclipse插件开发有关，才去仔细了解了下，才知道了JDT，PDE，RCP等概念。
现在彻头彻尾的介绍下Eclipse。
Eclipse是一个非常成熟的，具有良好的设计的集成开发环境。Eclispe是由蓝色巨人IBM开发，花了4千万美金。第一版1.0在2001年11月释出，随后逐渐受到欢迎（我04年开始全面接触Java开发，居然没有直接用Eclipse，而是用的Jbuilder）。单单从开发成本上看，Eclipse也是一个极富价值的软件作品。
Eclipse最大的特点就是他的扩展性，而它的扩展性是因为它良好的设计。Eclipse包括3个部分：Platform，Java Development Toolkit(JDT) ，Plug-in Development Environment(PDE) 。而从实质来说JDT也是一个Plug-in，只是因为Eclipse本身是java开发的，作为IDE，它先天就支持Java开发功能，但是这个开发功能是基于平台提供的一个插件。除了JDT，还有CDT，PDT，有了这这些DT，Eclipse就支持了C语言的开发，Php的开发。
当然插件并不仅仅是用来实现对某种语言的支持，Eclipse的插件是非常丰富的，几乎无所不能，有辅助完成代码，校验代码的，有实现某种工作流的，有支持某些框架或模式的，有管理外部软件的，比如tomcatPlugin，有提供所见即所得的界面设计的，如Designer，有提供某种开发环境的，如flex builder，噢，这个也算是实现对某种语言的支持。
正是Eclipse强大的插件功能，使得Eclipse具有强大的生命力。
Eclipse的另一个巨大贡献是SWT，SWT(Standard Widget Toolkit)是一个图形用户界面方案，在SWT之前，Sun为Java已经提供了AWT和Swing两个方案了。常常我们说，Eclipse是基于SWT写的，然后某种程度上，SWT是因为Eclipse而生的。SWT的优雅不赘述了，很多比较SWT，AWT和Swing的文章，百度百科SWT，界面设计中的LCD问题，都是可以参考的。
像Eclispe这样具有深厚内功的，可以做什么？
第一，它的Classic版（就是什么别的插件也不加，就是用来开发Java的版本）是个好的IDE。界面，功能，体验都是一流的。
第二，它是个能扩展功能的IDE，上面介绍了许多Eclipse的优秀插件，这些插件都已经被丰富的使用，说的大一点，他们都是生产力了，因为许多有价值的开发工作因为他们提高了效率。既然可以扩展，完全可以扩展出和开发无关的功能，甚至你可以通过Eclipse插件开发一个软件，需要用时打开Eclipse，使用你的软件。当然这不是最好的选择，后面会提到更好的方式。
第三，它提供了创造性的工作的平台，设计插件是个十分有意思也十分有意义的工作，Eclipse聚集了这些插件设计者的力量。插件还是一个买卖，Eclipse使用的开放原始码许可书是公共公众许可书（Common Public License），CPL设计上是可以容许商业利益的，可以容许Eclipse和其它开放原始码软件组合时，能够以更严谨的许可书散布软件，以求用于商业途径。许可协议貌似是个很复杂的东西，我不是很清楚，前面一段是抄的。用过的Designer和MyEclipse就是收费的。
第四，作为一个桌面软件的典范，它提供了桌面软件，更精确的说是富客户端软件的框架。并不是所有的具有良好UI，功能和体验设计的桌面软件都能把自己的良好设计外部化到别的软件设计上的。Eclispe做了这一点，RCP（Rich Client Platform）就是和这个有关的方案。在RCP面前，Eclipse成了一个实例了，也就是说Eclipse也是一个RCP。Eclispe的RCP使得我们可以开发出具有Eclipse那样的外观，体验，部件，面板，流程，向导等特性的软件，或者简单的说是Eclipse风格的软件。已经有很多软件都是用RCP实现的，美国国家航空航天管理局（NASA）的火星探测计划项目，就是一个 Eclipse RCP 应用，还有新版的IBM Workplace开发平台，JBuilder，Flash 9，等等。
如果说Eclipse的JDT算是一个普通的插件的话，那么Eclipse本身可不能算是一个普通的RCP。因为我们有理由相信Eclipse生来不是仅仅用来开发Java的，但我们不认为Eclipse在出生时就被认为是个通用的富客户端和开发富客户端的IDE。事实上，是在Eclipse早期，IBM的Lotus开发小组认为可以将Eclipse作为其工作台的富客户端版本。同时，许多Eclipse用户也认为Eclipse本身可以作为一个特殊的富客户端应用，并将这些建议反馈给Eclipse开发小组。Eclipse开发小组认真考虑并吸纳了这些建议，于是在Eclipse 3.0发布时，才正式声明将Eclipse作为通用的富客户端的IDE。
我觉得，设计一种语言，当然是很NB的，设计一个GUI方案，当然也是很NB的，设计一个软件框架，同样是很NB的。Eclipse的RCP就是一个很NB的软件框架。没错，你给我一个语言，我已经可以编写一个软件了，你给我个GUI方案，我可以编写使用的全是你提供的GUI组件的软件了，如果你能给我一个软件框架，我就能编写符合你定义的风格的软件了。
软件框架设计的一个动人之处在于，怎样在便捷和全面之间找一个平衡。比如我基于一个GUI方案编写软件，我可以直接用你提供的组件，那是很便捷，但我只能在你提供的组件中选择，那我一定有些想用的界面形式不能满足，我是否满意这个软件方案在于你提供的方案是否全面。软件框架问题更大，因为如果说GUI在设计方案的时候只是归纳人的视觉隐喻的化，那么软件框架需要归纳人使用软件的方式。僵化的设计会使得很多软件操作无法实现。
而Eclipse自身作为一个具有良好体验，流程顺畅的软件，把这些特性归纳成一个软件框架，应该是不会令人失望的。事实上，上面提到的案例，比如JBuilder，Flash 9，都是很复杂的软件，他们在RCP上实现，让我们对RCP很有信心。当然Eclipse的RCP的强大力量正是因为Eclipse本身就是个复杂的软件（一个用来创造软件的软件能不复杂吗），对许多应用需求都是有充足准备的。
总之，无限赞美Eclipse。之前曾经有文列举了史上最伟大的12款软件，其中包括Unix，DB2，Java，Excel等等，我觉得如果再排的话，应该加上Eclipse。
严格的说，google app和google app engine是不能比较的，因为两个服务的性质完全不同。
google app engine是google推出的web应用部署平台，它不是传统的做主机租赁，托管和运营虚拟主机的IDC，也不是经营自主建站平台的服务商，它的模式是特有的，用google自己的话说：“Run your web applications on Google’s infrastructure.”。是infrastructure，而不是server或platform。用户可以用google提供的IDE，使用google自己定义的数据存取方案，编写基于google提供的框架的web application，然后部署在google app engine提供的平台上。是一个包含平台、方案和开发环境且三者密切联系和配合的综合服务。
http://guobinsapp.appspot.com/是我注册的一个app，是个按照官方帮助写的一个留言板。
google app是google的一个自身服务外部化的方案，即google把自己的gmail、talk等服务提供给其他域名持有者，使得他们能容易的使自己的域名具有邮件、及时通信这些服务，当然使用的是google的程序。理论上，google基本可以把自己的任何服务都外部化，比如google新推出了google site，那么google app立即就集成了site服务。而在google app下也可以注册google app engine，是因为google app engine作为google的一个基础服务，当然可以被外部化。
http://www.google.com/a/guobins.com/就是在我的google app下使用google app engine的入口。
当然，google当然完全可以是出自google app的扩展性的考虑推出了google app engine，但是正如上面说明的，最终的效果是app engine作为google的基础服务被外部化了。
好像很复杂，但确实较合理，管理服务也是个学问。
现在有一个习惯，就是在apache.org浏览项目，看看有什么好东西可以玩下。
今天看到Derby了，他是DB项目的一个子项目，这个是干什么的呢，用apache的话说：“is an open source relational database implemented entirely in Java”。于是想到了早年接触过的一个java嵌入式数据库-HsqlDB，搜索了一下两者比较，又发现了个BerkeleyDB。
三个一起比较一下吧：
性能：
拿图说话
（BerkeleyDB不在图中）
Features（中文该怎么说这个词呢）：
HsqlDB
纯java，sql，关系数据库模型，jdbc，支持内存、嵌入、客户服务模式，支持HSQL, HTTP and HSQL-BER协议
Derby
基本和HsqlDB一样， Java, JDBC, and SQL，嵌入、客户服务模式，模式这些都是一样的，官网列出了JDBC等支持的情况：http://wiki.apache.org/db-derby/JDBCSupport
Berkeley DB Java Edition
这个走了完全不同的路，完全非SQL，API很陌生，用官网的话说“the Oracle Berkeley DB family provides very high performance, reliability, scalability, and availability for application use cases that do not require SQL”。Berkeley DB居然是Oracle的。
使用：
HsqlDB，Derby和都是标准JDBC+SQL，基本没有学习成本，Berkeley DB貌似比较C Style。
其他人说：
http://neoedmnd.bokee.com/5089066.html中做了比较，提到了HsqlDB会丢失数据，这个需要注意。
其他情况可以看官方网站：
http://hsqldb.org/
http://db.apache.org/derby/index.html
http://www.oracle.com/technology/products/berkeley-db/index.html
总结：
如果要使用，估计还是在HsqlDB和Derby中选，主要是考虑实现模式，jdbc，sql，rdbms还是更正统一些。两个中更倾向于HsqlDB，因为貌似它起步比较早，经历了长期的开发和完善的过程，也比较出名，许多java项目的demo都是用它演示的，官网上说OpenOffice.org 2.0就用了它。
最近，其实是三个月前就开始了，在参加一个微软的比赛-“微软HPC学者项目学生及教师研究奖”，大致说来就是微软为推广自己的并行运算服务器WCCS（Windows Computing Cluster Server）举办了一个竞赛，希望能有一些典型案例。
我们参加比赛是把并行运算引用到IT系统管理的领域，在使用海量监控数据分析整理故障规则的计算中，通过平行运算，减少运算时间。
所以最近，在非常久的时间之前的一次C语言速成之后，来了一次实际应用的场合。就使用了C中最基本的数组，指针，字符串，文件读写，字符串数字转换函数这些东西，对很多东西都没有深究，作为入门语言是java的人，最需要克服的是没有Array和Map之类的东西可用。于是在数据结构上很是苦恼了一番，最后以很不直接的方式实现了。
之前研究过一段时间的python，感觉有助于理解C的风格。
上次速成C之后给了个总结：C/C++和java差异的根源在于，C中的”=”任何时候都是值赋值，Java中的”=”在非基本类型时是引用赋值，以此引出了一切的指针，地址的问题。
现在也有个体会，因为C没有方便的高级数据结构可以用，使得人们在克服的同时使用了效率很高的途径，也许丰富的类库未必是好事。
