from: http://witmax.cn/cache-writing-policies.htmlCache写机制参考[http://en.wikipedia.org/wiki/Cache#Writing_Policies](http://en.wikipedia.org/wiki/Cache#Writing_Policies)上的说明，Cache写机制分为write through和write back两种。Write-through- Write is done synchronously both to the cache and to the backing store.Write-back (or Write-behind) – Writing is done only to the cache. A modified cache block is written back to the store, just before it is replaced.Write-through（直写模式）在数据更新时，同时写入缓存Cache和后端存储。此模式的优点是操作简单；缺点是因为数据修改需要同时写入存储，数据写入速度较慢。 Write-back（回写模式）在数据更新时只写入缓存Cache。只在数据被替换出缓存时，被修改的缓存数据才会被写到后端存储。此模式的优点是数据写入速度快，因为不需要写存储；缺点是一旦更新后的数据未被写入存储时出现系统掉电的情况，数据将无法找回。Write-misses写缺失的处理方式对于写操作，存在写入缓存缺失数据的情况，这时有两种处理方式：Write allocate (aka Fetch on write) – Datum at the missed-write location is loaded to cache, followed by a write-hit operation. In this approach, write misses are similar to read-misses.No-write allocate (aka Write-no-allocate, Write around) – Datum at the missed-write location is not loaded to cache, and is written directly to the backing store. In this approach, actually only system reads are being cached.Write allocate方式将写入位置读入缓存，然后采用write-hit（缓存命中写入）操作。写缺失操作与读缺失操作类似。No-write allocate方式并不将写入位置读入缓存，而是直接将数据写入存储。这种方式下，只有读操作会被缓存。无论是Write-through还是Write-back都可以使用写缺失的两种方式之一。只是通常Write-back采用Write allocate方式，而Write-through采用No-write allocate方式；因为多次写入同一缓存时，Write allocate配合Write-back可以提升性能；而对于Write-through则没有帮助。处理流程图Write-through模式处理流程： [](http://upload.wikimedia.org/wikipedia/commons/thumb/c/c5/Write_through_with_no-write_allocation.png/445px-Write_through_with_no-write_allocation.png "A Write-Through cache with No-Write Allocation")A Write-Through cache with No-Write AllocationWrite-back模式处理流程： [](http://upload.wikimedia.org/wikipedia/commons/thumb/a/ad/Write_back_with_write_allocation.png/468px-Write_back_with_write_allocation.png "A Write-Back cache with Write Allocation")A Write-Back cache with Write Allocation
from: http://www.plhwin.com/2014/06/13/web-security-sql/Web安全简史在Web1.0时代，人们更多是关注服务器端动态脚本语言的安全问题，比如将一个可执行脚本（俗称Webshell）通过脚本语言的漏洞上传到服务器上，从而获得服务器权限。在Web发展初期，随着动态脚本语言的发展和普及，以及早期工程师对安全问题认知不足导致很多”安全血案”的发生，至今仍然遗留下许多历史问题，比如PHP语言至今仍然无法从语言本身杜绝「文件包含漏洞」（参见这里），只能依靠工程师良好的代码规范和安全意识。伴随着Web2.0、社交网络、微博等一系列新型互联网产品的兴起，基于Web环境的互联网应用越来越广泛，Web攻击的手段也越来越多样，Web安全史上的一个重要里程碑是大约1999年发现的SQL注入攻击，之后的XSS，CSRF等攻击手段愈发强大，Web攻击的思路也从服务端转向了客户端，转向了浏览器和用户。在安全领域，一般用帽子的颜色来比喻黑客的善与恶，白帽子是指那些工作在反黑客领域的技术专家，这个群体是”善”的的象征；而黑帽子则是指那些利用黑客技术造成破坏甚至谋取私利造成犯罪的群体，他们是”恶”的代表。“白帽子”和”黑帽子”是两个完全对立的群体。对于黑帽子而言，他们只要找到系统的一个切入点就可以达到入侵破坏的目的，而白帽子必须将自己系统所有可能被突破的地方都设防，以保证系统的安全运行。这看起来好像是不公平的，但是安全世界里的规则就是这样，可能我们的网站1000处都布防的很好，考虑的很周到，但是只要有一个地方疏忽了，攻击者就会利用这个点进行突破，让我们另外的1000处努力白费。常见攻击方式一般说来，在Web安全领域，常见的攻击方式大概有以下几种：1、SQL注入攻击2、跨站脚本攻击 - XSS3、跨站伪造请求攻击 - CSRF4、文件上传漏洞攻击5、分布式拒绝服务攻击 - DDOS说个题外话，本来这篇文章一开始的标题叫做 「Web安全之常见攻击方法与防范」，我原本想把上面的这5种方法都全部写在一篇文章里，可是刚写完第一个SQL注入攻击的时候，就发现文章篇幅已经不短了，又很难再进行大幅度的精简，所以索性把Web安全分成一个系列，分多篇文章来呈现给大家，下面你看到的就是第一篇「Web安全之SQL注入攻击的技巧与防范」。SQL注入常见攻击技巧SQL注入攻击是Web安全史上的一个重要里程碑，它从1999年首次进入人们的视线，至今已经有十几年的历史了，虽然我们现在已经有了很全面的防范对策，但是它的威力仍然不容小觑，SQL注入攻击至今仍然是Web安全领域中的一个重要组成部分。以PHP+MySQL为例，让我们以一个Web网站中最基本的用户系统来做实例演示，看看SQL注入究竟是怎么发生的。1、创建一个名为demo的数据库：CREATE DATABASE `demo` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;2、创建一个名为user的数据表，并插入1条演示数据：CREATE TABLE `demo`.`user` (`uid` INT( 11 ) NOT NULL AUTO_INCREMENT PRIMARY KEY COMMENT '用户uid',`username` VARCHAR( 20 ) NOT NULL COMMENT '用户名',`password` VARCHAR( 32 ) NOT NULL COMMENT '用户密码') ENGINE = INNODB;INSERT INTO `demo`.`user` (`uid`, `username`, `password`) VALUES ('1', 'plhwin', MD5('123456'));实例一通过传入username参数，在页面打印出这个会员的详细信息，编写 userinfo.php 程序代码：<?phpheader('Content-type:text/html; charset=UTF-8');$username = isset($_GET['username']) ? $_GET['username'] : '';$userinfo = array();if($username){ //使用mysqli驱动连接demo数据库 $mysqli = new mysqli("localhost", "root", "root", 'demo'); $sql = "SELECT uid,username FROM user WHERE username='{$username}'"; //mysqli multi_query 支持执行多条MySQL语句 $query = $mysqli->multi_query($sql); if($query){ do { $result = $mysqli->store_result(); while($row = $result->fetch_assoc()){ $userinfo[] = $row; } if(!$mysqli->more_results()){ break; } } while ($mysqli->next_result()); }}echo '<pre>',print_r($userinfo, 1),'</pre>';上面这个程序要实现的功能是根据浏览器传入的用户名参数，在页面上打印出这个用户的详细信息，程序写的这么复杂是因为我采用了mysqli的驱动，以便能使用到 `multi_query` 方法来支持同时执行多条SQL语句，这样能更好的说明SQL注入攻击的危害性。假设我们可以通过 http://localhost/test/userinfo.php?username=plhwin 这个URL来访问到具体某个会员的详情，正常情况下，如果浏览器里传入的username是合法的，那么SQL语句会执行：SELECT uid,username FROM user WHERE username='plhwin'但是，如果用户在浏览器里把传入的username参数变为 `plhwin';SHOW TABLES-- hack`，也就是当URL变为 `http://localhost/test/userinfo.php?username=plhwin';SHOW TABLES-- hack` 的时候，此时我们程序实际执行的SQL语句变成了：SELECT uid,username FROM user WHERE username='plhwin';SHOW TABLES-- hack'_注意：在MySQL中，最后连续的两个减号表示忽略此SQL减号后面的语句，我本机的MySQL版本号为5.6.12，目前几乎所有SQL注入实例都是直接采用两个减号结尾，但是实际测试，这个版本号的MySQL要求两个减号后面必须要有空格才能正常注入，而浏览器是会自动删除掉URL尾部空格的，所以我们的注入会在两个减号后面统一添加任意一个字符或单词，本篇文章的SQL注入实例统一以 `-- hack` 结尾。_经过上面的SQL注入后，原本想要执行查询会员详情的SQL语句，此时还额外执行了 SHOW TABLES; 语句，这显然不是开发者的本意，此时可以在浏览器里看到页面的输出：Array( [0] => Array ( [uid] => 1 [username] => plhwin )[1] => Array ( [Tables_in_demo] => user ))你能清晰的看到，除了会员的信息，数据库表的名字`user`也被打印在了页面上，如果作恶的黑客此时将参数换成 `plhwin';DROP TABLE user-- hack`，那将产生灾难性的严重结果，当你在浏览器中执行`http://localhost/test/userinfo.php?username=plhwin';DROP TABLE user-- hack` 这个URL后，你会发现整个 `user` 数据表都消失不见了。通过上面的例子，大家已经认识到SQL注入攻击的危害性，但是仍然会有人心存疑问，MySQL默认驱动的mysql_query方法现在已经不支持多条语句同时执行了，大部分开发者怎么可能像上面的演示程序那样又麻烦又不安全。是的，在PHP程序中，MySQL是不允许在一个mysql_query中使用分号执行多SQL语句的，这使得很多开发者都认为MySQL本身就不允许多语句执行了，但实际上MySQL早在4.1版本就允许多语句执行，通过PHP的源代码，我们发现其实只是PHP语言自身限制了这种用法，具体情况大家可以看看这篇文章「PHP+MySQL多语句执行」。实例二如果系统不允许同时执行多条SQL语句，那么SQL注入攻击是不是就不再这么可怕呢？答案是否定的，我们仍然以上面的user数据表，用Web网站中常用的会员登录系统来做另外一个场景实例，编写程序login.php，代码如下：<?phpif($_POST){…
近期许多网民发现在使用360浏览器访问网站时会出现链接跳转失灵或者刚刚填写好的表单却被清空的现象。技术监测显示这是因为360浏览器在升级后随机篡改HTTP Referer，干扰用户浏览网站的访问序列，导致网站为用户提供的服务中断，带来不便。什么是HTTP Referer？简而言之，HTTP Referer是header的一部分，当浏览器向web服务器发送请求的时候，一般会带上Referer，告诉服务器我是从哪个页面链接过来的，服务器籍此可以获得一些公开信息用于响应访问需求。Referer被篡改固然导致不便，但更需要大家警惕的是360此举即意味着将所有网银用户暴露在CSRF攻击（Cross-site request forgery跨站请求伪造）面前。举个例子。当你在360buy完成购物按下付款按钮，你需要登录到网银，通过对银行网站发送一个请求来完成转账。这时候，如果有黑客瞄上了你，使用CSRF的攻击方式，而你又恰巧刚进行过转账操作不久，浏览器与银行网站之间的会话还没有过期，那悲剧就很可能会发生，黑客将轻松的把你账户里的钱据为己有。当前防御CSRF攻击最方便的方法就是验证Referer值。让我们回到上面说的那个例子来：银行对转账请求验证Referer值，当发现Referer值不是来自银行自己的网站时，将会拒绝转账的请求，以保证账户的安全。说到这里，聪明的你是不是隐约觉得有些不对头了？是的。如果Referer值被伪装成银行网站的话，那转账请求就会被通过，你账户里的钱就会变成黑客的囊中之物。因为Referer值是由浏览器提供的，使用验证 Referer 值的方法防御CSRF攻击，其实就是把安全性都依赖于浏览器来保障。当你使用的浏览器，Referer值能被随意更改，你对自己钱包的归属还那么有信心吗？与HTTP Referer一同被360搞得“不明不白”的还有User-Agent。所谓User-Agent，简单的说就是客户端浏览器等应用程序使用的一种特殊的网络协议，在每次浏览器进行HTTP请求时发送到服务器，服务器就知道了用户是使用什么浏览器来访问。若想知道当前浏览器的User Agent信息，大家可以在地址栏直接输入 javascript:alert(navigator.userAgent); 回车即可看到。目前360浏览器会频繁更改自身的User Agent，伪装成苹果safari或微软IE。此举不仅导致网站不能正确识别用户，而且还使得许多网站的页面因为对浏览器识别错误而呈现错乱。正常显示的360浏览器UA信息有“360SE”字样不定期伪装成IE9或者Safari的360浏览器360在用户正常使用浏览器时将这些参数不经许可就更来改去，甚至移花接木，包藏什么祸心我们不得而知。但数字公司视用户为禁脔的行径无疑正愈演愈烈，不仅是记录访问数据窥私窃密，而且意图“绑架”用户为肉鸡。为了自己的安全，我们是时候做出选择了！刚才忘记添加原文网址了原文网址：http://bbs.shendu.com/thread-2218175-1-1.html
文件名： cn_visio_professional_2013_x64_1138440.exe语言： Chinese - SimplifiedSHA1：10823adaf26ff3ed07bf6171f9f9e799b409a6fchttp://pan.baidu.com/share/link?shareid=115654&uk=1006662537
一直在AngularJs的使用,也学习过一点,没做什么笔记,有网上朋友做了笔记,还建立索引,推荐学习.索引导航…AngularJs学习笔记–bootstrapAngularJs学习笔记–html compilerAngularJs学习笔记–conceptsAngularJs学习笔记–directiveAngularJs学习笔记–expressionAngularJs学习笔记–FormsAngularJs学习笔记–I18n/L10nAngularJs学习笔记–IE CompatibilityAngularJs学习笔记–ModulesAngularJs学习笔记–ScopeAngularJs学习笔记–Dependency InjectionAngularJs学习笔记–Understanding the Model ComponentAngularJs学习笔记–Understanding the Controller ComponentAngularJs学习笔记–E2E TestingAngularJs学习笔记–Understanding Angular TemplatesAngularJs学习笔记–Using $locationAngularJs学习笔记–Creating ServicesAngularJs学习笔记–Injecting Services Into ControllersAngularJs学习笔记–Managing Service DependenciesAngularJs学习笔记–unit-testing在推荐一个angular-ui,整理集成了很多插件,完全可以作为一个js包含ui的框架使用了.链接: AngularJs官网 | angular-ui
终于不用为给css取名而烦恼了,感谢Vivien Chen的整理. about 关于 account 账户 action 操作 ad,advertisment 广告 arrow 箭头图标 article 文章 aside 边栏 audio 音频 avatar 头像 background 背景 banner 条幅，广告 bar 条 branding 品牌化 breadcrumbs 面包屑 button 按钮 caption 标题，说明 category 分类 chart 图表 clearfix 清除浮动 close 关闭 column 列 comment 评论 community 社区 container 容器 content 内容 copyright 版权 current 当前态，选中态 default 默认 description 描述 details 细节 disabled 不可用 entry 文章，博文 error 错误 even 偶数，常用于多行列表或表格中 fail 失败（提示） feature 专题 fewer 收起 field 用于表单的输入区域 figure 图 filter 筛选 first 第一个，常用于列表中 footer 页脚 forum 论坛 gallery 画廊 group 模块，清除浮动 header 页头 help 帮助 hide 隐藏 hightlight 高亮 home 主页 icon 图标 information 信息 last 最后一个，常用于列表中 links 链接 login 登录 logout 退出 logo 标志 main 主体 menu 菜单 meta 作者、更新时间等信息栏，一般位于标题之下 module 模块 more 更多（展开） msg，message 消息 nav,navigation 导航 next 下一页 nub 小块 odd 奇数，常用于多行列表或表格中 off 鼠标离开 on 鼠标移过 output 输出 pagination 分页 popup 弹窗 preview 预览 previous 上一页…
jQueryMobile现在已经更新到1.2.0RC2，相信正式版也不会远了！ jQueryMobile在布局、控件上面已经基本很满足开发者的使用了，在一些细节地方还是需要有其他插件的帮助了。比如日期选择控件，推荐DateBox这款日期选择插件使用简单，主题也能和jQueryMobile保持一致，特别是功能很丰富。 使用方法：<link rel="stylesheet" type="text/css" href="http://code.jquery.com/mobile/latest/jquery.mobile.min.css" /><link rel="stylesheet" type="text/css" href="http://dev.jtsage.com/cdn/datebox/latest/jqm-datebox.min.css" /><script type="text/javascript" src="http://code.jquery.com/jquery-1.7.1.min.js"></script><script type="text/javascript" src="http://code.jquery.com/mobile/latest/jquery.mobile.min.js"></script><!-- Optional Mousewheel support: http://brandonaaron.net/code/mousewheel/docs --><script type="text/javascript" src="PATH/TO/YOUR/COPY/OF/jquery.mousewheel.min.js"></script><script type="text/javascript" src="http://dev.jtsage.com/cdn/datebox/latest/jqm-datebox.core.min.js"></script><script type="text/javascript" src="http://dev.jtsage.com/cdn/datebox/latest/jqm-datebox.mode.calbox.min.js"></script><script type="text/javascript" src="http://dev.jtsage.com/cdn/datebox/i18n/jquery.mobile.datebox.i18n.en_US.utf8.js"></script>在线预览