Team里的少年们用着各式各样的前端IDE, 我却一直“坚贞不渝”的使用adobe家的Dreamweaver作为前端开发的工具。Dreamweaver CS系列本身对Code hints（代码提示）支持就很不错，尤其是在CS5.5上还默认的支持的jQuery，Drupal，Joomla等框架的Code hints。这样在写代码的时候就可以瞧得更流利的。但是webryan 在现实的开发环境中还是会遇到需要自定义代码提示的场景。于是自己动手丰衣足食，搞了一个最适合自己的Code hints。

二、需要自定义Code Hints的原因：

 1.自己或团队自研的JS库，或者组件类

2.JS库里非显示的声明函数。例如

/**
 * @description 通过ajax发出get请求
 */
$.get = $.http.get;

这样的引用式的方式，默认情况下是没办法做到提示的。除非使用自定义。

或者使用函数执行返回的结构体作为提示，也是需要自定义Code hints的。

/**
 * @description 获取样式相关
 */
$.css= function(){
     return {
        getComputedStyle:function(){},
        setStyle:function(){},
        ...
    }
}

3.同时在一些大型前端开发的时候，通常也会存在三种情况：a.JS路径是CDN远程地址，非相对目录。b.JS是动态加载的。 c.JS是需要合并使用的。这个时候默认的包含文件方式的Code hints也是很乏力。

综上，webryan认为自己搞一套自动生成自定义Code hints的东西势在必行。提升工作效率就是珍惜声明啊~

三、创建自定义Code hints for Dreamweaver的原理：

核心原理：Dreamweaver启动时会加载Dreamweaver安装目录下的\configuration\CodeHints\目录下的xml文件，作为Code hints触发依据。所以我们制作一个Dreamweaver提示器可以识别的xml文件放置在\configuration\CodeHints\目录里即可(当然，也可以用扩展插件的方式实现)。

这里我们先看下Dreamweaver识别的xml格式(点击这里可以看到官方的说明)：

这里简单说明下吧，这个 xml的组成：

1.第一层codehints是容器，保持一直即可

2.第二层是menugroup ，只属于codehints标签，有效属性有name, enabled, id，可以包含description，menu,function两种子标签

3.第三层，description是只是描述文档的。menu自身有pattern, doctypes, casesensitive, classpattern, displayrestriction这些属性，可以包含property和method两种子元素。 详情可以见这里。。 function是简单的来描述一个函数，主要可以用在类似php里面向函数的一些提醒。

4.第四层，method是匹配一个函数或方法，自身有pattern, icon, object, source, constructor, static, retType这些属性可以设置。property是匹配一个属性自身有label, value, icon, object, source, static, propType, item这些属性。

5.第五层是等，这里没用到，暂不赘述。想了解的可以参看这里。

哦了，有这些基本的信息，我们就可以开工了。

四、使用jsdoc来创建自定义的code hints XML吧

好吧，又纠结了，知道了xml的结构和code hints的出现方式，总不能都手写吧。 还好，我们有jsdoc这个好东西。先看看jsdoc。

官网地址：http://code.google.com/p/jsdoc-toolkit/ , 在这里你可以获得到jsdoc所有的东西。

引用官方的说法吧，jsdoc是一个可以通过你的js脚本里的注释（注释是需要约定格式的），直接生成帮助手册（jsdoc依赖于java）。例如你的文档这么写：

经过执行一行脚本：

java -jar jsrun.jar app/run.js -a -t=templates/jsdoc simple.js

在out目录里就出现一堆的html文件，点击index.html中的array部分。效果如下：

怎么样，是不是很好用的东西？所以平时写代码的时候注意格式就好。函数开始的时候，指明param return example就可以啦。非常简单。

	/**
	 * @description 判断元素elem是否在数组array中
	 * @param {array} array 数组
	 * @param {object} elem 要判断的元素
	 * @return {number} 元素在数组中对应的位置，若不存在返回-1
	 * @example $.array.indexOf([1,2,3],2);
	 */

好啦，转入正题，我们借助jsdoc的格式化js脚本（最新版本支持return对象里的函数说明，只要你加入了注释），可以生成自己的xml文件。

我们只要改一下index.tmpl文件就好了（既然jsdoc可以生成上面那么牛逼的东西，说明数据已经格式好了，我们只要引用数据，并生成xml结构就可以）。下面webryan给出自己写好的index.tmpl文件：

    
 		
    

						

			
				
				
					

					
				
			
			{! var ownMethods = thisClass.methods.filter(function($){return $.memberOf == thisClass.alias  && !$.isNamespace}).sort(makeSortby("name")); !}
			
					
						
					
			
		

		



 

从上面的结构可以看得出，jsdoc将所有的数据都放到data里，所有的输出都放到output里，用一种自定义的语言进行解析。 这里我们只要迭代data里的class名称就可以，然后二次遍历 class里的ownMethods就可以了。

然后再次执行

java -jar jsrun.jar app/run.js -a -t=templates/webryan simple.js

将out目录下生成的index.html改成.xml复制到D:\Program Files\Adobe\Adobe Dreamweaver CS5.5\configuration\CodeHints（Dreamweaver的安装目录里的）即可。这时候重启Dreamweaver，在任意文档中输入$. 或者$.array.提示代码如下：

大功告成！ 立马将这个xml发给Team里用Dreamweaver的少年们~~ hiahia~~

HTTP Cookie:
Cookie通常也叫做网站cookie,浏览器cookie或者http cookie,是保存在用户浏览器端的，并在发出http请求时会默认携带的一段文本片段。它可以用来做用户认证，服务器校验等通过文本数据可以处理的问题。
Cookie不是软件，所以它不能被携带病毒，不能执行恶意脚本，不能在用户主机上安装恶意软件。但它们可以被间谍软件用来跟踪用户的浏览行为。所以近年来，已经有是欧洲和美国的一些律师以保护用户隐私之名对cookie的种植宣战了。更严重的是，黑客可以通过偷取Cookie获取受害者的帐号控制权。

