进入 http://www.myipneighbors.com/ 输入你的IP地址,就可以列出同IP下的所有网站,就可以知道这台主机上一共运行了多少网站.有了他就不容易被JS主机商欺骗…

收藏、分享这篇文章!

很多人都以为htmlentities跟htmlspecialchars的功能是一样的，都是格式化html代码的，我以前也曾这么认为，但是今天我发现并不是这样的。

这两个函数在格式化带有英文字符的html代码的时候基本没啥问题，但是htmlentities对中文字符也不放过，这样得出来的结果是中文字符部分变为一堆乱码。当时做英文站的时候根本就没觉察到这个问题，而今天公司的一个收藏站却因为有有非英文字符而出现了问题，我最终查出来是htmlentities这个函数的问题，同时我也找到了htmlspecialchars这个函数。

对于这两个函数，php手册上都是英文做的解释，其中在htmlentities函数的说明部分有这么一段英文：

This function is identical to htmlspecialchars() in all ways, except with htmlentities(), all characters which have HTML character entity equivalents are translated into these entities.

从这句话中我们也可以看出来这两个函数虽然基本功能差不多，但是还是有细微的差别在里面的。再仔细看htmlspecialchars函数里面的一段话：

The translations performed are:

‘&’ (ampersand) becomes ‘&’

‘”‘ (double quote) becomes ‘”‘ when ENT_NOQUOTES is not set.

”’ (single quote) becomes ”’ only when ENT_QUOTES is set.

‘<’ (less than) becomes ‘<’

‘>’ (greater than) becomes ‘>’
可以了解到htmlspecialchars只转化上面这几个html代码，而htmlentities却会转化所有的html代码，连同里面的它无法识别的中文字符也给转化了。

我们可以拿一个简单的例子来做比较：

有条件的朋友，可以分别运行一下上面的这两段代码，就可以看出两者的差别了。

收藏、分享这篇文章!

SQL 注入
很多 web 开发者没有注意到 SQL 查询是可以被篡改的，因而把 SQL 查询当作可信任的命令。殊不知道，SQL 查询可以绕开访问控制，从而绕过身份验证和权限检查。更有甚者，有可能通过 SQL 查询去运行主机操作系统级的命令。
直接 SQL 命令注入就是攻击者常用的一种创建或修改已有 SQL 语句的技术，从而达到取得隐藏数据，或覆盖关键的值，甚至执行数据库主机操作系统命令的目的。这是通过应用程序取得用户输入并与静态参数组合成 SQL 查询来实现的。下面将会给出一些真实的例子。
由于在缺乏对输入的数据进行验证，并且使用了超级用户或其它有权创建新用户的数据库帐号来连接，攻击者可以在数据库中新建一个超级用户。
Example#1 一段实现数据分页显示的代码……也可以被用作创建一个超级用户（PostgreSQL系统）。

PHP代码:

一般的用户会点击 $offset 已被斌值的“上一页”、“下一页”的链接。原本代码只会认为 $offset 是一个数值。然而，如果有人尝试把以下语句先经过 urlencode() 处理，然后加入URL中的话：
0;
insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
    select ‘crack’, usesysid, ‘t’,'t’,'crack’
    from pg_shadow where usename=’postgres’;
–
那么他就可以创建一个超级用户了。注意那个 0; 只不过是为了提供一个正确的偏移量以便补充完整原来的查询，使它不要出错而已。
Note: — 是 SQL 的注释标记，一般可以使用来它告诉 SQL 解释器忽略后面的语句。

Click to continue »

收藏、分享这篇文章!

I’ve always enjoyed fractals, and was curious if scripting languages were up to the task. I wrote a very simple Mandelbrot set generator for my test. Rather than optimizing for each language, I tried to write each program in approximately the same way in each language to make a reasonable performance comparison.

Here are the results from running on my 867 mhz Powerbook G4. Shorter is better. Please note, the following benchmarks are not scientific, and were simply done to satisfy my curiosity. Your mileage may vary.

Feel free to send me ports to any other languages. The program should print the time in seconds that elapsed at the bottom in the form of ‘Elapsed %0.2f’. If you can, include instructions for building on MacOS X.

— Erik Wrenholt (erik -at- timestretch.com) 2005-09-20

Click to continue »

收藏、分享这篇文章!

Five important interfaces of JDBC

