Công cụ Xem Trước Markdown Trực Tuyến Miễn Phí

Tài liệu tham khảo Markdown

Về Markdown

Markdown được John Gruber, tác giả đứng sau blog Daring Fireball, tạo ra với phản hồi thiết kế đáng kể từ Aaron Swartz. Phiên bản công khai đầu tiên, 1.0, được công bố trên trang của Gruber ngày 9 tháng 3 năm 2004; phiên bản 1.0.1, bản tham chiếu kinh điển, theo sau ngày 17 tháng 12 năm 2004 và vẫn là phiên bản được liên kết từ daringfireball.net/projects/markdown. Markdown đồng thời là hai thứ: một cú pháp định dạng văn bản thuần và script Perl gốc chuyển cú pháp đó thành HTML. Mục tiêu Gruber tuyên bố là văn bản nguồn phải đọc được như nguyên bản, một tài liệu Markdown mở trong trình soạn văn bản thuần phải trông như một email đã được định dạng cẩn thận, không phải nồi súp thẻ. Ràng buộc về tính dễ đọc này là đường triết học chia Markdown khỏi các định dạng dựa trên XML và markup nặng hơn như LaTeX, và là lý do mỗi mở rộng về sau phải biện minh theo mức độ làm xáo trộn nguồn.

Gruber ghi công Swartz dài trong lời cảm ơn của Markdown: "Aaron Swartz xứng đáng nhận rất nhiều công lao cho phản hồi của ông về thiết kế cú pháp định dạng của Markdown". Swartz từng viết một markup nhẹ liên quan tên là atx (2002), góp phần vào kiểu tiêu đề # và ## nay quen thuộc, đôi khi vẫn gọi là "atx-style headings" trong đặc tả parser. Sự tham gia của Swartz là một phần di sản rộng hơn của ông: ông đồng xây dựng RSS 1.0 khi còn thiếu niên, đồng sở hữu Reddit đến 2007, và tiếp tục ảnh hưởng đến chuẩn web mở đến khi qua đời năm 2013. Một giai thoại đáng nhớ: phần mở rộng tệp .md nay gần như phổ quát, nhưng công cụ gốc của Gruber dùng .text, việc chuyển sang .md là quy ước cộng đồng đã lan rộng khi Markdown rời khỏi ngách blogging.

Vì sao Markdown thắng trên web

Một ngôn ngữ markup thắng bằng cách được các nền tảng xuất bản phần lớn văn bản thế giới chấp nhận. Trong cửa sổ năm năm chật, Markdown được các nền tảng đến lúc thống trị thảo luận dài, hợp tác mã và tài liệu cho lập trình viên áp dụng. Stack Overflow ra mắt ngày 15 tháng 9 năm 2008 với Markdown làm cú pháp định dạng cho câu hỏi, câu trả lời và bình luận, dùng một trình soạn tên WMD (Wysiwym Markdown) của John Fraser từ AttackLab; đội Stack Overflow sau đó viết lại nó thành trình soạn mã nguồn mở PageDown bảo trì tại github.com/StackExchange/pagedown. Reddit, do Steve Huffman và Alexis Ohanian sáng lập năm 2005 với Aaron Swartz tham gia ngay sau đó, giao Markdown cho bình luận sớm sau khi ra mắt và mang cú pháp đến khán giả rộng hơn nhiều, không phải lập trình viên. GitHub ra mắt năm 2008 và trong vòng chưa đầy một năm đã render Markdown trong README.md và bình luận issue; năm 2009 nó bắt đầu tài liệu hóa và giao phương ngữ riêng, GitHub Flavored Markdown. Discord, ra mắt tháng 5 năm 2015, đã chấp nhận cú pháp chat hương Markdown cho đậm, nghiêng, gạch ngang, code inline, code block và blockquote, điều mà phần lớn người không lập trình dưới 25 tuổi giờ gọi là "đặt sao quanh thứ gì đó". Kỹ năng tích lũy: một tác giả học Markdown một lần có thể viết bài blog trong Jekyll/Hugo/Eleventy, tài liệu trong MkDocs/Docusaurus/Read the Docs, slide trong Marp và Reveal.js, ghi chú trong Obsidian/Bear/Logseq/Notion, chat trong Slack và Discord, và tài liệu mã nguồn trong gần như mọi dự án mã nguồn mở hiện đại.

CommonMark, sửa đặc tả thiếu sót

