原文转自：C#4.0新特性（1）：Dynamic Lookup 动态查找
C# 4.0的主要主题是动态编程。对象的意义变得越来越“动态”，它们的结构和行为无法通过静态类型来捕获，或者至少编译器在编译程序时无法得知对象的结构和行为。例如——
- a. 来自动态编程语言——如Python或Ruby——的对象
- b. 通过IDispatch访问的COM对象
- c. 通过反射访问的一般.NET类型
- d. 结构发生过变化的对象——如HTML DOM对象
动态查找允许在编写方法、运算符和索引器调用、属性和字段访问甚至对象调用时，绕过C#静态类型检查，而在运行时进行解析。
动态查找允许动态(即在运行时)实现对某个对象的操作与对象类型的绑定，而不管这个对象是来自COM，IronPython，HTML DOM还是CLR的反射。你可以在程序中绕过编译器的类型检查，而把类型的匹配(lookup)丢给运行时去作。如果你需要对这样的对象进行操作，则会用到一个全新的类型：dynamic。
dynamic类型（The dynamic type）C# 4.0引入了一个新的静态类型，称为dynamic。当你拥有了一个dynamic类型的对象后，你“对他做的事情”只会在运行时进行解析——
Linux系统中grep命令是一种强大的文本搜索工具，它能使用正则表达式搜索文本，并把匹 配的行打印出来。grep全称是Global Regular Expression Print，表示全局正则表达式版本，它的使用权限是所有用户。
grep的工作方式是这样的，它在一个或多个文件中搜索字符串模板。如果模板包括空格，则必须被引用，模板后的所有字符串被看作文件名。搜索的结果被送到标准输出，不影响原文件内容。
grep可用于shell脚本，因为grep通过返回一个状态值来说明搜索的状态，如果模板搜索成功，则返回0，如果搜索不成功，则返回1，如果搜索的文件不存在，则返回2。我们利用这些返回值就可进行一些自动化的文本处理工作。
1．命令格式：
grep [option] pattern file
2．命令功能：
用于过滤/搜索的特定字符。可使用正则表达式能多种命令配合使用，使用上十分灵活。
3．命令参数：
-a --text #不要忽略二进制的数据。
-A<显示列数> --after-context=<显示列数> #除了显示符合范本样式的那一列之外，并显示该列之后的内容。
-b --byte-offset #在显示符合样式的那一列之前，标示出该列第一个字符的编号。
-B<显示列数> --before-context=<显示列数> #除了显示符合样式的那一列之外，并显示该列之前的内容。
-c --count #计算符合样式的列数。
-C<显示列数> --context=<显示列数>或-<显示列数> #除了显示符合样式的那一列之外，并显示该列之前后的内容。
-d <动作> --directories=<动作> #当指定要查找的是目录而非文件时，必须使用这项参数，否则grep指令将回报信息并停止动作。
-e<范本样式> --regexp=<范本样式> #指定字符串做为查找文件内容的样式。
-E --extended-regexp #将样式为延伸的普通表示法来使用。
-f<规则文件> --file=<规则文件> #指定规则文件，其内容含有一个或多个规则样式，让grep查找符合规则条件的文件内容，格式为每列一个规则样式。
-F --fixed-regexp #将样式视为固定字符串的列表。
-G --basic-regexp #将样式视为普通的表示法来使用。
-h --no-filename #在显示符合样式的那一列之前，不标示该列所属的文件名称。
-H --with-filename #在显示符合样式的那一列之前，表示该列所属的文件名称。
-i --ignore-case #忽略字符大小写的差别。
-l --file-with-matches #列出文件内容符合指定的样式的文件名称。
-L --files-without-match #列出文件内容不符合指定的样式的文件名称。
-n --line-number #在显示符合样式的那一列之前，标示出该列的列数编号。
-q --quiet或--silent #不显示任何信息。
-r --recursive #此参数的效果和指定“-d recurse”参数相同。
-s --no-messages #不显示错误信息。
-v --revert-match #显示不包含匹配文本的所有行。
-V --version #显示版本信息。
-w --word-regexp #只显示全字符合的列。
-x --line-regexp #只显示全列符合的列。
-y #此参数的效果和指定“-i”参数相同。
4．规则表达式：
grep的规则表达式:
^ #锚定行的开始 如：'^grep'匹配所有以grep开头的行。
$ #锚定行的结束 如：'grep$'匹配所有以grep结尾的行。
. #匹配一个非换行符的字符 如：'gr.p'匹配gr后接一个任意字符，然后是p。
* #匹配零个或多个先前字符 如：'*grep'匹配所有一个或多个空格后紧跟grep的行。
.* #一起用代表任意字符。
[] #匹配一个指定范围内的字符，如'[Gg]rep'匹配Grep和grep。
[^] #匹配一个不在指定范围内的字符，如：'[^A-FH-Z]rep'匹配不包含A-R和T-Z的一个字母开头，紧跟rep的行。
\(..\) #标记匹配字符，如'\(love\)'，love被标记为1。
\< #锚定单词的开始，如:'\<grep'匹配包含以grep开头的单词的行。
\> #锚定单词的结束，如'grep\>'匹配包含以grep结尾的单词的行。
x\{m\} #重复字符x，m次，如：'0\{5\}'匹配包含5个o的行。
x\{m,\} #重复字符x,至少m次，如：'o\{5,\}'匹配至少有5个o的行。
x\{m,n\} #重复字符x，至少m次，不多于n次，如：'o\{5,10\}'匹配5--10个o的行。
\w #匹配文字和数字字符，也就是[A-Za-z0-9]，如：'G\w*p'匹配以G后跟零个或多个文字或数字字符，然后是p。
\W #\w的反置形式，匹配一个或多个非单词字符，如点号句号等。
\b #单词锁定符，如: '\bgrep\b'只匹配grep。
POSIX字符:
为了在不同国家的字符编码中保持一至，POSIX(The Portable Operating System Interface)增加了特殊的字符类，如[:alnum:]是[A-Za-z0-9]的另一个写法。要把它们放到[]号内才能成为正则表达式，如[A- Za-z0-9]或[[:alnum:]]。在linux下的grep除fgrep外，都支持POSIX的字符类。
[:alnum:] #文字数字字符
[:alpha:] #文字字符
[:digit:] #数字字符
[:graph:] &nb
OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。
与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAUTH是安全的(没有涉及到用户密钥)。任何第三方都可以使用OAUTH认证服务，任何服务提供商都可以实现自身的OAUTH认证服务，因而OAUTH是开放的
An open protocol to allow secure API authorization in asimple and standard method from desktop and web applications.
Oauth提供了一种简单的，标准的方式去访问需要用户授权的API服务。
Request Token URL: 获取未授权的Request Token服务地址；
User Authorization URL: 获取用户授权的Request Token服务地址；
Access Token URL: 用授权的Request Token换取Access Token的服务地址；
2) OAUTH相关的参数定义
OAUTH_consumer_key: 使用者的ID，OAUTH服务的直接使用者是开发者开发出来的应用。所以该参数值的获取一般是要去OAUTH服务提供商处注册一个应用，再获取该appkey。
OAUTH_consumer_secret：OAUTH_consumer_key对应的密钥。
OAUTH_token：通过此token可以获取appkey权限下的资源。
OAUTH_token_secret：OAUTH_token对应的私钥
OAUTH_signature_method: 请求串的签名方法，应用每次向OAUTH三个服务地址发送请求时，必须对请求进行签名。签名的方法有：HMAC-SHA1、RSA-SHA1与PLAINTEXT等三种。
OAUTH_signature: 用上面的签名方法对请求的签名。
OAUTH_timestamp: 发起请求的时间戳，其值是距1970 00:00:00 GMT的秒数，必须是大于0的整数。本次请求的时间戳必须大于或者等于上次的时间戳。
OAUTH_nonce: 随机生成的字符串，用于防止请求的重复，防止外界的非法攻击。
OAUTH_version: OAUTH的版本号。
3) OAUTH HTTP响应代码：
l HTTP 400 Bad Request 请求错误
Unsupported parameter 参数错误
Unsupported signature method 签名方法错误
Missing required parameter 参数丢失
Duplicated OAUTH Protocol Parameter 参数重复
l HTTP 401 Unauthorized 未授权
Invalid Consumer Key 非法key
Invalid / expired Token 失效或者非法的token
Invalid signature 签名非法
Invalid / used nonce 非法的nonce
三、授权流程三句话可以概括：
1. 获取未授权的Request Token
2. 获取用户授权的Request Token
3. 用授权的Request Token换取AccessToken
当应用拿到AccessToken后，就可以有权访问用户授权的资源了。上面的三个步骤中，每个步骤分别请求一个URL，并且收到相关信息，并且拿到上步的相关信息去请求接下来的URL直到拿到Access Token。具体的步骤如下图所示：
具体每步执行信息如下：
用户指的是新浪微博用户，Consumer指的是CSDN网站，Service Provider代表新浪微博
前提：CSND网站在新浪微博注册应用，并发给它一个OAUTH_consumer_key和OAUTH_consumer_secret。
First: 用户登录CSDN网站，用户点击“使用新浪微博帐号登录”。
A. CSDN网站向新浪微博的Request TokenURL发起请求，请求未经用户授权的Request_Token和 Request_Token_Secret。
B. 新浪微博同意CSDN网站的请求，并向其颁发未经用户授权的oauth_token与对应的oauth_token_secret，并返回给CSDN网站，即Request_Token和 Request_Token_Secret。
C. CSDN网站向新浪微博的UserAuthorization URL发起请求，请求用户授权的Request Token。请求带上上步拿到的Request_Token和 Request_Token_Secret。
D. 新浪微博将引导用户授权，该过程可能会提示用户，你想将哪些受保护的资源授权给该应用，用户在微薄网页上输入用户名和密码，同意授权。此步可能会返回授权的Request Token也可能不返回。如Yahoo OAUTH就不会返回任何信息给CSDN网站。授权成功后，新浪微博引导用户回到CSDN网站页面。
E. Request Token 授权后，CSDN网站将向新浪微博的AccessToken URL发起请求，将上步授权的Request Token换取成Access Token。这个比第一步A多了一个参数就是用户授权的Request Token。
F. 新浪微博同意使用者的请求，并向其颁发Access_Token和Access_Token_Secret，并返回给CSDN网站。
G. CSDN网站以后就可以使用上步返回的AccessToken访问用户授权的资源。
四、通俗的说
OAuth协议中包含了三个角色：
Service Provdier，即服务提供者，如新浪微博；
User，即普通用户，如新浪微博用户；
Consumer，即第三方应用，如本人开发的应用。
现有如下场景：User想利用Consumer来更新自己在Service Provider中的状态，但此时Service Provider并不信任Consumer，且User也不想把帐号和密码告诉Consumer，于是三者之间需要建立起信任关系。
Consumer首先要向Service Provider申请一对Consumer_Key和Consumer_Secret，以此取得Service Provider的信任。因为User是信任Service Provider的，所以User与Consumer间的信任关系需要借助Service Provider来建立。
Consumer用自己的Consumer_Key和Consumer_Secret向Service Provider请求到一对Request_Token和Request_Token_Secret，而后Consumer拿上这对RequestToken，领着User去见Service Provider。Service Provider见到自己发的RequestToken，便确认Consumer是值得信任的，于是把头转向User。如果Service Provider不记得User了，只要User向Service Provider提供用户名和密码，就能建立起信任关系。然后Service
Provider对User说：“我很信任这个Consumer，你是不是也要信任他？”，若User确认，则Service Provider允许Consumer把User带回去，并发给Consumer一个Verifier.
回来以后，Consumer拿着RequestToken和Verifier又单独去找Service Provider，取回来一对Access_Token和Access_Token_Secret，并长期保存。
至此，三方信任关系就建立起来了，Consumer每次在Service Provider中更新User的状态时，只需要提供这对AccessToken，Service Provider便能确定此Consumer能代替User进行相应的操作。
在使用相关OAuth库进行开发时，所需要的关键字在以上场景中都有体现，包括：
Consumer_Key, Consumer_Secret, Request_Token, Request_Token_Secret, Verifier, Access_Token, Access_Token_Secret
五、参考
http://oauth.net/documentation/getting-started/
http://en.wikipedia.org/wiki/OAuth
http://zh.wikipedia.org/wiki/OAuth
http://blog.csdn.net/hereweare2009/article/details/4002537
http://oauth.net/core/1.0a/