数据库中某字段的部分内容有问题需要更正，由于业务已经上线由用户数据在内不方便重新导入。但如果手动逐条修改的话会累死个人。

查了下直接用 mysql 内建的字符串函数 replace() 可以解决问题,手册说明如下

REPLACE(str,from_str,to_str) 

Returns the string str with all occurrences of the string from_str replaced by the string to_str. REPLACE() performs a case-sensitive match when searching for from_str. 

mysql> SELECT REPLACE('www.mysql.com', 'w', 'Ww');
        -> 'WwWwWw.mysql.com'
This function is multi-byte safe. 

用法不复杂，和php /js内的方法相似

以下是执行替换的sql

UPDATE `quiz_question` SET `question`= REAPLCE(`question`, ' ', '_');

嗯，是的，就是把空格替换成下划线，因为显示在html中空格会被忽略掉，导致填空位置显示不清晰。

一句sql省下用python/php 取出来再重新写入的功夫。
PEACE!

自从网易博客玩球后，改用 Typecho 写日志已经有一段时间。可能我要求比较低，一直满意。

心血来潮想加个日历插件在右侧栏上, 搜了下现有的插件emmm ...只有一个2016年的版本，功能比较简陋就真的只显示个月历而已。
眼看博客程序已经3年没有更新，估计是指望不上别人自己动手改造一个。
看了一下 Typecho的插件开发说明，嫌麻烦。还是按自己熟悉的粗暴手法来强行嫁接吧！

最终效果如图（如果没出错的话应该在页面右边已经看到实物了）

我要实现的功能不多

1. 要能显示月历，能前后翻月
2. 样式要简洁，不突兀，与界面低调融合在一起
3. 要标记有博客的日期，点上去的话要切换到当天
4. 如果从下面按月归档的链接点进去的话，日历要跟随切换到当前月份

想了下，我用过的layDate日历插件应该能满足这个需求，也是一个已经3、4年没有更新的项目正好凑一对。
下面开干！

- 阅读剩余部分 -

用chrome从甲方提供的网页上保存了一批图片素材用于制作H5活动页。发布后反馈iOS上部分图片不显示，自己测试确实如此，找微信客服也抓头没办法解决只给了一些常规套路让我检查是不是文件太大，路径有中文、文件名大小写之类的问题。

最离谱的是 图片url直接在微信里也是打不开的，用图像处理软件处理过（tinypng压缩）也还是不显示。但是在安卓和PC端的开发工具上显示则正常。

情况实在太诡异，最后用文本工具直接打开图片，看到头部 RIFF ... WEBPVP8 ！！！ 恍然大悟

Chrome保存的时候帮我转换成了 webp?!

试试直接在 Safari 里打开有问题的素材url ，果然是iOS自身不支持webp，也不能显示。

解决办法无他，webp-> jpeg/png 替换掉原素材，完事！

这个问题其实早在2016年已经遇到，在2018年知道原因盖棺定论。近日项目重新触及，备忘一下。

从jssdk或scope接口获得用户信息内的头像链接，如果直接用php的 file_get_contents 请求的话，通常会非常的慢，脚本运行大约30秒之后才能加载出图像。如果请求量大非常容易造成服务器的堵塞。

原因

摘录另一网友的日志：
https://www.cnblogs.com/mysic/p/5421754.html

微信的服务器对头像的资源请求返回的头信息是 Connection: keep-alive ，于是请求传输完数据后就一直在干等超时。
网上对这个问题求助的也不在少数，不知道腾讯是故意为之还是装作不知道，反正问题存在至今没有主动解决。

解决办法：

自欺欺人的解决办法：
这是我最早期的解决思路，在发起请求或者获得用户头像资源的最初即在后台预载这个资源到本地缓存，降低用户对等待延迟的感知。

老实人的解决办法：
改用curl请求到本地缓存处理，加上header，下载完主动截断链接。代码演示略

无效的解决办法:
给file_get_contents() 设置第三参数 context 指定关闭链接，设置了参数后，腾讯返回过来的是0字节的数据。我觉得它们故意的嫌疑更大了！

//实验证明 context 无效，会导致返回0字节
$context = stream_context_create(
    array("http" => 
        array(
            'method'=>'get',
            'header'=>'Connection: close\r\n'
        )
    )
);
$tmp_face_data = file_get_contents($face_url, false, $context);

目前在用的解决办法：

ini_set('default_socket_timeout', 1);
$tmp_face_data = file_get_contents($face_url);

也不是没有缺点，一个小小的瑕疵是要浪费额外的1秒等timeout，不过还可以接受。
另外有一个优点，这个参数不但对 file_get_contents 有效，对于 getimagesize 这个没有context参数的方法也有帮助
所以，一劳永逸。

结论：

腾信真TM会恶心人！

奇怪的错误，虽然表格内容有点大，2万多行50多列。但单线程理应不会吃掉128M内存

试过代码中非常保守地注销不必要的对象管控内存，依然不行。

解决方法：做了一个激进的预设

ini_set('memory_limit', '1024M');

终于运行通过了。
导出的xlsx文件只有2M，百思不得其解，不该吃掉128M内存啊？