前端方案
实时保存为Base64
用户通过界面操作SVG内容,当生成或者编辑SVG时,实时将SVG内容转换成Base64编码的img标签,塞回到原来的DOM节点中。此种方式在前端通过浏览器就可以完成,无须后端的参与。
方案原理是使用canvas做中转,将svg+xml转换成png。在无需后端参与做二次处理时,可以满足业务场景。
|
|
前端生成png,定时提交到后台
在需要后台做二次处理时,可以借助于上述的前端方案,通过ajax请求定时、实时的将图片上传到服务器。
原理是使用字符串将base64编码的图片实时上传,在后台再做解码生成图片原型,落地到后台。因为需要实时转换和上传,对后端和前端的压力都比较大。
|
|
|
|
后端方案
引入PHP imagemagic扩展
PHP的imagemagic扩展,可以对SVG操作。使用方法也很简单。但因为imagemagic爆出的安全问题,生产环境一直没有装此扩展。对安全性要求不高的业务,可以使用。https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html
|
|
引入batik-rasterizer
batik-rasterizer是Apache基金会下使用Java编写的处理SVG的工具包,要求安装Java 1.6以上的运行时。原理是使用Mozilla Rhino作为JavaScript引擎,生成了一套浏览器环境。https://xmlgraphics.apache.org/batik/tools/rasterizer.html
建议使用最高版本的发布包,高版本对SVG和样式的支持性会更好。目前最新版batik-rasterizer已经支持和外部引用CSS样式,但不支持SVG中foreignObject和通过xmlns=”http://www.w3.org/1999/xhtml"引用HTML标签。
|
|
|
|
其他问题
SVG本身是属于W3C XML的分支,浏览器的实现方式和支持程度也不一样,在后端尤其如此。因为本身的语言标准以及CSS样式控制的问题,导致实际图片和浏览器预览都有差异,往往都需要使用正则对原始SVG文本做hack处理。尤其是后端的两种导出方式。
前端相比后端转换,兼容性和支持性会好很多。当然具体使用那种转换方式,还是需要针对业务场景。