DEVICE=eth0 #描述网卡对应的设备别名，例如ifcfg-eth0的文件中它为eth0
BOOTPROTO=static #设置网卡获得ip地址的方式，可能的选项为static，dhcp或bootp，分别对应静态指定的 ip地址，通过dhcp协议获得的ip地址，通过bootp协议获得的ip地址
BROADCAST=192.168.0.255 #对应的子网广播地址
HWADDR=00:07:E9:05:E8:B4 #对应的网卡物理地址

IPADDR=12.168.0.33 #如果设置网卡获得 ip地址的方式为静态指定，此字段就指定了网卡对应的ip地址
NETMASK=255.255.255.0 #网卡对应的网络掩码
NETWORK=192.168.0.0 #网卡对应的网络地址

然后重启network就可以了。 service network start;

<td width=”90″>发布选项：</td>
<td> <input name=”ishtml” type=”radio” value=”1″ checked>
生成HTML
<input name=”ishtml” type=”radio” value=”0″>
仅动态浏览</td>
修改为：

<td width=”90″>发布选项：</td>
<td> <input name=”ishtml” type=”radio” value=”1″>
生成HTML
<input name=”ishtml” type=”radio” value=”0″ checked>
仅动态浏览</td>
刷新一下发布文章页面看看可以了不！用DW可以很直观的修改。
2.如何批量修改动态发布为静态生成，或者反过来修改。
用phpmyadmin打开dede_dede_archives 这个表
ismake这个字段就是我们要修改的对象。
运行sql语句：

UPDATE  dede_archives SET  ismake = ‘-1′  修改所有文档为动态浏览

UPDATE  dede_archives SET  ismake = ’1′   修改所有文档为静态发布
这样就可以了
2.修改火车登录的静态页面发布和动态生成。火车采集入库的时候如果直接静态发布是很占CPU的，动态发布就会好很多！
先下载一个火车的dede登录模块！很多地方可以下
在WEB发布那里修改模块；
选择文章发布参数，发表POST数据那里修改ishtml=0为动态发布，ishtml=1为静态发布。
菜鸟写的教程，测试都是可行的。有高手还请指正。

2. 商业需求
说明：
不合理的需求导致资源的投入与产出成反比，开发人员有必要对产品提出的需求进行评估，对不影响大局或者可有可无的功能与产品进行协商，商讨是否可以放弃该功能或者适当修改功能。

实例：
产品提出论坛帖子总数实时更新，当前论坛情况是用户量庞大，同时帖子更新频繁。如果要做到实时，必须每次发帖后同时更新统计表数据(假设统计数据全部存储在统计表里面)。如果一秒内帖子产生很多，由于并发问题导致统计数据并不正确，由于如果有锁资源争用，造成性能下降。

解决方案：
跟产品讨论数据其实可以不那么实时，没有哪个无聊的人会发完帖子，盯着论坛的帖子数研究总数是否增加，即时不准确也不会影响用户的实际操作。把实时功能去掉后，可以做一个定时任务(SHELL或者用户触发皆可)，系统每5分钟跑一次，更新掉论坛帖子数即可，这样最直接的结果是减少了大量由于更新产生的query语句。
事实像类似DZ这样的开源项目都是不做实时的，甚至帖子的回复数都不是实时准确的，它是每发表一个回复，插入统计缓存，系统定时批量执行这些要更新的数据。

思考：
大家曾见过淘宝的分页，它并没有列出总共多少页，而是用户点击的附近几页，这样其实节省了select count(*) 的操作(innodb引擎做这个 跟myisam引擎做这个不在同一个概念，所以对于总数据庞大分页的东西其实可以修改分页方式，比如搜索结果)

PS:
无用功能堆积导致系统复杂
开发中经常会遇到做了的一些功能不需要啦，导致出现无用的代码和无用的数据表，应该在确认之后，及时对这些功能下线，可以备份一次数据即可

3. 数据表(schema)设计
Schema设计实质反映了一个项目的实际需求，是项目中的存储数据的一个体现，基本上我们看了数据表，大体知道这个项目在做什么。但在设计的同时需要考虑到基本业务逻辑所需要的QUERY操作以及由此产生的性能问题。

1) 适度冗余，减少JOIN操作
说明：
这个其实是反范式的操作，schema设计时不能完全遵照范式，范式的目的是减少冗余。 但适当的冗余对性能是有不少的提升。

