用PHP的ob_start()控制您的浏览器cache

< <?php
$f=fopen("test.txt", "wb");
$text=utf8_encode("a!");

//先用函数utf8_encode将所需写入的数据变成UTF编码格式。

$text="\xEF\xBB\xBF".$text;

//"\xEF\xBB\xBF",这串字符不可缺少，生成的文件将成为UTF-8格式，否则依然是ANSI格式。

fputs($f, $text);

//写入。

fclose($f);
?> 
 

 代码如下 复制代码


编码对于合格的PHP程序员来说并不是什么难事（也许只是花费时间长短的问题），因此系统分析和设计这一阶段就显得尤为重要。不过本文并不打算讨论和需求分析、获取商业逻辑相关的话题，而是针对系统设计方面进行探讨。

面临难题
编码对于合格的PHP程序员来说并不是什么难事（也许只是花费时间长短的问题），因此系统分析和设计这一阶段就显得尤为重要。对于一个担任PHP项目的系统分析员来说，面临着两个难题：

1. PHP语言本身的限制。
   这 一点在复杂系统的面向对象设计中尤其显著。PHP的面向对象特性在现有版本中虽然得到了改善，但是还不甚健全，根本不足以担任面向对象设计的实现语言；即 使眼光长远一些，在即将释出的以Zend Engine 2.0支持的全新PHP中，面向对象特性也不会像现在流行的Java或者C++那样（关于这方面的内容可以参见我在developerWorks中国网站 发表的另一篇文章）。但是如果采用完全面向过程（准确说是面向Web页面）的方式，可以想见整个系统的设计会非常复杂，而由此带来的编码复杂和维护困难更 加难以应付。
2. 现有资料的严重缺乏。
   这是众所周知的现象即针对Web项目的系统设计资料不足；而在这些有限资料中，关于 PHP的设计资料又非常匮乏。如果本公司或本人也没有相关的技术积累，系统分析员只能在黑暗中摸索方法（更坏的两种情况，一是照搬其他项目比如Java或 者C++的设计，二是认为项目简单而不负责任的草草了事）。

 

认识面对的系统
既然如此，采用何种方法妥善处理PHP系统的分析和设计？最初的构想应该需要分清项目承担任务的类型：

1. 涉及大量客户本身或者客户所在行业的商业逻辑的项目，包括办公系统、订单系统以及其他商业系统。
2. 简单网站项目，包括一些需要承担高访问量或要求快速响应的项目比如品牌网站或者活动网站以及其他一些网站。
3. 综合性网站项目。通常包含多个相对独立的子系统比如新闻子系统、论坛子系统、产品陈列子系统等等。

 

PHP 的设计初衷在于解决后两种项目的迫切需求，语言本身对于这些项目进行了良好的改造。而众多的PHP开发者对这些项目也具有或多或少的经验，相关书籍中的范 例也大都围绕于此。相对说来第一种系统所有的资料不多，各种出版物对其内容也很少提及。因此在本文中将题所述对第一种类型的项目进行详细讲述（有关MVC 模式和类封装），同时附带提及第二种项目（有关黑客代码）以及第三种项目的设计方法。当然，并不是被归类的这些项目就只能采用本文描述的方式，系统分析员 需要权衡各方面因素加以选择。

方案一：涉及大量商业逻辑项目
如何分离用户界面和后台操作？如何避免将商业逻辑混淆于一般的流程控制中？作为一个严谨的商用项目，就需要考虑很多类似的问题。对于由PHP担当的这类项目，贯彻Model-View-Controller（MVC）模式的设计是一个非常好的方法。

理论描述
在 这里我不想多加解释MVC模式本身--简单的从字面上以及应用上说，通过将系统的设计分为Model模型/逻辑、View视图/界面、 Controller控制/流程三个逻辑部分达到良好的项目效果，以此便利各部分开发者的工作并降低日后的维护成本。（如果您熟悉JSP开发的Model 2模式，可以发现它也是MVC模式的很好体现。）就现实的项目开发而言，现存的很大问题包括网页设计人员和程序开发人员的工作交错和冲突以及商业逻辑嵌入 页面造成不可重用也很难维护等等。引入MVC模式一方面可以为系统的总体设计指出明确的方向，对于开发团队的分工也是良好的指导。

