encoding_rs
1.0.0
تشفير isoding_rs تطبيق (الأجزاء غير الجاف) من المعيار الترميز المكتوب في الصدأ.
يحدد معيار الترميز مجموعة تشفير الأحرف المتوافقة مع الويب ، مما يعني أنه يمكن استخدام هذا الصندوق لفك تشفير محتوى الويب. يتم استخدام encoding_rs في Gecko بدءًا من Firefox 56. نظرًا للتداخل الملحوظ بين الترميزات القديمة على الويب والتشفيرات القديمة المستخدمة على Windows ، قد يكون هذا القفص مفيدًا في المواقف غير المرتبطة بـ Web ؛ انظر أدناه للحصول على روابط إلى الصناديق المجاورة.
بالإضافة إلى ذلك ، توفر وحدة mem عمليات مختلفة للتعامل مع النص داخل الرم (على عكس البيانات التي تأتي من أو الذهاب إلى حدود IO). وحدة mem عبارة عن وحدة نمطية بدلاً من صندوق منفصل بسبب كفاءة تفاصيل التنفيذ الداخلية.
نظرًا لحالة استخدام GECKO ، يدعم encoding_rs فك التشفير والترميز من UTF-16 بالإضافة إلى دعم حالة استخدام الصدأ المعتادة من فك التشفير والترميز من UTF-8. بالإضافة إلى ذلك ، تم تصميم واجهة برمجة التطبيقات لتكون صديقة FFI لاستيعاب الجانب C ++ من Gecko.
على وجه التحديد ، يقوم isoding_rs بما يلي:
u16 / char16_t ).u16 / char16_t ) المحتملة المحتملة في سلسلة من البايتات في حرف ترميز محدد المعالم المعرفة كما لو أن البديل الوحيد قد تم استبداله بالحروف البديلة قبل أداء الترميز. (من المحتمل أن يكون Gecko's UTF-16 غير صالح.)document.characterSet . بالإضافة إلى ذلك ، encoding_rs::mem يفعل ما يلي:
std::io والجدير بالذكر أن قائمة الميزات أعلاه لا تتضمن القدرة على لف std::io::Read ، فك تشفيرها في UTF-8 وتقديم النتيجة عبر std::io::Read . يوفر قفص encoding_rs_io تلك القدرة.
no_std يعمل الصندوق في بيئة no_std . بشكل افتراضي ، يتم تمكين ميزة alloc ، والتي تفترض أن مخصصًا موجودًا. بالنسبة لبيئة عدم التخصيص ، يمكن إيقاف تشغيل الميزات الافتراضية (أي alloc ). هذا يجعل جزء API الذي يعيد Vec / String / Cow غير متوفر.
لفك تشفير الأحرف التي تحدث في البريد الإلكتروني ، استخدم صندوق charset بدلاً من استخدام هذا الجهاز مباشرة. (يلف هذا الصندوق ويضيف فك تشفير UTF-7.)
بالنسبة إلى التعيينات من وإلى معرفات صفحة رمز Windows ، استخدم codepage Crate.
لا يدعم هذا الصندوق ترميزات DOS أحادية البايت التي لا تتطلبها منصة الويب ، ولكن قفص oem_cp .
تطبيع النص في نموذج تطبيع Unicode C قبل تشفير النص في ترميز قديم يقلل من الأحرف التي لا يمكن تركها. يمكن تطبيع النص إلى نموذج تطبيع Unicode C باستخدام صندوق icu_normalizer .
الاستثناء هو Windows-1258 ، والذي بعد تطبيع نموذج التطبيع C-unicode يتطلب تحلل علامات النغمة من أجل تقليل الأحرف التي لا يمكن تغطيتها. يمكن أن تتحلل علامات النغمة الفيتنامية باستخدام detone Crate.
TL ؛ DR: (Apache-2.0 OR MIT) AND BSD-3-Clause للرمز والبيانات.
يرجى الاطلاع على الملف المسماة حقوق الطبع والنشر.
رمز غير الاختبار الذي لم يتم إنشاؤه من بيانات Whatwg في هذا الصندوق تحت Apache-2.0 أو MIT. رمز الاختبار تحت CC0.
يحتوي هذا الصندوق على رمز/بيانات تم إنشاؤها من بيانات WhatWG. غيرت Whatwg Opstream ترخيصها لأجزاء من المواصفات التي تم دمجها في رمز المصدر من CC0 إلى BSD-3 بين الإصدار الأولي لهذا الصندوق والإصدار الحالي من هذا الصندوق. تم تحديث أساطير الترخيص أثناء المصدر لأجزاء الكود الذي تم إنشاؤه والتي تغيرت منذ تغيير ترخيص المنبع.
تتوفر وثائق API التي تم إنشاؤها عبر الإنترنت.
هناك كتابة طويلة الشكل حول تصميم وصندوق الصندوق.
تتوفر طبقة FFI لـ encoding_rs كصندوق منفصل. يأتي الصندوق مع غلاف C ++ التجريبي باستخدام أنواع المكتبة القياسية C ++ وأنواع GSL.
روابط وحدة mem موجودة في CRATERING_C_MEM.
بالنسبة لسياق Gecko ، هناك غلاف C ++ باستخدام أنواع MFBT/XPCOM.
هناك كتابة عن أغلفة C ++.
يوجد حاليًا هذه ميزات الشحن الاختيارية:
simd-accel يتيح تسريع SIMD باستخدام ميزة مكتبة portable_simd المعتمدة على المعتمد ليلياً.
هذه ميزة التقيد ، لأن تمكين هذه الميزة يختتم من ضمانات Rust للمترجمين المستقبليين الذين يقومون بتجميع الكود القديم (المعروف أيضًا باسم "قصة الاستقرار").
في الوقت الحالي ، لم يتم اختبار هذا ليكون تحسناً باستثناء هذه الأهداف وتمكين ميزة simd-accel من المتوقع أن يكسر البناء على أهداف أخرى:
إذا كنت تستخدم الصدأ الليلي ، فأنت تستخدم الأهداف التي يكون مكونها الأول أحد ما سبق ، وكنت مستعدًا للمراجعة تكوينك عند تحديث الصدأ ، يجب عليك تمكين هذه الميزة. خلاف ذلك ، يرجى عدم تمكين هذه الميزة.
تستخدم من قبل Firefox.
serde يمكّن الدعم للتسلسل والتخلص من حقول الهيكل &'static Encoding باستخدام Serde.
لا تستخدم من قبل Firefox.
fast-legacy-encodeخيار الجهد لتمكين خيارات التشفير القديمة الأسرع. لا يؤثر على سرعة فك الشفرة أو سرعة تشفير UTF-8.
في الوقت الحاضر ، هذا الخيار يعادل تمكين الخيارات التالية:
fast-hangul-encodefast-hanja-encodefast-kanji-encodefast-gb-hanzi-encodefast-big5-hanzi-encodeيضيف 176 كيلو بايت إلى الحجم الثنائي.
لا تستخدم من قبل Firefox.
fast-hangul-encodeالتغييرات التي تشفر مقاطع هانغول مسبقة في EUC-KR من البحث الثنائي على الجداول المحسّنة التي يتم فكها للبحث عن طريق فهرس جعل النص العادي الكوري يشفر حوالي 4 مرات بالسرعة دون هذا الخيار.
يضيف 20 كيلو بايت إلى الحجم الثنائي.
لا يؤثر على سرعة فك التشفير.
لا تستخدم من قبل Firefox.
fast-hanja-encodeالتغييرات التي تشفر هانجا في EUC-KR من البحث الخطي على الجدول المحسّن من أجل فك الشفرة إلى الفهرس. نظرًا لأن Hanja غائب عملياً في النص الكوري الحديث ، فإن هذا الخيار لا يؤثر على perfomance في الحالة المشتركة ، ومن المنطقي بشكل أساسي إذا كنت ترغب في جعل التطبيق الخاص بك مرنًا إنكارًا للخدمة من قبل شخص ما يطعمه كثيرًا من Hanja لتشفيره إلى EUC-KR.
يضيف 40 كيلو بايت إلى الحجم الثنائي.
لا يؤثر على سرعة فك التشفير.
لا تستخدم من قبل Firefox.
fast-kanji-encode التغييرات التي تشفر kanji في shift_jis و euc-jp و iso-2022-jp من البحث الخطي على الجداول المحسّنة التي يتم فكها للبحث عن طريق فهرس صنع النص الياباني للنص العادي إلى الترميزات القديمة من 30 إلى 50 مرة بأسرع ما دون هذا الخيار (حوالي 2 مرة كما هو الحال مع less-slow-kanji-encode ).
يأخذ الأسبقية على less-slow-kanji-encode .
يضيف 36 كيلو بايت إلى الحجم الثنائي (24 كيلو بايت مقارنة مع less-slow-kanji-encode ).
لا يؤثر على سرعة فك التشفير.
لا تستخدم من قبل Firefox.
less-slow-kanji-encodeيجعل JIS X 0208 المستوى 1 Kanji (الأكثر شيوعًا Kanji في Shift_jis و EUC-JP و ISO-2022-JP) يشفر بطيئًا (البحث الثنائي بدلاً من البحث الخطي) مما يجعل النص النص العادي الياباني ترميزًا إلى الترميزات القديمة من 14 إلى 23 مرة دون هذا الخيار.
يضيف 12 كيلو بايت إلى الحجم الثنائي.
لا يؤثر على سرعة فك التشفير.
لا تستخدم من قبل Firefox.
fast-gb-hanzi-encode التغييرات التي تشفر تشفير hanzi في Ideographs الموحد CJK في GBK و GB18030 من البحث الخطي على جزء من الجداول المحسنة فك تشفير تليها البحث الثنائي على جزء آخر من الطاولات المغطاة بالتشفير (حوالي 2.5 إلى الفهرس جعل النص الصيني مبسط الترميز للترفيهات القديمة 100- less-slow-gb-hanzi-encode ).
يأخذ الأسبقية على less-slow-gb-hanzi-encode .
يضيف 36 كيلو بايت إلى الحجم الثنائي (24 كيلو بايت مقارنة مع less-slow-gb-hanzi-encode ).
لا يؤثر على سرعة فك التشفير.
لا تستخدم من قبل Firefox.
less-slow-gb-hanzi-encodeيجعل GB2312 من المستوى 1 Hanzi (أكثر هانزي شيوعًا في GB18030 و GBK) يشفر أقل بطيئة (البحث الثنائي بدلاً من البحث الخطي) مما يجعل النص النص الصيني البسيط مبسطًا على الترميزات القديمة حوالي 40 مرة بأسرع ما دون هذا الخيار.
يضيف 12 كيلو بايت إلى الحجم الثنائي.
لا يؤثر على سرعة فك التشفير.
لا تستخدم من قبل Firefox.
fast-big5-hanzi-encode التغييرات التي تشفر Hanzi في Ideographs الموحدة CJK في حظر Big5 من البحث الخطي على جزء من الجداول المحسّنة التي تحسنتها الفهرس عن طريق تصنيع النص الصيني الصيني التقليدي إلى BIG5 إلى 125 مرة بأسرع هذا الخيار (حوالي 3 مرات بنفس السرعة مع less-slow-big5-hanzi-encode ).
يأخذ الأسبقية على less-slow-big5-hanzi-encode .
يضيف 40 كيلو بايت إلى الحجم الثنائي (20 كيلو بايت مقارنة مع less-slow-big5-hanzi-encode ).
لا يؤثر على سرعة فك التشفير.
لا تستخدم من قبل Firefox.
less-slow-big5-hanzi-encodeيجعل Hanzi من المستوى 1 BIG5 (هانزي الأكثر شيوعًا في Big5) يشفر بطيئًا (البحث الثنائي بدلاً من البحث الخطي) مما يجعل النص الصيني الصيني التقليدي يشفر إلى Big5 حوالي 36 مرة بأسرع ما دون هذا الخيار.
يضيف 20 كيلو بايت إلى الحجم الثنائي.
لا يؤثر على سرعة فك التشفير.
لا تستخدم من قبل Firefox.
لفك تشفير UTF-16 ، الهدف هو الأداء على الأقل وكذلك UCCONV من Gecko. لفك تشفير UTF-8 ، الهدف هو الأداء على الأقل وكذلك ترميز الصدأ. وقد تم تحقيق هذه الأهداف.
يجب أن يكون الترميز إلى UTF-8 سريعًا. (يجب أن تكون UTF-8 إلى UTF-8 تشفير ما يعادل memcpy و UTF-16 إلى UTF-8 يجب أن تكون سريعة.)
السرعة هي غير عازمة عند الترميز على الترميزات القديمة. بشكل افتراضي ، لا ينبغي تحسين الترميز إلى الترميزات القديمة للسرعة على حساب حجم الرمز طالما أن تقديم النموذج وحلية URL في Gecko لا يصبحون بطيئين للغاية في الاستخدام في العالم الحقيقي.
في مصلحة الحجم الثنائي ، بشكل افتراضي ، لا يحتوي isoding_rs على جداول بيانات خاصة بالتشفير تتجاوز 32 بت من البيانات الخاصة بالتشفير لكل ترميز بايت واحد. لذلك ، تفحص المشفرات جداول البيانات المحسنة. هذا بحث خطي في معظم الحالات. نتيجة لذلك ، بشكل افتراضي ، يختلف الترميز إلى الترميزات القديمة من بطيئة إلى بطيئة للغاية بالنسبة للمكتبات الأخرى. ومع ذلك ، مع أحمال العمل الواقعية ، بدا هذا سريعًا بما يكفي حتى لا يكون بطيئًا بشكل سيء على Raspberry Pi 3 (والذي كان يمثل هاتفًا للاختبار) في حالات استخدام التشفير المعرضة على شبكة الإنترنت.
شاهد ميزات الشحن أعلاه لجعل CJK Legacy Encode سريعًا.
يتوفر إطار لقياس الأداء بشكل منفصل.
إنه هدف لدعم أحدث الصدأ المستقر ، وأحدث الصدأ الليلي ونسخة الصدأ المستخدمة في Firefox Nightly.
في هذا الوقت ، لا يوجد التزام حازم بدعم نسخة أقدم من ما هو مطلوب من قبل Firefox ، وليس هناك التزام بمعالجة تغييرات MSRV باعتبارها خارقة Semver ، لأن هذا الصندوق يعتمد على cfg-if ، والذي لا يبدو أنه يعامل تغييرات MSRV على أنها تحطم Semver ، لذلك سيكون من غير المجدي أن يعامل هذا الرابطة تغييرات MSRV.
اعتبارًا من 2024-11-01 ، يبدو أن MSRV هو الصدأ 1.40.0 لاستخدام الصندوق و 1.42.0 للاختبارات المستندات لتمريرها دون أخطاء حول المخصص العالمي. مع ميزة simd-accel ، يكون MSRV أعلى.
يتم توفير طبقة التوافق التي تنفذ واجهة برمجة تطبيقات ترميز الصدأ أعلى التشفير_Rs كصقاف منفصلة (لا يمكن تحميلها على الصناديق). تمت كتابة طبقة التوافق في الأصل مع التأثير على أن Firefox ستحتاج إليها ، لكنها لا تستخدم حاليًا في Firefox.
لتجديد الكود الذي تم إنشاؤه:
https://github.com/hsivonen/encoding_c بجانب دليل encoding_rs .https://github.com/hsivonen/codepage بجانب دليل encoding_rs .https://github.com/whatwg/encoding بجانب دليل encoding_rs .1d519bf8e5555cef64cf3a712485f41cd1a6a990 من ريبو encoding . (ملاحظة: كان f381389 مراجعة encoding المستخدمة من قبل تغيير ترخيص ريبو encoding .)encoding_rs كدليل عمل ، قم بتشغيل python generate-encoding-data.py usize بدلاً من u8 في وقت واحد). alloc (مع سطح API أقل). std::simdunsafe بأنواع أكبر من u8 / u16 إلى align_to . portable_simd الليلية للمكتبة القياسية بدلاً من قفص packed_simd . يؤثر فقط على ميزة simd-accel الاختيارية الليلية.unsafe .rust-version إلى Cargo.toml .packed_simd بدلاً من packed_simd_2 مرة أخرى الآن بعد أن عادت التحديثات تحت اسم packed_simd . يؤثر فقط على ميزة simd-accel الاختيارية الليلية.build.rs إزالته. (يجب أن يحل هذا الإزالة إيجابيات كاذبة أبلغت عنها بعض منتجات مكافحة الفيروسات. قد يؤدي ذلك إلى كسر بعض تكوينات الإنشاء التي اختارت ضمانات Rust مقابل كسر في المستقبل.)no_std .no_std (مع alloc ).simd-accel .packed_simd إلى packed_simd_2 .cfg-if إلى 1.0.cfg-if تم تحديثه إلى الإصدار 2018 دون استراحة Semver.Decoder::latin1_byte_compatible_up_to to None في المزيد من الحالات لجعل الطريقة مفيدة بالفعل. على الرغم من أنه يمكن القول إن هذا تغيير كسر بسبب تغيير الأخطاء في تغيير الدلالات ، إلا أنه لا يكسر المتصلين الذين اضطروا إلى التعامل مع حالة None بطريقة معقولة على أي حال.convert_str_to_utf16 .mem::convert_utf8_to_utf16_without_replacement .mem::utf8_latin1_up_to و mem::str_latin1_up_to .Decoder::latin1_byte_compatible_up_to .bincode (DEV) إلى 1.0.simd إلى packed_simd .simd-accel (إصدار README فقط).clippy:: بادئة من clippy lint أسماء.static عند تحديد static آخر).is_single_byte() على Encoding .mem::decode_latin1() و mem::encode_latin1_lossy() .--features simd-accel مع برنامج التحويل البرمجي القناة المستقر لتبسيط نظام بناء Firefox.is_foo_bidi() لا يعامل u+feff (عرض الصفر لا يوجد مساحة لا تتكدس.is_foo_bidi() تقرير true إذا كان المدخلات تحتوي على نماذج العروض التقديمية العبرية (والتي هي من اليمين إلى اليسار ولكن ليس في كتلة من اليمين إلى اليسار).convert_utf16_to_latin1_lossy .mem تؤكد أن الإدخال في النطاق U+0000 ... U+00FF (شامل).mem ، توفر تحويلات من LATIN1 و UTF-16 إلى UTF-8 والتي يمكن أن تتعامل مع مساحة الإخراج غير الكافية. تتمثل الفكرة في استخدامها أولاً مع تخصيص مستدير بحجم دلو Jemalloc والقيام بتخصيص حالة أسوأ فقط إذا كان Jemalloc rounding غير كافٍ للتخمين الأول.simd-accel ، والذي تم تقديمه في الإصدار 0.8.1 في التحويلات بين UTF-16 و LATIN1 في وحدة mem .#[inline(never)] لم يكن مقصودًا للإفراج.mem لزيادة الأداء عند تحويل المخازن المؤقتة الطويلة.mem .mem .replacement ملصق لترميز الاستبدال. (تغيير المواصفات.)Encoding::for_name() . ( Encoding::for_label(foo).unwrap() أصبح الآن قريب بما فيه الكفاية بعد تغيير الملصقات أعلاه.)parallel-utf8 .&'static Encoding .Encoder::has_pending_state() عام.simd إلى 0.2.0.7F بشكل صحيح في ISO-2022-JP.Hash Encoding .InputEmpty عند الترميز بالاستبدال وتم تمرير المخزن OutputFull للإخراج هو قصير جدًا أو أن المساحة المتبقية في المخزن المؤقت للإخراج صغير جدًا بعد الاستبدال.PartialEq و Eq لأنواع CoderResult و DecoderResult و EncoderResult .Encoder::encode_from_utf16 . (بسبب الإشراف ، كان يفتقر إلى الإصلاح الذي كان عليه Encoder::encode_from_utf8 بالفعل.)#[must_use] .parallel-utf8 ).simd-accel .Encoding من const إلى static لجعل المراجع فريدة من نوعها عبر الصناديق التي تستخدم المراجع.FOO_INIT غير المطلوبة من نوعها Encoding للسماح للصناديق الأجنبية بتهيئة المصفوفات static مع الإشارات إلى مثيلات Encoding حتى في ظل قيود الصدأ التي تحظر تهيئة العناصر الصفيف &'static Encoding التي &'static Encoding statics .const العمل بحيث يكون الاستخدام المتقاطع يبقي المراجع فريدة من نوعها.Cow من طرق عدم الإبلاغ عن الصدأ فقط للتشفير وفك الشفرة.Encoding::for_bom() إرجاع طول BOM.simd-accel . (يتطلب الصدأ الليلي.)Encoder.encode_from_utf8_to_vec_without_replacement() . أضف Encoding.is_ascii_compatible() .
إضافة Encoding::for_bom() .
اجعل == Encoding استخدام اسم الاستخدام بدلاً من مقارنة المؤشر ، لأن استخدامات ثوابت الترميز في الصناديق المختلفة تؤدي إلى عناوين مختلفة ولا يمكن تحويل الثابت إلى إحصائيات دون كسر أشياء أخرى.
الإصدار الأولي.