1.Cookie的历史
a.概念的产生：
Cookie原名是”magic cookie”,是用来描述程序接受并原样发出的一组数据。（这里可以拿生活中的情况举例：比如说当我们在商场试穿衣服的时候，在试衣间门口店员会给你一个号码牌表示你试穿衣服的件数。当你出来的时候，店员会检查下拿着这个牌子和对应的衣服。）这个概念是一直就存在于计算机领域的.直到1994年，网景公司前雇员Lou Moutulli将magic cookie的概念引入到web,赋予了web记忆。

卖个关子。请大家设想一下，没有cookie的互联网将是一副什么的场景。
1.每次访问都像第一次访问一样，无法判断用户是否访问过
2.任何的购买等交互、验证行为都必须在一次访问中完成
3.无任何记忆，均需要用户重新点击或填写

大家说的很好，在1994年6月的某天，24岁的，网景公司第九位工程师，moutulli，坐在键盘前，遇到和大家描述的一模一样的困难，他凭借着他高超的编程技能和思想设计出了一个五页纸的方案来解决这些棘手的问题，这个五页纸后来也就演变成了最初版本的Netscape Cookie规范。五页纸的核心观点就是在用户的电脑上存放一个小的文件来记录用户对网站的访问情况。moutulli将其简称为cookie. 同年10月，Netscape浏览器就率先支持了Cookies，并在netscape官网上做了检查统计用户是否访问过的功能。次年10月，微软的IE2也开始支持Cookie。当然，微软是要交“保护费”了，因为moutulli在1995年申请了专利，并在1998年获得专利授权。整体来说，Cookie的引入对于互联网来说，这是一个划时代的转折点，它将零散的访问，无状态的请求变得有序并富有记忆，给互联网增添了更有趣味性的玩法。

b.隐私风险
1.1995年Q1，当时Cookie没有受到广泛的关注。但cookie不在用户知晓的情况下可以默认种植引来人们的担心。
2.1996年2月，金融时报（ft中文网就是翻译此杂志）发布关于cookie的文章对公众进行了认知的普及，并引起了媒体的广泛关注和讨论，尤其是在潜在的隐私风险上。
3.1996年-1997年，Cookie在美国联邦贸易委员会听证会持续讨论。

c.规范的发展：
1.1994年，Montulli,联合John Giannandrea写了Netscape cookie规范。
2.1995年4月，在www-talk邮件组第一次开始讨论正式统一的Cookie规范，并在IETF(Internet Engineering Task Force，互联网工程任务组，主要目标是协调制定互联网标准，几乎所有重要的网络底层协议都是有IETF制定,EG:TCP,IP,HTTP and so on,可以毫不夸张的说，没有IETF就没有今天的互联网，今年是IETF成立25周年，老外有很多文章专门回顾总结其光辉成就。IETF是由网民自发组织，自我管理的，任何人都和可以参加的，完全民主平等的，无投票机制的，充分体现了自由、开放、合作、共享的精神)里成立了特别工作小组。两种HTTP Cookie的方案被提议。
3.1996年2月，IETF认定第三方Cookie存在重大隐私风险。
4.1997年2月，IETF最终发布了Cookie规范,RFC 2109,其中指出不允许设置第三方cookie或者不能默认支持第三方cookie
5.2000年10月，RFC 2965发布，主要是由于广告在RFC 2109发布时已经广泛使用第三方Cookie,所以关于第三方cookie部分是没有被Netscape和IE所跟随。
6.2011年4月，RFC 6265发布。现实版使用的Cookie规范终于诞生了。

2.Cookie的类别
a.Session Cookie
这个类型的cookie只在会话期间内有效，即当关闭浏览器的时候，它会被浏览器删除。设置session cookie的办法是：在创建cookie不设置Expires即可。
b.Persistent Cookie
持久型cookie顾名思义就是会长期在用户会话中生效。当你设置cookie的属性Max-Age为1个月的话，那么在这个月里每个相关URL的http请求中都会带有这个cookie。所以它可以记录很多用户初始化或自定义化的信息，比如什么时候第一次登录及弱登录态等。
c.Secure cookie
安全cookie是在https访问下的cookie形态，以确保cookie在从客户端传递到Server的过程中始终加密的。这样做大大的降低的cookie内容直接暴露在黑客面前及被盗取的概率。
d.HttpOnly Cookie
目前主流的浏览器已经都支持了httponly cookie。1.IE5+ 2.Firefox 1.0+ 3.Opera 8.0+ 4.Safari/Chrome。在支持httponly的浏览器上，设置成httponly的cookie只能在http(https)请求上传递。也就是说httponly cookie对客户端脚本语言(javascript)无效，从而避免了跨站攻击时JS偷取cookie的情况。当你使用javascript在设置同样名字的cookie时，只有原来的httponly值会传送到服务器。
e.3rd-party cookie
第一方cookie是cookie种植在浏览器地址栏的域名或子域名下的。第三方cookie则是种植在不同于浏览器地址栏的域名下。例如：用户访问a.com时，在ad.google.com设置了个cookie，在访问b.com的时候，也在ad.google.com设置了一个cookie。这种场景经常出现在google adsense，阿里妈妈之类的广告服务商。广告商就可以采集用户的一些习惯和访问历史。
f.Super Cookie
超级cookie是设置公共域名前缀上的cookie。通常a.b.com的cookie可以设置在a.b.com和b.com，而不允许设置在.com上，但是很不幸的是历史上一些老版本的浏览器因为对新增后缀过滤不足导致过超级cookie的产生。

e.Zombie Cookie
僵尸cookie是指那些删不掉的，删掉会自动重建的cookie。僵尸cookie是依赖于其他的本地存储方法，例如flash的share object,html5的local storages等，当用户删除cookie后，自动从其他本地存储里读取出cookie的备份，并重新种植。
3.Cookie用途
a.会话管理
1.记录用户的登录状态是cookie最常用的用途。通常web服务器会在用户登录成功后下发一个签名来标记session的有效性，这样免去了用户多次认证和登录网站。
2.记录用户的访问状态，例如导航啊，用户的注册流程啊。
b.个性化信息
1.Cookie也经常用来记忆用户相关的信息，以方便用户在使用和自己相关的站点服务。例如：ptlogin会记忆上一次登录的用户的QQ号码，这样在下次登录的时候会默认填写好这个QQ号码。
2.Cookie也被用来记忆用户自定义的一些功能。用户在设置自定义特征的时候，仅仅是保存在用户的浏览器中，在下一次访问的时候服务器会根据用户本地的cookie来表现用户的设置。例如google将搜索设置（使用语言、每页的条数，以及打开搜索结果的方式等等）保存在一个COOKIE里。