1. Connection：特定数据库的连接（会话）。在连接上下文中执行 SQL 语句并返回结果
2. Statement：用于执行静态 SQL 语句并返回它所生成结果的对象

3. PreparedStatement：表示预编译的 SQL 语句的对象
4. CallableStatement：用于执行 SQL 存储过程的接口
5. ResultSet：表示数据库结果集的数据表，通常通过执行查询数据库的语句生成
如下图：

收藏、分享这篇文章!

随着软件分层设计的流行及广泛的应用，对于DAO的设计模式大家已经不再陌生了，DAO层已经在软件系统的开发中成为必不可少的一层，将后台的数据层和前台的VO进行分离。前段时间也针对于DAO的设计介绍过一个基于Hibernate的泛型DAO的设计。
csdn blog：http://blog.csdn.net/yongtree/archive/2008/03/12/2172071.aspx
javaeye blog：http://yongtree.javaeye.com/blog/170449
通过DAO的设计的确可以让我们的软件系统已经将数据层和表现层进行了简单的分离，让我们系统各层次的功能更加的清晰。所以我们开始洋洋得意了，DAO的引入让系统的耦合性更加的松散，表现层再也不需要关心后台数据操作的变化了。于是我们开始高枕无忧了，我们肆无忌惮的在表现层通过调用DAO来实现我们的系统了。事实真的如此吗？那我们就举个例子来看看我们的系统是否真的具有解偶的能力了。
现在我们有个员工管理系统，在该系统中，Person.java表示员工这个对象，它对应着数据库中的person表。还有用于操作Person对象的DAO接口—PersonDAO.java，还有一个PersonDAO的实现类PersonDAOImpl.java。在PersonDAOImpl.java中我们实现了操作Person对象的所有的方法。我们很自豪的说，看我们已经把操作封装在PersonDAO中了，现在我们可以在表现层（jsp，或者VO操作类中）使用PersonDAO personDAO=new PersonDAOImpl()来调用DAO操作我们的数据对象了。当我们陶醉于自己写的优美的代码的时候，项目经理来通知了，由于使用Hibernate的效率偏低，客户开始不满了，还是让我们重新用JDBC再重写一遍吧。于是所有DAO的Hibernate实现开始全部转换成JDBC实现。但是项目经理建议不要破坏现有的Hibernate实现，以后可以通过技术研究来提升Hibernate的访问效率。于是我们开始写了又写了一套JDBC的实现—PersonDAOJDBCImpl.java，现在问题出来了，表现层大量的使用了PersonDAO personDAO=new PersonDAOImpl()，全部改成new PersonDAOJDBCImpl()谈何容易，我们是不是开始欲哭无泪了。
怎么解决类似的问题呢？于是我们开始引进工厂模式。我们建立一个类DaoFactory.java对DAO进行统一管理。
Click to continue »

收藏、分享这篇文章!

    从昨天中国联通10:30恢复交易之后的10.71元涨停板价格跌至今天的8.70元,在短短的两个交易日里自高而下竟然暴跌接近20%,连续两天巨量大跌,已经令追高的投资者胆战心惊,帐户损失惨不忍睹.从中国联通暴跌走势能给投资者许多有益的启示:

    第一中国联通在大重组方案公布之前从8.31元放量冲至9.82元并收在9.74元.表明在公布重组之前已经泄露了消息.在停牌前基金扎堆于中国联通,并获得了10%以上拉升幅度,因此在信息不对称的前提下,基金或机构大力鼓吹中国联通是大赢家.使得中小投资者盲目跟风.酿造了套牢的苦果.

    第二从技术面看,中国联通在前期破位下跌的颈线位置10.60/10.74区抛售压力巨大.因此当中国联通恢复交易之后.短线高达20%赢利的主力机构,果断选择疯狂抛售.制造了这两天中国联通暴跌的大戏.它的走势可以说是和以前的中国石油如同胞兄.

    第四市场对于中国联通的预期性炒作,其实已经很长时间.所有的利好早已被市场透支,从其目前的业绩看恐怕难于支持当前的股价.因为目前大批银行股的市盈率在18倍左右.因此在蓝筹股,比价效应的作用下中国联通后市还有进一步调整的空间.

    第五对于习惯”三年计划五年实施”的管理层来说主力机构害怕整合的过程中将要消耗很长的时间.在大盘整体方向和空间不是特别明朗的情况,投资者很难坚持持股.因此抛售是主力必然的选择.

    第六从走势看毫无疑问以基金为主的机构借利好进行集中减仓,反映基金等主流机构.对于大盘中期走势依然保持谨慎.特别是中国联通巨量大阴所带来的不确定性,很可能宣告电信类股后市将转为个别发展.

收藏、分享这篇文章!

FCKeditor在线编辑器
FCKeditor 这个开源的HTML 文本编辑器可以让web 程序拥有如MS Word 这样强大的编辑功
FCKeditor官司方网址：http://www.fckeditor.net/

FCKeditor在线DEMO：http://www.fckeditor.net/demo

FCKeditor下载直址：http://www.fckeditor.net/download 最新版已经是2.6了。

在项目中使用FCKeditor在线编辑器：
(1) 新建一个WEB工程；
(2) 解压FCKeditor_2.6.zip包，将其中的editor文件夹复制到项目中去；
(3) 解压FCKeditor_2.6.zip包，将其中的fckconfig.js、fckeditor.js、fckstyles.xml、fcktemplates.xml赋值到项目中的WebRoot目录下面；
(4) 将FCKeditor.jar文件复制到WebRoot\WEB-INF\lib目录；
(5) 将FCKeditor.tld文件复制到WEB-INF下面；
(6) 修改web.xml配置文件中的信息，如下;

Click to continue »

收藏、分享这篇文章!

首先声明这些测试并不严格，全是在同一台机器（Core2 1.6，2G内存PC）上跑，DB是同一个MySQL，执行简单的单表读写操作，并发100个thread（此并发情况下各种技术基本都不会出Error），都不做缓存。数值都是取rps，具体的绝对数值没有考究的意义，不过相对一比较倒有些意思。

先用笔者前两三年一度热衷的Appfuse，测下来的结果大概在130左右；
然后直接采用Spring的三个例程，一来简单，二来Rod自制的Sample效率应当是有保证的，结果如下：
采用hibernate的petclinic：200左右；
采用ibatis的jpetstore：400左右；
采用jdbc的imagedb：750左右。

大家应该看出些门道来的吧。所以说Rod老大的确是聪明绝顶，早已预备了三种不同的性能方案，做成sample给大家采用。至于大家最后怎么用是自己的事，怪Spring就不对了，Rod真是高明！

顺便附上其它技术体系的参考值（由高到低）吧：
纯PHP：1000左右；
以快速闻名的FleaPHP：800左右；
JSTL：350左右；
Grails：50左右；
Seam：20左右；
RoR：12左右。

这下大家是不是有些总的概念了。基本规律是越偏向SQL的技术，性能越高；越偏向ORM的技术，性能越低。由此可见OO和关系DB的不匹配，不仅仅是在设计和编码上，在性能上更是个天大的问题。
差距如此之大，就连笔者也不禁怀疑起自己的测试。建议有心的同道们做一下更严格的测试以资验证。

值得一提的是，在引入DB前，JSP还是要快过PHP不少，大概是1900：1400左右，但加上DB后，JSP竟然干不过PHP，身为Java fans实在是有些愤怒。不过很久不写JSP了，但愿精于此道的同道写个更高效的，压过PHP才好。

现代主流DB在此配置下每秒钟大多能吞下500－1000条普通SQL。做为中间层，不管怎么做，还是要配得上才行。
是选择开发效率低一些，但性能高的偏SQL方案，还是选择开发效率高，但性能低的编OO方案，不同的场景有不同的回答。
但愿此文能帮助各位同道在不同的项目上能对性能－开发效率做出最好平衡的正确选择。

收藏、分享这篇文章!

struts通用Exception处理
自定义一个Exception类继承自RunTimeException，定义属性key、values等，并实现多个构造方法用于初始化。
如：

Java代码

1. private String key;    
2. private Object values;    
3. //带key和参数    
4. public SystemException(String message,String key,Object value){    
5.   super(message);    
6.   this.key=key;    
7.   this.values=new Object[]{value};    
8. }    
9. //带key和参数数组    
10. public SystemException(String message,String key,Object values[]){    
11.   super(message);    
12.   this.key=key;    
13.   this.values=values;    
14. }    
15. public SystemException(String message,String key) {    
16.   super(message);    
17. }   

 Click to continue »

收藏、分享这篇文章!