Mô tả cú pháp gốc của Gruber năm 2004 nổi tiếng không chính thức, một tài liệu prose có ví dụ, không phải ngữ pháp. Nó để hàng chục trường hợp đặc biệt không định nghĩa ("emphasis tương tác với gạch dưới giữa từ thế nào?"; "một danh sách bên trong blockquote có đóng blockquote không?"; "điều gì tính là danh sách chặt vs lỏng?"), và Gruber chưa bao giờ công bố parser tham chiếu nào ngoài script Perl, hành vi của script đặc thù theo cách buộc các implementer khác hoặc sao chép hoặc bỏ qua. Kết quả đầu thập niên 2010 là GitHub, Reddit, Stack Overflow, Pandoc và parser C Discount đều render cùng nguồn Markdown khác nhau chút ít, và cùng đầu vào có thể vỡ giữa các nền tảng.

Năm 2012, đồng sáng lập Stack Overflow Jeff Atwood (lúc đó dẫn dắt Discourse) và tác giả Pandoc John MacFarlane bắt đầu nỗ lực viết một đặc tả thực sự, kiểm thử được. Họ được David Greenspan (Meteor), Vicent Marti (GitHub), Neil Williams (Reddit) và Benjamin Dumke-von der Ehe (Stack Exchange) tham gia. Dự án ra mắt công khai tháng 9 năm 2014 dưới tên "Standard Markdown"; trong vài ngày, Gruber phản đối tên gọi qua một email riêng, Atwood viết bài công khai giải thích sự thay đổi, và dự án được đổi thành "CommonMark". Bản phát hành đánh số đầu tiên đến ngày 25 tháng 10 năm 2014. Phiên bản đang công bố hiện thời là CommonMark 0.31.2, ra ngày 28 tháng 1 năm 2024, một "1.0" đã hứa cho 2019 và không đến vì một số ít trường hợp đặc biệt bệnh lý (đáng chú ý quanh việc parse emphasis và embed HTML) không tạo được giải pháp đồng thuận. Trong thực tế, 0.31.2 được xem là ổn định cho production. Đặc tả CommonMark khác thường ở chỗ chính nó là một tài liệu CommonMark, với hơn 600 ca kiểm thử thực thi được trực tuyến; một parser tuyên bố tuân theo bằng cách qua các bài kiểm thử đó.

GitHub Flavored Markdown, năm mở rộng trên CommonMark

Đặc tả GFM chính thức, công bố năm 2017 và gần đây đánh phiên bản 0.29-gfm ngày 6 tháng 4 năm 2019, định nghĩa năm mở rộng trên CommonMark: bảng (khối ngăn cách bằng dấu sổ với dòng phân cách dùng gạch ngang và : để căn lề theo cột); mục danh sách công việc (mục danh sách bắt đầu bằng [ ] chưa tích hoặc [x] đã tích, render thành ô tích HTML bị vô hiệu, GitHub thêm cho phép người dùng đăng nhập bật/tắt bằng cách bấm, đó là một lớp UX trên đặc tả, không phải phần của đặc tả); gạch ngang (bọc văn bản trong ~~ tạo <del>, bản thân CommonMark không đặc tả điều này); mở rộng autolink (URL và email trần trong văn bản chạy được tự động liên kết, trong khi CommonMark chỉ làm cho autolink ngoặc nhọn rõ ràng); và HTML thô bị cấm (một hạn chế bảo mật loại bỏ <script>, <iframe>, <style>, <title>, <plaintext>, <textarea>, <xmp>, <noembed>, <noframes> và một số thẻ nguy hiểm khác). Một tính năng thứ sáu thường được gán cho GFM nhưng đáng xử lý cẩn thận là code block fence với chỉ định ngôn ngữ, code block fence là phần của chính CommonMark; chỉ định ngôn ngữ sau fence mở cũng là CommonMark; tô màu cú pháp mà GitHub áp lên dựa trên chỉ định đó là hành vi render của GitHub, không phải đặc tả. Engine render của GitHub cũng chạy hậu xử lý thêm, làm sạch HTML qua gem nhà html-pipeline, mở rộng shortcode emoji (:smile:), autolink @user và #issue, không cái nào trong số đó là phần của GFM.

Các parser chính