c.记录用户的行为
最典型的是公司的TCSS系统。它使用Cookie来记录用户的点击流和某个产品或商业行为的操作率和流失率。当然功能可以通过IP或http header中的referrer实现，但是Cookie更精准一些。

4. Cookie的实现
Cookie是web server下发给浏览器的任意的一段文本，在后续的http 请求中，浏览器会将cookie带回给Web Server。同时在浏览器允许脚本执行的情况下，Cookie是可以被JavaScript等脚本设置的。
a. 如何种植Cookie

http方式:以访问http://www.webryan.net/index.php为例
Step1.客户端发起http请求到Server

GET /index.php HTTP/1.1
Host: www.webryan.net
(这里是省去了User-Agent,Accept等字段)

Step2. 服务器返回http response,其中可以包含Cookie设置

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
Set-Cookie: name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT
(content of page)

Step3. 后续访问webryan.net的相关页面

GET /spec.html HTTP/1.1
Host: www.webryan.net
Cookie: name=value; name2=value2
Accept: */*

需要修改cookie的值的话，只需要Set-Cookie: name=newvalue即可，浏览器会用新的值将旧的替换掉。

脚本方式种植 Cookie：
JavaScript或类似的寄宿在浏览器中的脚本语言也可以设置Cookie。在JavaScript里，可以通过document.cookie对象实现。例如：
document.cookie = “key=newvalue”;
b. Cookie属性
除了name=value对以外，我们还可以设置Cookie其他属性以支持更丰富的Cookie需求，这些属性通常是浏览器用来判断如何对待cookie，何时删除、屏蔽或者如何发送name-value对给Server。也就是说无论我们设置了某个cookie的多少属性，这些Cookie属性是不会被浏览器发送回给Server的。
a) Domain and Path
作用：定义Cookie的生效作用域，只有当域名和路径同时满足的时候，浏览器才会将Cookie发送给Server。如果没有设置Domain和Path的话，他们会被默认为当前请求页面对应值。 举例如下：

提问下：第一个和第三个Cookie有啥不一样??
结论：浏览器优先匹配domain,而对于Path字段则是以匹配的方式进行判断。
对于 1.http://docs.foo.com/accounts/index.html
2.http://docs.foo.com/accountstest.html
1.会带上Cookie1,2,3; 2会带上1，2
b) Expires and Max-Age
作用：设置浏览器何时删除Cookie
Expires的规定格式是：“Wdy, DD-Mon-YYYY HH:MM:SS GMT”。
相对于Expires的精准的时间设置，在RFC 2965中规范提供了一个替代方案：Max-Age:seconds,来设置cookie在设置后多长秒后失效。

Set-Cookie: lu=Rg3vHJZnehYLjVg7qi3bZjzg; expires=Tue, 15-Jan-2013 21:47:38 GMT; path=/; domain=.foo.com; httponly
Set-Cookie: made_write_conn=1295214458; path=/; domain=.foo.com
Set-Cookie: reg_fb_gate=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.foo.com; httponly

第一个Cookie: 过期时间是2013年1月15日的精确时间；
第二个：没有设置过期时间，为Session cookie.
第三个：删除Cookie

C) Secure and HttpOnly
作用：设置Cookie的安全属性
特质：Secure和HttpOnly都是没有value字段的。
Secure字段告诉浏览器在https通道时，对Cookie进行安全加密，这样即时有黑客监听也无法获取cookie内容。
HttpOnly字段告诉浏览器，只有在HTTP协议下使用，对浏览器的脚本不可见，所以跨站脚本攻击时也不会被窃取。 从前面例子可以看到Google和Facebook都在使用HttpOnly的Cookie。
5. 浏览器相关
a) Cookie规范规定浏览器最少支持300个cookie，每个cookie 4kb；每个域名最少20个cookie。
b) 浏览器都支持删除和禁用cookie
c) 在浏览器地址栏输入：javascript:alert(document.cookie)可以看到所有cookie
d) 默认情况下，IE浏览器仅支持设置有P3P “CP” (Compact Policy) 标记的第三方Cookie.

测试方法：
javascript:for(var i=0;i<100;i++){document.cookie=’cookiename’+i+’=1aaa;’}document.cookie=’test=asdf;’;alert(document.cookie)
测试结论：ie8:每个域名50个，firefox:每个域名150个；chrome:每个域名170个；ie6、ie7:20个

测试方法：
javascript:var arr=[],i=5112;while(i){i–;arr.push(‘i’)}document.cookie=’test=’+arr.join(”)+’;';alert($.cookie.get(‘test’).length)
测试结论：
ie8:5112+5 = 5117
但最多10个大字段。字段内容多了的话，导致服务器无法响应。

6.Cookie窃取及会话劫持(hijacking)
相对很多Session验证方法的缺点和不足，大多数网站都是把Cookie当作用户的唯一标识。在这种情况下，黑客以可以通过窃取用户的cookie来模拟用户的请求行为，但对于服务器来说是无法辨别到底是来自用户还是黑客的。
下面给出Cookie作为用户标识的风险和安全隐患：
a. 网络监听

在网络上传输的数据都是会被监听获取的，尤其是在公共的、非加密的网络环境（free wifi）。这些数据也包括常规的http（非https加密通道）所有session，当然也就包括了HTTP 会话里的Cookie。当黑客拿到明文的cookie之后就可以模拟用户操作，比如改密码、消费等行为。
解决这个问题的最根本方法是采取https协议，通过SSL通道对内容及cookie进行加密。此外还有一些二次保护的方法可以作为过渡和折中。

b. DNS cache异常及其他
通过DNS cache或者DNS服务商的一些漏洞问题（www.baidu.com），黑客可以通过将www.baidu.com的子域名hack.www.baidu.com指向到黑客自己的IP。这样黑客就可以通过方式http://hack.www.baidu.com/a.png图片到公共环境，从而可以获取到baidu.com下的所有cookie，包括设置了HttpOnly属性的Cookie。
解决办法：1.减少dns无效配置 2.ISP服务商加强自我安全管理。3.通过HTTPS请求对请求进行加密和授权，这样黑客很难从凭证管理中心获得认证，那么用户在操作的时候会收到明显的提示。

c. 跨站脚本XSS—窃取Cookie

由于JavaScript等脚本语言可以读取页面文档内的Cookie值，同时又可以向任意服务器发出任意的请求。综合起来，黑客可以通过脚本将当前文档下的cookie据为己有。如果黑客使用的地址是https://attacker.com/stole.cgi,那么Secure Cookie也将以明文的方式发送个attacker.com.

跨站脚本是web安全永久不变的话题。Web开发者有责任去过滤掉恶意代码。同时，HttpOnly Cookies不可以被客户端脚本读取，这就大大降低了Cookie被盗取的风险。

d. 跨站脚本XSS—hijacking
当黑客可以在www.test.com上插入一段JS脚本的话，那么没有禁用JS的用户很轻易的会收到hijacking攻击。黑客利用用户的浏览器来发出HTTP请求到test.com本身，所以与用户相关的所有cookie都会存在（包括HttpOnly和Secure Cookie）。例如：人人网发生的分享蠕虫。
对于这种攻击，除了避免跨站脚本漏洞以外，可以采取验证码的方式进行一定程度上的规避。

e. 跨站脚本XSS—代理请求
老版本的浏览器允许用户使用XMLHttpRequest发出代理请求，黑客可以通过设置代理将本地的cookie全量的发给代理服务器，再从代理服务器转发给原始服务器。当然这是很快被禁止了。
f. 跨站请求伪造—CSRF
CSRF主要是黑客将伪造的请求URL放到一个图片或者其他静态资源里，这种成本极低，且传播性和形象力非常大。
举例：Qzone的签名的修改地址是：http://qzone.qq.com/cgi-bin/modify?nick=123
那么黑客将其并放到流量很大的论坛或者博客里。那么很多人就在不知情的情况下就执行了某些操作。

7. Cookie的缺点和不足
a) 被讨论最多的就是隐私问题
b) Cookie引入的各种安全问题
c) 与REST软件架构相背离。
d) 状态不一致，后退导致cookie不会重置。
c) 过多使用到是HTTP请求流量浪费

8.Cookie的取代方案
a) window.name
当前所有浏览器都能通过DOM结构中的window.name存储2-32MB的数据。同时window.name是跨域名，但是只能是在当前tab里使用，每个tab初始化后都是有个空的window.name。Window.name是可以传递对象的，所以我们通过将数据保存在json里进行传递和存储。
由于window.name不通过网络传送，所以不会存在被窃取的风险。同时所以从某种角度通过window.name进行用户行为分析更为合理，同时又不会像cookie一样引来http流量消耗
b.)Internet Explorer userData storage (starting IE9, userData is no longer supported)

支持：IE5-IE8
使用：

其他相关
RFC2109:
1.声明新增了Set-Cookie和Cookie两个HTTP头
2.延续使用HTTP/1.1的attribute-value对
3.Server可以在任意HTTP Header中设置cookie
4.Server可以设置多个Set-Cookie头
严格之处:
1.User Agent设置domain必须满足以.开头，且y.x.qq.com不能设置到.qq.com上
2.User Agent给服务器的是完整的Cookie
3.Netscape支持 Expires,协议支持max-age:
域名限制：
1.rfc要求
* at least 300 cookies
* at least 4096 bytes per cookie (as measured by the characters
that comprise the cookie non-terminal in the syntax description
of the Set-Cookie2 header, and as received in the Set-Cookie2
header)
* at least 20 cookies per unique host or domain name

哦了，进入正题。我购买了一个VPS，我在VPS后台(web)安装了centOS.
fdisk -l 查看磁盘情况，发现有20G可用空间，而目前分配了10G。说明这里还有10G未分区的磁盘空间。那么我们现在要对这个磁盘进行分区，格式化和挂载以便后续使用。这里涉及到linux命令有3个。fdisk分区命令，mkfs格式化命令，mount挂载命令。

A、fdisk有几个重要参数需要了解：
Command (m for help):

查看帮助信息：输入m，看到如下信息
d delete a partition 注：删除一个分区；
eg: fdisk /dev/hda1 –>d (删除其中一个分区)–>3（删除编号为三的分区）

l list known partition types 注：l是列出分区类型，以供我们设置相应分区的类型；
eg:fdisk -l, fdisk -l /dev/hda1

m print this menu 注：m 是列出帮助信息；
eg:fdisk /dev/hda1 –>m

n add a new partition 注：添加一个分区；
eg:fdisk /dev/hda –>n(新建分区)–>选择主分区还是逻辑分区–> 选择分区大小

p print the partition table 注：p列出分区表；
q quit without saving changes 注：不保存退出,分错了就退出
t change a partition’s system id 注：t 改变分区类型；
v verify the partition table 注：验证分区
w write table to disk and exit 注：把分区表写入硬盘并退出；

这里我就直接把我用到的写出来：

1.fdisk /dev/hda //对/dev/hda进行分区
2.n  //增加分区
3.p  //输入p类型设置为:主分区
4.3  //输入3分区编号设置为3
5.回车 //起始位置均可以默认
6.回车 //大小设为全部。这里可以自定义比如 +3000M 或+3000K,这里只支持M和K 
7.t //输入t　设置分区类型
8.3 //输入3,对新增3号分区设置格式
9.8e //输入8e 设置为LVM,因为服务器磁盘均为LVM
10.v //输入 v 检查分区表
11.w //输入w 写入分区表 ,分区结束
12.reboot //重启下，分区生效 ：）


2.mkfs格式化，分区好了就该格式化磁盘文件类型了。
这里有几种文件类型可以选ext2,ext3等。这里ext3比ext2新增了异常log处理，所以我们选用ext3.
mkfs.ext3 /dev/hda3 //对/dev/hda3建立ext3文件系统,同理你可以用 mkfs.ext2建立ext2文件系统

3.mount挂载，只有格式化好的分区才能挂载

1.mkdir /www //linux的分区都是挂载在目录下的，所以我们先在根目录下建立www目录
2.mount /dev/hda3 /www //将分区挂载到目录下，ok了。
3.df -hl //查看磁盘剩余空间信息， 就可以看到有/www有10G 可用空间
注意：这次mount操作只是一次有效，重启后需要重新mount,如果以后要开机自动挂载这个分区,您可以修改/etc/fstab 在这个文件最后一行加上 /dev/hda3 /www ext3 defaults 1 1 保存后,重启动就有效了.
4.1. vim /etc/fstab
4.2. GG ->end光标移动到文件结尾,
4.3. i //进入编辑模式
4.4.输入 /dev/hda3 /www ext3 defaults 1 1
4.5. esc//按退出键
4.6 :wq //保存退出，done!下次就会自动挂载了。
.

ok了，分区格式化挂载基本就搞定了，吸口气。继续搞。

Ok,先解释下flash的参数吧。

window：窗口模式,在没有指定wmode的时候，flash默认是以这种方式创建的。在这种模式下，flash拥有自己的窗口句柄，从而相对独立于浏览器的页面表现，独立的进行表现和渲染，所以窗口模式是相对其他模式来说效率最高的一种。同时也是因为它独立于浏览器的HTML渲染表面，所以当html的表现层和flash的表现层重合的时候，flash总是会遮住位置与他重合的所有html层。eg:你要做一个模态的提示框，想让灰色覆盖整个页面，但在有flash的情况，flash会不管你html中z-index的设置而表现在上层。 于是，就引出了第二种模式。

transparent ：透明模式，这种模式类似于把flash放到html层结构里，可以通过z-index来进行层表现的传递和高度。在这种模式下flash会让可以透明的html层都以透明的方式展示在自己之上。这种对动画的性能表现的非常差，而且在9.0.115之前的flash player版本设置wmode=”transparent”会导致全屏模式失效。

Opaque:非透明模式，整个是相对于transparent方式来说的，它使flash隐藏html层上所有位于它后面的所有内容。

那么在我们实际应用中，例如模态提示，例如flash右键属性扩展，我们都需要用到wmode=”transparent”或者“opaque”,为什么这么webryan不建议使用呢？

因为 Flash player 存在一个bug，对使用非默认模式，即wmode不等于”window”的时候，在 Firefox/Chrome浏览器下，不支持非英文的文字输入。

bug单见：http://bugs.adobe.com/jira/browse/FP-501=20，

这个bug影响到flash player 10.1以下的大部分版本。其表现就是：你在flash player 10+firefox上的flash上输入中文的时候，会显示乱码。 这个bug 在10.1版本以后得到了fix，但目前来说还是影响了绝大部分用户，建议采取其他方案进行规避。

同时,wmode=transparent+marquee的场景，会出现鼠标不停的闪动的问题。(这个bug跟了好久。。 郁闷。)

而在了解的过程中惊人的发现阿尔卡特朗讯在这个领域的两个大的举动。
1.2010-06-29, Alcatel-Lucent 闪电收购著名的互联网API（应用程序编程接口）存储库网站ProgrammableWeb.com。
2.2010-09-02, Alcatel-Lucent 收购移动应用程序开发工具厂商OpenPlug.com.

先说下prorammableweb.com吧，它找到了openAPI的运营模式和盈利模式，对于非内容运营商和开发者（尤其是那些已汇聚信息–mash up为主要工作的企业）,可以简易而方便获得信息及与第三方网站进行信息交换。
而openplug.com，最重要的一个产品就是 elips studio. 这个东东目前已经是稳定发布。主要是支持用AS(actionscript)+MXML (flex)的方式,进行移动应用(mobile app)的开发。 而最重要的特点是：只要你用flex开发一次，可以导出原生(natived)的android, ios, windows mobile,塞班等多种平台的app.真正的做到编写一次而在不同平台上运行的期望。 这个对于眼前手机终端迥异，n分天下的场景来说无疑是使得开发更敏捷、更有效率的一种方式。

我对elips studio比较感兴趣，于是在openplug.com注册了帐号并下载了elips studio,elis studio 是以插件的形式附属于elipse或者flash builder. 所以需要先安装elipse 或 flash builder 4. 然而这个有个弊端就是免费版本的,是会自动弹出广告，且不可以移除的。 而其他付费套餐真是贵的要命。这也彻底打消了俺深入研究这个的动力。 不过玩玩到很ok。毕竟actionscript的普及程度比object-c+java要多，也相对容易入手一些。

然而上面两个相对零散的消息合并到一起，再加上阿尔卡特朗讯原本推广的开发平台来说，无异于如虎添翼。 也就是说，在阿尔卡特朗讯的平台，你可以轻易的编写一个app，就像做一个web页面一样。然后轻易的和后台交换数据(api实现)，把自己从繁重的开发和数据的逻辑中解脱出来。所以足以见得阿尔卡特朗讯在新互联网时代已经备足马力准备一场鏖战了。

后面的希望自己能出一个简单的app，用elips studio,然后介绍给大家。因为openplug官方的视频教程在天朝是打不开的，所以webryan也是很烦躁的，最近事情很多，加油。

btw:最近阿尔卡特朗讯在topcoder上开展100 apps in 100 days的活动，http://topcoder.com/home/alcatel/100-apps-in-100-days/ 这个是地址，在此比赛期间，可以申请到elips studio的免费license。所以想玩的同学们，行动吧。需要以下三步。
1.注册topcoder,
2.注册100 apps in 100 days的活动
3.填写google调查表。

一种是用document.cookie.split(“; “)的方式把字符串分割成几个段，然后遍历整个数组。 把每个数组单元等号左边的和name对比是否相等，相等则取等号右边的值。

function getCookie(name){
    var arr = document.cookie.split("; ");
    for(var i=0,len=arr.length;i<len;i++){
        var item = arr[i].split("=");
        if(item[0]==name){
             return item[1];
        }
    }
    return "";
}

第二种就是直接在字符串中搜索关键字。由于分号有空格，加上防止出现搜索cookie name为“str”的value是，有一个test_str的cookie名称。这里我们先进行一次过滤。 然后在找到 ;str的位置，这样就不会出问题。具体情况如下

function getCookie(name){
		var value="";
		var cookie = ";"+document.cookie.replace(/;\s+/g,";")+";"
		var pos = cookie.indexOf(";"+name+"=");
		if(pos>-1){
			var start = cookie.indexOf("=",pos);
			var end = cookie.indexOf(";",start);
			value = unescape(cookie.substring(start+1,end));
		}
		return value;
	}

不同方法在不同时刻有不同的选择。 这个就是晓晓说的选型问题。

现在实际使用的代码是

/**
 * cookie相关
 */
