Kimin için · Evgeny K.

Yolculuğu bozulmadan tamamlayan tablolar

Genel HTML’den Markdown’a dönüştürücüler tam da önemli tablolarda kırılır. Clean Web Clipper kendi GFM tablo yazıcısını kullanır ve hücre içeriğini düzleştirir: teknik korpusta on beş tablonun on ikisi korundu, karşılaştırılan her motorda yedi.

Bu sayılar nereden geliyor: motor sürümleri ve tarihleriyle ölçüm

Kırılan hep önemli tablo oluyor

Bir raporun ya da dokümantasyonun içindeki tabloyu kaydedersiniz; notu açtığınızda sütunlar kaymış, bir satır tek hücreye çökmüş, başlık satırı veriyle karışmıştır. Kırılan tablo da genellikle sayfanın en değerli parçasıdır: eşikler, oranlar, sınırlar. Kalan metin okunur ama çalışılamaz.

Sebep çoğu zaman aynı: hücrenin içinde bir liste, bir bağlantı ya da bir kod örneği vardır. Genel dönüştürücüler böyle bir hücreyle karşılaşınca satırı düşürür ya da hücre sınırlarını kaybeder. Elle onarmak da mümkündür, ama on tablodan sonra kaydetmenin sağladığı zaman geri ödenmiş olur.

Elle yeniden yazmanın çok sonra ortaya çıkan üçüncü bir bedeli var. Bir tabloya elle girilmiş sayı kaynak, tarih ya da doğrulama yolu taşımaz – altı hafta sonra D14 hücresindeki saklama süresinin sayfadan ocakta mı martta mı okunduğunu kimse söyleyemez, sayfa da o arada iki kez düzenlenmiştir. Fiyatlar, istek sınırları ve kotalar duyurusuz değişir. Üstünde kaynak adresi ve sayfanın bildirdiği tarih duran bir tablo bu soruyu yanıtlar; bir sonraki çeyrekte aynı sayfayı yeniden kaydedip iki dosyayı karşılaştırdığınızda da yeniden yanıtlar.

Tablolarda ne değişir

• Genel bir eklenti değil, kendi GFM tablo yazıcısı – hücre içeriği düzleştirilir, satır düşürülmez
• Teknik korpusta on beş tablonun on ikisi korundu; karşılaştırılan her motorda yedi
• Düzensiz iki sütunlu tablolar kırık ızgara yerine Anahtar: değer satırlarına dönüşür
• Yerleşim tabloları – yalnızca konumlandırma için kurulmuş ızgaralar – yeniden üretilmez, açılır
• Sayılar, eşikler ve birimler okunabilir yerlerinde kalır; başlık satırı veriyle karışmaz
• Yalnızca tabloyu almak isterseniz sayfada seçin, seçim kaydedilir
• Kaynak adresi ve sayfanın bildirdiği tarih tablonun üstünde durur; sayılar dosyaladığınız günü değil geçerli oldukları tarihi taşır
• Aynı sayfanın ikinci kaydı sayı eki alır, üzerine yazılmaz – çeyreklik karşılaştırmayı mümkün kılan da bu

| Değişken | Tanım | Birim |
| --- | --- | --- |
| Nüfus | Yıl sonu itibarıyla ikamet kaydı bulunan kişi sayısı | kişi |
| Yıllık nüfus artış hızı | Bir önceki yıla göre değişim | ‰ |
| Yaş bağımlılık oranı | Çalışma çağı dışındaki nüfusun çalışma çağındakine oranı | % |

Tablolar için kurulum

İki ayar ve bir alışkanlık. Alışkanlık – kaydetmeden önce aşağı kaydırmak – hiçbir ayarın kurtaramayacağı kadar çok satır kurtarır.

1. Eklenti simgesinden Seçenekler’i açın ve hedefi çalışma verisinin durduğu klasöre yöneltin – onu kullanan not defterinin ya da elektronik tablonun yanındaki data/sources.
2. Simge tıklamasını önizleme penceresi olarak bırakın. Dosyalanmadan önce bakmaya değer tek şey tablodur: sütunların hizalı olup olmadığı tek bakışta görünür, klasör listesinde hiç görünmez.
3. Dosya adı şablonunu {date}-{domain}-{title} yapın; ocakta ve nisanda kaydedilen aynı fiyat sayfası yan yana sıralanan iki dosya olur.
4. Frontmatter’da source ve date alanlarını açın. Geldiği adresi taşımayan bir tablo, birinin eninde sonunda yeniden türetmek zorunda kalacağı bir sayı yığınıdır.
5. Kaydetmeden önce tablonun sonuna kadar kaydırın. Kaydırdıkça yüklenen satırlar yüklenene kadar DOM’da yoktur ve eklenti DOM’u kaydettiğiniz anda okur.
6. Çevredeki makale gereksizse tabloyu sayfada seçin ve seçimi kaydedin. Pencerenin üstündeki anahtar, sayfanın tamamına değil seçime baktığınızı doğrular.
7. Sayıları değişen sayfalar için takvime tekrarlanan bir kayıt koyun: kotalar, fiyatlar, saklama süreleri. Arşivin değeri ilk kayıtta değil ikincisindedir.

Yeniden kullanacağınız sayılar için ayarlar

Aşağıdaki her değerin amacı şu: altı ay sonra okunan bir tablo nereden ve ne zaman geldiğini hâlâ söylemeli.

