Gwtar: Statik ve Verimli Tek Dosyalı HTML Biçimi

 (gwern.net)
1 puan yazan GN⁺ 2026-02-17 | 1 yorum | WhatsApp'ta paylaş
  • Web tarayıcısının verimli biçimde gecikmeli yükleme (lazy-loading) yapabildiği tek HTML arşiv dosyası biçimi; tüm varlıkları içerirken aynı anda statiklik, tek dosya yapısı ve verimlilik sağlıyor
  • HTML ve JavaScript başlığının arkasına tarball biçimindeki özgün HTML ve varlıkları birleştiren; JS'nin HTTP Range istekleriyle yalnızca gereken bölümleri yüklediği bir yapı
  • Mevcut SingleFile veya MHTML gibi çözümler statiklik ve tek dosya özelliğine sahip olsa da verimlilikten yoksundu; Gwtar bunu çözüyor
  • Sunucu tarafında ek yapılandırma olmadan yalnızca standart tarayıcı özellikleriyle çalışıyor; Cloudflare gibi bazı ortamlarda MIME türü x-gwtar kullanılıyor
  • Büyük HTML sayfalarında korunabilirlik ve erişilebilirliği aynı anda sağlayarak, uzun vadeli web arşivleme ve yeniden üretilebilir araştırma materyali saklama için faydalı oluyor

Gwtar genel bakış

  • Gwtar, tek bir HTML dosyasından oluşan yeni bir polyglot arşiv biçimi; tarayıcı HTTP Range istekleriyle yalnızca gereken kısımları yüklüyor
    • Gwern.net'in büyük HTML arşivlerini sunmak için kullanılıyor
  • HTML başlığındaki JS, dosyanın tamamının indirilmesini durduruyor ve gerekli varlıkları kısmi istekler (range request) ile yüklüyor
  • Sonuçta sunucu yalnızca tek bir HTML dosyası sunuyor, ancak kullanıcı sadece ihtiyaç duyduğu varlıkları indiriyor
  • Tüm işlevler standart tarayıcı özellikleriyle gerçekleştirildiğinden geleceğe dönük uyumluluk sağlanıyor

HTML arşivlerinin üçlü ikilemi

  • HTML arşivlerinde statiklik, tek dosya olma, verimlilik özelliklerinden yalnızca ikisini karşılayabilen mevcut bir sınırlama var
    • Örnek: SingleFile statik ve tek dosyalı ama verimsiz; WARC statik ve verimli ama tek dosya değil
  • SingleFile ile oluşturulan anlık görüntüler eksiksiz statik sayfa sunuyor, ancak tüm varlıkları Base64 olarak satır içi eklediği için dosya boyutu yüzlerce MB'a çıkıyor
  • Kullanıcı sayfanın yalnızca bir kısmına baksa bile tüm dosyayı indirmek zorunda kalıyor; bu da verimsizlik yaratıyor
  • Gwern.net bunu çözmek için deconstruct_singlefile.php ile varlıkları ayırdı, ancak tek dosya olma özelliği kayboldu

Gwtar'ın teknik yaklaşımı

  • HTTP Range istekleri kullanılarak dosyanın yalnızca bir bölümünü seçerek indirmek mümkün oluyor
  • HTML + JS başlığının arkasına tarball ekleyen ardışık (concatenated) arşiv yapısı benimseniyor
  • JS'nin window.stop() komutuyla başlıktan sonraki indirme durduruluyor ve sadece gerekli varlıklar isteniyor
  • Tarayıcı bunu normal HTML gibi render ediyor; JS de varlık isteklerini yakalayıp Range isteklerine dönüştürüyor

Üretim ve uygulama

  • PHP betiği deconstruct_singlefile.php ile SingleFile HTML, Gwtar'a dönüştürülebiliyor
    • JPG/PNG/GIF yeniden sıkıştırması ve PAR2 FEC (ileri hata düzeltme) verisi ekleme desteği var
  • Tarayıcı, JS çalıştıktan sonra gereken varlıkları yalnızca Range istekleriyle yüklüyor; JS devre dışıysa tam dosya indirme yedek seçenek oluyor
  • Standartlara dayandığı için sunucu yapılandırması veya ek yazılım gerektirmiyor; tek dosyadan yeniden çok dosyalı HTML'ye geri dönüştürülebiliyor

