C#中的is和as

is和as都是用作类型转换的,类型转换包括显示转换和隐式转换,在.NET中类型转换的基本规则如下: 基本规则 任何类型都可以安全的转换为其基类类型,可以由隐式转换来完成; 任何类型转换为其派生类型时,必须进行显示转换,转换的规则是:(类型名)对象名; 使用GetType可以取得任何对象的精确类型; 基本类型可以使用Covert类实现类型转换; 除了string以外的其他类型都有Parse方法,用于将字符串类型转换为对应的基本类型; 值类型和引用类型的转换机制称为装箱(boxing)和拆箱(unboxing)。 is和as操作符,是C#中用于类型转换的,提供了对类型兼容性的判断,从而使得类型转换控制在安全的范畴,提供了灵活的类型转换控制。 is的模式如下: 检查对象类型的兼容性,并返回结果,true或者false; 不会抛出异常; 如果对象为null,则返回值永远为false。 使用很简单,用于条件判断中. 举例:  as的模式如下: 检查对象类型的兼容性,并返回转换结果,如果不兼容就返回null; 不会抛出异常; 如果结果判断为空,则强制执行类型转换将抛出NullReferenceException异常。 as必须和引用类型一起使用 举例:  参考:http://www.cnblogs.com/anytao/archive/2007/04/07/must_net_01.html

各种内存卡介绍

闪存卡(Flash Card)是利用闪存(Flash Memory)技术达到存储电子信息的存储器,一般应用在数码相机,掌上电脑,MP3等小型数码产品中作为存储介质,所以样子小巧,有如一张卡片,所以称之为闪存卡。 根据不同的生产厂商和不同的应用,闪存卡大概有Compact Flash(CF卡)、MultiMediaCard(MMC卡)、Secure Digital(SD卡)、Memory Stick(记忆棒)等。 SD卡 SD卡全称为Secure Digital卡,SD卡标准的面世相对而言比CF要晚,根据MMC为基础所开发的Secure Digital(SD),其改进主要是在增添了版权保护的功能,提高了传输速度和增加了写保护机制等,其主要引脚的定义与MMC卡并没有太大的区别。SD具有较高的兼容性,较小的体积和不错的数据传输速度,成为了当今的时尚数码相机和部分可拍照手机的标准配置。SD接口是当今世界上被采用得最多的闪存卡接口,市面上主流的PDA,数码相机,MP3的闪存卡,烧录卡接口大多为SD卡,也使SD卡取代了CF卡成为了当今最常见得存储卡。如图: MiniSD MiniSD是SD卡的一大改进,体积只有21.5x20x1.4mm,比普通SD卡足足节省了60%的空间,通过转接卡还能保证MiniSD在正常的SD插槽上的使用。如图: Micro SD(TF卡) TF卡又称T-Flash卡,也叫Micro SD卡,体积只有11×15×1mm,面积为MiniSD的一半 MMC卡 MMC卡全称为Multi Media Card,由SanDisk与Siemens AG/InfineonTechnologies AG所联合开发,且于1997年11月发表,Size:24mm x 32mm x 1.4mm,重量2g。MMC卡的兼容性方面不及SD卡的好,数据传输速度受到硬件的限制,不适合作高速的数据传输。如图: RSMMC RSMMC是Reduced-Size MMC的缩写,小型化的MMC卡,传说专门为智能手机设置。改良后的产品叫做MMCmobile 什么是CF卡? CF格式由来已久,被SanDisk公司在1994年首次制造出来。CF卡的全称是Compact Flash,Compact意指“小型的,轻便的”,CF大小为43mm x 36mm x 3.3mm,50 Pins。如图 MS卡 Memory Stick,索尼推出的存储产品。貌似是独树一帜,不多介绍。 参考: http://www.allmemorycards.com/sd.htm http://baike.baidu.com/view/26952.htm http://nds.cngba.com/nds_bd/2007122122100.shtml

