这是我在15年的使用在一个月的时候我写的一个东西，现在看来其实也是一个次品
代码还留在https://github.com/v-sir/voice--card-for-wechat
但是无论如何我觉得在当初这个探索的过程中，我还是有很多收获的，我现在想重新对当时的这样一个东西进行分析它的优缺点 它的功能方面内我个人觉得就是十分简单的一个操作：
1.向公众号直接发送一段语音
2.公众号返回一张图带有二维码的图片（即语音贺卡；服务器上已经预留了一下已经修理过的图，随机返回一张带上对应的二维码）
公众号可以直接右键扫描这个二维码，进入一个播放器页面
http://card.sky31.com/player.html
这个播放器页面GET请求对应的IMEDIAID的语音地址，进行播放
当时有这样的想法是源于圣诞节将至团队想在圣诞节期间在公众号上推行这一样的有符合节日的东西，我们的PM要求操作的步骤必须是最简单，认为对于用户来说不喜欢过于繁琐的步骤
原理分析：
1.从公众号提取语音文件并在服务器缓存（先从微信的官方接口去下载文件，并缓存）
2.生成带有唯一音频文件识别码的二维码，我存的是一个带有参数的URL
3.简单的图像处理，将二维码和服务器上随机挑选的图片进行适当位置的合并，并把合成的图片返回给公众号（通过微信官方给出回复图片的官方接口）
所以直接的处理的问题其实就是如何生成二维码？如何合并图片（图像处理）？还会遇到的一个问题是其实在H5的播放器并不直接支持微信公众号的音频格式，所以我还做了一个转码的处理。
二维码的生成其实并不是我自己写的，我是通过一个开源的二维码生成库
图片处理主要应用了图像处理的相关函数
https://github.com/v-sir/voice--card-for-wechat/blob/master/img_processing.php
然后我觉得是我做的比较牵强的一个处理就是在 服务器上利用ffmpeg进行转码，为什么说比较牵强的因为微信公众号它的一个安全机制的设置10S没有返回会被切断服务器通信，所以我为了防止超时我在服务器用了crontab进行 定时转码，其实这就会导致一系列的问题，转码可能不完成等系列问题
对于整体的美观来说这种模式其实还是不够吸引人，我们现在可以在很多第三方接入平台看到直接是H5的页面，可能在UI等多方面问题是还是更吸人眼球
