بزيب2

بزيب2
المؤلف(ون) الأصلي(ون)جوليان سيوارد
المطور(ون)مارك ويلارد، فيديريكو مينا ، ميكا سنايدر
الإصدار الأولي18 يوليو 1996 ؛ منذ 28 عامًا [1] ( 1996-07-18 )
إصدار مستقر
1.0.8 / 13 يوليو 2019 ؛ منذ 5 سنوات ( 2019-07-13 )
مستودعhttps://gitlab.com/bzip2/bzip2/
نظام التشغيلمتعدد المنصات [ أيهما؟ ]
يكتبضغط البيانات
رخصةرخصة zlib المعدلة [2]
موقع إلكترونيالمصدر: www.sourceware.org/bzip2/
بزيب2
امتداد اسم الملف
.bz2
نوع الوسائط على الإنترنت
application/x-bzip2
نوع الكودBzp2
معرف النوع الموحد (UTI)أرشيف public.bzip2 [3]
الرقم السحريBZh
تم التطوير بواسطةجوليان سيوارد
نوع التنسيقضغط البيانات
تنسيق مفتوح ؟نعم

bzip2 هو برنامج ضغط ملفات مجاني ومفتوح المصدر يستخدم خوارزمية Burrows–Wheeler . وهو يضغط الملفات الفردية فقط ولا يعمل كمؤرشف للملفات . ويعتمد على أدوات خارجية منفصلة لمهام مثل التعامل مع ملفات متعددة والتشفير وتقسيم الأرشيف.

تم إصدار bzip2 في البداية عام 1996 بواسطة Julian Seward . إنه يضغط معظم الملفات بشكل أكثر فعالية من خوارزميات الضغط LZW و Deflate القديمة ولكنه أبطأ. يعد bzip2 فعالًا بشكل خاص لبيانات النصوص، كما أن فك الضغط سريع نسبيًا. تستخدم الخوارزمية عدة طبقات من تقنيات الضغط، مثل ترميز طول التشغيل (RLE) وتحويل Burrows–Wheeler (BWT) وتحويل النقل إلى الأمام (MTF) وترميز Huffman . يضغط bzip2 البيانات في كتل بين 100 و 900 كيلو بايت ويستخدم تحويل Burrows–Wheeler لتحويل تسلسلات الأحرف المتكررة بشكل متكرر إلى سلاسل من الأحرف المتطابقة. يتم بعد ذلك تطبيق تحويل النقل إلى الأمام وترميز Huffman. أداء الضغط غير متماثل، حيث يكون فك الضغط أسرع من الضغط.

لقد خضعت الخوارزمية لعدة صيانات منذ إصدارها الأولي، حيث كان Micah Snyder هو الصيان منذ يونيو 2021. كانت هناك بعض التعديلات على الخوارزمية، مثل pbzip2، الذي يستخدم تعدد الخيوط لتحسين سرعة الضغط على أجهزة الكمبيوتر متعددة وحدات المعالجة المركزية ومتعددة النواة.

يعد bzip2 مناسبًا للاستخدام في تطبيقات البيانات الضخمة مع أطر الحوسبة العنقودية مثل Hadoop و Apache Spark ، حيث يمكن فك ضغط الكتلة المضغوطة دون الحاجة إلى معالجة الكتل السابقة.

تاريخ

أصدر سيوارد أول إصدار عام لـ bzip2، الإصدار 0.15، في يوليو 1996. ازداد استقرار الضاغط وشعبيته على مدار السنوات العديدة التالية، وأصدر سيوارد الإصدار 1.0 في أواخر عام 2000. [ لم يتم التحقق منه في النص ] بعد انقطاع دام تسع سنوات من التحديثات للمشروع منذ عام 2010، في 4 يونيو 2019، قبل فيديريكو مينا صيانة مشروع bzip2. [4] منذ يونيو 2021، أصبح المشرف هو ميكا سنايدر. [5]

تطبيق

