लघु पाठ तार के लिए एक कुशल संपीड़न एल्गोरिथ्म [बंद]


126

मैं छोटे पाठ स्ट्रिंग्स को संपीड़ित करने के लिए एक एल्गोरिथ्म की खोज कर रहा हूं: 50-1000 बाइट्स (यानी यूआरएल)। इसके लिए कौन सा एल्गोरिदम सबसे अच्छा काम करता है?


1
आप इन संकुचित तारों का उपयोग कहाँ करना चाहते हैं?
गमबो जूल 16'09

1
क्या यह tinyurlsस्टोरेज स्पेस के साथ कुछ करने जा रहा है?
निक

6
मैं यूआरएल को कंप्रेस करने के लिए एक एल्गोरिथ्म में दिलचस्पी रखता हूं, सबसे अच्छा संपीड़न अनुपात अधिक महत्वपूर्ण है, फिर चल रही लागत। ऑनलाइन सेवाओं में रुचि नहीं है जैसे कि टिनीलर्स या ट्रिम। मैं एक एल्गोरिथ्म की तलाश कर रहा हूं जो सेवा नहीं है। मत सोचो कि कोई अन्य जानकारी उपयोगी हो सकती है ...
वासिली कोरोलेव

3
@ गंबो: "शॉर्ट स्ट्रिंग्स के लिए टेक्स्ट कम्प्रेशन अल्गोरिद्म" एल्गो खोजने के लिए पर्याप्त है, आप यह जानने में क्यों रुचि रखते हैं कि वे किस लिए हैं? मुझे यकीन है कि ओपी को वही मिलेगा जो वह चाहता है।
डर्विन थंक

7
@Vasily, एक छोटा संकेत: जब भी आप SO पर एक प्रश्न पूछते हैं, " सबसे अच्छा XYZ क्या है ?", तो आपका प्रश्न लगभग समापन के लिए वोट प्राप्त करने के लिए बाध्य है क्योंकि सर्वश्रेष्ठ के लिए पूछने से अनावश्यक उत्पाद हो सकता है? तुलना, या सबसे खराब स्थिति में, यहां तक ​​कि युद्ध की लौ। (आमतौर पर इससे बचने के लिए केवल एक बहुत ही छोटा परिवर्तन होता है: यदि आपने एक ही प्रश्न पूछा है, जैसे "कृपया एक XYZ का सुझाव दें।", आपको मूल रूप से एक ही प्रश्न होने पर भी, कई समापन वोट नहीं मिलेंगे!)
stakx - अब

जवाबों:


62

की जाँच करें Smaz :

स्माज़ एक सरल संपीड़न पुस्तकालय है जो बहुत कम तारों को संपीड़ित करने के लिए उपयुक्त है।


17
देखें github.com/antirez/smaz/blob/master/smaz.c - यह कोडिंग का एक प्रकार है, प्रति से कम्प्रेशन नहीं (कम से कम पूरी तरह से नहीं)। वह एक स्थिर शब्द और अक्षर शब्दकोश का उपयोग करता है।
रॉय टिंकर

7
नोट: यह एंटिरेज का प्रोजेक्ट है। वह रेडिस के प्रमुख लेखकों में से एक है और उच्च गुणवत्ता, उत्पादन कोड जारी करने की बहुत मजबूत प्रतिष्ठा है।
होमर

7
Smaz एल्गोरिथ्म अंग्रेजी ग्रंथों के लिए अनुकूलित है, इसलिए यादृच्छिक स्ट्रिंग्स के लिए अच्छी तरह से काम नहीं करता है। यहाँ कुछ नमूने (हैं string:orig_size:compr_size:space_savings:) This is the very end of it.:27:13:52%, Lorem ipsum dolor sit amet:26:19:27%, Llanfairpwllgwyngyll:20:17:15%, aaaaaaaaaaaaa:13:13:0%, 2BTWm6WcK9AqTU:14:20:-43%,XXX:3:5:-67%
mykhal

4
इसके अलावा एक कम संपीड़न पर एक नज़र डालें, लेकिन एक तेज एल्गोरिथ्म shoco ed-von-schleck.github.io/shoco
डिकी सिंह

