目前总结：
1.跨平台跨地区的P4V客户端会导致非unicode mode的P4服务器在存储时产生乱码
2.P4服务器本身的db中有乱码的话，打出来的checkpoint也有乱码，在进行转码时，切莫用高级的编辑器一锅端，一定要注意乱码的实际情况是什么。如果是文件或路径，可以对照Versioned files修改，如果是changelist details，可以考虑使用脚本对乱码做无视或者换成？等操作。
==================================================================
趁着假期终于可以停服做Perforce维护，打算做三件事
1.迁移硬盘
2.升级Perforce服务器版本
3.打开unicode mode
本以为一两天能搞定的事，现在已经5号了，还没有搞定，而且也不确定什么时候能搞定，这一番下来心情真是五味杂陈，于是决定记录一下。
1号，用Rsync同步新旧服务器的文件
2号，先给服务器版本升级，打checkpoint然后还原DB，用来清理旧的DB文件。然后按文档推荐的用iconv给Checkpoint文件转编码，查到可以配合file命令来查看源文件的编码，发现是ISO-8859，于是用iconv -f ISO-8859-1 -t UTF-8 checkpoint > checkpoint.utf8进行转码，然后按文档步骤切换至unicode模式，结果发现Description都乱码，写了个脚本对乱码进行解码再编码，更新changelist，然后发现文件也乱码，中文名的太多，需要P4的db和versioned file一一对应才行，无解。
3号，于是开始思考是否转编码出了问题，先试了vim，于是觉得是iconv的问题，打算用vim来转码，但不知道是不是文件太大（90G+），转换失败。又换到ultraedit打开文件，转码也成功，于是又开始切换unicode mode的步骤，结果切换失败，报错是无法解析文件内容之类的，网上搜索无果。
4号，几番尝试，最后确认应该是ultraedit这类编辑器会无视一个GBK文件中的非GBK的字符，然后强行转换，导致转出来的utf8中有乱码存在，p4无法解析，为iconv洗白，说明不是file判断的编码不对，而是这个打出来的Checkpoint文件本身就有诸多编码问题，于是打算用iconv来定位出错的行数，去手动修正checkpoint中的非GBK字符，但文件真的太大了，90G+每次打开保存都要很久，一天过去了，还没有修正，睡前开始尝试能不能把大文本切成若干小文本，通过脚本判断哪些小文本中有问题的字符，然后只处理这些有问题的。
5号，开始修正几个小文件中的非GBK字符，发现有的是文件路径乱码了，有的是changelist描述乱码了，本以为逐一修正即可，却发现Changelist描述有问题的很多，改了一下午没改完，这里面又分为两类，第一类是完整描述中本来就有乱码的，定位到几个手动修改了，第二类比较麻烦，p4有一条命令行是p4 changes，默认情况下只会显示每条Changelist的被截取后的Short description，怀疑是不是因为中文是两个字符，P4在截取时按长度截取，可能正好截图到某个中文的一半，导致P4存了一个乱码的字符，如果是这样，那么checkpoint中有问题的地方会非常多，因为Changelist的description中有一大半是包含中文的，为了证明猜测，去命令里试着对有问题的Changelist跑了一下p4 changes，发现那个short description果然结尾处是一个问号，看起来非常像是对于乱码的自动处理。于是决定先在P4上直接修正第一类，然后重新打checkpoint，切割成小文件，打到有文件路径乱码的手动修改，然后对剩下的是short description乱码的，直接用python自动转码+ignore errors处理。
原文：https://www.cnblogs.com/sasafly/p/13770569.html