Alan adlarının sıkıştırılması

Bir kişinin rastgele bir IDN ana bilgisayar adının ( RFC5890 tarafından tanımlandığı gibi ) etki alanını nasıl çok sıkı bir şekilde sıkıştırabileceğini ve bunun ilginç bir meydan okuma olabileceğinden şüpheleniyorum. Bir Unicode ana bilgisayar veya etki alanı adı (U-etiketi), genellikle üst düzey etki alanına (ör. Altındaki Yunanca harfler ) bağlı olarak bir dille sınırlandırılmış (karşılık gelen bir ASCII dizesi ) bir Unicode karakter dizisinden oluşur. Bir etiket)..grxn--

Veri modelleri sadece resmi gereksinimlerden değil

Unicode olmayan her etiket bir dize eşleşmesi olabilir ^[a-z\d]([a-z\d\-]{0,61}[a-z\d])?$;
her A etiketi bir dize eşleşmesi ^xn--[a-z\d]([a-z\d\-]{0,57}[a-z\d])?$; ve
tüm alanın toplam uzunluğu ('.' sınırlayıcılarıyla birleştirilmiş A etiketleri ve IDN olmayan etiketler) 255 karakteri geçemez

aynı zamanda aşağıdakiler de dahil olmak üzere çeşitli buluşsal yöntemlerden:

daha düşük dereceli U-etiketleri, daha kısa ifadeler tercih edilerek , uygun isimler ve sayılar (tire hariç noktalanmamış , boşluk bırakılmış ve Nameprep başına katlanmış ) dahil olmak üzere bazı doğal dillerde genellikle sözcüksel, sözdizimsel ve anlamsal olarak geçerli ifadelerdir; ve
yüksek dereceli etiketler bir SLD ve TLD sözlüğünden çizilir ve alt dereceli etiketlerde hangi doğal dilin kullanıldığını tahmin etmek için bağlam sağlar.

Verilerin bu belirli özelliklerini dikkate almadan bu tür kısa dizelerin iyi bir şekilde sıkıştırılmasının zor olacağından ve ayrıca mevcut kütüphanelerin daha genel kullanım durumlarını karşılamak için gereksiz ek yük üreteceğinden korkuyorum.

Matt Mahoney'in çevrimiçi kitap Veri Sıkıştırma açıklanması Açıklandığı gibi , daha az spesifik araçlara kıyasla çok daha üstün sıkıştırma ile sonuçlanması gereken yukarıdaki (ve / veya diğer) modelleme varsayımlarından yararlanmak için bir takım mevcut tekniklerin kullanılabileceği açıktır.

Bağlam yoluyla, bu soru SO üzerinde bir öncekinden bir sorun .

İlk düşünceler

Bu sorunun çevrimdışı eğitim için mükemmel bir aday olması beni şaşırtıyor ve aşağıdaki satırlarda sıkıştırılmış bir veri formatı öngörüyorum:

Yayınlanmış bazı alan adı kaydı veya trafik hacimleri kaynağından alınan olasılıklarla " genel soneki " bir Huffman kodlaması ;
Geri kalan U-etiketleri için (doğal dil) modelinin kullanıldığı bir Huffman kodlaması, etki alanı son ekinin bağlamı verilen yayınlanmış bazı etki alanı kaydı kaynağından veya trafik hacimlerinden alınmış olasılıklar;
Belirtilen doğal dil modelinden bazı sözlük tabanlı dönüşümler uygulayın; ve
U etiketlerindeki her karakterin aritmetik kodlaması, çevrimdışı eğitimden türetilen bağlamsal olarak uyarlanabilir doğal dil modellerinden çizilen olasılıklarla (ve belki de çevrimiçi olsa da, verilerin anlamlı bir içgörü sağlamak için çok kısa olabileceğinden şüpheleniyorum).

— eggyal
kaynak

Belki de tüm alan adlarının bir listesini indirebilir ve her birine bir numara atayabilirsiniz. Bu çok kompakt olurdu.

@Dietrich Epp: Gerçekten de - ve aslında, belki de kayıt şirketlerinin WHOIS'te bunun güvenilir bir şekilde inşa edilebileceği her bir kayıttan bir seri numarası yayınlayabileceğini düşündüm, ama ne yazık ki değil. Gerçekçi olarak, böyle bir veritabanının bakımındaki pratik zorlukların onu olanaksız kıldığını düşünüyorum: bu tür veritabanlarının alt etki alanlarını işlemediğinden bahsetmiyorum.

— eggyal

... bir sayı yeterliyse ipv4 / 6 adresinin 4/6 bayt'ını almanız yeterlidir: /

@arnaud: Bir sorunu tersine çevirmek - içinde doğru bir işaretçi kullanır .in-addr.arpa; IP değiştiğinde de kesilir.

— ay içinde eggyal

Dietrich Epp'in yöntemine göre (tahmini 196 metre alana dayanarak) bir alan adını 28 bit (iki unicode karakter) içinde saklayabilirsiniz ve daha iyisini yapamazsınız. Tabii ki, alan adları üzerinde bir olasılık dağılımı size çok daha iyi beklenen bit sayısı sağlayabilir. En azından 1 milyon en popüler alan için aritmetik kodlama kullanabilir ve geri kalanı için bazı geçici şema kullanabilirsiniz.

— Peter

Huffman kodlaması harfler için idealdir ve kesinlikle dizilere uyarlanabilir. Örneğin, "ab" dizisi "a" ve "b" için bitlerden daha az bitle sonuçlanırsa, sadece ağaca ekleyin ... vb.

... muhtemelen size en uygun performansla bunu yapan basit bir kütüphaneyi de kullanabilirsiniz, böylece özel yapılmış süper süslü sıkıştırma algoritmanızı kullanarak fazla kazanç elde edemezsiniz.

Bence Huffman oldukça optimal değil (en yakın bite yuvarlar): aritmetik kodlama her zaman daha iyi performans göstermelidir. Ve biri sıkıştırılmakta olan verilerin doğru bir modelini uygulamadığı sürece, her zaman en düşük sonuçları elde edecektir ... yani her bit önemliyse, genel kütüphaneler yeterli olamaz.

— eggyal

Harfler arasındaki korelasyonları görmezden gelirseniz, Huffman kodlaması asimptotik olarak en uygunudur (örneğin, a'yı görürseniz, bir qsonraki harfin, olması unormalden çok daha muhtemeldir ). Ancak bu gerçekçi bir varsayım değildir. Uygulamada, bu korelasyonlar çok büyüktür ve pratikte saf Huffman kodlamasından çok daha iyi bir şey yapmayı sağlar.

— DW

@DW kişinin nasıl daha iyisini yapabileceğine dair önerileriniz var mı? Belki de bitişik karakter çiftlerinin veya üçlülerinin Huffman aracılığıyla kodlanmasına izin verebilir mi?

— ryan