يستخدم bzip2 عدة طبقات من تقنيات الضغط مكدسة فوق بعضها البعض، والتي تحدث بالترتيب التالي أثناء الضغط والترتيب العكسي أثناء فك الضغط:

  1. ترميز طول التشغيل (RLE) للبيانات الأولية.
  2. تحويل بوروز-ويلر (BWT)، أو فرز الكتل.
  3. تحويل التحرك للأمام (MTF).
  4. ترميز طول التشغيل (RLE) لنتيجة MTF.
  5. ترميز هوفمان .
  6. الاختيار بين جداول هوفمان المتعددة.
  7. ترميز أحادي القاعدة 1 لاختيار جدول هوفمان.
  8. ترميز دلتا (Δ) لأطوال بتات كود هوفمان.
  9. مصفوفة بتات متفرقة تظهر الرموز المستخدمة.

يتم استبدال أي تسلسل من 4 إلى 255 رمزًا مكررًا متتاليًا بالرموز الأربعة الأولى وطول تكرار بين 0 و251. وبالتالي AAAAAAABBBBCCCDيتم استبدال التسلسل بـ AAAA\3BBBB\0CCCD، حيث يمثل \3و \0قيم البايت 3 و0 على التوالي. يتم دائمًا تحويل عمليات تشغيل الرموز بعد 4 رموز متتالية، حتى إذا تم تعيين طول التشغيل على صفر، للحفاظ على قابلية التحويل للعكس.

في أسوأ الأحوال، قد يتسبب ذلك في توسع بمقدار 1.25، وفي أفضل الأحوال، تقليص إلى <0.02. وفي حين تسمح المواصفات نظريًا بترميز عمليات بطول 256-259، فإن المشفر المرجعي لن ينتج مثل هذا الناتج.

صرح مؤلف bzip2 أن خطوة RLE كانت خطأً تاريخيًا وكانت تهدف فقط إلى حماية تنفيذ BWT الأصلي من الحالات المرضية. [6]

تحويل بوروز-ويلر هو فرز الكتل القابل للعكس والذي يشكل جوهر bzip2. الكتلة مستقلة تمامًا، مع بقاء مخازن الإدخال والإخراج بنفس الحجم - في bzip2، الحد التشغيلي لهذه المرحلة هو 900 كيلو بايت. بالنسبة لفرز الكتل، يتم إنشاء مصفوفة (افتراضية)، حيث يحتوي الصف i على المخزن بالكامل، مع تدويره ليبدأ من الرمز i . بعد التدوير، يتم فرز صفوف المصفوفة حسب الترتيب الأبجدي (الرقمي). يتم تخزين مؤشر مكون من 24 بتًا يحدد موضع البداية عندما لا يتم تحويل الكتلة. في الممارسة العملية، ليس من الضروري إنشاء المصفوفة الكاملة؛ بل يتم إجراء الفرز باستخدام مؤشرات لكل موضع في المخزن. المخزن الناتج هو العمود الأخير من المصفوفة؛ يحتوي هذا على المخزن بالكامل، ولكن يتم إعادة ترتيبه بحيث يكون من المحتمل أن يحتوي على عمليات تشغيل كبيرة من الرموز المتطابقة.

لا يغير التحويل "نقل إلى الأمام" مرة أخرى حجم الكتلة المعالجة. يتم وضع كل الرموز المستخدمة في المستند في مصفوفة. عند معالجة رمز، يتم استبداله بموقعه (الفهرس) في المصفوفة ويتم خلط هذا الرمز إلى مقدمة المصفوفة. التأثير هو استبدال الرموز المتكررة على الفور برموز صفرية (وبالتالي تصبح التشغيلات الطويلة لأي رمز عشوائي تشغيلات من الرموز الصفرية)، بينما يتم إعادة تعيين الرموز الأخرى وفقًا لترددها المحلي.

تحتوي الكثير من البيانات "الطبيعية" على رموز متطابقة تتكرر ضمن نطاق محدود (النص هو مثال جيد). نظرًا لأن تحويل MTF يعين قيمًا منخفضة للرموز التي تظهر بشكل متكرر، فإن هذا يؤدي إلى تدفق بيانات يحتوي على العديد من الرموز في نطاق الأعداد الصحيحة المنخفضة، والعديد منها متطابقة (يمكن لرموز الإدخال المتكررة المختلفة أن تتطابق فعليًا مع نفس رمز الإخراج). يمكن ترميز مثل هذه البيانات بكفاءة عالية بواسطة أي طريقة ضغط قديمة.

