Ano ang Markdown to HTML conversion?
Markdown ay isang magaan na plain-text format na gumagamit ng minimal na bantas (# para sa heading, * para sa diin, - para sa mga aytem ng listahan) para mag-encode ng structured prose. GitHub Flavored Markdown (GFM) ay nagpapalawak ng orihinal na CommonMark spec gamit ang mga table, strikethrough, task list, at autolink. HTML ang rendered form na ipinapakita ng browser. Ang pag-convert ng Markdown sa HTML ay nagpapahintulot sa iyo na mag-author sa magaan na syntax at mag-ship sa rendered surface — isang README, isang static-site page, isang email body — nang hindi nagsusulat ng mga tag nang manu-mano.
Aling GitHub Flavored Markdown feature ang sinusuportahan?
Ang bundled na marked@12.0.2 parser ay sumusuporta sa buong GFM superset: ATX-style heading mula # hanggang ######, ordered at unordered list na may nesting, bold **text** at italic *text*, strikethrough ~~text~~, inline link [text](url) at inline image , fenced code block na may optional na language tag (```js), inline code span `code`, pipe table na may header row, GFM task list - [ ] / - [x], blockquote >, horizontal rule ---, at autolink. Ang bawat elemento ay nire-render sa preview pane sa parehong paraan ng GitHub.
Paano gumagana ang Markdown to HTML conversion?
Ang bawat conversion ay tumatakbo nang lokal sa iyong browser gamit ang dalawang bundled na library — walang CDN, walang fetch, walang telemetry. Ang mga pangunahing hakbang ay:
- Parse: ang
marked.parse(source)ay binabasa ang iyong Markdown at gumagawa ng HTML string. Ang parser ay tumatakbo sa GFM mode, kaya ang mga table, task list, strikethrough, at autolink ay lahat nakikilala. - Sanitize: ang HTML output ay dinadaan sa
DOMPurify.sanitize(html, { USE_PROFILES: { html: true } })bago italaga sainnerHTML. Ang DOMPurify ang parehong XSS sanitizer na ginagamit ng Mozilla MDN, Atlassian, at Microsoft 365 — nag-a-parse ito ng HTML, naglalakad sa DOM, at inaalis ang<script>element, bawaton*event handler attribute, atjavascript:URI scheme. - Render: ang sanitized na HTML ay isinusulat sa preview pane via
innerHTML, at ang raw HTML ay ipinapakita sa pangalawang panel via read-only na<textarea>para makopya mo ang markup. Ang live mode ay nagde-debounce ng input ng 150 ms para ma-update ang preview habang nagta-type ka nang hindi na-thrash ang parser.
Bakit gamitin ang tool na ito para mag-convert ng Markdown sa HTML?
- Privacy: ang bawat parse, sanitize, at render pass ay nangyayari sa iyong browser. Ang Markdown — kasama na ang mga hindi pa na-release na blog post, internal documentation draft, at confidential README content — ay hindi kailanman umaabot sa aming mga server.
- XSS-safe bilang default: ang rendered preview pane ay nagpapatakbo ng bawat HTML string sa DOMPurify bago ang
innerHTML, kaya ang isang<script>tag oonerror=handler sa loob ng raw HTML sa iyong Markdown ay gumagawa ng inert na preview. Ang raw tab ay nagpapakita ng unsanitized na output para sa inspeksyon sa loob ng<textarea>viavalue— hindi kailanman naisakatuparan. - GFM-kumpleto: ang mga table, strikethrough, task list, at autolink ay nire-render sa parehong paraan ng GitHub. Ang isang Markdown pipe-table ay nagiging HTML
<table>na may<thead>at<tbody>— walang nawawalang row, walang pinatabing structure.
Ano ang mga karaniwang gamit ng Markdown to HTML conversion?
Ang pag-convert ng Markdown sa HTML ay lumalabas sa dokumentasyon, static-site work, at email authoring:
- GitHub README authoring: pagsulat ng project README nang lokal bilang Markdown at pag-preview nito bago mag-push. Ang preview ay tumutugma sa GFM renderer ng GitHub para sa mga table, task list, at fenced code.
- Static-site content: pag-paste ng isang Markdown post at pagkuha ng HTML para sa CMS field o templating engine na umaasa ng markup kaysa sa Markdown source.
- Email template: pagsulat ng transactional-email body bilang Markdown at pag-convert sa HTML para sa templating engine ng email service provider. Ang output ay plain semantic HTML — walang inline style, walang email-client quirk na idinidag.
Ano ang hitsura ng isang Markdown to HTML na halimbawa?
Ang pag-paste ng # Title\n\n- item 1\n- item 2\n\n[link](https://example.com) ay gumagawa ng preview pane na naglalaman ng <h1>Title</h1>, isang two-item unordered list, at isang <a href="https://example.com">link</a>. Ang raw panel ay nagpapakita ng eksaktong HTML string para makopya mo ito nang direkta sa isang template. Ang pipe table na may alignment row na |---|---| ay nagiging buong <table> na may <thead> at <tbody> — kumpirmadong ang GFM table ay nire-render sa parehong paraan ng GitHub.
Tumatakbo ba nang buo ang Markdown to HTML converter na ito sa aking browser?
Oo. Ang bawat parse, sanitize, at render pass ay tumatakbo nang lokal bilang JavaScript sa loob ng iyong browser tab. Ang mga bundled na library — marked@12.0.2 at DOMPurify@3.1.7 — ay ipinapadala mula sa parehong origin ng page, kaya walang CDN dependency, walang fetch, walang XMLHttpRequest, walang navigator.sendBeacon sa input. Gumagana rin ang tool offline kapag na-load na ang page, dahil ito ay isang static HTML/CSS/JS bundle na may vendor library na nakakopya sa tabi nito. Ang mga hindi pa na-release na post, internal doc, at confidential README ay nananatili sa iyong device.
XSS-safe ba ang rendered preview pane?
Oo. Ang bawat HTML string na itinalaga sa innerHTML ay dinadaan muna sa DOMPurify.sanitize(html, { USE_PROFILES: { html: true } }). Ang DOMPurify ay ang open-source XSS sanitizer na pinapanatili ng Cure53; ito ang parehong library na ginagamit ng Mozilla MDN, Atlassian, at Microsoft 365 para palakasin ang user-supplied HTML. Ang default na html profile ay nag-aalis ng <script> element, bawat on* event-handler attribute (onerror, onclick, atbp.), javascript: URI scheme sa loob ng href / src, at kilalang-mapanganib na CSS expression. Ang pag-paste ng <img src=x onerror=alert(1)> ay gumagawa ng preview kung saan ang document.querySelector('#output-preview img[onerror]') ay nagbabalik ng null at walang alert na nagpapaputok.
Sinusuportahan ba ang mga GFM table?
Oo. Ang Markdown → HTML direction ay hinahawakan ang pipe table natively via GFM mode ng marked — isang header row na pinaghihiwalay ng |---|---| alignment row, na sinusundan ng mga data row, ay gumagawa ng <table> na may <thead> + <tbody>. Ang strikethrough (~~text~~ → <del>text</del>) at task list (- [ ] / - [x] → <input type="checkbox">) ay nire-render sa parehong paraan ng GitHub.
Tapat ba ang pag-convert ng aking Markdown?
Para sa canonical GFM feature set — heading h1 hanggang h6, ordered at unordered list na may nesting, bold / italic / strikethrough, inline link, inline image, fenced code block na may language tag, inline code span, pipe table, task list, blockquote, horizontal rule, at autolink — ang HTML output ay stable at tumutugma sa renderer ng GitHub. Ilang gawi na dapat malaman: ang raw inline HTML sa loob ng Markdown (hal. <sub>text</sub>) ay dumadaan nang buo sa output, at ang CommonMark setext heading (=== underline) at ATX heading (# Title) ay parehong gumagawa ng parehong <h1>. Ito ay mga dokumentadong gawi ng marked, hindi bug. Kung kailangan mo ang kabaligtaran, gamitin ang HTML to Markdown tool.
Sinusuportahan ba ang syntax highlighting sa mga fenced code block?
Hindi sa v1. Ang mga fenced code block ay nire-render na may monospaced font at banayad na background pero walang per-language token highlighting. Ang pagdaragdag ng syntax highlighting ay mangangailangan ng pag-bundle ng Prism o highlight.js, ang bawat isa ay nagdadagdag ng 15–40 KB kasama ang per-language grammar file at theme matrix na kailangang iayon sa Workshop Terminal palette. Sa ngayon, nakatuon ang renderer sa kawastuhan at XSS-safety; kung may demand ng gumagamit para sa inline highlighting, ang opt-in toggle ay isang magagawang follow-up.
Ang Markdown to HTML Converter na ito ay may kasamang marked@12.0.2 at DOMPurify@3.1.7 na naka-bundle sa parehong origin, sinusuportahan ang buong GFM feature set, at nagsa-sanitize ng bawat rendered HTML string bago ito humipo ng DOM. Walang upload, walang CDN, walang telemetry — ang bawat byte ay nananatili sa iyong browser.