मेरी लाइब्रेरी Unishox को github.com/siara-cc/unishox की सूची में जोड़ें । यह Smaz और Shoco से बेहतर प्रदर्शन करता है और UTF-8 स्ट्रिंग्स को संपीड़ित करने का समर्थन करता है।
arun

28

हफ़मैन की एक स्थिर लागत है, हफ़मैन तालिका, इसलिए मैं असहमत हूं यह एक अच्छा विकल्प है।

अनुकूली संस्करण हैं जो इस के साथ दूर करते हैं, लेकिन संपीड़न दर पीड़ित हो सकती है। दरअसल, आपको जो प्रश्न पूछना चाहिए वह यह है कि "इन विशेषताओं के साथ पाठ स्ट्रिंग को संपीड़ित करने के लिए क्या एल्गोरिदम है"। उदाहरण के लिए, यदि लंबे दोहराव की उम्मीद है, तो सरल रन-लेनघ एन्कोडिंग पर्याप्त हो सकता है। यदि आप गारंटी दे सकते हैं कि केवल अंग्रेजी शब्द, स्थान, विराम चिह्न और सामयिक अंक मौजूद होंगे, तो हफ़मैन एक पूर्व-परिभाषित हफ़मैन तालिका के साथ अच्छे परिणाम दे सकता है।

आम तौर पर, लेम्पेल-ज़िव परिवार के एल्गोरिदम में बहुत अच्छा संपीड़न और प्रदर्शन होता है, और उनके लिए पुस्तकालय लाजिमी है। मैं उसके साथ जाऊँगा।

इस जानकारी के साथ कि क्या संकुचित किया जा रहा है URL हैं, तो मैं सुझाव दूंगा कि, संपीड़ित करने से पहले (जो भी एल्गोरिथ्म आसानी से उपलब्ध है), आप उन्हें कॉडी दें। यूआरएल अच्छी तरह से परिभाषित पैटर्न का पालन करते हैं, और इसके कुछ हिस्से अत्यधिक अनुमानित हैं। इस ज्ञान का उपयोग करके, आप URL को कुछ छोटे से शुरू करने के लिए संहिताबद्ध कर सकते हैं, और हफ़मैन एन्कोडिंग के पीछे के विचार यहाँ आपकी मदद कर सकते हैं।

उदाहरण के लिए, URL को एक बिट स्ट्रीम में अनुवाद करते हुए, आप "http" को बिट 1 से बदल सकते हैं, और बिट के साथ कुछ और "0" और उसके बाद वास्तविक प्रोटोटल (या किसी अन्य सामान्य प्रोटोकॉल को प्राप्त करने के लिए तालिका का उपयोग कर सकते हैं, जैसे https,) ftp, फ़ाइल)। ": //" को पूरी तरह से छोड़ा जा सकता है, जब तक आप प्रोटोकॉल के अंत को चिह्नित कर सकते हैं। आदि URL प्रारूप के बारे में पढ़ें, और सोचें कि कम स्थान लेने के लिए उन्हें कैसे कोडित किया जा सकता है।


4
नहीं यदि हफ़मैन तालिका सभी फ़ाइलों के लिए समान है, तो यह समझ में आएगा कि यदि फाइलें एक-दूसरे के समान हैं।
फिन जुव 16'09

1
यदि आपके पास कई, समान, छोटी फाइलें हैं, तो आप यह सब गलत कर रहे हैं। सबसे पहले, उन सभी को संक्षिप्त करें (जैसे टार करता है), और फिर उस को संपीड़ित करें। आपको बेहतर संपीड़न मिलेगा, और समस्या "50-1000 बाइट्स" होना बंद हो जाती है।
डैनियल सी। सोबरल

8
@ डैनियल: यह निर्भर करता है कि आप संपीड़ित डेटा तक यादृच्छिक पहुँच चाहते हैं या नहीं। सभी को एक साथ संपीड़ित करना सबसे संपीड़न प्रणालियों के साथ रोकता है।
स्टीव जेसप

22