marked.js được Christopher Jeffrey tạo, với bản quyền gốc đề năm 2011, và đã được tổ chức GitHub markedjs bảo trì từ năm 2018. Đó là thiết kế lexer-rồi-parser một lượt ưu tiên tốc độ thô; tài liệu định vị nó rõ là "trình biên dịch tầng thấp để parse markdown không cache hay block". Đó là parser bộ xem trước này hiện dùng để render trực tiếp. Marked nhỏ, nhanh, mở rộng được qua hook token, và là một trong các dự án markdown được star nhiều nhất trên GitHub (~36k sao).

markdown-it ra mắt năm 2014 do Vitaly Puzrin và Alex Kocharin. Cả hai đã đóng góp gần như toàn bộ mã cho một parser tên Remarkable; khi tranh chấp lãnh đạo chặn tiến độ, họ tổ chức lại cùng tác quyền quanh markdown-it. Dự án quảng bá tuân thủ 100% CommonMark với toggle GFM tùy chọn cho bảng và gạch ngang, cộng hệ sinh thái plugin quyết liệt (markdown-it-footnote, markdown-it-emoji, markdown-it-attrs, markdown-it-anchor, markdown-it-task-lists và vài trăm cái khác). Đó là parser được xem trước Markdown tích hợp của VS Code, UI web GitLab, và một danh sách dài các trình sinh site tĩnh kể cả Eleventy dùng.

remark / unified.js không phải một parser duy nhất mà là khung biến đổi cây. Tập thể unified, khởi đầu khoảng 2014, định nghĩa đặc tả cây cú pháp trừu tượng tên mdast (Markdown Abstract Syntax Tree); remark parse Markdown thành mdast, plugin thao tác cây, và remark-rehype chuyển mdast thành hast (AST của HTML) để xuất. Mô hình chậm hơn marked nhưng kết hợp được rộng hơn nhiều. Người dùng đáng chú ý gồm Prettier (định dạng Markdown bằng remark), Gatsby, MDN, pipeline tài liệu Node.js, và linter ngôn ngữ bao trùm alex. Tập thể unified liệt kê 312 dự án và khoảng 6,3 tỷ lượt tải npm hàng tháng trên tất cả các gói.

MDX, lần đầu commit cuối năm 2017 do John Otander và những người khác liên quan đến công ty công cụ thiết kế Compositor, được công bố công khai tại ZEIT Day 2018 và giao 1.0 ngày 11 tháng 4 năm 2019. MDX kết hợp nội dung Markdown với thành phần JSX, nên một tác giả có thể thả một <Chart /> hay <Tweet id="123" /> trực tiếp vào prose. Nó cấp năng lượng cho tài liệu Next.js, Docusaurus và phần lớn các site tài liệu dựa trên React. MDX có parser riêng phân biệt với CommonMark; v1 dựa trên remark, v2+ dùng ngữ pháp MDX chuyên xử lý đúng biểu thức JSX trong ngữ cảnh đoạn văn.

Pandoc, bộ chuyển đổi đa năng

Pandoc được John MacFarlane, lúc đó là giáo sư triết học tại Đại học California, Berkeley, công bố ngày 10 tháng 8 năm 2006. Nó viết bằng Haskell, và thiết kế xoay quanh việc parse một trong khoảng 30 định dạng đầu vào (Markdown, reStructuredText, HTML, LaTeX, DocBook, Textile, markup MediaWiki và DokuWiki, Org-mode, Microsoft Word .docx, OpenDocument, EPUB, JATS XML, Jupyter .ipynb và những cái khác) thành mô hình tài liệu trừu tượng chia sẻ, rồi render mô hình đó thành khoảng 40 định dạng đầu ra (HTML, PDF qua LaTeX hoặc wkhtmltopdf, .docx, .odt, ePub2/3, định dạng slide gồm Beamer và reveal.js, và nhiều cái khác). Nó có mặt khắp nơi trong xuất bản học thuật và kỹ thuật vì mang trích dẫn qua CSL JSON / BibTeX và phân giải chúng thành tham chiếu định dạng cho bất kỳ kiểu trích dẫn lớn nào. Phương ngữ Markdown mà Pandoc parse theo mặc định ("Pandoc Markdown") tự nó là siêu tập CommonMark với mở rộng cho footnote, danh sách định nghĩa, div fence, toán ($...$ và $$...$$ kiểu LaTeX) và chú thích bảng. Pandoc cấp phép GPL v2-or-later và là cái phần lớn khoa học thuật dùng để biên dịch bản thảo Markdown thành tài liệu Word sẵn sàng xuất bản.

MultiMarkdown, Markdown Extra và SmartyPants