$.cookie = {
	/**
	 * 读取cookie
	 *
	 * @param {String} n=名称
	 * @return {String} cookie值
	 * @example
	 * 		$.cookie.get('id_test');
	 */
	get:function(n){
		var m = document.cookie.match(new RegExp( "(^| )"+n+"=([^;]*)(;|$)"));
		return !m ? "":unescape(m[2]);
	},
	/**
	 * 设置cookie
	 * @param {String} name cookie名称 --必填
	 * @param {String} value cookie值  --必填
	 * @param {String} domain 所在域名
	 * @param {String} path 所在路径
	 * @param {Number} hour 存活时间，单位:小时
	 * @example
	 *  $.cookie.set('value1','cookieval',"id.qq.com","/test",24); //设置cookie
	 */
	set:function(name,value,domain,path,hour){
		var expire = new Date();
		expire.setTime(expire.getTime() + (hour?3600000 * hour:30*24*60*60*1000));

		document.cookie = name + "=" + value + "; " + "expires=" + expire.toGMTString()+"; path="+ (path ? path :"/")+ "; "  + (domain ? ("domain=" + domain + ";") : "");
	},

	/**
	 * 删除指定cookie,复写为过期 !!注意path要严格匹配， /id 不同于/id/
	 *
	 * @param {String} name cookie名称
	 * @param {String} domain 所在域
	 * @param {String} path 所在路径
	 * @example
	 * 		$.cookie.del('id_test'); //删除cookie
	 */
	del : function(name, domain, path) {
		document.cookie = name + "=; expires=Mon, 26 Jul 1997 05:00:00 GMT; path="+ (path ? path :"/")+ "; " + (domain ? ("domain=" + domain + ";") : "");
	},
	/**
	 * 删除所有cookie -- 这里暂时不包括目录下的cookie
	 * @example
	 * 		$.cookie.clear(); //删除所有cookie
	 */

	clear:function(){
		var rs = document.cookie.match(new RegExp("([^ ;][^;]*)(?=(=[^;]*)(;|$))", "gi"));
		// 删除所有cookie
		for (var i in rs){
			document.cookie = rs[i] + "=;expires=Mon, 26 Jul 1997 05:00:00 GMT; path=/; " ;
		}
	},
	/**
	 * uin -- 针对业务,对外开源请删除
	 *
	 * @return {String} uin值
	 * @example
	 * 		$.cookie.uin();
	 */
	uin:function(){
		var u = $.cookie.get("uin");
		return !u?null:parseInt(u.substring(1, u.length),10);
	}
};

