Markdown 표 생성기

입력은 넷, 출력은 하나

Markdown 표는 쓰기는 쉽고 유지하기는 괴롭습니다. 칸에 단어 하나만 더해도 그 아래 세로줄이 전부 어긋나고, 이미 가진 데이터 — 질의 결과, 스프레드시트 내보내기, API 응답 — 로 표를 만들려면 결국 손으로 다시 치게 됩니다. 이 도구는 데이터를 지금 있는 모양 그대로 받아 GitHub 방언의 깔끔한 Markdown 표를 돌려줍니다.

읽을 수 있는 형식은 넷이고, 어느 쪽으로 판단했는지 조용히 정하지 않고 알려 줍니다.

• Markdown 표. 정렬이 흐트러진 표는 그대로 다시 붙여 넣기만 하면 반듯해집니다.
• CSV. RFC 4180에 따라 해석하므로 따옴표로 묶인 필드 안의 쉼표, 따옴표, 심지어 줄바꿈까지 그대로 살아남습니다.
• TSV. 스프레드시트나 데이터베이스 클라이언트에서 범위를 복사하면 나오는 형식입니다.
• JSON 배열. 객체의 배열이면 키가 열이 되고, 배열의 배열이면 첫 행이 머리글이 됩니다.

감지는 가장 분명한 단서부터 봅니다. 앞머리의 대괄호는 JSON뿐이고, 하이픈만 늘어선 행은 Markdown 구분 행뿐이며, 첫 줄의 탭은 TSV뿐입니다. 쉼표 구분은 남는 쪽이라 발견이 아니라 기본값으로 보고됩니다. 도구가 추측해야 했다면 그렇다고 말하고, 형식 선택이 그 위에 놓입니다.

출력은 Markdown 하나뿐입니다. 표를 CSV나 JSON으로 되돌리는 일은 다른 작업이고, 이 사이트에는 그 일을 하는 도구가 이미 있습니다. 범용 변환기를 하나 더 두면 그것들과 겹치기만 하고 이 페이지를 설명하기만 어려워집니다.

칸은 길이가 아니라 너비로 채운다

세로줄을 맞춘다는 것은 한 열의 모든 칸을 같은 너비로 채운다는 뜻이고, 그러려면 칸이 얼마나 넓은지 알아야 합니다. 글자 수를 세면 된다는 뻔한 답은 세계 대부분의 문자 체계에서 틀리며, 그것도 양쪽 방향으로 틀립니다.

고정폭 글꼴은 한 글자에 한 칸이 아닙니다. 한자, 가나, 한글 음절, 전각 라틴 문자, 그리고 거의 모든 이모지는 라틴 문자의 정확히 두 배 너비로 그려집니다. 반면 결합 문자 — 라틴 문자의 악센트, 히브리어 모음 부호, 아랍어 발음 부호 — 는 앞 글자 위에 겹쳐 그려져 너비를 전혀 차지하지 않습니다. 글자 수로 채우면 일본어 열은 너무 짧고 부호가 붙은 글의 열은 너무 길어집니다.

'日本語'.length          // 3  UTF-16 code units
[...'日本語'].length     // 3  code points
displayWidth('日本語')   // 6  columns in the editor

그래서 여백은 표시 칸 수로 잽니다. 먼저 텍스트를 자소 묶음으로 나눕니다. 독자가 한 글자로 세는 단위라서 여러 코드 포인트를 이어 붙인 이모지도 한 덩어리로 남습니다. 그리고 각 묶음을 Unicode 문자 데이터베이스의 East_Asian_Width 속성과 대조합니다. 이 속성 하나만은 브라우저가 스스로 답하지 못합니다. JavaScript는 정규식으로 범주와 문자 체계와 대소문자를 알려 주지만 이 속성은 알려 주지 않아서, 넓은 범위를 담은 작은 표를 페이지와 함께 보냅니다. 나머지는 모두 엔진에서 옵니다.

일부러 좁게 다루는 분류가 하나 있습니다. Unicode는 상자 그리기 문자, 일부 그리스 문자와 키릴 문자, 몇몇 문장 부호를 '모호함'으로 표시합니다. 옛 동아시아 글꼴에서는 넓고 그 밖에서는 좁은 글자들입니다. Markdown 파일은 라틴 문자를 기본으로 삼는 편집기에서 읽으니 이들을 한 칸으로 셉니다. 실제로 그 파일을 열게 될 터미널과 편집기가 그렇게 하기 때문입니다.

Markdown 표가 담을 수 없는 것

이 형식에는 단단한 한계가 둘 있고, 현실의 데이터는 둘 다에 부딪힙니다. 칸은 맨 세로줄을 담을 수 없습니다. 그것이 바로 칸을 나누는 기호라서, 이스케이프해 써야 합니다. 그리고 표의 한 행은 한 줄이므로 칸은 줄바꿈을 아예 담을 수 없습니다. CSV 필드는 얼마든지 담을 수 있는데도 말입니다.