يتم استبدال السلاسل الطويلة من الأصفار في مخرجات تحويل التحرك للأمام (والتي تأتي من الرموز المتكررة في مخرجات BWT) بسلسلة من رمزين خاصين، RUNA وRUNB، يمثلان طول التشغيل كرقم ثنائي. لا يتم ترميز الأصفار الفعلية مطلقًا في المخرجات؛ يصبح الصفر الوحيد RUNA. (في الواقع، تتم هذه الخطوة في نفس وقت MTF؛ كلما أنتجت MTF صفرًا، فإنها تزيد بدلاً من ذلك من العداد للترميز باستخدام RUNA وRUNB.)

0, 0, 0, 0, 0, 1سيتم تمثيل التسلسل على النحو التالي RUNA, RUNB, 1؛ RUNA, RUNBيمثل القيمة 5 كما هو موضح أدناه. يتم إنهاء كود طول التشغيل بالوصول إلى رمز عادي آخر. تعد عملية RLE هذه أكثر مرونة من خطوة RLE الأولية، حيث إنها قادرة على ترميز أعداد صحيحة طويلة بشكل تعسفي (في الممارسة العملية، يقتصر هذا عادةً على حجم الكتلة، بحيث لا تقوم هذه الخطوة بترميز تشغيل يزيد عن900000  بايت ). يتم ترميز طول التشغيل بهذه الطريقة: تعيين قيم مكانية 1 للبت الأول، و2 للبت الثاني، و4 للبت الثالث، وما إلى ذلك في التسلسل، وضرب كل قيمة مكانية في موضع RUNB في 2، وإضافة جميع قيم الأماكن الناتجة (لقيم RUNA وRUNB على حد سواء) معًا. هذا مشابه للترقيم الثنائي الأساسي 2. وبالتالي ، ينتج عن التسلسل RUNA, RUNBالقيمة (1 + 2 × 2) = 5. كمثال أكثر تعقيدًا:

رونا رانب رونا رونا رانب (ABAAB)
   1 2 4 8 16
   1 4 4 8 32 = 49

تستبدل هذه العملية الرموز ذات الطول الثابت في النطاق من 0 إلى 258 برموز ذات طول متغير بناءً على تكرار الاستخدام. تنتهي الرموز الأكثر استخدامًا إلى أن تكون أقصر (2 إلى 3 بتات)، بينما يمكن تخصيص ما يصل إلى 20 بتًا للرموز النادرة. يتم اختيار الرموز بعناية بحيث لا يمكن الخلط بين تسلسل البتات ورمز مختلف.

إن الكود الموجود في نهاية التدفق مثير للاهتمام بشكل خاص. فإذا كان هناك n بايت (رموز) مختلفة مستخدمة في البيانات غير المضغوطة، فإن كود هوفمان سوف يتكون من كودين RLE (RUNA وRUNB)، و n − 1 كود رمزي وكود واحد في نهاية التدفق. وبسبب النتيجة المجمعة لترميزي MTF وRLE في الخطوتين السابقتين، فلن تكون هناك حاجة مطلقًا للإشارة صراحةً إلى الرمز الأول في جدول MTF (سيكون صفرًا في MTF العادي)، وبالتالي يتم حفظ رمز واحد لعلامة نهاية التدفق (وهذا يفسر سبب ترميز n − 1 رمز فقط في شجرة هوفمان). وفي الحالة القصوى حيث يتم استخدام رمز واحد فقط في البيانات غير المضغوطة، فلن تكون هناك أكواد رمزية على الإطلاق في شجرة هوفمان، وستتكون الكتلة بأكملها من RUNA وRUNB (تكرار البايت الفردي ضمناً) وعلامة نهاية التدفق بقيمة 2.

0: رونا،
1: ركض،
2–257: قيم البايت 0–255،
258: نهاية الدفق، انتهاء المعالجة (قد يكون منخفضًا إلى 2).

يمكن استخدام عدة جداول هوفمان متطابقة الحجم مع كتلة إذا كانت المكاسب من استخدامها أكبر من تكلفة تضمين الجدول الإضافي. يمكن أن يكون هناك جدولان على الأقل وحتى 6 جداول، مع إعادة تحديد الجدول الأكثر ملاءمة قبل كل 50 رمزًا تتم معالجته. هذا له ميزة وجود ديناميكيات هوفمان سريعة الاستجابة دون الحاجة إلى توفير جداول جديدة باستمرار، كما هو مطلوب في DEFLATE . تم تصميم الترميز بطول التشغيل في الخطوة السابقة للعناية بالرموز التي لها احتمالية عكسية للاستخدام أعلى من أقصر رمز هوفمان قيد الاستخدام.