但结果是”amabcnc”. （内容本来为html代码，这里webryan给替换成便于理解的字符串）. 对比不难发现$_被解释成了str本身的字符串”abc”（都是美元符号搞得鬼啊）。
查看了下javascript手册，发现还是学艺不精。 解释如下：

24.171.2. Description
replace( ) performs a search-and-replace operation on string. It searches string for one or more substrings that match regexp and replaces them with replacement. If regexp has the global “g” attribute specified, replace( ) replaces all matching substrings. Otherwise, it replaces only the first matching substring.

replacement may be a string or a function. If it is a string, each match is replaced by the string. Note that the $ character has special meaning within the replacement string. As shown in the following table, it indicates that a string derived from the pattern match is used in the replacement.
 Replacement
 
$1, $2, …, $99： The text that matched the 1st through 99th parenthesized subexpression within regexp
 
$&: The substring that matched regexp
 
$’: The text to the left of the matched substring
 
$’: The text to the right of the matched substring
 
$$: A literal dollar sign
 
$_: The whole string //add by webryan

看到上述描述，对于javascript中的replace(exp,replacement)函数的replacement参数，$（美元符号）是有特殊含义的。 那么我们的replacement如果是服务器返回的内容或者是其他不可预知的字符串（可能包含$），最后的替换结果就会出问题。

