所谓图文保存与分享理想方案，指的是满足以下要求的放哪：
- 本地化，不依托于云服务
- 格式通用，不同平台可以打开
- 易于理解，自己以后再看也看得明白，分享给别人别人也看得懂
- 配图不被压缩，在保存和传输过程中，图片文件不被修改
- 易于他人修改和上传图片，比如投稿给媒体编辑
Word 和 Markdown 各自的弊端
被使用最多的解决方案应该是 Word。从 Word 直接复制内容发布到公众号的做法应该也是有的，可以说满足了大多数人的大部分需求。但如果处理文档的双方，要求稍微高一点，想更舒服一点，平台还不是公众号，“Word + 公众号”这个组合的弊端就会远大于优势。Word 和公众号是市场胜利而不是产品胜利，大家捏着鼻子在用罢了。
Word 之外，Markdown 因为它的通用性和轻便俘获了不愿在 Word 上讲究的用户群。但它是个纯文本格式，没办法像 Word 那样拖图片上去，并实现所见即所得。
如果你像平常那样拖拽图片到 Markdown，也有一些编辑器可以在预览界面下显示图片。但这时候，这个图片是作为一个外部文件被读取的。它不是像图片在 Word 里一样直接被保存和显示。所以，如果你修改了图片的位置，把它放到了另一个文件夹，预览就会失效。
而且，最关键的是分享。如果使用把图片拖入 Markdown 文档的方法，可以显示图片，但如果分享给别人，别人不会收到这些图片，只能收到代表图片位置的路径文本。
TextBundle 的出现和尴尬局面
为了解决 Markdown 里配图位置变更后失效这个问题，以及它带来的分享问题，出现了一个新的格式，名为 TextBundle。支持 TextBundle 的编辑器可以让你把图片拖到文本文件里的相应位置。它不是像 Markdown 一样保存了一个路径。而是把图片存在了编辑器的库里，来解决你移动图片位置的问题。
在支持 TextBundle 的编辑器里，当你完成了一篇带有配图的文章并将其导出时，你导出的将不是 markdown 文件而是 TextBundle 文件。接收方需要有支持 TextBundle 的编辑器才能将这个文件打开，并在他的设备上看到和你一样的图文排版。
这就是 TextBundle 的功能和尴尬之处。
首先它是一个新的格式，打开它需要支持该格式的编辑器。其次，把这些图片取出来同样不容易。也就是说如果你是把文章发给编辑，让编辑帮你排版上传网站后台，那没比 Word 省事多少。
为什么强调本地
到这，我们讲完了 Word 和基于 Markdown 的 TextBundle 各自的问题。很多人肯定已经按耐不住了，这小问题用图床就能解决。
是的，上传到图床也是很多编辑器的做法。但问题是，图床是归根结底是他人运营的云服务。他人运营的云服务就有运营风险，会出现倒闭的可能。上网时间足够长，看的网页足够多，就会对文章里那些因为图床服务失效而无法显示的配图有足够的印象。
除此之外，图床还有审核风险、隐私风险以及图片压缩等问题。