Markdown Html 변환기

마크다운을 HTML로, HTML을 마크다운으로 실시간 미리보기와 함께 변환합니다. CMS와 README, 이메일 사이에서 내용을 옮길 때 씁니다.

변환은 양방향이고, 두 방향의 실패 양상이 다릅니다. 마크다운에서 HTML로 가는 길은 정의가 분명합니다. 반대 방향은 본질적으로 손실이 있습니다. 마크다운에는 셀 병합이나 중첩 표, 스타일이 붙은 구간을 표현할 문법이 없어서, 변환기가 무엇을 인라인 HTML로 남기고 무엇을 버릴지 결정해야 합니다.

이 페이지는 마크다운이 표현할 수 있는 구조 — 제목, 목록, 표, 링크, 코드 블록, 인용 — 를 유지하고 나머지는 조용히 지우는 대신 인라인 HTML로 남깁니다. 복사해 온 웹 페이지나 워드에서 내보낸 문서를 README나 위키가 받아 주는 형태로 바꾸는, 실제로 자주 하는 작업에 쓸 수 있는 이유입니다.

마크다운은 하나의 표준이 아닙니다. 대부분의 혼란이 여기서 시작됩니다. 2004년의 원래 문법에는 표도, 취소선도, 체크박스 목록도 없었습니다. 그것들은 GitHub Flavored Markdown에서 들어온 것이고, 오늘날 대부분의 파서가 구현하는 엄격한 문법인 CommonMark도 그것들을 핵심이 아니라 확장으로 취급합니다. 그래서 GitHub README에서 깔끔하게 보이던 표가 위키에서는 파이프 문자 덩어리로 나타나고, 같은 원본이 읽는 곳에 따라 다른 문서가 됩니다. 이 페이지의 파서는 GitHub 확장을 켠 상태로 동작합니다. README, GitLab 이슈, Obsidian 노트가 기대하는 방식이고, 목적지가 따로 말하지 않는 한 가정해도 좋은 쪽입니다.

붙여넣은 HTML은 깨끗한 경우가 드뭅니다. 무엇이 버려지는지 알아 두면 한 번의 혼란을 줄일 수 있습니다. 워드나 구글 문서에서 복사한 내용에는 단어마다 붙은 인라인 스타일, mso- 로 시작하는 클래스, 여백 대신 쓰인 빈 문단이 함께 딸려 옵니다. 마크다운에는 그것들을 표현할 방법이 아예 없습니다. 살아남는 것은 마크다운이 이름을 가진 구조입니다. 제목, 목록, 표, 링크, 강조, 코드, 인용입니다. 꾸미기용 마크업은 별표로 흉내 내지 않고 버립니다. 그래야 결과가 읽을 수 있는 문서로 남고, 서식이 들어간 문서가 잡음으로 변하지 않습니다. 변환 뒤에 확인할 곳은 중첩 목록입니다. 변환기가 내보내는 들여쓰기 칸 수와 특정 렌더러가 기대하는 칸 수가 늘 같지는 않기 때문입니다.

결과물을 다른 곳으로 옮기기 전에 알아 둘 것이 두 가지 있습니다. 마크다운으로 바꿀 때는 마크업으로 읽힐 수 있는 문자를 이스케이프합니다. 그래서 some_name_here 같은 식별자가 가운데만 기울임꼴로 변하지 않고 밑줄을 그대로 유지합니다. 코드 예시가 옮겨지는 도중에 조용히 망가지는 가장 흔한 경로가 이것입니다. 반대 방향은 아무것도 정화하지 않습니다. 마크다운 원본에 적힌 script 태그는 script 태그로 렌더링됩니다. HTML을 걷어내면 마크다운이 의도적으로 허용하는 인라인 마크업까지 깨지기 때문입니다. 변환기로서는 그것이 옳은 동작이고, 대신 이 페이지의 HTML 쪽 출력은 읽고 붙여넣기 위한 것이지 신뢰할 수 없는 입력을 렌더링하는 페이지에 그대로 집어넣기 위한 것이 아닙니다.

줄바꿈은 방언 사이의 가장 작은 차이인데 가장 많은 혼란을 만듭니다. 원래 문법에서 줄바꿈 하나는 줄바꿈이 아닙니다. 두 줄이 한 문단으로 합쳐지고, 강제 줄바꿈은 줄 끝에 공백 두 칸을 넣어야 합니다. 눈에 보이지도 않는 데다 저장할 때 끝 공백을 지우는 편집기가 흔히 없애 버립니다. GitHub Flavored Markdown은 댓글과 이슈에서는 문단 안의 줄바꿈을 줄바꿈으로 취급하지만 모든 맥락에서 그렇지는 않습니다. 같은 저장소에서 같은 텍스트가 댓글 창과 README에서 다르게 줄이 잡히는 이유입니다.