markdown to HTML with customised WMD editor_问答_开发者

For my application I customized slightly the way WMD behaves so when user enters empty lines, these are reflected in HTML output as <br />'s. Now I came to a point when I should store it somewhere at backend and so after going thru SO posts for a while I'm not sure what is the best way to do it. I have few options and if you could point out which their pros/cons that would be much appreciated.

send to server and store as markdown rather than HTML. To me obvious advantage would be keeping exactly same formatting as user originally entered. But then how can I convert it back to HTML for display to a client? It seems very troublesome to convert it on client side as even if it would be possible what would happen if JS would be disabled? If I wanted to do it on the server, then standard server side implementations of markup to HTML might be resource expensive. Would that be an issue in your opinion? Even if it wouldn't be the case then as I mentioned my WMD implementation is customised and those server side solutions wouldn't probably do the right conversion to markdown anyway and there always would be a risk that something would convert wrong.
Send to server as converted HTML. Same as above.. conversion on client side would be difficult, server side same with possibility of getting it wrong.
send original markdown and converted HTM开发者_开发技巧L and store both. No performance issues related to converting markdown to HTML on client side, nor on server side. Users would have always same markdown they originally entered and same HTML they originally saw in preview (possibly sanitized in php though). It would have to take twice that much storage space though and that is my biggest worry.

I tend to lean towards 3rd solution as it seems simplest, but there is a worry of doubled storage space needed for this solution. Please bear in mind that my implementation of WMD is slightly modified and also I'm going with PHP/MySql server side implementation.

So apart from 3 options I listed above, are there any other possible solutions to my problem? Did I miss anything important that would make one of the options above better then the rest? And what other pros/cons would apply to each solution I listed? Also how is it implemented on SO? I read somwhere that they using option 3, and so if its good enough for SO would be good enough for me :) but not sure if its true anyway, so how is it done?

Also please forgive me, but at least for once I got to say that StackOverflow IS THE BEST DAMN RESOURCE ON THE WEB and I truly appreciate all the people trying to help others here! The site and users here are simply amazing!

Send to server as markdown or as converted HTML

One reason for accepting markdown instead of HTML from the client is that accepting arbitrary HTML from the client is a security risk: if you accept HTML then a client might send you HTML with malicious code, which you'd store and then feed back (perhaps to another client: so you end up sending malicious code to another client). For that reason, it might be better to accept only markdown (not HTML) from the client.

If I wanted to do it on the server, then standard server side implementations of markup to HTML might be resource expensive. Would that be an issue in your opinion?

I don't know what "the standard server side implementations" are but I'd guess that this (generating HTML) is the kind of processing that a server ought to be able to do.

The 4th. option is to store the markdown, and render the markdown to HTML using a server side library when it is requested, and then use caching to prevent a performance hit.

A comment on the security concern from ChrisW -- This a really valid point to concern yourself with sanitizing that input. However, don't make the mistake of assuming the markdown is safe either. From what I've seen of WMD and it's showdown.js processor, you can still feed it HTML and it will leave it in there. So it's possible for someone using WMD editor to still ender in <script> or whatever.

Actually talking about this makes me think I need to check my current implementation of this..