C#中的Class和Struct

 什么是class?  class(类)是面向对象编程的基本概念,是一种自定义数据结构类型,通常包含字段、属性、方法、属性、构造函数、索引器、操作符等。.NET中,所有的类都最终继承自System.Object类,因此是一种引用类型,也就是说,new一个类的实例时,对象保存了该实例实际数据的引用地址,而对象的值保存在托管堆(managed heap)中。 什么是struct?  struct(结构)是一种值类型,用于将一组相关的信息变量组织为一个单一的变量实体 。所有的结构都继承自System.ValueType类,因此是一种值类型,也就是说,struct实例分配在线程的堆栈(stack)上,它本身存储了值,而不包含指向该值的指针。所以在使用struct时,我们可以将其当作int、char这样的基本类型类对待。 比较:  相同点:语法类似。  不同点: class是引用类型,继承自System.Object类;struct是值类型,继承自System.ValueType类,因此不具多态性。但是注意,System.ValueType是个引用类型。 从职能观点来看,class更多表现为行为;而struct常用于存储数据。 class支持继承,可以继承自类和接口;而struct没有继承性,struct不能从class继承,也不能作为class的基类,但struct支持接口继承 class可以声明无参构造函数,可以声明析构函数;而struct只能声明带参数构造函数,且不能声明析构函数。因此,struct没有自定义的默认无参构造函数,默认无参构造器只是简单地把所有值初始化为它们的0等价值 实例化时,class要使用new关键字;而struct可以不使用new关键字,如果不以new来实例化struct,则其所有的字段将处于未分配状态,直到所有字段完成初始化,否则引用未赋值的字段会导致编译错误。 class可以是抽象类(abstract),可以声明抽象函数;而struct不能为抽象,也不能声明抽象函数。 class可以声明protected成员、virtual成员、sealed成员和override成员;而struct不可以,struct可以重载System.Object的3个虚方法,Equals()、ToString()和GetHashTable()。 class的对象复制分为浅拷贝和深拷贝,必须经过特别的方法来完成复制;而struct创建的对象复制简单,可以直接以等号连接即可。 class实例由垃圾回收机制来保证内存的回收处理;而struct变量使用完后立即自动解除内存分配。 作为参数传递时,class变量是以按址方式传递;而struct变量是以按值方式传递的。  我们可以简单的理解,class是一个可以动的机器,有行为,有多态,有继承;而struct就是个零件箱,组合了不同结构的零件。其实,class和struct最本质的区别就在于class是引用类型,内存分配于托管堆;而struct是值类型,内存分配于线程的堆栈上。由此差异,导致了上述所有的不同点,虽然在某些方面struct有性能方面的优势,但是在面向对象编程里,基本是class横行的天下。  那么,既然class几乎可以完全替代struct来实现所有的功能,那么struct还有存在的必要吗?答案是,至少在以下情况下,鉴于性能上的考虑,我们应该考虑使用struct来代替class:  实现一个主要用于存储数据的结构时,可以考虑struct。 struct变量占有堆栈的空间,因此只适用于数据量相对小的场合。 结构数组具有更高的效率。 提供某些和非托管代码通信的兼容性。

C#中的const和readonly

 本文来自《你必须知道的.NET》这本书,是我看书过程中的笔记整理。  不变的量是程序设计中的平衡剂,是系统中恒定不变的量,在.NET中提供哦你了两种方式来实现,const和readonly。其中,const是静态常量,readonly是动态常量。 const,readonly和static readonly定义的常量,一旦初始值指定,(包括在构造函数内指定初始值),将不可更改,可读不可写。 const必须在声明的时候指定初始值,而readonly和static readonly在在声明时可以指定,也可以不指定初始值,同时也可以在构造函数中指定初始值,如果同时在声明时和构造函数中指定了初始值,以构造函数内指定的值为准。 const和static readonly定义的常量是静态的,只能由类型来访问,不能和static同时使用,否则可能出现编译错误,而readonly定义的常量是非静态的,只能由实例对象来访问。可以显式使用static定义静态成员 static readonly常量,如果在构造函数内指定初始值,那么必须是在静态无参构造函数中。不同的构造函数可以为readonly常量实现不同的初始值。 const可以用于定义局部常量和字段常量,而readonly和static readonly不能定义局部变量,只能定义字段常量,实际上,readonly应该被称之为只读字段,因此局限于定义字段,而const才是常量,可以定义字段和局部量。 const常量编译后保存在模块的元数据中,无需在托管堆中分配内存,并且const常量只能是百年机器能够识别的基元类型,比如Int32,string等,而readonly需要分配独立的存储空间,并且可以是任意类型。 const只能应用在值类型和string类型上,其他引用类型常量只能定义为null,否则以new为const引用类型常量赋值,编译器会引发“只能用null对引用类型(字符串除外)的常量进行初始化”错误提示,原因是构造函数初始化是在运行时,而非编译时,readonly只读字段,可以是任意类型,但是对于引用类型字段来说,readonly不能限制对该对象实例成员的访问控制。 总结:尽可能以只读属性来实现对类型读写特性的控制,而不是只读字段,但是在某些情况下,只读字段更简化些。  const是编译时常量,readonly是运行时常量,const较高效,readonly更灵活,在应用上,推荐以static readonly代替const,以平衡const在灵活性上的不足,同时克服编译器优化const性能时,所带来的程序集引用不一致问题。    