既然依照MVC模式要求对系统的总体结构在逻辑上分成三部分，那么团队的开发者中也存在着针对各个部分的开发者。

开发者角色	相关系统逻辑	职责
网页设计人员	View视图/界面

 网上很多文章介绍优化php程序，是通过安装Zend Optimizer之类的加速软件实现的，但这种加速是有限的。本文主要从程序代码着手介绍一些优化手段。

1、程序的抽象层越多，各抽象层分离得越严格，程序效率越低。

最原始的应用于网页的php程序模式莫过于脚本嵌入模式，即仅仅在一个网页中需要动态处理或显示数据的地方通过加入标识符嵌入php脚本。一般来说这是php程序员最早学习的模式，它只有一个抽象层，就是网页，故本文称其为单层模式。

随着网站规模逐渐增大，程序员可能会发现单层模式的程序很难维护，当想对程序修改或扩充功能时，会发现代码非常混乱，感觉无从下手。于是模板类诞生了，它使一个网页由两个文件组成：一个php程序文件，一个html模板文件。常用的模板类有PHPLib库带的Template模板类，Smarty模板类等。由于加入了额外的处理程序（模板类），程序效率下降了。你若不信可自己测试一下。其实一般情况下，不用函数（最原始的编程方法）比用函数（面向过程）的效率高，而用函数的效率又比对象封装（面向对象）高。所以就算在编译语言中，需要高效率的地方会用C写而不用C++，例如FreeBSD操作系统的内核；而需要极端高效的地方还要用汇编写。

为了使程序可以适应多种数据库系统，或者方便随时转换数据库系统，常常还会用一个类把跟数据库打交道的函数封装起来，这样当转换数据库系统时只要把封装类换掉就行了，主程序不需要修改。这里又用了一个类，效率又打折扣了。

上述模板类的使用，使程序分成两个抽象层：程序层和表现层。而数据库类的使用又把程序层分为数据接口层和数据处理层。

项目越庞大，需要分离的抽象层就越多，这样使得分工清晰，方便管理，但是以牺牲程序执行效率为代价。

对于抽象层造成的效率下降，优化的方法有二：减小抽象层、优化抽象层之间的接口。一般地，不应该为了提高效率而盲目减小抽象层，这样会使得代码混乱、难于管理。但是不应该为小项目建立过多的抽象层，除非你有将来把它做得很大的计划。关于如何恰当分割抽象层，本文不作更深入讨论。

对于上文说的两个分层例子，优化抽象层之间的接口分别是模板类和数据库操作类。抽象层接口在程序中需要被频繁调用，以在不同层之间交换信息，所以层接口是很值得优化的。对于数据库接口类，可能仅仅是封装一些数据库函数，优化余地恐怕不大。对于模板类，很多时候是有较大优化余地的。一般地，模板模型越通用，模板类功能越强大，效率就越低，例如PHPLib库带的Template类就有极大的优化余地。而Smarty模板类比PHPLib的Template更复杂，我没有用过，据称有缓存机制，不知是否可以弥补其性能损耗。下面就来看看PHPLib的Template类有多少东西可以优化掉。

(1) 读入模板文件时，file函数效率低，改用get_file_content函数。

(2) 匹配子模板时，正则表达式替换函数preg_replace效率低，改用str_pos函数进行定位和用str_replace函数进行替换操作。此优化手段后文会详细分析。

(3) 模板模型通用性很强，能适应各种情况，但在具体细节的处理上，通用的方法效率可能很低。可以对模板模型作适当修改。我的做法是建一个相对通用的模板类，然后再派生出一个只适用于特定程序的模板类。在通用模板类的模板模型上可以作些优化（相对于PHPLib的Template），例如在处理二维数据表的时候用PHPLib的Template处理就比较复杂，需要多次调用类方法（本质上是函数调用），所以重写的时候可以把处理二维数据表的功能封装到一个高效率的方法中，直接避免方法的多次调用。

(4) 调试功能在小项目上不需要用，跟调试相关的代码全部去掉。

我在按上面4点重写了模板类之后，一个复杂页面的执行时间缩小了一个数量级（除模板外没有作其它优化）。

