我们公司使用专有的CMS，这个CMS被用于近千个网站，大约有15年的历史了。(它已经进化，但功能非常丰富)
到目前为止，我们一直使用iso-8859-1作为字符集，但有必要在一个项目中使用utf-8。
这是我的问题:
- 你认为这样做是好的吗(维护一个SVN版本，自动转换为utf8搜索/替换有问题的php函数，并在那里做一些魔术)
- 你以前做过这种进化吗，对你来说什么是危险的?
TLDR info:
- 我们的CMS的核心是集中(SVN)和部署(rsync)在我们的每个服务器上的特定路径，这个路径是在每个网站的包含路径。
- 每个项目的数据库不同(但核心表的结构相同)。
- 每个网站使用一个document_root保存网站的具体文件(媒体，js，特定的PHP代码)
在这种配置中，我们不能一次迁移每个网站(即:因为有本地代码)。所以我想做两个版本的核心:一个是iso-8859-1，另一个是utf8。从现在开始，我想我要在我们的部署系统上开发一个脚本，这个脚本将在同步之前创建一个我们核心的utf8编码的副本。
我关心的是例如所有的"mb_"的东西在PHP中不会被调用，所以我必须搜索/替换每一个PHP本地函数替换它的自定义一个将使用"mb_"的版本，如果有必要(此外，这些函数的重载必须在PHP .ini文件，它不能定义在一个特定网站(源)的。htaccess)
PS:对不起，我的英语不好，这不是我的母语:(
我是这样处理的:
- 每个服务器是iso-8859-1或utf-8，并有专用的配置(即:mbstring.func_overload)
- 在每次部署脚本之前，创建一个iso版本的副本并将其转换为utf8
- 每个服务器获得utf-8或iso-8859-1源代码
对于每个单独的CMS，存在一个转换工具，它转换文件系统，数据库字符集/排序，配置(即:连接到mysql与utf8)， ....
对于不兼容的函数，如utf8_encode，我搜索/替换为一个函数谁负责不调用函数，如果服务器是utf8