Markdown tablo oluşturucu

Dört giriş, tek çıkış

Markdown tablosu yazması kolay, bakması çilelidir. Bir hücreye tek bir kelime eklemek altındaki bütün dikey çizgileri kaydırır; elinizde zaten olan verilerden — bir sorgu sonucundan, bir hesap tablosu dışa aktarımından, bir API yanıtından — tablo kurmak ise her şeyi elle yeniden yazmak demektir. Bu araç veriyi hangi biçimdeyse o biçimde alır ve GitHub lehçesinde temiz bir Markdown tablosu döndürür.

Dört biçim okur ve hangisine karar verdiğini sessizce belirlemek yerine size söyler:

• Markdown tablosu; hizası bozulmuş bir tablo olduğu gibi yapıştırılır ve düzelmiş olarak geri gelir.
• CSV, RFC 4180'e göre ayrıştırılır — tırnak içindeki bir alan virgül, tırnak ve hatta satır sonu içerebilir, hepsi korunur.
• TSV; bir hesap tablosundan ya da bir veritabanı istemcisinden aralık kopyaladığınızda elinize geçen budur.
• JSON dizisi; nesnelerden oluşuyorsa anahtarlar sütun olur, dizilerden oluşuyorsa ilk satır başlık olur.

Algılama önce en ayırt edici kanıta bakar: baştaki köşeli parantez ancak JSON olabilir, tirelerden oluşan bir satır ancak Markdown ayraç satırı olabilir, ilk satırdaki sekme ancak TSV olabilir. Virgülle ayrılmış olan geriye kalandır, bu yüzden bir buluş olarak değil geri düşülen seçenek olarak bildirilir — araç tahmin etmek zorunda kaldıysa bunu söyler ve biçim seçici onun üstündedir.

Çıktı Markdown'dır, yalnızca Markdown. Bir tabloyu CSV ya da JSON'a geri çevirmek başka bir iştir ve bu sitede onu yapan araçlar zaten var; ikinci bir genel amaçlı dönüştürücü yalnızca onlarla yarışır ve bu sayfayı anlatmayı zorlaştırırdı.

Hücre uzunluğuna göre değil genişliğine göre doldurulur

Çizgileri hizalamak, bir sütundaki her hücreyi aynı genişliğe kadar doldurmak demektir; bunun için de hücrenin ne kadar geniş olduğunu bilmek gerekir. Akla ilk gelen yanıt — karakterleri say — dünyadaki yazı sistemlerinin çoğu için yanlıştır, üstelik iki yönde birden yanlıştır.

Eşaralıklı bir yazı tipi «bir karakter, bir sütun» demek değildir. Bir Çin ya da Japon ideogramı, bir kana, bir Hangul hecesi, tam genişlikte bir Latin harfi ve neredeyse her emoji, bir Latin harfinin tam iki katı genişliğinde çizilir. Birleşen bir işaret ise — bir aksan, bir İbranice sesli işareti, bir Arapça hareke — kendinden önceki harfin üstüne çizilir ve hiç genişlik kaplamaz. Karakter sayısına göre doldurun, Japonca bir sütun kısa, aksanlı metinden oluşan bir sütun uzun çıkar.

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

Bu yüzden doldurma görüntü sütunlarıyla ölçülür. Metin önce grafem kümelerine ayrılır — okurun tek karakter saydığı birim, böylece birkaç kod noktasının birleşmesinden oluşan bir emoji tek parça kalır — ve her küme Unicode karakter veritabanındaki East_Asian_Width özelliğiyle karşılaştırılır. Bu özellik, tarayıcının kendi başına yanıtlayamadığı tek şeydir: JavaScript kategoriyi, yazı sistemini ve harf durumunu düzenli ifadelerle açar ama bunu açmaz, bu yüzden geniş aralıkları içeren küçük bir tablo sayfayla birlikte gönderilir. Geri kalan her şey motordan gelir.

Bir kategori bilerek dar sayılır. Unicode bir grup karakteri — kutu çizim işaretlerini, bazı Yunan ve Kiril harflerini, birkaç noktalama işaretini — «belirsiz» olarak işaretler: eski bir Doğu Asya yazı tipinde geniş, başka her yerde dar. Markdown dosyası öntanımlı yazı tipi Latin olan bir düzenleyicide okunur, dolayısıyla bunlar tek sütun sayılır; dosyayı açacağınız uçbirimler ve düzenleyiciler de tam olarak bunu yapar.

Markdown tablosunun taşıyamadıkları

Biçimin iki katı sınırı var ve gerçek veriler ikisine de çarpar. Bir hücre çıplak dikey çizgi içeremez, çünkü hücreleri ayıran şey odur; kaçışlanarak yazılması gerekir. Ve bir tablo satırı tek bir satırdır, dolayısıyla hücre satır sonunu hiç taşıyamaz — oysa bir CSV alanının buna tam hakkı vardır.