对不起,我等不了你了

这不是我写的,这篇文章也不是讲爱情的,来自XuTuo的方式,大学生活。人生理想。不错的文章。收藏分享之。  很多事很多人你觉得对你很重要,会在你的一生中留下不可磨灭的印记,却总在你的渐行渐远中云淡风轻。  大一的时候不写高考,因为年少轻狂中带有那么点不可一世的自尊心。大三的时候写不出高考,因为想再提起时已经变成愈加模糊与苍白,甚至还有点可笑。那时候的你已经开始忙着考研或者找工作,忙着褪去象牙塔里那张不老的脸,忙着一个人或者两个人的未来。  后来觉得有必要在这个稚嫩的末尾画上一个走向成熟的句号,在夏天还没到来的时候。  两年前你迷茫着要走上那条路,两年后你迷茫着这条路会走向哪里。  学生生涯是一个很美好的时刻,当然这种美好往往得等失去了才知道珍惜。就像记忆中的高中班主任总是苦口婆心地告诉我们,拼一拼,过了这一个月,你们就解放了。年幼的人有种向往年长人的生活的冲动,这种原始的冲动就像小时候注册QQ的时候总喜欢把年龄放大到十八岁,好像花季雨季里总会有那么些纯纯的爱恋等着我们。而直到了那个季节才发现原来小说里都是骗人的,这里除了长个不停的青春痘还有做不完的作业与考不完的试,爱情是战乱里的奢侈品,珍贵且易碎。  一群刚考完试的高考生们疯狂地撕掉课本,然后撒向天空大吼说:“我终于解放了!”接下去的几天里他们不停地聚会,不停地唱K,不停地喝酒,不停地网路短信暧昧,然后接下来是高中“革命一辈”的“生离死别”。 说着一生一世的誓言走上两条反方向的路,我喜欢那个时候忽明忽暗的爱恋,喜欢就是喜欢,不喜欢就是不喜欢,表白的那个男生可能以后会考上一所名牌大学,毕业后能当上国家公务员,家里供有着一套以及一套以上的房子让他结婚。但不喜欢就是不喜欢,因为他胖,他油性皮肤,他的校服一个礼拜都没洗,还有,他的字不好看。  接着他们如愿以偿地上了老师口中的“由你玩四年”。这是一个很不负责任的谎言,并且被我们尊重的老师屡用不止,就好像你在吃一根玉米,你啃到第三排的时候已经吃不下了,然后一个人告诉你说越往后越好吃,逼你不得不继续往下吃,然而你却逐渐感到反胃,旁边的人说一开始不习惯,慢慢地就会好了,你相信了,硬着头皮往下吃,直到吃完最后一颗时你才发现这根玉米原来压根就烂了,你吐了三天拉了三天后却忘记了自己当初吃玉米的缘由,只剩下一堆无尽的怨言。  银行卡里的生活费准时的打来,人民币上毛爷爷微笑的脸使你渐渐淡忘了家中父母的样貌,你终于有了支配财富的能力以满足你的愿望,这像是一种迟来的报复般让你有种快感,然而当这种权利到手时你却感到一种迷茫与不真实。小时候的你一直暗下决心说等长大了有钱了就要买一大堆零食,结果现在如愿了,但面对超市柜台前满满的零食,你却如何也抬不起兴趣。  生活像是一场黑色幽默的电影,越往后越是笑得想哭出来。  周围的同学渐渐都恋爱了,有几对是新结连理,有几对则是异地的革命伉俪。你开始也心动了,心猿意马地看着校道上那一双双白花花的大腿,你的下半身逐渐代替了上半身的思考能力,你只是不想一个人过了,这样的生活让你感到孤单,无趣,甚至还有那么一点的自卑。高中时你曾经喜欢过一个女生,每当她走过你们班级的窗前你的心跳都会加速得快要蹦出来,那种奇妙的感觉让你喜欢着又害怕着,她就像你心目中的女神一样。那天晚上你终于下了好大的决心发了条短信给她,“在干吗?”“没啊,你呢?”你们有一搭没一搭地聊到了深夜却都心照不宣地不捅破内心的青春情怀。暧昧总是美好的,你以前老是不懂什么叫“人生若只如初见。”现在你渐渐懂了,以后你会更懂。  大学的爱情却让你逐渐感到些许恶心与廉价,前些天你看上一个不错的女生,找了人打听到了她的电话号码,头一句便问她:“你有男朋友吗?”她说,有。之后你便不再回复了。你开始忙了起来,因为你必须马不停蹄地找到下一个猎物。什么时候你失去了等待和耐心爱一个人的能力,你说不上来,在行色匆匆中搪塞着,晚了就找不到对象了。  大学的第一个新年里几个同学在老师家聚会,大家寒暄着暖场,讲着那个陌生地域的生活,有人说得眉飞色舞,有人说得黯然神伤,但却没有人知道明天会怎样。  父母们不再会催你赶紧读书了,你终于有了足够的时间玩游戏,看电视。无论你做什么他们都会一脸慈爱地看着你,有时甚至你自己都过意不去,你觉得是不是他们还会像以前帮你报个补习班或者训练营,结果没有。他们只是老了,累了,你终于考上了他们曾经仰望着的大学,他们感到很欣慰,惟愿你一切安好。  大学却依然在继续着,高考后的第二个夏天来临时你开始有些许羡慕地看着那群刚刚高考完的准大学生们,你听他们喊着你喊过的口号,过着你过过的生活,经历着你的曾经。你喜欢他们那种充满希望的眼神里闪烁着的光,只是你的眼角边不知什么时候多了条皱纹。  你开始得打算自己要往哪个方向发展了,这一年里你旷了将近四分之一的课,每天睡了有十个小时的觉,你交了两个女友,却还不到三个月的时间,到了大一结束的时候你才勉强能念出自己专业的全名,却仍不知道这个专业到底教的是什么。父母们常在你耳边旁敲侧击地说着一些称之为“现实”事情,比如谁谁家的女儿嫁了个好人家,谁谁家的孩子考上公务员后待遇很好。你烦了,爹妈不高兴了,他们会说你已经二十岁了,你则说你的事自己会处理好,但事实上你却依旧迷茫:未来在哪里?  跨入大二前你曾暗下决心要好好学习,就如打仗前的誓师般悲壮。然而在坚持了两个礼拜后却又开始了之前的生活循环,在新的一年里的慢慢发现了身边的人慢慢变了,有的人依旧每天叫上你一起去喝酒玩乐,有的人则一早上就出去,直到晚上才回来,他抱着书,你抱着酒瓶。你们的生活从这里开始分离开来,多年之后你会后悔,但却忘了当初是谁拿起那把剪子分道扬镳。  大二的那个圣诞节里你度过了大学的第三次失恋,你听了一天的《圣诞结》并骂着甩你的女生现实,势力。然而你的舍友却在同一天表白成功了,他和你一样,没有背景,没有一个可以拼的爹,你们曾经在同一条起跑线上,然后现在却互相看不到彼此的身影。你在网上刷了一天的微博看到了那么一句话:“永远不要低估一个女生和你同甘共苦的决心。”你冷冷一笑,关了电脑,却没看到下本句写的:“一个女生最怕的,是在你身上看不到希望。”  大二上学期的春节来临时父母还为你的回来准备着大鱼大肉,貌似什么都没变,但貌似什么都变了一点,就像你的压岁钱不知怎么就少了,几个小外甥甚至还嚷着:“舅舅,给我红包!”  过了这个年你戏谑着自己走在奔三的路上,在回学校的时候父母到车站送你,你突然发现他们的脚步什么时候变慢了,你已经走了好远他们怎么都跟不上,那一刻你突然感到一种前所未有的孤独,就好像曾经可以依靠的肩膀都不在了。  这个春天你觉得怎么过得那么快,你说你已经不打游戏了,不打牌了,也不常和朋友出去玩了,你说你制定了一个计划,但为什么日子还是过得那么快,白天转眼就是黑夜。  就像又到了一年的高考时。  我等不了你了,少年。

