下载地址：http://www.blogjava.net/Files/96sd2/IntelliJ.IDEA.v7.0-Keygen.rar

　　下载地址：http://www.sfz123.com/html/38/n-38.html

　　====软件说明====

　　“真实姓名身份证查询软件”原名为“真实姓名身份证号核查助手”，由于不容易理解核查的概念，所以更名。

　　软件采用国家统计局公布的数据，解读身份证号码中信息的特别含义，包括原始发证地、性别、出生日期等，可以把15位身份证号码升位为18位，还可校验一个身份证号格式是否正确。

　　软件采用“全国公民身份证号码查询服务中心”提供的身份信息核查服务，通过验证姓名和身份证号信息在公安部全国公民人口数据库中是否有效来判别身份证的真实性，如果信息真实，同时可以查看身份证照片。身份信息核查服务由身份网（id5.cn）提供运营，非本软件提供。

　　身份信息核查服务的核查结果为一致、不一致和库中无此号，如果结果为一致，还会返回身份证照片。身份信息核查服务是付费服务，成功核查每次5元，其中库中无此号不收费，所以同时需要用户提供手机号码，通过移动梦网代为收费。身份证解读服务是免费服务。

　　身份信息核查服务适用于雇请保姆或家教、出租房屋或求租房屋、婚介交友、网上购买物品等情况下核实对方身份证信息，预防假证诈骗。

　　==== 2.0版更新内容 ====

　　*在核查完成后自动获取核查结果保存到软件附带的数据库中，如果核查有照片，则把照片同时保存下来；

　　*增加了核查记录管理功能，可以查看历史核查记录，查看照片等，使每次核查都有收获，付出更有所值；

　　*整理了目前国家统计局公开发布的最全的行政区划数据(1999-2007.12.31)用于身份证解读；

　　*软件内嵌了网页浏览器，身份信息核查服务不再通过外部浏览器窗口打开；

　　*简化了软件界面，去掉了同名同姓查询；

