貌似还是个比较艰巨的任务啊。

1，登录取得session。。

2，提交数据。

POST /api.php HTTP/1.1

Content-Type: application/x-www-form-urlencoded

Host: thebestspinner.com

action=rewriteText&inapp=1&session=【这里是sessionid】&protectedterms=&text=【文章内容】（记得是urlencode，并且不带超链接的数据）

3，获得数据。

POST / HTTP/1.1

Content-Type: application/x-www-form-urlencoded

Host: thebestspinner.com

Content-Length: 295

uniq=【这里是sessionid】&action=app_spingroups&article=【文章内容】

//这个是会变动的uniq=4f4cdf7d17627

uniq=4f4cf1ec387

经过研究，发现这session只要不做登录操作，就一直不会变动，所以这个软件还是存在漏洞的。不知道session存在的时常是多少。

主要特性：

1，多站点，多数据库。完全自定义，不同站点绑定到一个根目录，后台设置采用不同数据库即可。

2，伪静态。

3，seo。url,自定义自己喜欢的url，可以放置必要的关键字。站点关键字及描述seo，后台设置即可。

4，风格自定义。分为两部分，一部分是大体框架，一部分是细节部分。在需要的地方放置{替换字段}即可。可以完美的匹配任何风格类型，细节做到极致。有关可替换字段，稍后放出。

5，文章页完全静态话。运行一次，自动生成静态文件。所以对于一个新站点，先应该做好风格的处理。

存在的问题。

1，伪静态部分。伪静态部分，如果出现特殊字符，如&，会发生错误。好在只是数据显示缺失（存在的数据没有显示出来），并不会导致不可预估的错误。

2，其他有待挖据。

正如我轻轻的来。

回家移树，树大且重。回家挖土，两膀酸重。直挖的口干舌燥，气喘嘘嘘，浑不然早已湿身。

久坐肌萎缩，动久肾虚早，自古两难全，劝君须自保。有树堪移直须移，莫待无果空摇头。三十计为美女，奈何鳖首只堪缩；可怜可叹狡孙兴，身败名裂做嫁衣。

1，www.zcde.com和zcde.com视为两个不同的站点，如果要使得两站点保持一致，那么需要设置转发。
2，配置信息会尽早跟上。

3，模板的选择。目前模板设置还是通过ftp来更新。毕竟为了维护最小的开销。尽管可能你的模板都是一样的，但是还是尽量使用ftp来维护。

4,伪静态链接设置中不能有_，否则出错。

5，采集开关：关键字混合开关，准备一个字段。

• 1，无需采集 值1，做正规战。
• 2，无需采集 但需要混合关机键子值2 （关键字混合与文章是不相关的，自己采集好文章利用关键案子库混合做垃圾站）
• 3，点击不存在内容的时自动采集，并根据此文章关键字给出不存在内容的连接，这将形成一个无限的循环。 值 3（这个采集来的数据无需混合关键字）
• 4，自动采集，更具给出的关键字库，采集相关文章。不给出空连接。值4，适合使用关键字库一键生成n多文章。

想判断一个文件或目录是否存在，用上面两个函数。
我原本想避免使用上面两个函数的，总觉得要先判断下，不如直接使用is_writable()，如果可写就执行下一步，总觉得这样似乎更快些。。
于是测试了下，发现is_writable()效率最差。时间是file_exists的十倍。。。

对比了下 is_dir 和 file_exists，结果前者耗时是后者的2～3倍。郁闷死了。如果目录存在，那么耗时将会到4倍。。太恐怖了。。

原本最不看好file_exists，总觉得他会遍历目录，看来我错了。。

防御1:  arp防火墙开启主动防御，无奈每秒只有50次，显然对于攻击者来说，他就是欺骗的频率高了点，该欺骗还是欺骗。启用防御2：被动防御，你主动欺骗我的时候，我不理睬。

结果对比下来，开启主动防御的时候，几乎不能上网。被动防御的时候速度还行，慢是慢了点，总能用了。。

我的一点理解：

攻击者，显然对你每秒50的arp不感冒，小case，相比他攻击的arp包，你这点完全不够看的。而且还造成了自己的欺骗频率变高（包括路由器端），被动防御的时候，因为不发包，相对欺骗的频率有所降低，显然他是不会欺骗到路由器堵塞吧。