c#温故而知新: 线程篇

上次的C#温故而知新:Stream篇 已经完结了,这次,JimmyZheng 开始更新线程了,转发收藏,持续更新,当然你也可以直接去看JimmyZheng的文章,欢迎学习交流 c#温故而知新: 线程篇(一):Thread c#温故而知新: 线程篇(二):线程池和异步线程

WPF实现不规则窗体

这几天在想C# winform程序界面实在太单一,而我C#实现不规则窗体中也说了,如果用背景这种东西来做的话,效果很差,抗锯齿能力基本为0,所以我当时在博客园提问,然后园友有了很给力的回答,比如WPF来做,或者第三方插件,或者深入底层改写ONPaint函数的,今天没事,恰好看到了一篇文章讲这个的,于是,就做一个简单的Demo出来,华丽的效果有木有,先看效果图 在win 7下使用win+Tab切换效果也很华丽。就不演示了。 做起来还算比较简单,首先使用Microsoft Expression Design 4 设计一个界面,破解版什么的太多了,,软件界面和ps挺像,不过功能弱很多,自己操作操作就好了,我说一个问题,就是我当时想画一个空心的圆,也就是一个圆环,ps里大家都知道,直接选区相减就可以了,但是这个死活没找到,基本上最后这个界面所有的地方被找了一遍,猜了猜,才发现了, 具体操作如下,首先汇出一个圆形,然后在圆里面再绘出一个圆形,这时候选中第二次的这个小圆,点击屏幕右侧的那个箭头会出现高级选项, 然后选择混合模式为橡皮擦,就会擦去这个小圆,于是就只剩下一个圆环了。 画好以后,选择文件->导出,按如下设置,  会得到一个xaml文件,一会用 然后新建wpf项目,然后在解决方案资源管理器视图右键点击项目 导入现有项,把上一步的xaml文件导入 然后需要在app.xaml文件中进行设置,具体在<Application.Resources>标签内添加如下代码,中间那个文件名看情况而定。  然后打开“MainWindow.xaml”文件的设计视图,点击窗体边缘以选中窗体,在属性面板中更改AllowsTransparency及WindowStyle属性。 AllowsTransparency 指示窗体是否支持透明。选中 WindowStyle指示窗体边框样式,设为 None 为无边框。 然后呢在 MainWindow.xaml文件中添加如下代码, 最终代码是: 其中background那个是固定的,而MouseDown是为了给窗体写可以拖动的函数,函数名为Window_MouseDown你也可以自己制定 然后对着那个函数名点右键,如下图 导航到事件处理程序,然后在打开的函数里写上 拖动功能就实现了。 至于添加关闭按钮的,我就不写了,很简单,代码里都有。可以参考源文件。 工程源码下载:WPFDemo 参考: http://www.cnblogs.com/SkyD/archive/2008/07/13/1242044.html http://www.cnblogs.com/yinyao/archive/2011/05/23/2054056.html

