易栈网-膘叔

有意思的文章，大多数时候，我们都是知道\r,\n,\r\n，但为什么是这样的呢，居然找到了一篇科普贴。
来吧，看看为什么吧。
原文来自：【科普贴】话说回车和换行
看xml的时候发现这样的一段话：

XML 以 LF 存储换行

在 Windows 应用程序中，换行通常以一对字符来存储：回车符 (CR) 和换行符 (LF)。这对字符与打字机设置新行的动作有相似之处。在 Unix 应用程序中，新行以 LF 字符存储。而 Macintosh 应用程序使用 CR 来存储新行。

让我对这三个(win,unix,mac)苦逼的主产生了兴趣，为啥你们不一样呢，难道你们认识“回车”和“换行”的时间有先有后吗？为啥没统一或者说为啥产生了CR和LF这两个玩意？说说历史吧！

为什么会有两个貌似一样功能的东西？

潜台词：很多时候敲击enter就是换行了呀，还回啥个车，回车就是换行吗？

在计算机还没有出现之前，有一种叫做电传打字机（Teletype Model 33）的玩意，每秒钟可以打10个字符。但是它有一个问题，就是打完一行换行的时候，要用去0.2秒，正好可以打两个字符。要是在这0.2秒里面，又有新的字符传过来，那么这个字符将丢失。

于是，研制人员想了个办法解决这个问题，就是在每行后面加两个表示结束的字符。一个叫做"回车"，告诉打字机把打印头定位在左边界；另一个叫做"换行"，告诉打字机把纸向下移一行。

-http://www.ruanyifeng.com/blog/2006/04/post_213.html

为啥windows，unix，mac不统一呢？

可能是基于成本和效率的考虑，我认为都统一成一个“回车”就够了，可是当年正是这种想法导致了现在的问题，至于这三家互不相同，我也不知道，各有各的考虑吧，反正蛋疼的是用户，比起现在浏览器的兼容性问题，这算不上问题。

以下是他们表示“下一行”的方式：

    OS          表示                              C语言表示    16进制表示

    windows  回车+换行（CR/LF）        \r\n             0x0d0a

    UNIX       换行符（LF）                   \n               0x0a

    MAC        回车符（CR）                   \r               0x0d

 

看一下在一份xml文件里的情况吧，我没钱买苹果，所以下面不包括MAC OS，果粉别砍我！

抱怨之余，我们还能干啥呢？

至少你知道这是怎么回事了，至少在不同平台之间传送文件时别傻傻的骂别人没整理文件格式，至少...，这还不够吗？

－－－－－－－－－－－－－
在用PHP写文件的时候，一般我们都是用\n来解决断行。但这时候，如果用windows下的记事本打开这个文件，你会发现一堆黑框，并且处在一行里。
因此，看了上面的文章后，你会知道怎么办了。突然想到以前的str_replace(array("\r\n","\r","\n"),"<br />",$str), 这种烂代码。当然nl2br就解决这样的功能了。然后再转回来？哎。纠结啊。。

在直接引用外部图片的时候，经常会出现，该图片来自于XXX网站，请勿盗链
找了一下资料，发现只有几种方法可以解决
1、JS，HTML里嵌入iframe，然后类似地打开一个网页的形式，使得页面认为已经访问过主体网站，所以可以解决防盗链
2、如果页面中的图片是：/xxljaslkdjf/xxx.jpg，而这个图片事实上来自于：xxx.xxx.com网站，这时候在页面的<base >TAG里设置一下，就不需要全文正则替换图片了。灰常方便。。。
3、设置HTTP_REFERER，这个有点麻烦，不是每个站都支持。。。
4、在页面中放置一iframe，地址就是主体网站。然后等访问完成后302跳转到真正的页面，图片就能正常了
5、用URL转发的形式，如：image.php?url=image.path.jpg，通过这种方式，几乎解决了很多问题（但，不能走CDN了。真可惜啊。怎么办呢？？生成本地图片后，再由CDN转发？不太现实）

基本上就上述的方法了，如果你还有新方法，请告知

Yii for sae终于提交到了google code了。

yii framework for sina sae platform. 初步实现将yii framework 移植到 sina SAE云平台。 assets目录生成到storage中，runtime则是用memcached来实现， 也因此需要激活storage和memcached。 几乎不需要改原来的代码，如果需要设置主从数据库，请另外加一个components节点：sdb，配置信息与db一样，但需增加一个 'isSlave'=>true,即OK。不过在这种情况下，所有的model都请继承SaeActiveRecord?。

配置信息中，在params里增加 'params'=>array(

'sae'=>array(

'storage' => array(

'assets' => 'assets', 'runtime'=>'runtime',

), 'db'=>array(

'slave'=>'sdb', 'master'=>'db',

)

),

);
－－－－
配置起来是不是很简单？
当前目前还是有一点问题的