那么如何规避这个问题呢？  $$: A literal dollar sign –这个一行提示给了我们答案。 就是在replacement中$$是代表$符号的，也就是类似转义符一样。

那么我们程序可以改成如下：


var content="m$_n";
var str = "abc";
var res = str.replace(/b/g,content.replace(/\$/g,"$$$$"));
alert(res); //am$_nc

解释：因为content是”m$_4″,我们要把其中的$-美元符号合法化，就要把content中的$替换成$$。但是在replacement中$$才被当作一个$.所以我们把$替换成”$$$$”就好。
但是$在exp中也有特殊意义,我们需要\$表示，所以替换函数就成了 content.replace(/\$/g,”$$$$”).

Done. bug fix了，以后学习的时候还是要细心和细节和深度呢。。

一、云输入法是什么东西?

依webryan来看, 云输入法是依托于网络词库和ajax通讯方式，在用户不用安装任何软件的情况下，用户在浏览器端可以拥有与传统输入法一致的输入体验。

二、云输入法的特点。

OK,上面的概念相对来说比较抽象。这里简单根据概念来描述下“云输入法”的几个特点。

1.依赖于网络词库，相对节省存储空间和计算机运算。 对于传统的输入法来说，在安装输入法的时候就需要在用户本地安装好某种语言的词库。比如，中文输入法，就要包括中文的所有的词汇。这个总词汇量大约在40G左右。把所有词汇放到用户的计算机上，这显然是一个不现实的问题（用户心理和下载带宽等各个方面）。根据二八原理和cache原理来分析，其实在40G的数据中，有大量的数据很少有人会真正的用到，即使是用到再开销一次下载补救也是完全ok的。所以传统软件的做法是将最常用的词汇汇总压缩，最终可以达到200M左右的常规词库。(当然这200m的常规词库通常也不是跟第一个安装包下载到用户电脑上的，这个常规词库也可以具体的细化分类等等，这个就是产品运营的范畴了：） )。  而云输入法的最初实现则非常简单，你用到什么样的词，云输入法直接向服务器请求相应的词汇，服务器在后台计算好后返回给用户。所以对于用户来说，牺牲一点网络流量实现了存储的节约和cpu的节省。