Performans ve uyumluluk

  • Range istekleri desteklenmiyorsa tüm dosya indiriliyor, ancak gzip/Brotli sıkıştırması hız konusunda kısmen telafi sağlayabiliyor
  • Cloudflare, text/html yanıtlarındaki Range üstbilgisini kaldırdığı için Gwern.net bunu MIME türünü x-gwtar yaparak aşıyor
  • Yerelde dosyayı görüntülemek mümkün değil :
    • Bu durum SingleFileZ için de geçerli; çünkü tarayıcı güvenlik politikaları (CORS vb.) JS isteklerini engelliyor
    • Talihsiz olsa da bunun kabul edilebilir bir ödünleşim olduğu düşünülüyor; yerel gezinme ise JS'ye bağımlı olmayan bir dosyaya dönüştürülerek çözülebilir

Genişletme özellikleri

  • Gwtar dosyasının sonuna ek ikili veri (ör. FEC, imza, meta veri) eklenebiliyor
  • PAR2 kullanılarak dosyanın bir kısmı bozulduğunda kurtarma yapılabiliyor
  • GPG imzası HTML yorum biçiminde eklenerek bütünlük doğrulaması yapılabiliyor
  • Gelecek sürümlerde varlık hash doğrulaması, otomatik prefetch, yerleşik sıkıştırma, çoklu sayfa desteği gibi planlar bulunuyor

Olası kullanım alanları

  • Büyük HTML sayfaları veya araştırma veri kümeleri (ör. SQLite3) içeren yeniden üretilebilir bilimsel çalışmalar için uygun
  • Veritabanı, tarayıcıda doğrudan Range istekleriyle yüklenip analiz edilebiliyor
  • Uzun vadeli korunabilirlik ve erişilebilirliği aynı anda sağlayan bir web arşivleme biçimi olarak öneriliyor

Lisans ve gelecekteki geliştirmeler

  • Gwtar belgeleri ve kodu CC-0 public domain olarak yayımlanmış
  • Gelecek sürümde (v2) FEC'in zorunlu hale gelmesi, yerleşik sıkıştırma, çoklu belge desteği, yinelenen verilerin kaldırılmasının iyileştirilmesi gibi başlıklar değerlendiriliyor

İlgili okumalar