إذا كانت هناك جداول هوفمان متعددة قيد الاستخدام، فإن اختيار كل جدول (مرقمة من 0 إلى 5) يتم من قائمة بواسطة تشغيل بت منتهٍ بصفر بين 1 و6 بت في الطول. يتم الاختيار في قائمة MTF للجداول. يؤدي استخدام هذه الميزة إلى توسع أقصى يبلغ حوالي 1.015، ولكن بشكل عام أقل. من المرجح أن يتم التغاضي عن هذا التوسع بشكل كبير بسبب ميزة اختيار جداول هوفمان الأكثر ملاءمة، ويتم تمثيل الحالة الشائعة للاستمرار في استخدام نفس جدول هوفمان على أنه بت واحد. بدلاً من الترميز الأحادي، يعد هذا في الواقع شكلًا متطرفًا لشجرة هوفمان، حيث يكون لكل رمز نصف احتمالية الرمز السابق.

أطوال بتات كود هوفمان مطلوبة لإعادة بناء كل من جداول هوفمان الكنسية المستخدمة . يتم تخزين كل طول بت كفرق مشفر مقابل طول بت الكود السابق. يعني البت الصفري (0) أنه يجب تكرار طول البت السابق للكود الحالي، بينما يعني البت الواحد (1) أنه يجب قراءة بت آخر وزيادة أو تقليل طول البت بناءً على تلك القيمة. في الحالة الشائعة، يتم استخدام بت واحد لكل رمز لكل جدول وفي أسوأ حالة - الانتقال من الطول 1 إلى الطول 20 - سيتطلب ما يقرب من 37 بت. نتيجة للترميز MTF السابق، تبدأ أطوال الكود بطول 2-3 بت (أكواد مستخدمة بشكل متكرر) وتزداد تدريجيًا، مما يعني أن تنسيق دلتا فعال إلى حد ما، ويتطلب حوالي 300 بت (38 بايت) لكل جدول هوفمان كامل.

تُستخدم خريطة البتات لإظهار الرموز المستخدمة داخل الكتلة والتي يجب تضمينها في أشجار هوفمان. من المرجح أن تستخدم البيانات الثنائية جميع الرموز البالغ عددها 256 والتي يمكن تمثيلها بواسطة بايت واحد، في حين قد تستخدم البيانات النصية مجموعة فرعية صغيرة فقط من القيم المتاحة، ربما تغطي نطاق ASCII بين 32 و126. سيكون تخزين 256 بتًا صفريًا غير فعال إذا لم يتم استخدامها في الغالب. يتم استخدام طريقة متفرقة : يتم تقسيم الرموز البالغ عددها 256 إلى 16 نطاقًا، وفقط إذا تم استخدام الرموز داخل تلك الكتلة يتم تضمين مجموعة من 16 بت. يتم الإشارة إلى وجود كل من هذه النطاقات الستة عشر من خلال مجموعة بت إضافية مكونة من 16 بت في المقدمة. تستخدم خريطة البتات الإجمالية ما بين 32 و272 بتًا من التخزين (4-34 بايت). للتباين، ستظهر خوارزمية DEFLATE غياب الرموز عن طريق ترميز الرموز على أنها ذات طول بت صفري باستخدام ترميز طول التشغيل وترميز هوفمان إضافي.

تنسيق الملف

لا توجد مواصفات رسمية لـ bzip2، على الرغم من أن مواصفات غير رسمية تم هندستها عكسيًا من التنفيذ المرجعي. [7]

كنظرة عامة، .bz2يتكون التدفق من رأس مكون من 4 بايتات، يتبعه صفر أو أكثر من الكتل المضغوطة، يتبعه على الفور علامة نهاية التدفق التي تحتوي على CRC مكون من 32 بتًا للتدفق الكامل للنص العادي الذي تتم معالجته. الكتل المضغوطة محاذية للبتات ولا يحدث أي حشو.