实例：
记录论坛版块最后的发帖人以及发帖时间，这个可以通过在帖子表里面进行查询(select * from posts where pid = ‘’ order by dateline desc) , 但如果在版块表设计两个字段last_post_member last_post_time, 则可以减少查询次数，一次取出数据。虽然更新（对于频繁的更新，我们同样使用定时任务操作）要导致数据表的写操作，但相对更新，查询显然更加频繁。

2) 大表水平拆分
说明：
跟适当冗余相反，大表水平拆分则是根据表里面数据读取的频繁度将一张表分成多张。

实例：
大家见过许多开源项目，基本上用户数据存储在两张或者更多的表中，比如bbs_member (主表) bbs_memberfields(从表)，主表存储读写比较多的字段(一般都是定长字段，比如username、password、groups)，而从表存储的是读写相对少的字段(比如qq msn 以及存数容量比较大的数据,比如text类型的数据)

3) 合适的数据类型
说明：更小的数据类型让数据库以更小的空间存储相同的数据量，这样直接较少IO的消耗。 特别是对于要进行比较或者排序的字段应该选用更为迅速的字段类型，从而节省CPU的消耗。

4) 创建合适的索引(单独做一节介绍)

总结：
所以我们在表的设计的时候，需要考虑到我们有多大的用户量(包括一个较为长远的考虑)，考虑哪些query执行得更加频繁，从而给出相应的优化方案。

4. 索引(index)设计
1）索引类型：
B-tree ()
Myisam 主键就是聚集索引
聚集索引（数据表的物理存储顺序和表的逻辑存储顺序一致）
非聚集索引：。。。
InnoDB表会包含一个聚集索引
一般是按照下面的规则来设定聚集索引的：
1，假如表包含PRIMARY KEY，InnoDB使用它作为聚集索引
2，假如表没有定义PRIMARY KEY，InnoDB将第一个只包含NOT NULL属性列的UNIQUE index作为主键并且将它设置为聚集索引
3，前两者都不满足的时候，mysql就增加一个隐藏的autocreament

HASH （仅仅memory和 ndb引擎支持)
full-text （仅仅myisam支持，并且只支持 char varchar text三种数据类型)
r-tree

2）索引用途：
# 提高数据表检索效率
# 降低数据排序成本（排序主要消耗cpu和内存， 对于分组操作同样是先排序后分组）

2）如何判定 是否建立索引：
# 只有在操作频繁的字段建立索引，绝不建不必要或者想当然的索引，这个在设计表的时候要能大致估计SQL要怎么写。

# 唯一性太差的字段不建立索引，基本上当一条QUERY返回的数据占15%以上就不适合建立索引(通常的像像性别这样的字段绝对不建立索引)

# 更新频繁的字段不建立索引。更新表数据的时候同时要更新索引数据，导致IO访问增大以及影响整个存储系统的消耗。(如果查询更新都较多的情况下，则要比较查询与更新的比例，当比例较大的时候，更新附带的成本是可以接受的)

3) 单键索引和联合索引
# 当where语句的过滤条件比较多的时候，考虑几个字段同时出现的频繁度，对频繁度出现较高的字段集建立联合索引。

# 联合索引的缺点是多个字段同时存在，更新可能性更高，索引存储长度也越大。但就查询角度来讲这个因为它过滤掉更多的数据，所以效率更高。同时比在多个字段都建立单键索引效果好（因为mysql query optimizer需要将多个索引 index_merge 成本更高，有时候还会放弃其他索引）

# 联合索引左前缀原则
使用最左（leftmost）前缀。建立多列复合索引的时候，你实际上建立了MySQL可以使用的多个索引。复合索引可以作为多个索引使用，因为索引中 最左边的列集合都可以用于匹配数据行。这种列集合被称为”最左前缀”（它与索引某个列的前缀不同，那种索引把某个列的前面几个字符作为索引值）。

假设你在表的state、city和zip数据列上建立了复合索引。索引中的数据行按照state/city/zip次序排列，因此它们也会自动地按照 state/city和state次序排列。这意味着，即使你在查询中只指定了state值，或者指定state和city值，MySQL也可以使用这个 索引。因此，这个索引可以被用于搜索如下所示的数据列组合：
state, city, zip
state, city
state