U盘或硬盘装满资料后,质量会增加吗?

科普文,以前看到过,今天又想起来了,所以拿来和大家分享,感谢原作者的努力。  U盘或硬盘装满资料后,质量会增加吗?  要回答这个问题,先让我们看看U盘和硬盘的存储原理。  U盘又称为闪存(Flash Memory),其存储介质为flash,简单地说,flash是用浮栅来存储数据的,浮栅就是可以存储电荷的电荷势阱,向flash写入数据的过程就是向这个电荷势阱注入电荷的过程。  至于硬盘,如今使用较多的是固态硬盘,其存储介质多为DRAM,简单来说,DRAM是用电容来存取数据的,电容可以充放电,可以储能,有电荷的时候是"1",无电荷的时候是"0"。  回到开头的问题,通过上面的分析可以发现,U盘或硬盘装满资料前后,改变的是数字讯号记录的内容,也就是说多了许多电子。  电子的质量约为9.10938188E-31 kg,所以说,U盘或硬盘装满资料后,质量是会增加的,只不过增加的量非常的少。  同样,我们可以思考这样的问题,每比特的数据有多重?  众所周知,计算机使用一串串二进制的"1"和"0"表示所有种类的信息———电子邮件、文档、视频、网页,一切的一切。  我们拿普通电脑的存储器来说,其存储机制就是刚刚提到的DRAM,电容充电后代表"1",没充电就代表"0"。比特"0"的数据是没有电子的,也就是没有质量的,而比特"1"的数据是有质量的,虽然轻得微不足道。  具体是多少,需要考虑存储器的电容器,估计的值是每个电容器只需要4万个电子就能充满,4万个电子的质量就是3.6E-26 kg,也就是说,比特"1"的数据质量是3.6E-26 kg。  最后,让我们计算一下全球互联网信息总重量!  要想得出这个结果,我们需要的数据是互联网上流动的信息总量,这可以从克利福德·霍利迪的著作《互联网发展2006》中找到答案:这个总流量就是……大得令人吃惊的40P字节,即4E16字节———4后面跟着16个0。  并不是所有的比特都是"1",要不然网络的内容也太无趣了,平均大约有一半的比特是"1",另一半是"0",也就是有20P的比特"1",套用我们计算的比特"1"数据重量时的公式,于是得到了总数7.2E-9 kg。  在遭罪地写了这么多字之后,我们终于得出了结论:互联网的重量全部加起来大约只有1盎司(1盎司约等于28克)的五百万分之一。  原文:http://www.cnblogs.com/jyaray/archive/2010/12/09/1901610.html