1 yorum

 
GN⁺ 2026-02-17
Hacker News yorumları

  • Bugün ilk kez window.stop() diye bir şey öğrendim
    Bu işlev, tarayıcının artık kaynak yüklemeyi durdurmasını sağlar
    Başlıca tarayıcılar bunu zaten 10 yıldan uzun süredir destekliyor (MDN belgesi, Can I Use)
    Kullanım örneği bu ekran görüntüsünde görülebilir
    Daha fazla ayrıntıyı blog yazımda toparladım

    • SPA geliştiricisiyseniz bunun document.write veya window.open gibi API'lerden daha iyi olduğunu söylemek zor
      Yine de sunucu merkezli mantıkta indirme ya da lazy-loading işini doğrudan uygulamaya çalışıyorsanız ilginç bir yaklaşım olabilir
      Başlatma ya da yönlendirme scriptleri gibi özel durumlar dışında önermek zor
    • Bunun Claude Artifacts ile uyumlu olup olmayacağını merak ediyorum
      Ben kendi bundler'ım üzerinden dosyaları sıkıştırılmış base64 parçaları halinde yayımlıyorum; buna benzer bir yaklaşım
      Eğer böyle tek dosyalı paylaşım ortamlarında çalışırsa, platformun bunu engelleyebileceğini düşünüyorum
    • Ben de bu özelliği ilk kez duydum
      PHP'de de benzer bir __halt_compiler() özelliği var; dosyanın sonuna yorum kullanmadan belge veya veri eklemek gerektiğinde kullanmıştım

  • Başta ilginç gelmişti ama bu biçimin yerel dosya olarak doğrudan açılamadığını görünce tereddüt ettim
    Arşivleme formatıysa yerel erişim temel kullanım senaryolarından biri olmalı

    • Ben de öyle düşünüyorum. Tıpkı asm.js gibi, tarayıcıya gömülü özelliklerden yararlanarak yeni imkânlar açabilir diye ummuştum
      Ama yerelde doğrudan açılamıyorsa bu avantajın büyük kısmı kayboluyor (backdoor pilot kavramına bakın)
    • Bunu bir görüntüleyici program veya basit bir statik HTML sunucusu ile çözmek mümkün olabilir diye düşünüyorum
    • Aslında HTML'nin kendisi zaten harika bir tek dosya formatı
      Görseller, CSS ve JS'nin hepsi data-uri ile gömülebilir; fontlar da aynı şekilde
      Hatta kelime işlemci belge formatları HTML kullansaydı daha esnek olurdu diye düşünüyorum
    • python -m http.server gibi bir komutla yerel sunucu açıp kolayca çözülebilir
      Claude komutuyla da yapılabilir

  • Yazar bunu görürse, arşiv formatına bir BASE64 ekran görüntüsü alanı, bir açıklama alanı ve bir ISO zaman damgası eklemesini isterdim
    Hatta aynı URL'nin birden fazla sürümünü saklayabilse ve yinelenen varlık kaldırma özelliği olsa ideal olurdu

  • Yazarın WARC'a neden olumsuz baktığını anlamadım
    Bana kalırsa Gwtar daha karmaşık ve daha az esnek görünüyor

    • Ama WARC, tarayıcıda doğrudan tıklayıp içeriği görüntüleyebileceğiniz bir URL veremiyor
    • Başka bir yorumda söylenen gerekçe şu: WARC/WACZ statik ve verimli, ama tek bir dosya olarak doğrudan görüntülenemiyor ve WebRecorder gibi ayrı, daha karmaşık bir kurulum gerektiriyor

  • SingleFile'in ZIP/HTML polyglot formatı için neden “statik ve tek dosyalı ama verimsiz” dendiğini merak ediyorum
    Gwtar'a kıyasla hangi açıdan daha verimsiz olduğunu öğrenmek isterdim

    • Buradaki verimlilik, yalnızca gereken varlıkları kısmi olarak indirebilme yeteneği anlamına geliyor
      Asıl mesele, tarayıcının tüm dosyayı indirmeden ihtiyaç duyduğu parçaları range request ile alabilmesi

  • Gerçekten harika bir fikir
    Ben tek dosyalı HTML web uygulamalarının en uzun ömürlü yazılım biçimi olduğunu düşünüyorum
    Benim yaptığım örnekler arasında FuzzyGraph ve HyperVault var

  • Ben de benzer bir şeyi Service Worker düzeyinde uygulamayı düşünmüştüm
    Sayfayı olduğu gibi bırakıp tüm HTTP isteklerini yakalama fikriydi
    window.stop() gibi, HTML'nin bir kısmını alıp geri kalanını varlık blob'ları olarak işleyen bir yapı
    Service Worker'ın kendisini dataURI olarak gömersiniz, böylece tamamen tek dosya olur

  • İlginç ama yerel dosyada lazy load neden gerekli, tam anlayamadım
    Dosyanın bu kadar büyük olması mı bekleniyor? Yoksa zaten uygulanmış işlevselliği olduğu gibi korumak mı amaçlanıyor?

    • Aslında hedef yerel değil, HTTP sunucusundaki büyük dosyalar
      Ağ üzerinden tamamını almadan sadece gereken parçaları istemek için range request gerekiyor
      Elbette bunu birden fazla dosyaya bölmek daha yaygın, ama bazen tek dosya yönetimi daha pratik olabiliyor
      Muhtemelen Gwern'in MediaWiki tabanlı sitesi yapısıyla da ilgilidir

  • Ben de yıllar önce benzer bir şey yapmıştım — Zundler adlı bir projeydi ve oldukça hacky bir yaklaşımdı
    Yerelde de çalışıyor ama başta tüm arşivin açılması gerekiyor

    • Bu, SingleFileZ gibi tek dosyalı statik HTML arşivi ama yerelde de kolay görüntülenebilen bir biçim gibi görünüyor
      Yalnız güvenlik kısıtlamalarını nasıl aştığını merak ediyorum
      Açıklamada yalnızca tek kaynaklılık (single-origin) ile ilgili bir şeyler yazıyor, o yüzden tam kavrayamadım