MySQL不能利用这个索引来搜索没有包含在最左前缀的内容。例如，如果你按照city 或zip来搜索，就不会使用到这个索引。如果你搜索给定的 state和具体的ZIP代码（索引的1和3列），该索引也是不能用于这种组合值的，尽管MySQL可以利用索引来查找匹配的state从而缩小搜索的范 围。

# 前缀索引(只使用某个字段前面部分内容作为索引键索引该字段)
4) MYSQL索引限制
# 索引键长度总和不超过1000字节
# BLOB TEXT类型列只创建前缀索引
# 不支持函数索引
# 使用(!= <> )的时候, mysql不支持索引
# 过滤字段使用了函数运算(如abs() ) 等，不支持索引
# join语句中JOIN字段类型不一致，不支持索引
# LIKE语句中以(‘%abc’)开始，不支持索引
# 非等值查询时，不支持HASH索引

5) JOIN语句优化
# 永远用小结果集驱动大结果集（资源消耗存在较大区别外），比如A B联查，
A过滤后 10rows
B过滤后 20rows
A作为驱动表，JOIN过滤则为10次
B作为驱动表，JOIN过滤则为20次
所以选择结果集小的作驱动表

# join字段优化，保证每次查询节省资源

6）ORDER BY、 GROUP BY、 DISTINCT优化
原理都需要进行排序，除对字段索引外，需要去掉不必要的返回字段，节省内存(排序的原则)

5. QUERY语句优化
优化10原则：
1）优化更需要的优化
说明：执行对系统影响更大的QUERY，一般指的是高并发，执行更加频繁的SQL）

2）定位优化对象性能瓶颈
3）明确优化目标
4）explain
5）profule
6）小结果集驱动大结果集
7）尽可能在索引中完成排序
8）只取自己需要的字段
9）仅仅使用最有效的过滤条件
10）尽可能避免复杂的JOIN和子查询

6. 实例分析
Demo1：过度弱化query造成性能消耗
Table1: users表(user_id, user_name, last_feed_time)
Table2: feeds表(feed_id, user_id, feed_data, dateline)
显然users表与feeds表是一对多的关系，现在要查询最近有动作的10个用户，同时在列表页要显示该用户最近24小时的动作。

解决方法1：
// 得到10个最近有动作的用户
$sql = ‘SELECT user_id, user_name
FROM users ORDER BY last_feed_time DESC limit 10’;

// PHP获得10条数据 $rs

// 循环query查询对应ID的最近三个动作
foreach($rs as $k=>$v) {
$sql = “SELECT feed_data
FROM feeds WHERE user_id = ‘{$v[‘user_id’]}’ AND dateline <’’ ORDER BY dateline DESC “;
}

解决方法2：
// 同第一步

// 查询10个用户最近24小时动作
$sql = “SELECT user_id, feed_data
FROM feeds WHERE user_id IN () AND dateline < ‘’ ORDER BY dateline DESC ”:

// 数组组装

总结：我们在开发中经常碰到一些二级栏目的列表页，但数据来自不同的数据表，通常的做法是循环里面执行query，殊不知这样增加了QUERY的次数，而每次QUERY都需要MYSQL进行解析，在这种情况下，宁愿QUERY复杂点或者在程序端复杂点，保证性能。而从另一个理论来讲，这种情况属于弱化了QUERY造成性能问题。

Demo2：过度依赖query造成性能消耗
Table1: users表(user_id, user_name)
Table2: user_profile表(user_id, profile_data)
Table3: users_group表(id, group_id, user_id, level)
现在要查询群组ID为1的群组成员信息以及群主的详细信息。
解决方法1：
// 一次查询所有信息
SELECT u.user_name, up.profile_data
FROM users_group ug LEFT JOIN users u ON ug.user_id = u.user_id LEFT JOIN users_profile up ON u.user_id = up.user_id
WHERE ug.group_id = ‘1’

解决方法2：
// 先查询群组下用户的基本信息
SELECT u.user_id, u.user_name,
FROM users_group ug LEFT JOIN users u ON ug.user_id = u.user_id
WHERE ug.group_id = ‘1’
// 查群主信息
SELECT *
FROM users_profile WHERE user_id = ‘’;

总结：与上例相反，这个DEMO操作是增加一个query减少不必要的访问(只需要群主的详细信息，而profile存储的是数据类型比较大的数据，这样操作减少的是IO的访问)

Demo3：小结果集驱动大结果集
Table1: users表(user_id, user_name, sex)
Table3: users_group表(id, group_id, user_id, level, join_time)
现在要查询某个群组下面(id = 1)用户的名称和性别，按加入时间倒序取100-120条的记录

解决方法1：
SELECT u.user_id, u.username, u.sex
FROM users_group ug LEFT JOIN users u ON ug.user_id = u.user_id
WHERE ug.group_id = ‘1’ ORDER BY ug.join_time DESC LIMIT 100,120;

解决方法2：
SELECT u.user_id, u.username, u.sex
FROM （
SELECT user_id
FROM user_group
WHERE user_group.group_id = 1
ORDER BY join_time DESC
LIMIT 100,20) ug, user
WHERE ug.user_id = user.user_id;

总结：方法1参与join操作的是全部user_group中group_id = 1的数据、而方法2 参与join操作的数据仅仅是过滤过的20条数据。所以SQL优化永远记住小结果集驱动大结果集，节省的是CPU和IO的消耗。

BIT数据类型保存位字段值，并且支持MyISAM、MEMORY、InnoDB和BDB表。

作为SQL标准的扩展，MySQL也支持整数类型TINYINT、MEDIUMINT和BIGINT。下面的表显示了需要的每个整数类型的存储和范围。

当使用日期和时间类型时应记住以下几点：

·         MySQL以标准输出格式检索给定日期或时间类型的值，但它尽力解释你指定的各种输入值格式(例如，当你指定一个分配给或与日期或时间类型进行比较的值时)。只支持下面章节中描述的格式。期望你能提供有效值。如果你使用其它格式的值会发生意想不到的结果。

·         包含两位年值的日期会令人模糊，因为世纪不知道。MySQL使用以下规则解释两位年值：

o        70-99范围的年值转换为1970-1999。

o        00-69范围的年值转换为2000-2069。

·         尽管MySQL尝试解释几种格式的值，日期总是以年-月-日顺序(例如，’98-09-04′)，而不是其它地方常用的月-日-年或日-月-年顺序(例如，’09-04-98′，’04-09-98′)。

·         如果值用于数值上下文中，MySQL自动将日期或时间类型的值转换为数字，反之亦然。

·         当 MySQL遇到一个日期或时间类型的超出范围或对于该类型不合法的值时(如本节开始所描述)，它将该值转换为该类的“零”值。一个例外是超出范围的TIME值被裁剪到TIME范围的相应端点。

下面的表显示了各类“零”值的格式。请注意如果启用NO_ZERO_DATE SQL模式，使用这些值会产生警告。

CHAR和VARCHAR类型类似，但它们保存和检索的方式不同。它们的最大长度和是否尾部空格被保留等方面也不同。在存储或检索过程中不进行大小写转换。

CHAR和VARCHAR类型声明的长度表示你想要保存的最大字符数。例如，CHAR(30)可以占用30个字符。

CHAR列的长度固定为创建表时声明的长度。长度可以为从0到255的任何值。当保存CHAR值时，在它们的右边填充空格以达到指定的长度。当检索到CHAR值时，尾部的空格被删除掉。在存储或检索过程中不进行大小写转换。

VARCHAR列中的值为可变长字符串。长度可以指定为0到65,535之间的值。(VARCHAR的最大有效长度由最大行大小和使用的字符集确定。整体最大长度是65,532字节）。

同CHAR对比，VARCHAR值保存时只保存需要的字符数，另加一个字节来记录长度(如果列声明的长度超过255，则使用两个字节)。

VARCHAR值保存时不进行填充。当值保存和检索时尾部的空格仍保留，符合标准SQL。

如果分配给CHAR或VARCHAR列的值超过列的最大长度，则对值进行裁剪以使其适合。如果被裁掉的字符不是空格，则会产生一条警告。如果裁剪非空格字符，则会造成错误(而不是警告)并通过使用严格SQL模式禁用值的插入。参见5.3.2节，“SQL服务器模式”。

下面的表显示了将各种字符串值保存到CHAR(4)和VARCHAR(4)列后的结果，说明了CHAR和VARCHAR之间的差别：

二、把id_rsa.pub文件拷贝到remote主机的用户目录下 然后再运行如下命令
cat id_rsa.pub >~/.ssh/authorized_keys
它将在/root/.ssh/目录下面生成authorized_keys这个文件
[root@server2 .ssh]# ssh remotehost
Enter passphrase for key ‘/root/.ssh/id_rsa’:    ###输的是私钥的密码，而不是server端的密码###
但这只是以root身份登录才会免密码，如果以其他用户身份登录还是会要求输入密码，不用以上密码加密和解密的过程。

三、ssh-agent（客户端上)
通过上面的实验我们发现虽然加了私钥密码很安全，但是每次连接都要输私钥密码就会很麻烦，所以可以通过代理的方式使私钥只要解密一次，就会把它加载在内存里，以后登录的时候就不用输入密码了
但这只在该新起的shell中生效
[root@server2 .ssh]# ssh-agent /bin/bash
[root@server2 .ssh]# ssh-add    ###将私钥导入内存，输入解密密码###
Enter passphrase for /root/.ssh/id_rsa:
Identity added: /root/.ssh/id_rsa (/root/.ssh/id_rsa)
四、scp自动备份：
scp  root@remote:/home/backup/*  /home/backup/

它的高性能主要体现在高速度的运算能力、长时间的可靠运行、强大的外部数据吞吐能力等方面。

服务器服务器的构成与微机基本相似，有处理器、硬盘、内存、系统总线等，它们是针对具体的网络应用特别制定的，因而服务器与微机在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面存在差异很大。服务器外型有以下3种

实际上是工业标准化下的产品，其外观按照统一标准来设计，配合机柜统一使用，以满足企业的服务器密集部署需求。机架服务器的主要作用是为节省空间，由于能够将多台服务器装到一个机柜上，不仅可以占用更小的空间，而且也便于统一管理。　机架服务器的宽度为１９英寸，高度以Ｕ为单位（１Ｕ＝１。７５英寸＝４４。４５毫米），通常有１Ｕ，２Ｕ，３Ｕ，４Ｕ，５Ｕ，７Ｕ几种标准的服务器。

这种服务器的优点是占用空间小，而且便于统一管理，但由于内部空间限制，扩充性较受限制，例如１Ｕ的服务器大都只有１到２个ＰＣＩ扩充槽。此外，散热性能也是一个需要注意的问题，此外还需要有机柜等设备，因此这种服务器多用于服务器数量较多的大型企业使用，也有不少企业采用这种类型的服务器，但将服务器交付给专门的服务器托管机构来托管，尤其是目前很多网站的服务器都采用这种方式。

这种服务器由于在扩展性和散热问题上受到限制，因而单机性能比较有限，应用范围也受到一定限制，往往只专注于某在方面的应用，如远程存储和网络服务等。

在价格方面，机架式服务器一般比同等配置的塔式服务器贵上二到三成。

塔式服务器一般是大家见得最多的，它的外形及结构都与普通的ＰＣ机差不多，只是个头稍大一些，其外形尺寸并无统一标准。

塔式服务器的主板扩展性较强，插槽也很多，而且塔式服务器的机箱内部往往会预留很多空间，以便进行硬盘，电源等的冗余扩展。这种服务器无需额外设备，对放置空间没多少要求，并且具有良好的可扩展性，配置也能够很高，因而应用范围非常广泛，可以满足一般常见的服务器应用需求。

这种类型服务器尤其适合常见的入门级和工作组级服务器应用，而且成本比较低，性能能满足大部分中小企业用户的要求，目前的市场需求空间还是很大的。

但这种类型服务器也有不少局限性，在需要采用多台服务器同时工作以满足较高的服务器应用需求时，由于其个体比较大，占用空间多，也不方便管理，便显得很不适合。

刀片服务器是一种ＨＡＨＤ（Ｈｉｇｈ　Ａｖａｉｌａｂｉｌｉｔｙ　Ｈｉｇｈ　Ｄｅｎｓｉｔｙ，高可用高密度）的低成本服务器平台，是专门为特殊应用行业和高密度计算机环境设计的，其主要结构为一大型主体机箱，内部可插上许多“刀片”，其中每一块刀片实际上就是一块系统母板，类似于一个个独立的服务器，它们可以通过本地硬盘启动自己的操作系统。每一块刀片可以运行自己的系统，服务于指定的不同用户群，相互之间没有关联。而且，也可以用系统软件将这些主板集合成一个服务器集群。在集群模式下，所有的刀片可以连接起来提供高速的网络环境，共享资源，为相同的用户群服务。在集群中插入新的刀片，就可以提高整体性能。而由于每块刀片都是热插拔的，所以，系统可以轻松地进行替换，并且将维护时间减少到最小。

刀片服务器比机架式服务器更节省空间，同时，散热问题也更突出，往往要在机箱内装上大型强力风扇来散热。此型服务器虽然空间较节省，但是其机柜与刀片价格都不低，一般应用于大型的数据中心或者需要大规模计算的领域，如银行电信金融行业以及互联网数据中心等。

目前，节约空间、便于集中管理、易于扩展和提供不间断的服务，成为对下一代服务器的新要求，而刀片服务器正好能满足这一需求，因而刀片服务器市场需求正不断扩大，具有良好的市场前景。

安 全表现在：首先，不需要通过网络传输ssh key，其次，ssh key是经过加密后保存的，即使让人偷了还需要有加密串才能解密。相反，如果密码被偷了，可以直接用来登陆的。这样还可以避免别人对我们的ssh服务器进 行暴力破解。当然有人通过修改ssh默认端口，但是这根本不能起到多大的作用。端口扫描工具很容易就能查到你的开放端口。

我 们这边提到的ssh key实际上是一对key，分别保存在两个文件中。其中私钥也就是我们所谓的密钥保存在客户端的机器上，并使用密窜加密。而公钥则存储在服务器上。在创建 ssh链接时，客户端和服务端之间使用公钥和私钥进行协商，如果它们之间匹配（当然是在加密状态下），则成功创建链接。

了解了基本的过程之后实现起来就不难了。我们需要做的是：
１.生成公钥私钥对相应的文件并分别放到客户端和服务端
$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user1/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user1/.ssh/id_dsa.
Your public key has been saved in /home/user1/.ssh/id_dsa.pub.
The key fingerprint is:
4c:92:e9:88:35:ed:b5:81:ab:6f:97:d5:50:e6:7a:75

其中id_sda是私钥，id_dsa.pub是公钥。
你现在可以通过ftp或scp将公钥传到远程的ssh服务器上。
scp id_sda.pub remote_login@remote_server
(当然，现在你们还是使用密码认证，而不是公钥认证，还没完成呢）

２.远程登陆到ssh服务器
ssh -l remote_login remote_server
在远程服务器上的用户当前目录，看看有没有.ssh目录，通常都会有的，如果没有，则创建。
remotehost$ mkdir -p ~/.ssh
remotehost$ chmod 700 ~/.ssh
把公钥文件id_dsa.pub 的内容附加到 ~/.ssh/authorized_keys
remotehost$ cat id_dsa.pub >> ~/.ssh/authorized_keys
remotehost$ chmod 600 ~/.ssh/authorized_keys

3.配置ssh服务器，允许客户端通过 public-key authentication来登陆
用vim打开ssh服务器的配置文件查看PubkeyAuthentication 配置是不是yes,如果不是则修改并重起sshd守护进程
/etc/ssh/sshd_config:
PubkeyAuthentication yes
之后就你可以通过public-key authentication来访问ssh服务器了。如果登陆失败，则可以在运行ssh时加上-v选项来查看失败的具体原因。

如果你的客户端是在window下使用的,那么你需要使用putty-gen来生成

LoadFile “D:/Wamp/php-5.2.10/libmysql.dll”
LoadFile “D:/Wamp/php-5.2.10//libmhash.dll”

按上面说的方法，操作后仍未解决问题。看一下你的PHP版本是不是5.2.14。因为PHP5.2.14这个版本的curl模块本身就有bug。由果是的话建议你更换PHP版本，下载其他版本。然后按照上说的再重新操作一下。重启APACHE服务，问题解决。你就随心所欲的使用php_curl抓取网页。如果您看到现在还依然未解决，那可能又是另一种情况了，不妨留言一起研究下。

原因: 编码的问题呀。我网站的编码是GBK的，而Smarty是UTF-8的。

解决方法：打开Smarty.class.php文件，找到define(‘SMARTY_RESOURCE_CHAR_SET’, SMARTY_MBSTRING ? ‘UTF-8′ : ‘ISO-8859-1′);修改为define(‘SMARTY_RESOURCE_CHAR_SET’, SMARTY_MBSTRING ? ‘GB2312′ : ‘ISO-8859-1′);问题解决了。

总结：由于大多数PHP框架，或者模板引擎都是UTF-8。我们开发网站最好也用UTF-8编码，这样就不会遇到编码的烦恼了。