C#WinForm实现不规则窗体

这个纯属娱乐,因为其实用的不是太多,因为非主流,非标准的界面不符合用户的体验,不符合可用性功能的某一条HE规则。 为了完成这个效果,首先需要自己动手画个你需要的界面出来,界面边缘需要是一种可以很好区别的颜色,比如纯蓝色,因为实现不规则窗体是让C#使边缘颜色透明化来实现的,所以需要唯一识别。因为我用的图是一张灰色的图,我然后圈了一个蓝色的边缘。 刚开始的图; 然后新建windows应用程序。创建windows窗体并设置窗体基本属性。 (1)将 FormBorderStyle 属性设置为 None。 (2)将窗体的 BackgroundImage 属性设置为先前创建的位图文件。不必将文件添加到项目系统中;这将在指定该文件作为背景图像时自动完成。 (3)将 TransparencyKey 属性设置为位图文件的背景色,本例中为蓝色。(此属性告诉应用程序窗体中的哪些部分需要设置为透明。 ) 上面两个步骤已经完成了不规则窗体自身显示效果的制作。 有人说在24位色以下的环境中可以显示正常,但在24位色以上时黄色背景不能消失,所以上述不能胜任24位色以上环境。但我看到了一种解决方法,那就是先将背景图片添加到资源文件,然后在窗体构造时为窗体设置背景图片:   实测是可以的。 然后就是为窗体添加移动、关闭、最大最小化的事件。代码直接给出 还有其他一些比如关闭按钮的添加,都很简单,直接添加一个button,事件里写,两个选一个。 我最终的效果是个圆,可以看到,锯齿很明显,我想要效果好的话,那个位图得好好设计。这个只是演示。。所以。。还有一种方法是链接1中提供的,有兴趣的可以试试。 工程源码下载:IrregularForm.7z 参考: http://www.cnblogs.com/KissKnife/archive/2006/10/02/520116.html http://allancandy.cnblogs.com/archive/2005/09/01/227814.html

GET和POST有什么区别?及为什么网上的多数答案都是错的。