但是这面临这几个问题：a.是不是每次输入同样的拼音都要去服务器拉去网络词库？ b.是不是每个网站的词库输入都是独立的？ c.如何针对pc or 用户级来说实现全局cache.   这些问题都可以专题去讨论。ryan 这里暂时不详述。

2.跨平台性及免安装性。云计算范畴的东西，玩的就是免安装。云输入法当然也不例外。云输入法的技术核心是javascript在页面里的执行和DOM渲染。所以只要浏览器支持javascript，理论上都支持云输入法，而不需要安装其他东西。 正因为这种基于web化的东西，云输入法理所当然支持跨平台。（没有哪个傻帽系统上开发出的浏览器会断然不支持javascript的吧，除非特殊功用。哈哈）

3.需要保存”云输入法”到书签或收藏夹。每次需使用的云输入法的时候，就从“收藏夹”或“书签”中点击这个输入法的url。当然，它不会像传统的被收藏的网站，会覆盖你当前的页面，而是简单的在当前页面启动云输入法。

4.页面独立性，每个页面要启动云输入法一次，才能使用云输入法。比如：你打开www.webryan.net ,启动了云输入法，然后你有打开了 http://bibubu.com 这个新页面，那么就需要重新启动一次云输入法，才能在bibubu.com这个页面使用。

三、云输入法的技术结构简述。

总体来说，云输入法与web2.0中被炒作已久的ajax技术唯一的区别就是：bookmarklet技术。

什么是bookmarklet呢? 以ryan所认知的就是：我们通常使用收藏夹或者书签保存一个URL, 当打开这个书签的时候，会在当前面打开这个被保存的URL。 而bookmarklet就是用使用收藏夹或者书签保存一段Javascript代码。 在当前页面打开书签则相当于在当前页面执行一段javascript代码。

而云输入法就是用bookmarklet,保存了一段javascript. 如下是搜狗云输入法执行的一段bookmarklet:

