Pembuat tabel Markdown
Buat tabel Markdown dari CSV, TSV, atau JSON, atau ratakan ulang tabel yang ada, dengan perataan per kolom dan padding sadar CJK. Di peramban Anda.
Dibaca sebagai CSV. Tidak ada yang menandai formatnya, jadi ini pilihan cadangan — pilih format di atas bila keliru.
Perataan kolom
| city | country | population |
| --------- | ------- | ---------- |
| 東京 | Japan | 37400068 |
| Delhi | India | 28514000 |
| São Paulo | Brazil | 21650000 |Kolom: 3 · baris: 3
Empat masukan, satu keluaran
Tabel Markdown mudah ditulis dan menyiksa untuk dirawat. Menambah satu kata ke dalam sel membuat semua garis tegak di bawahnya melenceng, dan menyusun tabel dari data yang sudah Anda punya — hasil kueri, ekspor lembar kerja, respons API — berarti mengetik ulang semuanya dengan tangan. Alat ini menerima data dalam bentuk apa pun yang Anda punya dan mengembalikan tabel yang rapi dalam Markdown milik GitHub.
Ia membaca empat format, dan memberi tahu Anda format mana yang dipilihnya alih-alih memutuskan diam-diam:
- Tabel Markdown, sehingga tabel yang perataannya sudah melenceng cukup ditempel kembali untuk diluruskan.
- CSV, diurai menurut RFC 4180 — sebuah bidang dalam tanda kutip boleh memuat koma, tanda kutip, bahkan pergantian baris, dan semuanya selamat.
- TSV, yaitu yang Anda dapat ketika menyalin rentang dari lembar kerja atau dari klien basis data.
- Larik JSON, entah berisi objek (kuncinya menjadi kolom) atau berisi larik (baris pertama menjadi kepala tabel).
Deteksi mencari bukti yang paling khas lebih dulu: kurung siku di awal hanya mungkin JSON, deretan tanda hubung hanya mungkin baris pemisah Markdown, dan tab pada baris pertama hanya mungkin TSV. Pemisahan dengan koma adalah sisanya, jadi ia dilaporkan sebagai pilihan cadangan dan bukan sebagai temuan — kalau alat ini harus menebak, ia mengatakannya, dan pemilih format mengalahkannya.
Keluarannya adalah Markdown dan hanya Markdown. Mengubah tabel kembali menjadi CSV atau JSON adalah pekerjaan lain, dan situs ini sudah punya alat yang melakukannya; pengubah serbaguna kedua hanya akan bersaing dengan mereka dan membuat halaman ini lebih sulit dijelaskan.
Sel diisi menurut lebar, bukan menurut panjang
Meratakan garis tegak berarti mengisi setiap sel dalam satu kolom sampai lebar yang sama, dan itu menuntut kita tahu seberapa lebar sebuah sel. Jawaban yang paling jelas — hitung saja karakternya — keliru untuk sebagian besar sistem tulisan di dunia, dan keliru ke dua arah sekaligus.
Fonta berspasi tetap bukan berarti satu karakter satu kolom. Ideogram Tionghoa atau Jepang, kana, suku kata Hangul, huruf Latin lebar penuh, dan hampir setiap emoji digambar tepat dua kali lebih lebar daripada huruf Latin. Sebaliknya tanda gabung — aksen, tanda vokal Ibrani, harakat Arab — digambar di atas huruf sebelumnya dan tidak menempati lebar sama sekali. Isi menurut jumlah karakter, maka kolom berisi bahasa Jepang keluar terlalu pendek sedangkan kolom berisi teks beraksen keluar terlalu panjang.
'日本語'.length // 3 UTF-16 code units
[...'日本語'].length // 3 code points
displayWidth('日本語') // 6 columns in the editorKarena itu padding diukur dalam kolom tampilan. Teks lebih dulu dipecah menjadi gugus grafem — apa yang dihitung pembaca sebagai satu karakter, sehingga emoji yang dirakit dari beberapa titik kode tetap satu satuan — lalu tiap gugus dibandingkan dengan properti East_Asian_Width dari basis data karakter Unicode. Properti itulah satu-satunya hal yang tidak bisa dijawab sendiri oleh peramban: JavaScript membuka kategori, sistem tulisan, dan huruf besar-kecil lewat ekspresi reguler, tetapi tidak yang ini, jadi sebuah tabel kecil berisi rentang lebar dikirim bersama halaman. Selebihnya datang dari mesinnya.
Ada satu kategori yang sengaja diperlakukan sebagai sempit. Unicode menandai sekelompok karakter — gambar kotak, beberapa huruf Yunani dan Kiril, sejumlah tanda baca — sebagai «ambigu»: lebar dalam fonta Asia Timur lama, sempit di mana pun selainnya. Berkas Markdown dibaca di penyunting yang fonta bawaannya Latin, jadi karakter-karakter itu dihitung satu kolom, persis seperti yang dilakukan terminal dan penyunting tempat Anda akan membuka berkas itu.
Yang tidak bisa ditampung tabel Markdown
Format ini punya dua batas keras, dan data sungguhan menabrak keduanya. Sel tidak bisa memuat garis tegak telanjang, karena justru itulah pemisah antarsel; ia harus ditulis dengan escape. Dan satu baris tabel adalah satu baris saja, jadi sel sama sekali tidak bisa memuat pergantian baris — padahal bidang CSV berhak sepenuhnya memilikinya.
Keduanya ditulis ulang, dan setiap penulisan ulang dilaporkan lengkap dengan jumlah sel yang terdampak serta posisi yang pertama. Itulah intinya: alat yang diam-diam menjadikan alamat dua baris Anda satu baris telah merusak data Anda tanpa memberi tahu. Pergantian baris secara bawaan menjadi tag pemutus, yang oleh GitHub, GitLab, dan sebagian besar perender ditampilkan sebagai baris baru di dalam sel; kalau perender Anda membuang HTML, ganti dengan spasi.
Baris yang lebih panjang daripada kepala tabel adalah kasus ketiga. Markdown milik GitHub begitu saja membuang sel berlebih, dan itu kehilangan data secara diam-diam. Di sini tabel justru dilebarkan, dengan sel kepala yang kosong, dan ketidakcocokannya dilaporkan — kepala tabel yang tampak ganjil tapi bisa Anda perbaiki lebih baik daripada kolom yang tak pernah Anda ketahui. Baris yang lebih pendek daripada kepala tabel diisi sel kosong dan dilaporkan dengan cara yang sama.
Garis miring terbalik ditangani sedikit lebih cermat di sini daripada di kebanyakan alat. Garis miring terbalik hanya digandakan di tempat ia bisa menelan garis tegak yang mengikutinya: sebelum garis tegak di dalam teks, atau tepat di ujung sel, tempat pemisah akan datang. Di tempat lain ia dibiarkan apa adanya, sehingga jalur Windows di dalam sel tetap terbaca alih-alih berubah menjadi deretan garis miring ganda.
Perataan tinggal di baris pemisah
Baris tanda hubung di bawah kepala tabel mengerjakan dua hal. Ialah yang menjadikan blok itu sebuah tabel, dan titik duanya menetapkan perataan tiap kolom: titik dua di kiri merata kiri, di kanan merata kanan, di kedua sisi berarti tengah. Tanpa titik dua, perender memakai bawaannya sendiri, yang di setiap implementasi adalah kiri, tetapi itu tidak sama dengan meminta rata kiri.
Di sini tiap kolom punya kendalinya sendiri, karena begitulah perataan benar-benar dipakai: teks ke kiri, angka ke kanan, kolom status di tengah. Dan ketika Anda menempel tabel yang sudah punya perataan, nilainya dibaca dari baris pemisah dan ditampilkan pada kendali itu, sehingga memformat ulang tabel yang sudah ada tidak pernah diam-diam membuang kerja orang lain.
Padding pun mengikuti perataan. Kolom rata kanan diberi spasi di sisi kiri, sehingga sumbernya tampak sama seperti tabel yang nanti dirender. Markdown mengabaikan spasi itu sepenuhnya, dan justru karena itulah spasi bisa dipakai cuma-cuma untuk membuat sumbernya enak dibaca.
Diberi spasi atau ringkas, dan mengapa teks kanan ke kiri berbeda
Padding sepadan pada dokumen yang disunting orang dan berbiaya di dalam repositori. Setiap sel yang memanjang membuat seluruh kolomnya diisi ulang, sehingga perubahan satu kata muncul di diff sebagai perubahan pada semua baris tabel. Bentuk ringkas menulis tabel tersempit yang masih sah — tanpa padding, tiga tanda hubung per kolom — dan menjaga diff tetap terbatas pada baris yang benar-benar berubah. Keduanya dirender sama persis. Garis tegak di awal dan akhir tiap baris bersifat opsional dalam Markdown milik GitHub tetapi diwajibkan oleh sebagian perender lama, jadi ia dibuat sebagai sakelar, bukan keputusan.
Padding sama sekali tidak bisa bekerja pada tabel berisi bahasa Ibrani atau Arab, dan alat ini mengatakannya alih-alih berpura-pura. Spasinya dihitung dengan benar, tetapi penyunting menata baris campuran memakai algoritme dwiarah: potongan yang mengalir dari kanan ke kiri disusun ulang, dan garis tegak di sekitarnya ikut bergeser. Karakternya berada di tempat yang benar dan garis tegaknya tetap tampak tidak sejajar, karena pada baris seperti itu posisi visual dan posisi logis bukan hal yang sama. Tidak ada yang bisa memperbaikinya, jadi ketika ada teks kanan ke kiri di dalam sel, alat ini melaporkannya dan menyarankan bentuk ringkas, tempat tidak ada perataan yang bisa mengecewakan.
Karena alasan yang sama, keluaran Markdown di halaman ini selalu ditampilkan dari kiri ke kanan, bahkan ketika Anda membaca situs ini dalam bahasa Ibrani atau Arab. Ia kode sumber, dan kode sumber punya arahnya sendiri.
Di mana ini berjalan
Semuanya terjadi di peramban Anda. Tabelnya diurai, diukur, dan dibangun ulang di mesin Anda sendiri, dan tidak ada yang Anda tempel diunggah, disimpan, atau dicatat — dan itu penting, sebab tabel yang perlu diformat ulang biasanya hasil kueri dan ekspor, bukan data publik.
Pertanyaan yang sering diajukan
- Apakah data saya dikirim ke server?
- Tidak. Penguraian, pengukuran lebar, dan keluarannya semua dihitung di peramban Anda, dan tidak ada yang Anda tempel diunggah atau dicatat.
- Bagaimana mengubah CSV menjadi tabel Markdown?
- Tempel saja. Alat ini mengenali teks yang dipisah koma, mengambil baris pertama sebagai kepala tabel, dan mengembalikan tabel Markdown yang rata. Bidang dalam tanda kutip yang memuat koma, tanda kutip, atau pergantian baris ditangani dengan benar, dan segala sesuatu yang harus ditulis ulang agar muat dalam format ini dilaporkan.
- Mengapa tabel saya yang berisi teks Jepang atau Tionghoa masih belum rata?
- Periksa fontanya. Padding mengandaikan fonta berspasi tetap yang di dalamnya sebuah ideogram tepat dua kali lebar huruf Latin, dan itulah yang dipakai terminal serta penyunting kode. Pada fonta proporsional, atau fonta yang glif CJK-nya tidak tepat dua kali lebar, tidak ada padding yang bisa meratakan kolom: di sana pakailah bentuk ringkas.
- Apa yang terjadi pada pergantian baris di dalam sel?
- Secara bawaan ia menjadi tag pemutus, karena satu baris tabel Markdown adalah satu baris dan tidak bisa memuat pergantian baris sungguhan. Ganti dengan spasi jika perender Anda membuang HTML. Bagaimanapun, alat ini melaporkan sel mana saja yang diubahnya.
- Mengapa baris saya yang selnya berlebih menambahkan kolom kosong?
- Karena pilihan lainnya adalah kehilangan sel-sel itu. Markdown milik GitHub membuang apa pun yang melewati lebar kepala tabel, jadi tabelnya justru dilebarkan dengan sel kepala kosong dan ketidakcocokannya dilaporkan. Hapus kolom itu atau beri nama setelah Anda melihat isinya.
- Sebaiknya pakai bentuk berpadding atau ringkas?
- Berpadding untuk dokumen yang dibaca dan disunting orang dengan tangan — README, catatan desain — karena sumbernya enak dibaca. Ringkas untuk apa pun yang berada di bawah kendali versi dan tabelnya sering berubah: dengan padding, satu sel yang disunting membuat seluruh kolom terisi ulang dan muncul di diff seolah semua barisnya berubah.
- Apakah saya perlu garis tegak di awal dan akhir tiap baris?
- Markdown milik GitHub tidak mengharuskannya, begitu pula sebagian besar perender modern. Beberapa pengurai lama mengharuskannya, dan garis itu membuat tabel yang disunting dengan tangan lebih mudah dibaca, jadi ia menyala secara bawaan dan bisa dimatikan.
- Mengapa alat ini tidak bisa meratakan tabel berisi bahasa Ibrani atau Arab?
- Karena penyuntingnya menyusun ulang barisnya. Tata letak dwiarah menempatkan potongan kanan ke kiri dalam urutan visual, dan garis tegak di sekitarnya ikut bergeser, sehingga paddingnya benar secara aritmetika dan tidak berguna secara visual. Alat ini melaporkannya dan menyarankan bentuk ringkas alih-alih menghasilkan tabel yang tampak rusak.