　　*软件的支持网站使用身份证知识网(http://www.sfz123.com)；

　　*优化提示：在输入框中输入信息完成后，按回车键即可进入下一步。

　　实现的方法很简单，在窗体添加一个 WebBrowser 组件，然后执行以下代码：

　　但随之而来出现了一个问题：WebBrowser 组件在未载入 HTML 之前是无边框的，当载入 HTML 之后，WebBrowser 四周出现了一个三维边框，和程序本身的风格极不协调，查看了 WebBrowser 的所有属性，没有属性可以改变这一设置。

　　经过测试以后发现，该边框并不是 WebBrowser 产生的，而是 WebBrowser 中载入的 HTML 产生的，如果是这样的话，那问题就好解决了，真接用 CSS 去掉边框：

　　当你高兴地设置以上 CSS 后，却发现 WebBrowser 的边框却依然存在，是 CSS 错了吗？NO，是你的 DOCTYPE 出了问题，以上的 CSS 在 XHTML 下是无效果的，将 DOCTYPE 设为 HTML4 即可：

　　闲话表过，再表闲话。

　　话说Mitch Kapor以数十亿美金高价把一手创建的Lotus公司卖给IBM后，做了一段投资人，又回归技术界，创立一家开源基金会。为了实现心目中“最好的PIM软件（个人信息管理，类似Outlook那样的）”，投入百万美元，聘请了一群最NB的程序员（包括Netscape元老级程序员、Macintosh操作系统核心程序员、微软资深开发工程师……），动手开干。有近乎奢侈的资源（财力、人力、时间），照说项目应该顺利进行吧。其实不然。这个名为Chandler的项目，从2000年开始立项，开发过程中软件功能列表一再缩减，直至今日尚未推出1.0正式版本。测试版本在我的Windows 2003操作系统上，仍然无法运行。

　　看过上面两桩闲话，读者大概知道我想说什么了。雄伟的愿景往往流于空想，做软件难，第一难就在于蓝图太宏大。常有朋友找我帮他们做顾问，看看他们的软件/网站项目。通常的过程会是这样——

 　　（演示、讲解项目目标、功能等等）
　　我：请问，这是你们真正想要的东西吗？
　　对方：是，我们想做最好的xxx。
　　我：请问，你们打算花多长时间来做这个项目呢？
　　对方：三个月。
　　我：坦率地说，你们不可能做得到。我的建议是，把刚才说的功能先砍掉一半，再砍掉三分之二，剩下的部分，大概就是三个月之内你们能完成的部分了。
　　对方：……

 　　产品设计者往往会想得太多，把所有可能路径都设想在内。而开发者则往往会低估项目难度，做出太过乐观的判断。这样的结果就是，以为可以在过短时间内完成过于庞杂的功能。危害有二：其一，项目无限期延误；其二，功能不断缩减。六个月甚至一年之后，大褂没做成，千疮百孔内裤倒是有一条。与其如此，不如一开始就以内裤为目标好了。

　　昨天有人问我，为什么是“先砍一半再砍三分之二”而不是“砍掉六分之五”。我说的“砍”，不是简单按字母顺序嚓嚓嚓，而是一个讨论、思考的过程。第一步去除一半，第二步去除一半的三分之二。起初设想出那么多功能，肯定花了不少心血。现在要砍，每一项都显得那么宝贵而舍不得丢弃。反复斟酌、流泪放弃，最后剩下的，是软件/网站项目最最核心和关键的功能，也是以目前资源所能完成的工作。以后，再视运营情况加以增补。

　　我想，做其它事，或许也可以采用类似的方法吧。大褂还是内裤，这是一个难题。以我之愚鲁，大褂不敢妄想，甚至没准内裤也做不出来，那就踏踏实实、裁剪缝制一个真有用的口罩吧。

　　我想这种场景在我们的项目实施过程中会经常出现，那么接下来该做些什么呢？是技术人员该就此技术方案找出N+1条拒绝的理由还是产品经理继续讲述第N+1遍方案细节呢？当然都不是，腾讯搜索产品中心副总经理邢宏宇认为：讨论一致性的目标才是最应该做的。

　　腾讯搜索产品中心副总经理邢宏宇是一位技术团队“老练的”的领路人。他认为，在项目实施的过程中，技术和需求之间会产生矛盾这是一个普遍的现象。这些矛盾的存在带来的负面影响可谓是大小不一，大到会使整个项目停滞或者流 产，小到员工之间不和睦闹矛盾。当然，我们也看到了很多成功合作的案例，他们是如何解决这些矛盾的呢？

　　在上面的故事中，其实产品经理做了B技术方案是为了实现产品功能A，那么他只需要把他要实现的功能A清楚的描述给技术人员就可以了。最后技术人员用了更好的技术方案C轻松的实现了产品功能A。因此，在现代项目实施过程中，产品经理和技术人员之间需要学会“沟通、信任、支持”。

　　软件产品特别是互联网产品的多样性、多变性的特征使得它的诞生必然要伴随着成千上万次的沟通。 邢宏宇表示，“沟通更深层次的也代表着你主动参与意识的强弱，而不仅仅是被动的去完成一项任务，参与程度越高它所能给你带来的乐趣也越大。”

　　沟通也需要技巧，正如我们之前的故事里所讲，如果产品经理一直和技术人员沟通B技术方案，但技术人员却并不知道是为了实现功能A，这样的沟通只会浪费时间。所以，沟通也要“各司其职”。越线的沟通就会埋下问题的种子，这也是为什么沟通之后需要信任。

　　产品经理擅长的是功能描述、技术人员擅长的是技术方案的制定。邢宏宇说：“我们都要相信对方的专业素质，技术人员要相信产品经理提出的功能一定是经过专业思考的，而产品经理也一定要相信针对这样的功能技术人员肯定能拿出最优的技术解决方案。”只有这样，技术人员才不会说产品的某一个功能是“垃圾”，而产品经理也不会越俎代庖的帮技术人员想好技术方案。团队之间表现在，技术人员帮助产品经理提建议和想办法，思考自己在技术实现的过程中出现的问题，可不可以做技术上的优化；而产品经理在帮助技术人员建议方案同时也要反思一下自己提出的功能是否真的合理。

　　邢宏宇总结说：“任何一个软件产品都是一个高度集中的集体智慧，这其中团队内部、团队之间你来我往的协作过程中，包含了更多的艺术和技巧。”