İkisi de yeniden yazılır ve her yeniden yazma, etkilenen hücre sayısı ve ilkinin konumuyla birlikte bildirilir. Mesele de budur: iki satırlık adresinizi sessizce tek satıra indiren bir araç, size söylemeden verinizi bozmuştur. Satır sonu öntanımlı olarak bir satır sonu etiketine dönüşür; GitHub, GitLab ve işleyicilerin çoğu bunu hücre içinde yeni satır olarak gösterir. İşleyiciniz HTML'i temizliyorsa bunun yerine boşluğa geçin.

Başlıktan uzun satır üçüncü durumdur. GitHub lehçesi fazla hücreleri öylece atar ve bu, sessiz bir veri kaybıdır. Burada tablo bunun yerine boş başlık hücreleriyle genişletilir ve uyuşmazlık bildirilir — düzeltebileceğiniz tuhaf görünen bir başlık, varlığından hiç haberdar olmayacağınız bir sütundan iyidir. Başlıktan kısa satır boş hücrelerle doldurulur ve aynı şekilde bildirilir.

Ters eğik çizgiler burada çoğu araçtakinden biraz daha özenle ele alınır. Ters eğik çizgi yalnızca kendisinden sonraki dikey çizgiyi yutabileceği yerde ikiye katlanır: metindeki bir dikey çizginin önünde ya da ayracın geldiği hücre sonunda. Başka her yerde olduğu gibi bırakılır, böylece hücredeki bir Windows yolu çift ters eğik çizgi dizisine dönüşmek yerine okunur kalır.

Hizalama ayraç satırında yaşar

Başlığın altındaki tire satırı iki iş görür. Bloğu en baştan bir tablo yapan odur ve üzerindeki iki noktalar her sütunun hizasını belirler: solda iki nokta sola, sağda iki nokta sağa hizalar, iki yanda iki nokta ortalar. İki nokta yoksa işleyici kendi öntanımını kullanır; bu her uygulamada soldur ama sola hizala demekle aynı şey değildir.

Burada her sütunun kendi denetimi var, çünkü hizalama gerçekte böyle kullanılır: metin solda, sayılar sağda, durum sütunu ortada. Ve içinde zaten hizalama olan bir tabloyu yapıştırdığınızda bu, ayraç satırından okunup o denetimlerde gösterilir; böylece mevcut bir tabloyu yeniden biçimlendirmek, birinin üzerinde yaptığı işi hiçbir zaman sessizce atmaz.

Doldurma da hizalamayı izler. Sağa hizalı sütun soldan doldurulur, böylece kaynak, işlenmiş tablonun görüneceği gibi görünür. Markdown o boşlukları tümüyle yok sayar; kaynağı okunur kılmak için onları bedelsiz harcayabilmenizin nedeni de tam olarak budur.

Doldurulmuş mu sıkışık mı, ve sağdan sola yazılan metin neden farklı

Doldurma, bir insanın elle düzenlediği belgede değer, bir depoda ise bedel taşır. Büyüyen her hücre bütün sütununu yeniden doldurur, dolayısıyla tek kelimelik bir değişiklik farkta tablonun bütün satırlarının değişmesi olarak görünür. Sıkışık biçim izin verilen en dar tabloyu yazar — doldurma yok, sütun başına üç tire — ve farkı gerçekten değişen satırlarla sınırlar. İkisi de aynı şekilde işlenir. Her satırın başındaki ve sonundaki çizgiler GitHub lehçesinde isteğe bağlıdır ama bazı eski işleyiciler bunları zorunlu tutar, bu yüzden bir karar değil bir anahtardır.

İbranice ya da Arapça içeren bir tabloda doldurma hiç işe yaramaz ve araç bunu gizlemek yerine söyler. Boşluklar doğru sayılır ama düzenleyici karışık bir satırı iki yönlü algoritmayla yerleştirir: sağdan sola akan bölüm yeniden sıralanır ve çevresindeki çizgiler onunla birlikte kayar. Karakterler doğru yerlerdedir ve çizgiler yine de hizalı görünmez, çünkü böyle bir satırda görsel konum ile mantıksal konum aynı şey değildir. Bunun çaresi yok; hücrede sağdan sola yazılan metin olduğunda araç bunu bildirir ve hayal kırıklığına uğratacak bir hizalamanın hiç bulunmadığı sıkışık biçimi önerir.

Aynı nedenle bu sayfadaki Markdown çıktısı, siteyi İbranice ya da Arapça okurken bile her zaman soldan sağa gösterilir. O bir kaynak koddur ve kaynak kodun kendine ait bir yönü vardır.

Nerede çalışır

Her şey tarayıcınızda olur. Tablo sizin makinenizde ayrıştırılır, ölçülür ve yeniden kurulur; yapıştırdığınız hiçbir şey yüklenmez, saklanmaz ya da günlüğe yazılmaz — bu önemlidir, çünkü insanların yeniden biçimlendirmesi gereken tablolar genellikle açık veri değil sorgu sonuçları ve dışa aktarımlardır.