来源: 互联网  发布时间: 2013-12-24

最近经常有同学在使用LAMP/WAMP时，遇到这样的编码错误问题：

A网站程序编码UTF-8编码安装成功，运行成功。

B网站程序编gb2312也要安装在同一服务器上。

这样就出现问题了，Apache默认编码UTF-8在解析A网站的时候没有任何问题，当运行B网站时出现的"蝌蚪文"乱码问题。

单纯的修改Apache默认编码为gb2312这样就导致A网站出现"蝌蚪文"。

问题分析：

如果你在网上搜索 “apache配置”，搜到的页面大多都会建议你在httpd.conf中加上这么一句：AddDefaultCharset GB2312。

对于新手而且是只用GB2312编码的开发人来说，这么做是ok的。但是如果要想使用UTF-8字符集的话，比如 在test.php文件中需要有 meta http-equiv="Content-Type" content="text/html; charset=UTF-8" 这段代码。

这时你再打开浏览器访问test.php页面的话，你看到的是正确的页面。但是如果实际上浏览器还是以GB2312编码解释从服务器返回的response，为什么呢？原因是浏览器是根据http应答消息头部中的 Content-type: text/html; charset=GB2312 来决定使用何种编码解释应答，也就是说apache服务器仍然用GB2312编码传递数据。

所以说如果apache的默认字符集被设置成了GB2312，即使在页面中声明使用UTF-8编码，apache服务器还是会按照GB2312编码来传送http response。没关系，我们把AddDefaultCharset GB2312 改成 AddDefaultCharset UTF-8，看看什么结果？

如果你看到乱码恭喜你，你还知道是乱码问题；如果你看到是空白页面，那么你就惨了，你可能会以为这是其他什么原因造成的，而不会从编码的角度去考虑怎么解决问题。这是为什么？原因在于php文件本身是用系统字符集来编码的，中文的windows XP都是用GB2312，每一个文件头部都有字段指示该文件是用何种方式编码的。当apache接到浏览器的请求后，会让php去解释所请求的页面，比如 test.php。php会识别出test.php的编码方式是GB2312后(就像我们用javac编译java源文件时，编译器默认用系统编码读源文件里的内容。

如果源文件不是用系统编码来保存的，可以用命令javac -encoding指定具体的编码)，把数据以GB2312的编码格式传递给apache，而apache服务器不会改变从php传来的数据，只是在应答消息头部中把字符集设置成UTF-8： Content-type: text/html; charset=UTF-8. 也就是说你传递的是GB2312编码的数据，而浏览器却以UTF-8编码来解释应答消息。

由于UTF-8为3个字节表示一个汉子，而普通的GB2312或BIG5是两个。页面输出时，由于上述原因，出现半个汉字的情况，这时该半个汉字会和的>结合成一个乱码字，导致IE无法读完的话，会发现实际上整个叶面全部已经输出了。如果使用的是Mozilla、Mozilla Firefox、Sarafi的浏览器这不会造成这个问题，而是一堆乱码。这是由于Firefox浏览器和IE解析网页编码的策略不同产生的。OK,我们把test.php以UTF-8保存，再用浏览器访问时，就没有问题了。

可这样做，会使得apache目录下的所有web应用只能用同一种编码。如何搞定？

解决办法：

首先，可以使用AddDefaultCharset off来关闭默认文件编码，这样apache服务器就不会在http应答消息头部设置charset，只是设置Content-type: text/html. 而浏览器就会依靠html文件中设置的harset来决定编码。

其次，脚本php.ini文件中的default_charset = “UTF-8″作用同httpd.conf文件，把该行注释掉，使php自动识别文件的编码方式。

这样不论你用什么编码方式，只要test.php中的meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ 与你test.php文件编码方式相同，就不会产生乱码问题。用户提交数据的编码浏览器提交的字符编码由客户端的characher encoding决定。

例如，当前浏览器的编码是Gb2312，用户提交数据后，无论apache设置的编码方式是GB2312还是UTF-8，这时在服务器端接收到的仍是以Gb2312编码的数据。

如果要在返回页面上显示用户刚才提交的数据，而该页面是用UTF-8编码的或者要在数据库中存储的用户提交的数据，而数据库是UTF-8编码的，那就要做字符转换了。

    

    来源: 互联网  发布时间: 2013-12-24

1:网盘自动备份（隔离备份）

隔离备份介绍：直接在网盘内建立项目、文件进行稿写操作很可能会与网盘数据不同步导致数据丢失完整性，对文件造成损坏，所以这种方式是不可取的。因此采用隔离备份，所谓隔离备份就是在A文件夹进行稿写，当关闭计算机时自动备份A文件夹的所有内容到 B文件夹（这里B文件夹是网盘目录） 

进行隔离后，稿写与备份互不干扰，双份数据。达成目的流程如下：

1.开机时候网盘程序运行，自动备份网盘文件夹内的内容

2.关机时拷贝当前正在稿写的文件夹内容到网盘文件夹

数据测试截图：

 

左侧是网盘 右侧是本机，这是关机时自动进行的数据备份。

网盘生成文件夹截图

-----------------------------------------------------
实现过程如下：建立一个批处理程序代码如下：

（注：这里我为了包含sql的数据库一起备份，所以我先停止了sql服务再进行的备份，否则是无法拷贝SQL数据库文件的）
写好批处理后如何让这个批处理关机运行呢？

如下操作即可：

1：开始 -- 运行 -- 输入gpedit.msc 然后出来了组策略.计算机配置---windows设置---脚本(启动和关机)  双击关机策略,再点添加--浏览到你的批处理文件.

就可以了。
如图：

大功告成。

    

    来源: 互联网  发布时间: 2013-12-24

服务器方面

1、首先是要NTFS格式，并减少user之类用户的权限，FAT32格式的磁盘没有权限设置，也就没有安全可言；

2、其次是补丁要全，否则服务器中了木马，那什么都是白搭；

3、接着是禁用危险的组建和服务项，这个比较难，如果是简单的应用还好说，如果服务器里跑着比较纠结的程序，很可能就会因为禁止了某些组件或服务导致无法运行，我对这个是比较头痛的，所以做安全还是有必要知道应用所涉及到的权限以及其他方面；

4、端口屏蔽，比如普通的WEB服务器开个21和80以及3389就够了；

5、加密传输，这个防止嗅探的，不过WIN好像没自带；

6、密码安全、桌面锁定软件、命令函数更名等其他小的设置，就和安全意识有关了，作用不会太大，但是比没有要好。

IIS安全

1、执行权限这个很重要，不同的站点用不同的匿名用户访问，但是这些用户不能给权限，连组都不用加，而且这写单独访客的权限只在对应的WEB目录有效，其他盘都无效，Everyone之类的大权限统统删掉…而且大部分目录不给写入权，用户权限是WEB安全最重要的一块；

2、取消掉没用的API扩展，搞黑的都知道asp传不了就用asa或者cer格式的木马，安全也一样，没用的API扩展统统去掉，比如asp的站点只留一个.asp的，其他扩展删掉，你传了后门也没用；

3、取消不必要的WEB扩展，扩展多了漏洞也就多，能少用还是少用吧。

权限类

1、站点单独用户权，防止跨站，IIS那说过了，其实这个可以再IIS设置，也可以再硬盘设置，本质都一样，就是NTFS格式的权限设置，而且权限最多给到读取写入，不可能再多了；

2、目录与文件的权限设置，图片目录这样的，给个读取权就可以了，而且脚本都可以禁掉，没哪个图片是可执行的吧… 文件也一样，HTML的目录和文件，脚本权可以禁掉，普通页面给个读取权就可以了，写入权这玩意很危险，能少给就少给，但是弄错了网站会崩；

3、特殊目录的权限，像D盘E盘这样的，删了Everyone就连子目录的也一并删了，但是例如system这样的目录，没有继承权，你删了C盘的某用户，很多子目录里还是有的，要一个一个删，否则就会出现像入侵时候遇到的情况：C盘无法访问，但是用户文件夹和windows目录可以访问。

代码安全

1、代码防注入，这个是最多的安全问题，有了数据库就有了注入，防御办法很多，绕过防御的办法也很多，很难一概而论，总之还是靠程序员的安全意识与代码功底；

2、上传漏洞的防止，除了注入上传也是个大户，很多入侵依赖上传，解决方案是：减少上传数量，提高验证强度，验证的时候要固定后缀、类型，而不是排除，上传的文件随即命名，自动修改后缀，上传目录不给任何权限！

3、文件命名规则，一些测试文件和敏感文件，名称和目录一定不能让人猜解，或者加入验证，猜解到了文件也进不去；

4、第三方代码，这个要少用，尤其是小团队写的，DISCUZ这么牛X的代码都一直爆漏洞，别说其他代码了，原因是这些代码都是公开的，可以从源代码里找漏洞，很危险的；

5、其他一些例如防社会工程学漏洞、防爆路径，就比较难说清了，还是安全意识的问题。