मेरे हाथ में कोड नहीं है, लेकिन मुझे हमेशा आकार के 2 डी लुकअप टेबल 256 * 256 चार्ट ( आरएफसी 1978 , पीपीपी प्रिडिक्टर संपीड़न प्रोटोकॉल ) के निर्माण का दृष्टिकोण पसंद आया । एक स्ट्रिंग को संपीड़ित करने के लिए आप प्रत्येक चार पर लूप करते हैं और तालिका में अनुक्रमित के रूप में वर्तमान और पिछले चार का उपयोग करके 'पूर्वानुमानित' अगला चार्ट प्राप्त करने के लिए लुकअप तालिका का उपयोग करते हैं। यदि कोई मैच है तो आप एक सिंगल बिट लिखेंगे, अन्यथा 0 लिखें, चार और वर्तमान चार्ट के साथ लुकअप टेबल को अपडेट करें। यह दृष्टिकोण मूल रूप से डेटा स्ट्रीम में सबसे संभावित अगले चरित्र की एक गतिशील (और क्रूड) लुकअप तालिका को बनाए रखता है।

आप एक शून्य लुकअप तालिका के साथ शुरू कर सकते हैं, लेकिन यह बहुत छोटा तार पर सबसे अच्छा काम करता है यदि यह प्रत्येक चरित्र जोड़ी के लिए सबसे अधिक संभावित चरित्र के साथ आरम्भ किया जाता है, उदाहरण के लिए, अंग्रेजी भाषा के लिए। जब तक प्रारंभिक लुकअप तालिका संपीड़न और विघटन के लिए समान है, तो आपको इसे संपीड़ित डेटा में फेंकने की आवश्यकता नहीं है।

यह एल्गोरिथ्म एक शानदार संपीड़न अनुपात नहीं देता है, लेकिन यह मेमोरी और सीपीयू संसाधनों के साथ अविश्वसनीय रूप से मितव्ययी है और डेटा की एक सतत स्ट्रीम पर भी काम कर सकता है - डिकम्प्रेसर लुकअप तालिका की अपनी प्रति बनाए रखता है क्योंकि यह डिकंप्रेस होता है, इस प्रकार लुकअप तालिका डेटा के प्रकार को समायोजित किया जा रहा है।


लेकिन भविष्यवक्ता सामान्य अंग्रेजी वाक्य के साथ कैसे व्यवहार करेगा? दिए गए उदाहरण में बहुत मजबूत अतिरेक है, और लाभ कम से कम है।
डेन्यूबियन सेलर

एक 256 * 256 लुकअप टेबल "स्मृति के साथ अविश्वसनीय रूप से मितव्ययी" ध्वनि नहीं करता है ...!
माइक डब्ल्यूएच

@ माइकाइक खैर यह 65 किलोबाइट है।
Redcalx

@redcalx अगर यह 65 बाइट्स होता तो मैं सहमत हो सकता था!
माइक

11

कोई भी एल्गोरिथ्म / पुस्तकालय जो एक पूर्व निर्धारित शब्दकोश का समर्थन करता है, जैसे zlib

इस तरह आप कंप्रेसर को उसी तरह के टेक्स्ट के साथ प्राइम कर सकते हैं जो इनपुट में दिखाई देने की संभावना है। यदि फाइलें किसी तरह से समान हैं (जैसे सभी URL, सभी C प्रोग्राम, सभी StackOverflow पोस्ट, सभी ASCII- आर्ट ड्रॉइंग) तो कुछ सब्सक्रिप्शन सबसे या सभी इनपुट फ़ाइलों में दिखाई देंगे।