.magic:16 = توقيع/رقم سحري 'BZ'
.version:8 = 'h' لـ Bzip2 (ترميز 'H'uffman')، '0' لـ Bzip1 (غير مستخدم)
.hundred_k_blocksize:8 = '1'..'9' حجم الكتلة 100 كيلو بايت - 900 كيلو بايت (غير مضغوط)

.compressed_magic:48 = 0x314159265359 (BCD (pi))
.crc:32 = المجموع الاختباري لهذه الكتلة
.عشوائي: 1 = 0=>طبيعي، 1=>عشوائي (غير مستخدم)
.origPtr:24 = مؤشر البدء في BWT بعد عدم التحويل
.huffman_used_map:16 = خريطة بتات، تتراوح من 16 بايت، موجودة/غير موجودة
.huffman_used_bitmaps:0..256 = خريطة نقطية للرموز المستخدمة، موجودة/غير موجودة (مضاعفات 16)
.huffman_groups:3 = 2..6 عدد جداول Huffman المختلفة قيد الاستخدام
.selectors_used:15 = عدد المرات التي يتم فيها تبديل جداول هوفمان (كل 50 رمزًا)
*.selector_list:1..6 = عمليات تشغيل بت منتهية بصفر (0..62) من جدول Huffman الذي تم تحويله إلى MTF (*selectors_used)
.start_huffman_length:5 = 0..20 طول البت الأولي لدلتا هوفمان
*.delta_bit_length:1..40 = 0=>الرمز التالي؛ 1=>تغيير الطول
                                                { 1=>تقليل الطول؛ 0=>زيادة الطول } (*(الرموز+2)*المجموعات)
.contents:2..∞ = دفق بيانات مشفر بتقنية هوفمان حتى نهاية الكتلة (الحد الأقصى 7372800 بت)

.eos_magic:48 = 0x177245385090 (BCD الجذر التربيعي (باي))
.crc:32 = المجموع الاختباري للتيار بأكمله
.padding:0..7 = محاذاة إلى البايت بأكمله

بسبب ضغط RLE في المرحلة الأولى (انظر أعلاه)، فإن الحد الأقصى لطول النص العادي الذي يمكن أن يحتويه كتلة bzip2 واحدة بحجم 900 كيلو بايت هو حوالي 46 ميجا بايت (45,899,236 بايت). يمكن أن يحدث هذا إذا كان النص العادي بالكامل يتكون بالكامل من قيم متكررة ( .bz2يبلغ طول الملف الناتج في هذه الحالة 46 بايت). يمكن تحقيق ملف أصغر حجمًا يبلغ 40 بايتًا باستخدام إدخال يحتوي بالكامل على قيم 251، وهي نسبة ضغط ظاهرة تبلغ 1147480.9:1.

يمكن فك ضغط كتلة مضغوطة في bzip2 دون الحاجة إلى معالجة الكتل السابقة. وهذا يعني أنه يمكن فك ضغط ملفات bzip2 بالتوازي، مما يجعلها تنسيقًا جيدًا للاستخدام في تطبيقات البيانات الضخمة مع أطر الحوسبة العنقودية مثل Hadoop و Apache Spark . [8]

كفاءة

يضغط bzip2 معظم الملفات بشكل أكثر فعالية من خوارزميات الضغط القديمة LZW ( .Z ) و Deflate ( .zip و .gz )، لكنه أبطأ بشكل ملحوظ. يعتبر LZMA بشكل عام أكثر كفاءة في استخدام المساحة من bzip2 على حساب سرعة الضغط الأبطأ، مع وجود فك ضغط أسرع. [9]

يضغط bzip2 البيانات في كتل بحجم يتراوح بين 100 و900 كيلو بايت ويستخدم تحويل بوروز ويلر لتحويل تسلسلات الأحرف المتكررة بشكل متكرر إلى سلاسل من الأحرف المتطابقة. ثم يطبق تحويل الانتقال إلى الأمام وترميز هوفمان . استخدم سلف bzip2، bzip، الترميز الحسابي بدلاً من هوفمان. تم إجراء التغيير بسبب تقييد براءة اختراع البرنامج . [10] bzip3، [11] ضاغط حديث يشترك في أصل مشترك ومجموعة من الخوارزميات مع bzip2، عاد إلى الترميز الحسابي.

أداء bzip2 غير متماثل، حيث أن فك الضغط سريع نسبيًا. بدافع من الوقت الطويل المطلوب للضغط، تم إنشاء نسخة معدلة في عام 2003 تسمى pbzip2 والتي استخدمت تعدد الخيوط لتشفير الملف في أجزاء متعددة، مما أعطى تسريعًا خطيًا تقريبًا على أجهزة الكمبيوتر متعددة وحدات المعالجة المركزية ومتعددة النواة. [12] اعتبارًا من مايو 2010 ، لم يتم دمج هذه الوظيفة في المشروع الرئيسي.

مثل gzip ، فإن bzip2 عبارة عن ضاغط بيانات فقط. إنه ليس برنامج أرشفة مثل tar أو ZIP؛ لا يدعم تنسيق ملف bzip2 تخزين محتويات ملفات متعددة في ملف مضغوط واحد، ولا يحتوي البرنامج نفسه على تسهيلات للملفات المتعددة أو التشفير أو تقسيم الأرشيف. في تقاليد UNIX ، يمكن إجراء الأرشفة بواسطة برنامج منفصل ينتج أرشيفًا يتم ضغطه بعد ذلك باستخدام bzip2، ويمكن إلغاء الأرشفة عن طريق فك ضغط ملف الأرشيف المضغوط بواسطة bzip2 وبرنامج منفصل لفك ضغطه. تحتوي بعض برامج الأرشفة على دعم مدمج للضغط وفك الضغط، بحيث لا يكون من الضروري استخدام برنامج bzip2 لضغط أو فك ضغط الأرشيف. يحتوي GnuPG أيضًا على دعم مدمج لضغط وفك ضغط bzip2.

تتيح الأداة grepالقائمة على bzgrep- البحث المباشر عبر النص المضغوط دون الحاجة إلى فك ضغط المحتويات أولاً. [13]

انظر أيضا

مراجع

  1. ^ bzip2/README، 18 يوليو 1996 (الإصدار 0.15)
  2. ^ سيوارد، جوليان. "bzip2 و libbzip2". sourceware.org .
  3. ^ "bz2". وثائق مطوري Apple: معرفات النوع الموحد . Apple Inc.
  4. ^ "مقالات تحمل الوسم bzip2". viruta.org .
  5. ^ "مستودع Bzip2 التجريبي يغير من أسلوب الصيانة - مدونة Federico". viruta.org . تم الاسترجاع في 27 يوليو 2022 .
  6. ^ "bzip2 و libbzip2، الإصدار 1.0.8". sourceware.org .
  7. ^ "مواصفات تنسيق BZIP2" (PDF) . GitHub . 17 مارس 2022.
  8. ^ "[HADOOP-4012] توفير دعم التقسيم لملفات مضغوطة بتنسيق bzip2". Apache Software Foundation . 2009 . تم الاسترجاع في 14 أكتوبر 2015 .
  9. ^ "7-zip vs bzip2 vs gzip". مؤرشف من الأصل في 24 أبريل 2016. اطلع عليه بتاريخ 12 فبراير 2019 .
  10. ^ "الصفحة الرئيسية لبرنامج bzip2". مؤرشف من الأصل في 4 يوليو 1998. اطلع عليه بتاريخ 5 مارس 2009 .- القسم "كيف يرتبط بعرضك السابق (bzip-0.21)؟"
  11. ^ Palaiologos (13 أكتوبر 2022)، kspalaiologos/bzip3 ، تم الاسترجاع في 13 أكتوبر 2022
  12. ^ “compressionrated.com”. www1.compression ratings.com .
  13. ^ "أمر bzgrep في لينكس مع الأمثلة". die.net .
  • أمر bzip2 - بواسطة مشروع معلومات Linux (LINFO)
  • bzip2 لنظام التشغيل Windows
  • برنامج bzip2 الرسومي لنظام Windows (WBZip2)
  • MacBzip2 (لنظام التشغيل Mac OS الكلاسيكي ؛ في نظام التشغيل Mac OS X ، يتوفر bzip2 القياسي في سطر الأوامر)
  • مقارنة الميزات والمعايير لمختلف أنواع تنفيذات bzip2 المتوازية المتاحة
  • 4 تطبيقات متوازية لـ bzip2 مؤرشفة في 18 أكتوبر 2006 على موقع Wayback Machine في مدونة أخبار ضغط البيانات
  • ضاغط bzip الأصلي - قد يكون مقيدًا ببراءات الاختراع
تم الاسترجاع من "https://en.wikipedia.org/w/index.php?title=Bzip2&oldid=1247710570"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate