转换网页编码是否会影响 SEO？

按我理解，重新转码，应该会让浏览器认为页面更新了。。然后反而提高了SEO？

错了，让搜索引擎。。

用了，SEO 效果变了，不管是什么原因，肯定先想到你的 utf8…

为啥要尝试改变客户的思维呢？只是编码问题而已。

你的代码中只仅应该出现ANSI里的字符，PHP文件应该保存成ANSI编码的文件，这样无论什么编码都能正常运行（事实上就算你的PHP文件都是UTF-8的也一样，PHP程序文件的编码和输出编码不应该有必然关系）。

剩下的就是MySQL和页面输出编码的问题了，这个完全可以通过正确设定MySQL的输出&链接字符集以及在PHP里用Header设定Body charset=来搞定。

所有也就是几个设定的问题，没必要就这个和客户闹不开心。

前端输出用BIG5，其他全部UTF-8

@raincious

修正不严谨的地方：

- PHP文件应该保存成ANSI编码的文件
+ PHP代码文件应该保存成ANSI编码的文件

貌似很多程序是直接用PHP语言作为模板的，模板文件中如果有非ANSI字符的话，那么文件编码就应该遵守输出编码的约束了。但我个人认为直接用PHP语言作为模板存粹是程序设计有问题（写不出模板引擎还懒得学Smarty）。

@raincious 我就是那个学了 Smarty 还写了自己的模板引擎最后还是用 PHP 做模板的那个人。

很多时候只是大家的分别心罢了。

@shiny

那你得小心了，说不定某天你就看到这样的代码了 :D


来自：
http://www.v2ex.com/t/89039#r_834102

你还回了呢

@raincious 所以需要代码规范，用模板语言照样也能写成这样。

@shiny 这不是OP的主要问题+我知道改变一个即成观点比较难，但是，我觉得用不用模板引擎这效果是立竿见影的。

https://gist.github.com/raincious/a9a7414df096332039ef
（是的，又是我无脑敲的代码）

我倒不是说Smarty好（那么慢而且代码规范和我用的不一样），只是说开发+协作方面的好处。

烫烫烫烫烫烫烫烫烫烫烫烫烫

@raincious
1. 稍作补充：PHP 5.4 无论 short_open_tag 是否 on，已经让 <?= 语法默认可用， http://php.net/manual/zh/ini.core.php#ini.short-open-tag
所以 <?php echo $data['UserName'] ?> 可以简化为 <?= $data['UserName'] ?> （可能PHP官方也注意到了这点）

2. 建议逻辑抽象出来，比如 if (isset($data['Admin']) && $data['Admin'] 可以抽象成 if(is_admin()) ；偶数 highlight 也可以抽象出来，并且做成可复用的插件，也可以提高可读性——而模板语法反而会掩盖此类问题。

3. 我明白你的观点，但也发现引入模板引擎后需要额外处理的问题，比如：
调试模板时增加难度
模板缓存文件的管理
文件夹权限的确保
模板更新时的刷新机制
类似 SAE 不支持的问题

一个小插曲，记得当时写好了模板引擎心头直爽，写 FAQ 的时候不小心列了一个问题：为什么要使用这个模板引擎。
想了半天，就只有一个好处，语法比原生稍微好读一点。


当然，如果协作时无法用非技术手段来解决问题的时候（和不用心的程序员合作），我还是希望引入模板引擎来补救一下。

@raincious 目前我们公司用的「模板引擎」实际上除了语法用 PHP 原生，Template 类该有的方法还是有，对开发很有助益。 :)

@shiny

那么其实还是选择问题，我总归还是选模板引擎的，哪怕是自己一个人的项目。

就你提出的几点：

1、这个没错，确实让模板变得方便了很多。但我其实不觉得这是怂恿别人拿PHP当模板引擎来用。

2、我决定在写模板引擎之前就考虑过使用这种方式。但是最后还是放弃了。我自己的理由是：
A）不能将太多权利交给前端人员，这意味着他们不应该自己定义各种函数和处理方法；
B）通过模板调用任何内部方法都是不安全的，一个模板应该仅仅负责决定数据以何种方式展示，而不应该自己获得数据；

3、是的，
> 模板缓存文件的管理
> 模板更新时的刷新机制
> 类似 SAE 不支持的问题
这些问题是真实存在的。而且解决起来比较复杂：

第一个+第二个：老实说我没有办法优雅的解决当一个数据实体从数据库中删掉之后，它的模板缓存依然存在的问题。这种情况我只能在删除数据实体的方法里手动调用模板缓存文件删除过程，分布式之后这完全就行不通了（因为可能有很多个文件，于是我用Memcache+Eval了）。
还有一个问题是局部缓存刷新，模板的一部分内容需要更新，这个我没解决，模板缓存需要更新时会强制刷新真个模板的缓存。

SAE：事实上可以Memcache+Eval，但是效率低。

> 调试模板时增加难度
这个得看模板引擎怎么具体实现的。Smarty这样比较成熟的模板引擎貌似有调试机制，“轻量级”模板引擎比较难说。我自己的模板引擎反正是有的，虽然不是很完善，但是至少可以告知哪个标记没有合并或者哪个标记的参数格式出错，比如：
https://imgur.com/nTekxXx

> 为什么要使用模板标记引擎
1、使用模板引擎可以让HTML中的代码大幅简化。通过模板中间转换码可以产生标准化代码，促进输出页面的安全性。
2、前端无需了解程序的其他细节，仅依靠更加简单的模板的语法和分配进模板的数据就可以让页面安全的输出，无需考虑何时手动进行无效数据效验等等细节。
3、使用一套模板引擎可以让前端开发人员将注意力集中在HTML和CSS本身的语法和管理上，不需要在一个语法体系（HTML，包括缩进，换行等）中维护另一种语法（PHP，各种<??>，各种if(): foreach():）。
4、编辑器里的颜色更加好看了（重复嵌套的尖括号），现在模板标记……可以统一变成白色了……呢。

另外除了模板引擎的标记，模板本身引擎还能带来这些好处：
1、直接将要输出的内容缓存在模板里：这意味着你可以直接以稍高于include的代价来输出页面，无需调用各种函数和方法来重新产生页面，这样可以使得网站的负载大幅上升。
2、基于上面这条，大部分模板引擎支持部分缓存，让你可以仅仅缓存一部分内容，比如页面通用部分等等。程序仅仅需要调用本页面需要的独特数据就可以产生整个页面。（当然，这回带来缓存失效的问题，双刃剑）
3、以上的管理都可以是自动的，通过参数进行控制，由模板引擎自动处理。可以在一定程度上降低后端程序员的工作量。

我们跑题跑得好远。

@raincious 哈哈哈，是的，安全是一个重要理由，你的模板引擎也很出色。

性能一般瓶颈都出在数据库上（除非以前写Smarty 插件时执行时间按 s 计，不能忍）。「负载（能力）大幅上升」不认同，何况有时候 eval（N年前 smarty 的插件就是好多个 eval 来实现的） 还会让 opcache 之类难以优化。

感谢你的认真回复，对我亦有启发（虽然我还是不去用模板语法嘿嘿嘿，保持代码 KISS）。
楼主该怒了（闪）

@raincious 对了，一个题外话，我青睐那种写法，是因为：DedeCMS 如此流行，和它的模板语法也很有关系。把工作尽量以前端 + 插件方式完成，甚至不需要二次开发就能定制出很多出色效果，同时保持很好的可读性和复用性。