1. 比如对于文件的LOG暂时无法实现，准备使用memcache存储部分，等到了一定大小后，扔到storage中存储。
2. GII暂时还不能在线上使用，这个有点纠结，因为GII是需要生成文件 ，而sae平台不支持生成文件。如果扔到storage中，效率又不能保存。如果扔到memcache中。include之类的又不知道是否能够完美实现？纠结中。。（生成到storage?然后下载？扔到models目录中？这多没意思，与其这样，还不如本地建好model，然后SVN上传呢）
3. 好象cdbcache是用了sqlite，原本看代码里是能够自动生成的，但在线上，怎么搞呢？存到storage中又没有效率？哎。。。

不过，暂时基本功能都实现了，嗯项目地址是：http://code.google.com/p/yiiforsae/

这两天在实现Yii for SAE，之所以想实现这样的功能，主要还是YII相对比较深入开发人员的人心吧？
这一定是我的个人偏见，因此不要打口水仗。
开发的时候，遇到的问题大多是runtime目录下的存储，以及主从数据库的问题，因此大部分的精力都是在解决这些。
所幸，还是可以利用yii的一些特性来搞定它。
嗯。70％已经完成了。如果差不多了，到时候会扔到google code上，这样想用的人就直接可以使用啦。

目前还在测试中，可以访问 http://ixyz.sinaapp.com进行测试。

因为新浪的Oauth即将变成2.0，所以找找资料
老王更新了，还画了ascii图，说实话我是对他文中的那个画ascii图的视频有兴趣。。。
老王在博客里是这么介绍的：

OAuth2.0

OAuth1.0虽然在安全性上经过修补已经没有问题了，但还存在其它的缺点，其中最主要的莫过于以下两点：其一，签名逻辑过于复杂，对开发者不够友好；其二，授权流程太过单一，除了Web应用以外，对桌面、移动应用来说不够友好。

为了弥补这些短板，OAuth2.0做了以下改变：

首先，去掉签名，改用SSL（HTTPS）确保安全性，所有的token不再有对应的secret存在，这也直接导致OAuth2.0不兼容老版本。

其次，针对不同的情况使用不同的授权流程，和老版本只有一种授权流程相比，新版本提供了四种授权流程，可依据客观情况选择。

在详细说明授权流程之前，我们需要先了解一下OAuth2.0中的角色：

OAuth1.0定义了三种角色：User、Service Provider、Consumer。而OAuth2.0则定义了四种角色：Resource Owner、Resource Server、Client、Authorization Server：

• Resource Owner：User
• Resource Server：Service Provider
• Client：Consumer
• Authorization Server：Service Provider

也就是说，OAuth2.0把原本OAuth1.0里的Service Provider角色分拆成Resource Server和Authorization Server两个角色，在授权时交互的是Authorization Server，在请求资源时交互的是Resource Server，当然，有时候他们是合二为一的。

－－－－－－－
当然，我这里CP的不全，更详细的请看：http://huoding.com/2011/11/08/126
如果不把ascii图CP过来，老王是不是很伤心？

这是第二次CP的。希望成功
+----------+  
| resource |  
|   owner  |  
|          |  
+----------+  
     ^  
     |  
    (B)  
+----|-----+          Client Identifier      +---------------+  
|         -+----(A)-- & Redirection URI ---->|               |  
|  User-   |                                 | Authorization |  
|  Agent  -+----(B)-- User authenticates --->|     Server    |  
|          |                                 |               |  
|         -+----(C)-- Authorization Code ---<|               |  
+-|----|---+                                 +---------------+  
  |    |                                         ^      v  
 (A)  (C)                                        |      |  
  |    |                                         |      |  
  ^    v                                         |      |  
+---------+                                      |      |  
|         |>---(D)-- Authorization Code ---------'      |  
|  Client |          & Redirection URI                  |  
|         |                                             |  
|         |<---(E)----- Access Token -------------------'  
+---------+       (w/ Optional Refresh Token)  
哈哈，好象失败了。。。
OK，还有一篇介绍 ：http://hueniverse.com/2010/05/introducing-oauth-2-0/

6 New Flows

• User-Agent Flow – for clients running inside a user-agent (typically a web browser).
• Web Server Flow – for clients that are part of a web server application, accessible via HTTP requests. This is a simpler version of the flow provided by OAuth 1.0.
• Device Flow – suitable for clients executing on limited devices, but where the end-user has separate access to a browser on another computer or device.
• Username and Password Flow – used in cases where the user trusts the client to handle its credentials but it is still undesirable for the client to store the user’s username and password.  This flow is only suitable when there is a high degree of trust between the user and the client.
• Client Credentials Flow – the client uses its credentials to obtain an access token. This flow supports what is known as the 2-legged scenario.
• Assertion Flow – the client presents an assertion such as a SAML assertion to the authorization server in exchange for an access token.

Native application support (applications running on a desktop or mobile device) can be implemented using many of the flows above.

－－－－其实看起来就很纠结，反正先了解一下，refresh_token还得向新浪申请。真纠结