今天突然看到很多好的技术文章,转载收藏备用分享。 如果有人问你,GET和POST,有什么区别?你会如何回答? 我的经历 前几天有人问我这个问题。我说GET是用于获取数据的,POST,一般用于将数据发给服务器之用。 这个答案好像并不是他想要的。于是他继续追问有没有别的区别?我说这就是个名字而已,如果服务器支持,他完全可以把GET改个名字叫GET2。他反问道,那就是单纯的名字上的区别喽?我想了想,我觉得如果说再具体的区别,只能去看RFC文档了,还要取决于服务器(指Apache,IIS****)的具体实现。但我不得不承认,我的确没有仔细看过HTTP的RFC文档。于是我说,我对HTTP协议不太熟悉。这个问题也就结束了。 最普遍的答案 回来之后寻思了很久,他到底是想问我什么?我一直就觉得GET和POST没有什么除了语义之外的区别,自打我开始学习Web编程开始就是这么理解的。 可能很多人都已经猜到了,他要的答案是: 1. GET使用URL或Cookie传参。而POST将数据放在BODY中。 2. GET的URL会有长度上的限制,则POST的数据则可以非常大。 3. POST比GET安全,因为数据在地址栏上不可见。 但是很不幸,**这些区别全是错误的,**更不幸的是,这个答案还是Google搜索的头版头条,然而我根本没想着这些是答案,因为在我看来他们都是错的。我来一一解释一下。 GET和POST与数据如何传递没有关系 GET和POST是由HTTP协议定义的。在HTTP协议中,Method和Data(URL, Body, Header)是正交的两个概念,也就是说,使用哪个Method与应用层的数据如何传输是没有相互关系的。 HTTP没有要求,如果Method是POST数据就要放在BODY中。也没有要求,如果Method是GET,数据(参数)就一定要放在URL中而不能放在BODY中。 那么,网上流传甚广的这个说法是从何而来的呢?我在HTML标准中,找到了相似的描述。这和网上流传的说法一致。但是这只是HTML标准对HTTP协议的用法的约定。怎么能当成GET和POST的区别呢? 而且,现代的Web Server都是支持GET中包含BODY这样的请求。虽然这种请求不可能从浏览器发出,但是现在的Web Server又不是只给浏览器用,已经完全地超出了HTML服务器的范畴了。 知道这个有什么用?我不想解释了,有时候就得自己痛一次才记得住。 HTTP协议对GET和POST都没有对长度的限制 HTTP协议明确地指出了,HTTP头和Body都没有长度的要求。而对于URL长度上的限制,有两方面的原因造成: 1. 浏览器。据说早期的浏览器会对URL长度做限制。据说IE对URL长度会限制在2048个字符内(流传很广,而且无数同事都表示认同)。但我自己试了一下,我构造了90K的URL通过IE9访问live.com,是正常的。网上的东西,哪怕是Wikipedia上的,也不能信。 2. 服务器。URL长了,对服务器处理也是一种负担。原本一个会话就没有多少数据,现在如果有人恶意地构造几个几M大小的URL,并不停地访问你的服务器。服务器的最大并发数显然会下降。另一种攻击方式是,把告诉服务器Content-Length是一个很大的数,然后只给服务器发一点儿数据,嘿嘿,服务器你就傻等着去吧。哪怕你有超时设置,这种故意的次次访问超时也能让服务器吃不了兜着走。有鉴于此,多数服务器出于安全啦、稳定啦方面的考虑,会给URL长度加限制。但是这个限制是针对所有HTTP请求的,与GET、POST没有关系。 安全不安全和GET、POST没有关系 我觉得这真是中国特色。我讲个小段子,大家应该可以体会出这个说法多么的可笑。 觉得POST数据比GET数据安全的人会说 _ “防君子不防小人;中国小白多,能防小白用户就行了。”_ _ “哼,”我不以为然,“那你怎么不说,_URL__参数都Encode__过了,或是Base64__一下,小白也看不懂啊。” 那人反驳道,_“_Encode__太简单了,聪明点儿的小白很容易就可以Decode__并修改掉。” 我笑道,_“五十步笑百步耳,再聪明点儿的小白还会截包并重发呢,_Opera__就有这功能。” 那人阴险地祭出神器——最终解释权,说,“这个不算小白。” 我日啊。 最后一点儿感想 我之前一直做Windows桌面应用,对Web开发无甚了解,直到一年多前转做服务器端开发,才开始接触到HTTP。(注意,我说的是HTTP,不是HTML。服务器开放接口是基于REST理念设计的,使用的协议是HTTP,但是传输的内容不是HTML。这不是Web Server,而是一个Web Service) 所以我对于GET和POST的理解,是纯粹地来源于HTTP协议。他们只有一点根本区别,简单点儿说,一个用于获取数据,一个用于修改数据。具体的请参考RFC文档。 如果一个人一开始就做Web开发,很可能把HTML对HTTP协议的使用方式,当成HTTP协议的唯一的合理使用方式。从而犯了以偏概全的错误。 可能有人会觉得我钻牛角尖。我只是不喜欢模棱两可,不喜欢边界不清、概念不明,不喜欢“拿来主义”,也不喜欢被其它喜欢钻牛角尖的人奚落得无地自容。 “知之为知之,不知为不知,是知也。” 原文链接:http://www.cnblogs.com/nankezhishi/archive/2012/06/09/2542968.html