Hai phương ngữ mở rộng trước CommonMark đã ảnh hưởng cả GFM và Pandoc. MultiMarkdown được Fletcher T. Penney tạo với bản phát hành đầu tháng 5 năm 2007 (công việc dự án bắt đầu 2005-2006), thúc đẩy bởi viết học thuật, Penney muốn một Markdown có thể tạo bản thảo xuất bản được với footnote, trích dẫn, toán, danh sách định nghĩa và metadata tài liệu kiểu YAML. MultiMarkdown giới thiệu hoặc phổ biến bảng dùng dấu sổ, đánh dấu footnote [^id], ký pháp toán, khối metadata cấp tài liệu ở đầu tệp, và chú thích ảnh và bảng. Markdown Extra được Michel Fortin (tác giả PHP Markdown) tạo năm 2005-2006 và thêm bảng dấu sổ, code block fence với ~~~ (sau đó cũng ```), footnote, danh sách định nghĩa, từ viết tắt và cú pháp thuộc tính {#id .class} cho tiêu đề. Đóng góp khác biệt nhất của nó là nới các quy tắc Markdown-trong-HTML, thuộc tính markdown="1" cho phép lồng Markdown bên trong khối HTML. Một số lựa chọn thiết kế CommonMark và GFM về fence code và bảng có gốc từ Markdown Extra. Riêng biệt, SmartyPants, đồng nghiệp typography của chính Gruber từ năm 2002, thực hiện thay thế typography: nháy thẳng ASCII thành nháy cong, gạch đôi và ba thành en dash và em dash, ba dấu chấm thành ellipsis thật. Markdown xử lý cấu trúc; SmartyPants xử lý đánh bóng; nhiều parser gói gọn hành vi kiểu SmartyPants thành bước hậu xử lý (markdown-it-smartypants, remark-smartypants), và Pandoc tích hợp nó sau cờ --smart.

Cạm bẫy thường gặp, mười điều cắn tác giả mới

Một bộ xem trước trực tiếp làm phần lớn ngạc nhiên parse hiện rõ ngay, nhưng hiểu vì sao chúng xảy ra giúp tác giả viết nguồn đúng từ lần đầu.

1. Chuyển đổi nháy thông minh phá ví dụ code. Bộ lọc kiểu SmartyPants vui vẻ chuyển nháy trong cái có vẻ là prose, đôi khi gồm bên trong span code inline hoặc giá trị thuộc tính HTML, để bạn lại với markup vỡ. Phần lớn parser hiện đại loại trừ span code khỏi thay thế typography, nhưng các nền tảng blog với pipeline tùy biến thường không.
2. Phát hiện đánh dấu danh sách nhạy với khoảng trắng. Trộn -, * và + trong cùng danh sách, thụt đoạn tiếp danh sách ít hơn yêu cầu của đánh dấu, hoặc đặt dòng trống giữa các mục danh sách có thể chuyển danh sách chặt thành lỏng (mỗi mục bọc trong thẻ <p>), một khác biệt vô hình trong nguồn nhưng dồn dập trong đầu ra.
3. Autolink quá nhiệt tình. Autolink kiểu GFM biến mọi URL trần thành liên kết, thường là điều bạn muốn, nhưng cũng có thể làm hỏng URL trong cái lẽ ra phải là span code, hoặc URL chứa dấu ngoặc đơn (URL Wikipedia đặc biệt). Quy tắc "URL này kết thúc ở đâu?" thay đổi giữa các parser.
4. Chỉ định ngôn ngữ fence code. Văn bản sau ba backtick mở, ```js vs ```javascript vs ```ts vs ```typescript, là chỉ định, không phải đặc tả. Các trình tô màu khác nhau nhận diện alias khác nhau; Highlight.js, Prism, Shiki và engine render của GitHub mỗi cái có từ điển ngôn ngữ riêng.
5. Bảng cần escape. Ký tự dấu sổ trong ô bảng phải được escape thành \|, nếu không chúng được đọc là dấu phân tách cột. Bẫy bất kỳ ai cố đặt ví dụ code một dòng trong ô bảng.
6. Xuống dòng cứng. Bên trong đoạn văn, một xuống dòng đơn được xem là khoảng trắng và các dòng được nối; phải đặt hai khoảng trắng cuối dòng, hoặc dùng backslash, tùy parser. CommonMark cho phép cả hai. Một số parser cũ đòi <br> rõ ràng.
7. Trộn Markdown và HTML. Markdown được thiết kế để truyền HTML tùy ý qua, nên thả <div class="callout"> vào tệp Markdown vẫn hoạt động. Nhưng ngay khi bạn đặt cú pháp Markdown bên trong khối HTML, các parser khác nhau: CommonMark xem phần lớn khối HTML như đục; Markdown Extra giới thiệu markdown="1" để bật parse lồng.
8. Thực thể HTML và escape ký tự. Một dấu & trong URL không cần escape bên trong liên kết Markdown, nhưng cùng & ngoài liên kết sẽ được truyền sang HTML và có thể cần là & để tuân thủ HTML5 nghiêm. Phần lớn engine render xử lý điều này tự động; một số không.
9. ID tiêu đề. GitHub tự sinh ID đoạn URL từ văn bản tiêu đề dùng quy tắc slugify; nhiều parser cũng làm vậy, nhưng thuật toán slugify khác nhau. Cùng tiêu đề, anchor khác giữa các nền tảng, một nguyên nhân vĩnh viễn của liên kết nội-tài-liệu vỡ khi nội dung di chuyển giữa các hệ thống.
10. Khoảng trắng cuối và thiết lập trình soạn. Trình soạn xóa khoảng trắng cuối khi lưu sẽ âm thầm bỏ cú pháp xuống dòng hai-khoảng-trắng-cuối của Markdown. Trình soạn chuyển tab thành khoảng trắng (hoặc ngược lại) sẽ phá code block phụ thuộc thụt lề.

Markdown và bảo mật, XSS và sanitization

Markdown nguy hiểm theo cách cụ thể: mọi parser dòng chính truyền HTML thô qua không thay đổi. Đó là theo thiết kế, đó là điều làm Markdown hữu ích cho callout và embed viết tay, nhưng cũng nghĩa là một bộ xem trước Markdown tiêm đầu ra parser trực tiếp vào DOM theo mặc định là vector XSS. Dán <img src=x onerror="alert(1)"> vào trình soạn Markdown và render đầu ra không sanitize sẽ chạy alert. Hai lớp phòng thủ là chuẩn. Thứ nhất, cấu hình ở mức parser: marked.js, markdown-it và remark đều phơi tùy chọn để vô hiệu HTML thô hoặc escape nó ở đầu ra (markdown-it có html: false theo mặc định; remark/rehype có rehype-sanitize). GFM thêm đặc tả phần mở rộng "HTML thô bị cấm" loại bỏ danh sách phần tử nguy hiểm mã hóa cứng. Thứ hai và vững hơn, sanitize HTML sau parse: DOMPurify, do hãng bảo mật Berlin Cure53 viết từ tháng 2 năm 2014, là sanitizer JavaScript de facto. Nó nhận một chuỗi HTML, parse nó thành DOM, đi qua cây cho phép chỉ một tập an toàn cấu hình được các phần tử và thuộc tính, và serialize kết quả. DOMPurify bỏ <script>, chặn handler sự kiện inline, gỡ URL javascript:, và xử lý cả trăm bypass XSS tinh tế (lạm dụng SVG <use>, polyglot thuộc tính MathML) mà sanitizer regex ngây thơ sẽ bỏ sót. Pipeline khuyến nghị cho mọi bộ xem trước dựa trên trình duyệt nhận HTML thô là: markdownString → parser → htmlString → DOMPurify.sanitize() → innerHTML. CommonMark cũng yêu cầu rõ rằng các parser từ chối URI javascript: trong autolink; phần lớn parser mở rộng từ chối đó cho mọi dạng liên kết.

Markdown vs reStructuredText vs AsciiDoc

Markdown là ngôn ngữ markup nhẹ thống trị nhưng không phải duy nhất. reStructuredText (reST) được David Goodger công bố lần đầu tháng 6 năm 2001 trong khuôn khổ Python Doc-SIG, tiến hóa từ định dạng Zope cũ tên StructuredText. Nó trở thành định dạng tài liệu chính thức của Python năm 2002 và là ngôn ngữ đầu vào của Sphinx, trình sinh tài liệu đứng sau gần như mọi tài liệu dự án Python (tài liệu chính thức ngôn ngữ Python, NumPy, SciPy, Django, Flask, scikit-learn, pandas, tài liệu kernel Linux từ 2016, CMake, LLVM). Triết lý thiết kế của RST về cơ bản ngược Markdown: nó chấp nhận nhiều nhiễu thị giác hơn trong nguồn để đổi lấy độ chính xác ngữ nghĩa cao hơn ở đầu ra. RST có cơ chế mở rộng tích hợp qua "directive" (.. note::, .. code-block:: python) và "role" (:func:, :ref:) cho phép một dự án định nghĩa markup riêng cho lĩnh vực mà không rời định dạng. AsciiDoc được Stuart Rackham tạo năm 2002 như công cụ Python có chủ ý nhắm ngữ nghĩa DocBook XML, mỗi tài liệu AsciiDoc ánh xạ gọn sang DocBook, làm nó là markup được chọn cho dự án cần sách chất lượng xuất bản, đặc tả kỹ thuật và sổ tay. AsciiDoc là cái tài liệu dự án Git được viết bằng, cái O'Reilly Media dùng cho nhiều sách, cái Red Hat và Mozilla dùng cho nhiều bộ tài liệu sản phẩm, và cái GitHub và GitLab hỗ trợ nguyên gốc như giải pháp thay thế README.adoc. Triển khai Python gốc đã được Asciidoctor, một triển khai Ruby công bố năm 2013, thay thế. Lời khuyên thực tế: chọn Markdown cho bài blog, README, chat, ghi chú và phần lớn tài liệu; reStructuredText cho tài liệu Python xử lý qua Sphinx; AsciiDoc cho sách hoặc đặc tả dài phải render sang DocBook, PDF và EPUB cùng lúc với độ trung thành ngữ nghĩa đầy đủ.

Câu hỏi thường gặp

Những tính năng Markdown nào được hỗ trợ?

Trình xem trước này hỗ trợ tiêu đề, in đậm, in nghiêng, liên kết, hình ảnh, danh sách, trích dẫn, khối mã, bảng, đường kẻ ngang và gạch ngang. Nó bao phủ đặc tả CommonMark cùng với các phần mở rộng phổ biến.

Tôi có thể xuất HTML đã kết xuất không?

Bạn có thể sao chép kết quả đã kết xuất từ khung xem trước. Để lấy HTML thô, nhấp chuột phải vào bản xem trước và sử dụng tính năng "Kiểm tra" hoặc "Xem nguồn" của trình duyệt để sao chép mã nguồn đã tạo.

Văn bản của tôi có được lưu không?

Không. Mọi thứ chạy trong trình duyệt của bạn và không có gì được lưu trữ hoặc gửi đến máy chủ. Đóng tab và văn bản của bạn sẽ biến mất. Sao chép Markdown trước khi rời đi nếu bạn muốn lưu nó.

Văn bản của tôi có được lưu hay gửi đi đâu không?

Không. Parser Markdown chạy hoàn toàn trong trình duyệt qua JavaScript. Không gì được upload, không API nào được gọi, không log nào được viết. Đóng tab và văn bản biến mất. Nếu bạn muốn giữ thứ đã viết, hãy sao trước khi rời trang. Bạn cũng có thể dùng trang offline khi đã tải xong, cache qua service worker nghĩa là parser vẫn khả dụng không cần kết nối Internet.

Bộ xem trước có sanitize HTML thô không?

Parser truyền HTML thô qua, đó là hành vi CommonMark chuẩn, hữu ích để nhúng một <div> hay <details> đôi khi. Vì đầu vào đến từ phiên trình duyệt của chính bạn và đầu ra chỉ render trong tab của chính bạn, an toàn cho trường hợp xem trước một-người mà nó được dựng. Nếu bạn xuất bản đầu ra đến hệ thống nhiều người dùng (CMS, diễn đàn, site tài liệu nhận đóng góp người dùng), bạn vẫn nên đẩy HTML đã render qua sanitizer như DOMPurify trước khi tiêm vào trang công khai, Markdown cộng HTML thô là vector XSS trong mọi hệ thống nơi tác giả và người đọc là người khác nhau.

Có giới hạn kích thước tệp không?

Không có giới hạn cứng. Parser xử lý hàng chục nghìn dòng Markdown không vấn đề trên một laptop điển hình. Render lại trực tiếp chạy ở mỗi phím gõ, nên các tài liệu rất lớn (cả một cuốn sách trong một tệp duy nhất) sẽ bắt đầu thấy chậm trên thiết bị chậm hơn. Chia thành chương, hoặc dán nội dung để render một lần rồi sửa offline, là cách giải. Trang sẽ không đóng băng trình duyệt của bạn, marked.js là một trong các parser Markdown nhanh nhất có sẵn.

Công cụ liên quan