**Kapsam**: Türkiye’de ikamet eden hanehalkı fertleri.

**Referans dönemi**: Takvim yılı.

**Yayımlama sıklığı**: Yıllık.

**Revizyon politikası**: Yeni bilgi geldiğinde geçmiş dönemler yeniden
hesaplanır.

Özgün sayfada bunlar iki sütunlu bir tabloydu, ama satırların bir kısmı
üç hücreli, bir kısmı tek hücreliydi. Kırık bir ızgara üretmek yerine
her satır `**Anahtar**: değer` biçimine açıldı.

Üç tablo, üç sonuç

Fiyat sayfasından karşılaştırma tablosuna

Dört sağlayıcı, dört fiyat sayfası, dört kayıt. Her tablo GFM tablosu olarak geliyor: plan adları, tutarlar ve sınırlar bulundukları hücrelerde, kaynak adresi de üstünde. Karşılaştırma tablosu tek bir sayı yeniden yazılmadan kuruluyor.

Tablo yazıcısının varlık sebebi burası – genel dönüştürücüleri kıran hücreler dipnot işareti, dahil özellikler listesi ya da kod örneği taşıyanlardır. On beş tablolu teknik korpusta burada on iki tablo sağ kaldı, karşılaştırılan her motorda yedi.

Aynı sayfa, bir çeyrek arayla

Bir sağlayıcının istek sınırlarını şubatta ve mayısta kaydettiniz. İkinci dosya sayı eki aldı. Fark, başlangıç planında ani yük hakkının yarıya indiğini ve üst planda saklama süresinin uzadığını gösteriyor – ikisi de hiçbir yerde duyurulmamış.

Şubat dosyası olmadan değişiklik kanıtlanamaz, çünkü sayfa yalnızca bugünkü hâlini gösterir ve önceki sayılar sağlayıcının yayımladığı hiçbir yerde durmaz. Yöntemin tamamı, ilk kaydın önemli olacağı bilinmeden alınacak kadar ucuz olmasına dayanır.

Tablo olamayacak bir ızgara

Bir belirtim sayfası yirmi başlığı, birleşik başlık hücreleri ve bir satırında iç içe liste olan iki sütunlu bir ızgarada tanımlıyor. Markdown tablosu olarak üretilse çökerdi; bunun yerine altında değerleri olan kalın anahtar satırları olarak geliyor – okumak da aramak da kayıpsız.

Bu davranış bir yedek arıza değil, bilinçli. Düzensiz iki sütunlu tablolar veri olmaktan çok ızgara giymiş tanım listeleridir; kırık bir tabloyu onarmak, bir listeyi okumaktan zordur.

Bir tabloyu taşımanın alışılmış yollarına karşı

Bunların hepsi sayfadan sayı alır. Farkları, sayılarla birlikte neyin geldiği ve sonrasında sizin ne yapmanız gerektiğidir.

Tablo doğru çıkmadığında

Birleşik hücreler neden gitti?

Markdown’da birleşik hücre yoktur, bu yüzden colspan ve rowspan düzleştirilir – içerik korunur, görsel birleşme korunmaz, çünkü biçim bunu ifade edemez. Üç sütuna yayılmış bir başlığın metni ilk sütuna düşer. Bu dönüşümün değil hedef biçimin bir özelliğidir; hiçbir Markdown tablosu bunu ifade etmez.

Satırların yarısı neden eksik?

Eklenti DOM’u kaydettiğiniz anda okur; sayfanın kaydırdıkça yüklediği, “daha fazla göster” düğmesiyle sunduğu ya da sayfalara böldüğü satırlar siz yükletmedikçe henüz yoktur. Sonuna kadar kaydırın, açılanları açın, sonra kaydedin. Sayfalanmış bir tabloda her sayfayı ayrı kaydedin – parçalar sonradan birleştirilebilir; tarayıcının hiç almadığı satırları başka hiçbir şey kurtaramaz.

Veri yerine neden bir gezinme ızgarası geldi?

Bu bir yerleşim tablosu: eski sitelerin çoğunun menü ve başlık için hâlâ kullandığı, yalnızca konumlandırmaya yarayan bir ızgara. Bunlar dönüştürülmez, açılır; içerik ızgarasız gelir. Bir gezinme ızgarası nota yine de tablo olarak girdiyse, sayfa onu veri tablosu olarak işaretlemiştir – işaretleme “veri” demiş, eklenti de inanmıştır.

Tablo neden anahtar–değer satırları olarak çıktı?

Bu, düzensiz iki sütun yolu. Satırları eşit olmayan iki sütunlu bir tablo genellikle ızgara olarak çizilmiş bir tanım listesidir; onu tablo olarak üretmek okunur değil kırık bir ızgara verir. İçerik eksiksizdir: kalın anahtar, altında değer, özgün sırada. Gerçek bir tabloya ihtiyacınız varsa çiftler mekanik olarak geri dönüştürülebilir.

Yapmadıkları

Sayı işlemez: hesap yapmaz, birim çevirmez, biçimlendirilmiş sayıları ayrıştırmaz – metinde ne yazıyorsa o gelir. CSV ya da XLSX üretmez; çıktı Markdown tablosudur. Birleştirilmiş hücreler düzleştirilir, çünkü Markdown bunu ifade edemez. JavaScript ile sayfalanan tablolarda yalnızca o anda çizili olan sayfa alınır; grafikler görsel oldukları için bağlantı olarak kalır.

Sorular