प्रत्येक संपीड़न एल्गोरिथ्म अंतरिक्ष को बचाएगा यदि एक ही फाइलिंग में एक ही विकल्प में कई बार दोहराया जाता है (जैसे "अंग्रेजी पाठ में" या "सी कोड में" इंट "।)

लेकिन URL के मामले में कुछ तार (जैसे " http: // www ।", ".Com", "html", ", .aspx" आमतौर पर प्रत्येक इनपुट फ़ाइल में एक बार दिखाई देंगे। इसलिए आपको उन्हें फ़ाइलों के बीच साझा करने की आवश्यकता है। प्रति फ़ाइल एक संपीड़ित घटना होने के बजाय किसी भी तरह एक पूर्व निर्धारित शब्दकोश में रखने से यह प्राप्त होगा।


2
कस्टम शब्दकोश का उपयोग करने पर सुझाव: stackoverflow.com/questions/2011653
ट्रेंटन

4

हफ़मैन कोडिंग आम तौर पर इसके लिए ठीक काम करती है।


4
यह लिंक-ओनली उत्तर नहीं है; लिंक के बिना, यह अभी भी एक वैध जवाब है।
एसएल बर्थ -

..और अभी भी एक अच्छा जवाब नहीं है। (पर्याप्त प्रासंगिक जानकारी नहीं लाई गई।)
user2864740

4

यदि आप वास्तव में पाठ को संक्षिप्त करने के बारे में बात कर रहे हैं तो न केवल छोटा / छोटा करें (gzip के आसपास आवरण), ज़िप छोटी फ़ाइलों और पाठ के लिए अच्छी तरह से काम करें। अन्य एल्गोरिदम बड़ी फ़ाइलों जैसे bzip2 आदि के लिए अत्यधिक कुशल हैं।

विकिपीडिया में संपीड़न समय की एक सूची है। (दक्षता की तुलना के लिए देखें)

Name       | Text         | Binaries      | Raw images
-----------+--------------+---------------+-------------
7-zip      | 19% in 18.8s | 27% in  59.6s | 50% in 36.4s
bzip2      | 20% in  4.7s | 37% in  32.8s | 51% in 20.0s
rar (2.01) | 23% in 30.0s | 36% in 275.4s | 58% in 52.7s
advzip     | 24% in 21.1s | 37% in  70.6s | 57& in 41.6s
gzip       | 25% in  4.2s | 39% in  23.1s | 60% in  5.4s
zip        | 25% in  4.3s | 39% in  23.3s | 60% in  5.7s

6
वह पाठ को संपीड़ित करना चाहता है न कि फाइलों को।
गमबो जूल 16'09

3
आप इन एल्गोरिदम के साथ पाठ और बायनेरिज़ को संपीड़ित कर सकते हैं। वास्तव में हम एक cms सिस्टम के भीतर अपस्फीति का उपयोग करते हैं जो अजगर में चलता है।
रायन क्रिस्टेंसेन

C # उदाहरण में स्ट्रिंग्स के लिए gzip का उपयोग करना यहाँ है: csharphelp.com/archives4/archive689.html
रायन क्रिस्टेंसेन


3
gzip (और zlib) डिफ्लेट का उपयोग करता है और रैपर / फ्रेमिंग ओवरहेड जोड़ता है .. डायरेक्ट डिफ्लेट / LZ77 (शब्दकोश ओवरहेड और दक्षता अभी भी ऐसी और सेटिंग्स के कार्यान्वयन पर निर्भर करता है) ब्रेक-ओवर ओवरहेड को कम कर सकता है। यह दर्जनों से सैकड़ों पात्रों में "कम" तार के लिए है, निश्चित रूप से (अभी भी "यह संकुचित है" इंगित करने के लिए थोड़ा सा होना चाहिए? बड़े पैमाने पर डेटा से बचने के लिए)। पाठ की वृद्धि के रूप में बड़ा अतिरिक्त उपरि मायने नहीं रखता है। यहां पोस्ट की गई संख्याएं बड़ी टेक्स्ट-फाइल्स (चलाने के लिए कई सेकंड!) के लिए प्रतीत होती हैं, जबकि ओपी 50-1000 चार्टर्स के लिए पूछता है - तुलना में बहुत छोटा
user2864740

2

आप यूनिकोड के लिए मानक संपीड़न योजना पर एक नज़र रखना चाहते हैं ।

SQL Server 2008 R2 इसे आंतरिक रूप से उपयोग करते हैं और 50% तक संपीड़न प्राप्त कर सकते हैं।


SCSU 'UTF-16 / MB एनकोडिंग में गैर-अंग्रेजी यूनिकोड को संपीड़ित करता है। यदि अंग्रेजी-आधारित यूनिकोड / सादे-
पुराने-
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.