둘 다 다시 쓰이고, 다시 쓸 때마다 영향을 받은 칸 수와 첫 위치가 함께 보고됩니다. 그게 요점입니다. 두 줄짜리 주소를 조용히 한 줄로 만들어 버리는 도구는 알리지도 않고 데이터를 상하게 한 것입니다. 줄바꿈은 기본적으로 줄바꿈 태그가 되는데, GitHub와 GitLab을 비롯한 대부분의 렌더러가 칸 안의 새 줄로 보여 주는 형태입니다. 렌더러가 HTML을 제거한다면 공백으로 바꾸세요.

세 번째는 머리글보다 긴 행입니다. GitHub 방언은 남는 칸을 그냥 버리는데, 이는 조용한 데이터 손실입니다. 여기서는 대신 빈 머리글 칸을 붙여 표를 넓히고 어긋남을 보고합니다. 고칠 수 있는 어색한 머리글이 존재조차 모르는 열보다 낫기 때문입니다. 머리글보다 짧은 행도 빈 칸으로 채우고 같은 방식으로 보고합니다.

역슬래시는 대부분의 도구보다 조금 더 조심스럽게 다룹니다. 뒤따르는 세로줄을 삼킬 수 있는 자리 — 본문 속 세로줄 바로 앞이나, 구분 기호가 이어지는 칸의 맨 끝 — 에서만 두 개로 늘립니다. 그 밖의 자리에서는 그대로 두므로, 칸 안의 Windows 경로가 이중 역슬래시의 행렬이 되지 않고 읽을 만하게 남습니다.

정렬은 구분 행에 산다

머리글 아래 하이픈 행은 두 가지 일을 합니다. 그 덩어리를 애초에 표로 만들어 주는 것이 이 행이고, 거기 놓인 쌍점이 각 열의 정렬을 정합니다. 왼쪽 쌍점은 왼쪽 정렬, 오른쪽 쌍점은 오른쪽 정렬, 양쪽 쌍점은 가운데 정렬입니다. 쌍점이 없으면 렌더러가 자기 기본값을 쓰는데 어느 구현에서나 왼쪽이지만, 그것은 왼쪽을 지정한 것과 같지 않습니다.

여기서는 열마다 따로 지정합니다. 정렬이 실제로 그렇게 쓰이기 때문입니다. 글은 왼쪽, 숫자는 오른쪽, 상태 열은 가운데. 그리고 이미 정렬이 들어 있는 표를 붙여 넣으면 그 값이 구분 행에서 읽혀 이 조작부에 나타나므로, 기존 표를 다시 다듬어도 누군가 손본 결과가 조용히 사라지지 않습니다.

여백도 정렬을 따릅니다. 오른쪽 정렬 열은 왼쪽에 여백이 붙어서, 소스가 완성된 표와 같은 모양으로 보입니다. Markdown은 그 공백을 완전히 무시하는데, 바로 그래서 소스를 읽기 좋게 만드는 데 마음껏 쓸 수 있습니다.

여백을 넣을까 압축할까, 그리고 오른쪽에서 왼쪽으로 쓰는 글이 다른 이유

여백은 사람이 손으로 고치는 문서에서는 값어치를 하고, 저장소에서는 비용이 됩니다. 칸 하나가 길어지면 그 열 전체가 다시 채워지므로, 한 단어 수정이 diff에서는 표의 모든 행이 바뀐 것으로 나타납니다. 압축 형식은 허용되는 가장 좁은 표 — 여백 없이 열마다 하이픈 셋 — 를 써서 diff를 실제로 바뀐 행으로 묶어 둡니다. 렌더링 결과는 둘이 같습니다. 각 행의 처음과 끝 세로줄은 GitHub 방언에서는 필요 없지만 일부 오래된 렌더러는 요구하므로, 결정이 아니라 스위치로 두었습니다.

히브리어나 아랍어가 들어간 표에서는 여백이 아예 통하지 않고, 도구는 그것을 감추지 않고 말합니다. 공백은 정확히 세어지지만 편집기는 섞인 줄을 양방향 알고리즘으로 배치합니다. 오른쪽에서 왼쪽으로 흐르는 부분이 재배치되고 그 둘레의 세로줄도 함께 움직입니다. 글자는 제자리에 있는데도 세로줄은 맞아 보이지 않습니다. 그런 줄에서는 시각적 위치와 논리적 위치가 같지 않기 때문입니다. 이건 어쩔 도리가 없어서, 칸에 오른쪽에서 왼쪽으로 쓰는 글이 있으면 도구가 그 사실을 보고하고, 실망할 정렬 자체가 없는 압축 형식을 권합니다.

같은 이유로 이 페이지의 Markdown 출력은 히브리어나 아랍어로 사이트를 읽고 있을 때에도 늘 왼쪽에서 오른쪽으로 보여 줍니다. 소스 코드에는 그 나름의 방향이 있으니까요.

어디서 실행되나

모든 일이 브라우저 안에서 일어납니다. 표를 해석하고 너비를 재고 다시 만드는 일이 모두 여러분의 기기에서 이뤄지며, 붙여 넣은 것은 업로드되거나 저장되거나 기록되지 않습니다. 다시 다듬어야 하는 표는 대개 공개 데이터가 아니라 질의 결과와 내보내기이니 이는 중요한 점입니다.