询问下关于日志显示的问题
如上所示
之前有见过好友发日志也是这种情况
标题无法显示，就是只能点击评论或者进入该BLOG后点击日志查看才行
不知道这是怎么回事
标题起得太长了吗——应该不是吧
点击日志后才能查看的情况 ……可能想保持一点神秘感吧……？ 因为作品通关的原因
重新写了评测上去
——所以改了下标题
代码问题解决，好神奇 看起来感觉跟首字是否英文或外文有关系 啥时候再出现这种问题把链接发给我看看吧。 怎么我印象中是设了好友可见的文章就会变成这样……？ 6# 狐
當時設置的是全站可見的
嗯 专业点说的话，UCenter在把日志的标题与索引内容提取出来的时候，因为序列化函数的问题，导致中文字符有一定几率会被序列化丢失。
再详细一些的话，UCenter虽然有分编码版本（比如300里面用的是GBK大字符集版），但是实际上源代码所用的字符串的字符集在不同的地方不一样，有些地方是GBK（或者是UTF-8，如果用的是这个版本的话），有些地方则是根据客户端所用的语言来决定字符集（就是ANSI，这不是一个定死的字符集）。
当一个日志被发表的时候，由于代码内传递字符串的时候可能进行了转换，当进行序列化的时候，因为没有正确地进行url编码，有可能双方采用的字符集都是靠通过文字推测，会导致不一致，这样传到浏览器这边的时候，不管是标题还是内容都会因为字符集不同，出现乱码而被PREG_REPLACE替换成了空字符串，结果就是显示类似于{subject}的占位符。
这种情况经常会出现在不同语种的文字混用的情况下，比如英文和中文，中文和日文，甚至简体中文和繁体中文里面。要解决的话需要修改源代码，在序列化这两块内容之前，使用urlencode函数将它们编码成%3E这种十六进制形式，反序列化之前用urldecode进行解码，这样在序列化过程中传输的都是ASCII字符，就不会出现字符集不一致导致文字丢失的情况发生。
我想UCenter之所以会这样是因为开发者觉得HTTP POST数据不会通过URL传输，因而一般不会出问题的缘故。但是UCenter的好几处地方都用的不是统一的字符集，字符串编码转换很难避免。
页:
[1]