javascript:void((function(){var e=document.createElement(‘script’);e.setAttribute(‘src’,'http://web.pinyin.sogou.com/web_ime/init.js’);document.body.appendChild(e);})())

从代码上不难看出：1.先定义了一个匿名函数。 2.匿名函数的功能是先创建一个script标签，然后把它添加到document.body上。3.这个script标签指向’http://web.pinyin.sogou.com/web_ime/init.js’ 这个js文件，也就是js的真实内容的所在。4.执行这个匿名函数。

而在init.js这个文件中就包含了整个云输入法的web前端的所有逻辑。通过监听用户输入，ajax方式请求数据，创建DOM等等。

四、云输入法所面临的具体问题和实现。

1.如何防止DOM污染和JS污染，这个污染是双向的。先要防止云输入法对页面正常的功能的污染，不能让页面出现页面扭曲错位，js功能失效出现脚本错误等问题。 其次是防止页面的js对云输入法的js的破坏。 这个是一个相对来说比较简单的议题，js就用匿名函数+特殊标记的命名方式即可，dom的话，使用页面里用不到的标签即可。

2.页面dom树变化的监控和处理。对于web2.0以上的网站来说，ajax异步加载更新页面是常有的事儿，如果动态加载出来一个input框，而你的输入法又不能支持这个输入框的输入，岂不是掉了大。所以同步监控dom树的变化成为一个成熟云输入法必备的特性。这个不同浏览器的处理方式不一致。ie非ie9啊，ie8新版本啊，用{behavior:expression(window.namespace.func(this))}就可以了。其他不同浏览器得各自找办法。

3.事件监听以及按键兼容处理。 这个方面主要就是为了实现输入的功能实现。不同的按键对输入法来说可能有不同的含义和功能。事件的监听和按键都有浏览器兼容性的问题。 这里就不赘述。

总体来看，搜狗的云输入法和后续的QQ云输入法都是在云的应用中拓展了，收藏夹和书签的功用，加以利用，虽然不是bookmarklet的创始，确实应用的很好的创新。 希望国内各个it公司的实验室能推出更多这样的产品。

已经不记得自己多久没有一点点时间、一点点情绪、一点点意愿去记录些什么了。

或许这是很多脱离校园气质后的孩子们，都无法逾越的一道坎。于是，很佩服小猪同学，可以马不停蹄的个自己的博客、空间灌输新的养料。 而自己却一再的沉沦和落寞着。

老徐终究要走了，从他做决定的那天开始，就始终有一股强烈的东西撞击着我心理那最后的顽固防线。在每个让我感觉无奈和无味的日子里，那种强烈而明亮的意念，无时不割痛着那个叫做理想的杂碎。

二、

真的太久没有写东西了，以至于一打开回忆的匣子，太多太多值得记录的东西，片片的浮现在眼前，拼凑，拼凑成不太完整的皱巴巴的笔记。

三、

我和帅小姐已经2年多了, 纪念日那天晚上9点多和小J坐在电脑面前改bug.. 一边改一边脸色苍白的憋着一边跟小J说，我今天得早点走，我今天得早点走。。。  后来才晓得，那天也是小J和他老公的周年纪念日。

想那年 和帅小姐在那样尴尬的状况下了见面，走在那样熟悉的广八路，喝着那样未曾遗忘的原味奶茶，在吉祥小饭馆里那样简单的对白。 “你第一次见面就色诱我了的”， “哪有”，“有～ 大白腿”，在后来熟知的日子里我常常这样放纵得“取笑”她当年的模样， 黑色的短裤，比现在苗条很多的身材，在厚厚的镜片下藏着的一双迷人的大眼睛。 “我要减肥的”，“啊，你还减肥啊。这么瘦了已经”，“其实我很胖的。。”，“没有挖，真的都ok啦”，她小声的说，“我胖在看不到的地方”，我转身看了看她的眼睛，然后在3秒钟之后慢慢下移。。

似乎时间就是在昨天刚刚离去，我依然记得那个在雨中搭讪借伞的老头，记得桂园楼下的花花树树，还有那些拒搬有理的字条。现在就希望时间快一点，她离我近一点，我们过得快乐一点。谢谢Seven.

四、

工作的开心或不开心，似乎连自己都没有评说的权利。自己努力了，却发现还是不够努力。自己付出了，却发现始终弄不清楚什么才不是徒劳。快一年了，是更清楚了，还是更迷茫了?   醒醒吧，孩子。 真的该醒醒了。 最近帮忙一起招人，看了很多人的简历或者经历，有的人说自己已经工作了3年或者5年抑或更多，然而他们带给我的除了震撼就是反思。 什么样的情形可以让一个人工作了那么多年连基本的原理都搞不清楚，弄不明白。 我们真的是富士康一线的按螺丝的工人么？ 当我们年华逝去的时候，我们是否要有同样的底气和实力说，你们需要我。 

五、

新的开始了吧，当一些事情已经结束。

我们一起走新的路吧。  Fighting 花&盆儿。

由于各种原因webryan.cn现正式更名为webryan.net. 在一个月缓冲期内，webryan.cn的所有访问将直接重定向到webryan.net上，之后webryan.cn域名将停止服务。

这里将不影响webryan.cn的订阅用户。请feed订阅的同学不用关注。

下面webryan将描述一下，域名变迁的原因和整个过程。

—————————–俺是分割线——————————————————————————————

我为什么放弃了webryan.cn这个.cn域名。虽然它已经有一些固定的流量和读者。

原因一. 国内域名商随意更变域名价格。

国内的域名商新网某代理商，做法非常的不负责任。之前白菜价的域名注册后，随意将.cn域名价格调整为150元/注册，80元/年的价格。这个价格变更完全没有通知域名的所有者，而且没有做出合理解释。最关键的是，nnd，其他代理商的续费价格在50元左右。 哥就差钱了。跟你这几十块和服务态度差杠上了。

原因二. 国内域名商（新网为代表）不提供url跳转服务。

国内的域名商在信产部等政策的约束下以及自身的保护策略影响下，已经不提供url跳转服务。什么是url跳转服务呢？ 就是你有一个域名webryan.net上面放着你的博客信息，后来你有注册了个webryan.cn这个域名，但是你想把两个域名绑定到一个博客上，而主打webryan.net这个域名。那么通常的做法是，你需要将webryan.cn这个域名重定向到webryan.net即可。这个重定向可以在几个层面上做。 1.也是最好的办法就是在域名管理那边进行direct reforwarding处理，这样的开销最小。2.在服务器或虚拟主机的dns层面上做，这个时候其实域名已经指向到你的服务器，但你的服务器可以将它重定向另一个网址。 3.在应用脚本上处理，这个可以用一个php,jsp等cgi脚本来完成。将index.html or index.php 按照内容转发重定向。4.apache服务器的.htaccess重定向其实也是可以的。这个类似与第二个。

这个功能虽然不大但某些特殊情况下非常重要。

原因三. 国内域名商域名转出手续繁琐。

case: 如果你在域名服务商A（假设新网）注册了一个域名webryan.cn，你现在觉得A(新网)的服务太差，或者域名价格不合理或者其他原因，你想使用B(万网)的服务。那么这个时候你可以申请做域名转出手续。

通常这个手续在国外的域名管理处，点击A申请转出，填写转到的服务商B，以及你的转出码（这个在你的域名管理处可以查询到），并在邮箱和B处做了接受的确认，域名即可转出。

但在国内的话，政策的要求和新网的客服讲解步骤应该是。 你先填写域名转出申请表，然后连同你的身份证复印件一同邮寄到你申请的域名商那里。 域名商根据你的情况来进行审批。  我很奇怪的是，我域名转出审批的不应该是域名商A吧，这个就好像你用移动的号，用不爽了，你需要拿身份证跟移动的人申请说，我要申请使用联通。 这个有点搞笑。

原因四.国内域名管制严格，屏蔽你的时候完全不需要打招呼。

这个以史为鉴，比如说牛博网，饭否这些知名的，当然不知名的死掉的更是成千上万，血流成河。如果有一天你的网站打不开了，也不要感到很奇怪，因为在这里没有什么可以让人奇怪的。屏蔽你不需要理由，不需要通知，不需要公开的审核。

如果某单位看你的网站不爽的话，或者某一东西你没有做到位的话，某些帖子你没删除及时的话。那么你的域名将会在你完全不知情的情况下被屏蔽，无法访问。 这个在一个法治国家里出现如此情形，的确会让人非常的费解。如果被封了的话，上面没人还真不好办。  虽然说webryan不会发什么色情啊反动之类的东东，但对这种行为从心里的反感。

原因五..cn域名不允许个人持有，互联网创业成本提高

这是一场闹剧，前些年信产部为了加速.cn的国人持有率，采取了1元一年的白菜价促销活动。后来渐渐的.cn域名成了垃圾域名的代名词，于是.cn域名的注册和续费成本开始提高，但基本也在30rmb左右，（.com国际域名均价在60rmb左右）。这个不是重点，重点是在09年末，新的政策出炉，个人用户将不允许在拥有.cn域名的注册权。而你想注册个单位去注册域名的话，那你就痴人说梦了。因为互联网创业的成本在09年开始也大大提高，光注册资本这一项的涨幅就不是一个一般创业者可以接受的。

原因六. 国外域名商没有以上的五个问题。并且管理功能强大，更自主化和自由化。

这里推荐一个name.com的2010年2月的优惠码：CRUSHIT

最后告诫各位要注册域名的同志们， 去国外吧。godaddy.com已经支持了支付宝，name.com等其他域名服务商支持信用卡支付。.cn域名将持续不明亮。 公有制的区域，域名是否也会变成共有，你注册的.cn域名是不是你的，以后都不是你说的算啊。