现在就优化你的程序的抽象层之间的接口，特别是当这些接口是使用现成的函数或类的时候。因为这些函数或类在设计时会为了适应普遍情况而牺牲一些效率，而且它们的作者也可能没有考虑效率问题。像如此著名的PHPLib的模板类的效率也不见得就高。

2、细节代码优化

(1) 上文模板类优化已提到的，正则表达式匹配比一般字符串匹配慢得多，尽可能用字符串匹配而不用正则表达式匹配。有时候虽然用正则表达式匹配使程序代码更简洁，而一般字符串匹配使代码更冗繁，但很多时候字符串匹配仍比正则表达式高效。

(2) 字符串替换函数str_replace和preg_replace都是可以接受数组参数的。有时候需要对字符串进行批量替换，则用数组参数比循环调用替换函数来得高效。例如下面的代码：

for ($i = 0; $i < $n; $i++) {
$str = str_replace($search[$i], $replace[$i], $str);
}

应该换成：

$str = str_replace($search, $replace,

声明：本文同时发表于一搏IT社区、CSDN、昨夜风个人网站，欢迎任何网站/个人转载，但请保留声明信息和作者信息，多谢合作！

作者：靳英辉(昨夜风)
版本：Jpage v2.0 for php
发表：2008-12-02

______________________________________________________________

在先后推出针对Java、.Net2.0开发语言下的Jpage两版分页之后，随着一搏IT社区、abcbaby、加拿房产网、中国开源网的开发需求，以及新东方一搏PHP01班的盛大起航，对php下的Jpage分页需求，提上日程。

版本历史：
2007年10月，Jpage分页php版诞生，初步应用于几个项目中。
2007年11月，我和PHP01的学生们，一起对Jpage第一版进行了全面的测试和完善。
2008年12月，Jpage 2.0 php的诞生。

Jpage v2.0 for php

特点：
1、通用的数据封装。
只需包含mysql.php，解决所有增、删、改、查的问题。执行SQL语句、执行过程、返回数组结果、返架一行结果、返回一行一列，尽在其中。
对数据持装类，吸纳了微软的.NET数据层的思想，结合了实际开发需求，将大大提高开发效率。

2、只需一条查询语句。
使用简单、开发快捷、最优查询一直是Jpage系列分页的核心思想。只需一条语句，即支持普通查询、海量查询，并同时得到多种分页样式， 这就是Jpage分页。

3、优化小量查询和海量查询。
经Mysql5 260万条数据测试，Jpage分页执行飞快。明显优于网上其它分页以及基于PHP程序层结果集的分页。在Mysql中，Jpage分页采用了limit来分页，这延续了Jpage分页“需多少，取多少”基于数据库层面的分页思想。

4、内置三种页脚风格。
为了解决不同的显示需求，Jpage分页内置了三种页脚显示风格：
默认样式：适合一般企业需求。
简捷样式：适合窄页面显示需求。
数据样式：适合海量数据显示需求。
除了上述三种风格之外，开发者还可在footPage.php中自定义风格。

5、灵活的页脚样式控制。
你可以定义诸如：#page a{color:red}样式表文件，来得到不同显示效果。

６、与Jwork框架无缝集成。
作为Jwork框架的前身，Jpage分页,它不是一个在战斗。Jwork框架是软件开发的经验集、通用集、效率集。

对比：

一般分页／自定分页存在的问题：

１、网址传参的问题。
网上有些分页，包括我们自己写的分页，往往忽略了网址传参的问题。我们知道，分页的网址一般为:
list.php  list.php?page=2，

但当网址有参数时，
list.php?name=yiboit&id=20
一般分页则为：list.php?page=2
Jpage分页为：list.php?name=yibit&id=20&page=2

2、书写复杂、代码冗余、和数据层独立。
一般的分页，和数据层独立，并且和视图（页面）过于耦合，在使用上、开发上、运行效率上都是值得商榷的。
Jpage分页，已先后发布Java、.Net、PHP三版，基于同一思想，经过百万级项目测试、压力测试，尚未出现任何问题。
Jpage分页，把分页作为数据层一个功能，把显示层(分页样式)以配置文件独立出来，站在“松散耦合”的高度，让开发如此便捷。

3、基于结果集的分页或基于存储过程。
分页主要有两种方案，一种是基于结果集的指针，一种是基于数据端TOP N的思想。