由此可见，这个欺骗应该是建立在获取arp请求上的，比纯粹的arp断网欺骗攻击多了一层相应arp请求。果然是道高一尺，莫高一丈啊。

受比攻好。这个问题教育我们活着就得逆来顺受。

虽然程序还没写，但优化的问题已经在考量中。

mysql性能的优化，索引的建立。

具体数据库的设计还需要仔细考量。

TINYTEXT是固定长度，不到长度的字符以空格填充。

varchar是可变长度，更节省空间。

但不知道索引效率如何。反正我注意到wordpress连title都是text，我喷了。。。

介绍下char varchar text的区别

他们的存储方式和数据的检索方式都不一样。

数据的检索效率是：char>varchar>text

空间占用方面，要具体情况具体分析了。

Char为定长，varchar，text为变长

Char在保存的时候，后面（右边）会用空格填充到指定的长度，在检索的时候后面的空格会去掉，所以检索出来的数据需要再用什么trim之类的函数去处理。(与sql server可能有些不同)

Varchar在保存的时候，不进行填充。当值保存和检索时尾部的空格仍保留。

TEXT列不能有默认值，存储或检索过程中，不存在大小写转换.

当存储的字符超过他们定义的长度时候，如果不是在sql服务器的严格模式下，都会自动截取合适的字段存储，而不会出现错误。但是，如果是中文的话同样要报错误：）比如定义char(4),然后insert (‘c哈哈’).

注意一点的，Char，Varchar不像数值类型，有系统默认长度，所以必须在括号里定义长度，可以有默认值

text不可以写默认值，后面如果指定长度，不会报错误，但是这个长度是不起作用的，意思就是你插入数据的时候，超过你指定的长度还是可以正常插入（严格模式下没有测试 ：））

存储计算：

在使用UTF8字符集的时候，手册上是这样描叙的：

·        基本拉丁字母、数字和标点符号使用一个字节。

·        大多数的欧洲和中东手写字母适合两个字节序列：扩展的拉丁字母（包括发音符号、长音符号、重音符号、低音符号和其它音符）、西里尔字母、希腊语、亚美尼亚语、希伯来语、阿拉伯语、叙利亚语和其它语言。

·        韩语、中文和日本象形文字使用三个字节序列。

char会造成空间浪费，但是有速度优势；而varchar节省了空间，但是速度就不如char。

1. 经常变化的字段用varchar
2. 知道固定长度的用char
3. 尽量用varchar
4. 超过255字节的只能用varchar或者text
5. 能用varchar的地方不用text

CREATE TABLE `tag` (
`tag` varchar(65532) DEFAULT NULL COMMENT ‘Tag’
) TYPE=MyISAM DEFAULT CHARACTER SET utf8

综合下来就是：

需要索引 并且 能定的就用CHAR
少的用VARCHAR
多的用TEXT

今天提到很多问题。关于目前正在写作的blog程序（具体做成什么样子当然还是看需求）。

考虑良多，觉得还是使用mysql数据库，而不是文本数据库。

速度及性能要求考良。如果从数据库安全方面，当然是采用文章全部入库的好;不过从性能方面来说，这样是不够的。（不过好在可以定义是否入库来解决这个问题。如果入库，当然尽量不调用这个数据库，而只作为生成文章时候的依据）

其他杂项

自动生成html。根据md5判断

过滤敏感字符

基于以上几点，那么数据库的设置极为重要。

架构

1，数据库（关键字设置）

表格：hash(放置md5数据及url-seo数据，必须) || wenzhang（文章数据，只在迁移时根据数据使用，定义开关）||key(关键字数据，定义开关)||other(杂项 首页seo设置；敏感字符过滤;伪静态优化设置)。

2，采集模块

基本做好，这个还是比较简单的

=========================================

详细

hash-md5title-url

char(32)-varchar(255)

key-key-subkey

varchar(255)-text

posts-title-content-tag-cat

varchar(255)-text-varchar(255)-varchar(255)

other-sitetitle-siteinfo-sitekey-permalink-deny

text-text-text-text-text

重新考虑了下，绝对上面有点多余，重新设置表如下。post(文章库) key(关键字库) site(站点信息库)

==================================

post

id title titleslug titlemd5 content tag cat ping

索引id

key

key subkey

site

domain postdb keydb sitetitle sitekey sitedes permalink