الفيديو والترجمات · مجموعة أدوات الترجمة
لماذا تصبح é في الترجمة: ترميزات النص وكيف تقوم المتصفحات بفك تشفيرها
· كيف يعمل
ترجمات ترميز الأحرف معالجة المتصفح
غالبًا ما يكون Mojibake في الترجمة غير متطابق في التشفير. يشرح هذا المنشور كيف تتحول وحدات البايت إلى أحرف، ولماذا يختلف UTF-8 وصفحات الرموز القديمة لنظام التشغيل Windows وكيف تقوم أداة تعتمد على المتصفح بفك ترميز ملف دون إرساله إلى أي مكان.
اللهجات تافهة ولكن التوقيت مثالي – كيف تظهر مشاكل التشفير نفسها
والخبر هو أن كل شيء ما عدا الشخصيات على ما يرام. التوقيتات دقيقة، والترتيب الصحيح، ويتم تحميل الملف، والأحرف المميزة فقط هي الخاطئة. يستبعد هذا المزيج حدوث خطأ هيكلي، لأن المحلل اللغوي الذي لم يتمكن من قراءة الملف لم يكن ليتمكن من إنتاج التوقيت الصحيح. الخطأ الذي حدث حدث قبل التحليل، عندما تم تحويل سلسلة من البايتات إلى سلسلة من الأحرف.
وهذا ما يفسر أيضًا سبب ظهور الخطأ غالبًا في منتصف سير العمل بدلاً من ظهوره عند المصدر. الملف الذي بدا صحيحًا في أحد المحررين يمكن أن يبدو خاطئًا في المحرر التالي، دون الحاجة إلى تعديله. لم يعدله شيء. قدم البرنامج الثاني افتراضًا مختلفًا حول معنى البايتات.
البايتات مقابل الأحرف - لماذا يمكن قراءة نفس البايتات كـ "é" أو "é" اعتمادًا على وحدة فك التشفير
الملف الموجود على القرص هو بايت. توجد الأحرف فقط عندما يطبق شيء ما تشفيرًا، وهو عبارة عن جدول يعين تسلسلات البايت إلى الأحرف. يمثل UTF-8 حرفًا لاتينيًا معلمًا مثل e-acute بمقدار بايتين. يمثل Windows-1252 نفس الحرف كبايت واحد، ويعطي البايتتين UTF-8 معنيين مختلفين تمامًا: الأول هو حرف A كبير مع علامة التلدة والثاني هو علامة حقوق الطبع والنشر.
لذا فإن الزوج المشوه المألوف ليس فسادًا. إنها قراءة صادقة وغير قابلة للفقد للبايتات الصحيحة ضمن الجدول الخطأ. نجا كل بايت. فقط تغير التفسير. ولهذا السبب عادةً ما يكون الضرر قابلاً للإصلاح، ولهذا السبب من المفيد تحديد الاتجاه الذي ذهب إليه عدم التطابق بدلاً من تحرير الأحرف المرئية يدويًا.
UTF-8، Windows-1252 والأصدقاء - تظهر ملفات الترجمة للترميز فعليًا
تظهر ملفات الترجمة في عدد صغير من الترميزات. UTF-8 هو الإعداد الافتراضي الحديث وهو الوحيد الذي يسمح به WebVTT. Windows-1252 شائع في الملفات التي تنتجها الأدوات القديمة في أوروبا الغربية، وقريبه ISO-8859-1 يغطي الكثير من نفس الأساس. تظهر الملفات من مصادر أوروبا الوسطى أو السيريلية أو اليونانية في صفحات الرموز المقابلة لنظام التشغيل Windows، وتضيف المواد الشرق آسيوية العديد من الملفات الأخرى.
لا يسجل أي من هذه الترميزات هويته الخاصة داخل الملف. لا يحتوي ملف SRT على أي إعلان عن الترميز المستخدم لكتابته، وهو أصل المشكلة برمتها: يجب على القارئ أن يقرر، ولا يوجد شيء موثوق لقراءته.
علامة ترتيب البايت - تلميح مفيد لبعض اللاعبين وخلل واضح لدى البعض الآخر
علامة ترتيب البايت هي الاستثناء الجزئي الوحيد. وهو عبارة عن حرف محدد في بداية الملف يشير، عند وجوده، إلى الترميز. إنه يساعد بعض اللاعبين ويظهر لدى آخرين كشخصية ضالة قبل فهرس الترجمة الأول، ولهذا السبب يمكن أن تفشل الملفات التي تحمل هذا في برنامج واحد بالضبط وتعمل في أي مكان آخر.
يقوم المحلل اللغوي بإزالتها قبل القيام بأي شيء آخر، لأن العلامة المتبقية في مكانها تلتصق برقم الفهرس الأول وتكلف الإشارة الأولى. تتم كتابة اكتشاف التنسيق لتحمله أيضًا، لذلك يظل ملف WebVTT الذي يبدأ بعلامة قبل رأسه يتم التعرف عليه على أنه WebVTT بدلاً من معاملته على أنه SRT.
كيف يقوم المتصفح بفك تشفير ملف محليًا - TextDecoder API، ولماذا يكون الاكتشاف تخمينًا عندما لا يتم الإعلان عن أي تشفير
عندما تقوم الأداة بتحميل ملف، فإنها تستدعي أسلوب الملف النصي API، ويتم تحديد هذا الأسلوب لفك التشفير كـ UTF-8. لا توجد معلمة ترميز ولا يوجد تفاوض. تتم قراءة الملف الذي UTF-8 بشكل صحيح؛ يقدم ملف Windows-1252 الذي يحتوي على حرف مميز أحادي البايت بايتًا لا يمكنه بدء تسلسل UTF-8 صالح، وتقوم وحدة فك الترميز باستبدال حرف بديل بدلاً من التخمين.
وهذا أمر يستحق المعرفة لأنه يغير الأعراض. تؤدي قراءة ملف UTF-8 باستخدام جدول قديم إلى ظهور تشويه مألوف مكون من حرفين. تؤدي قراءة ملف قديم كـ UTF-8 إلى ظهور أحرف بديلة بدلاً من ذلك، المعينات السوداء أو المربعات الفارغة. يتطلب فك التشفير كشيء آخر غير UTF-8 تسمية التشفير بشكل صريح من خلال وحدة فك ترميز المتصفح API، وتسميته هو الجزء الصعب: مع عدم وجود إعلان في الملف، فإن أي اختيار تلقائي هو استنتاج من أنماط البايت، وهو تخمين عادة ما يكون صحيحًا وأحيانًا خاطئ بشكل مؤكد.
مثال عملي: إنقاذ ملف Windows-1252 - تحديد ترميز المصدر وإعادة حفظه كـ UTF-8 قبل التحويل
لإنقاذ ملف قديم، قم بإجراء التحويل قبل عمل الترجمة وليس بعده. افتحه في محرر يتيح لك تحديد الترميز على كلا الجانبين، واطلب منه إعادة فتح الملف كـ Windows-1252، والتأكد من ظهور الأحرف المميزة بشكل صحيح. إذا فعلوا ذلك، فإن التخمين كان صحيحا. ثم احفظ الملف بشكل صريح باسم UTF-8.
قم بالتحقق على سطر يمكنك التنبؤ به بدلاً من التحقق على الملف ككل. اختر إشارة تحتوي على لهجة تعرف أنها يجب أن تكون موجودة وتحقق منها في الإخراج المحول. القيام بذلك أولاً يعني أن أداة الترجمة تتلقى ملفًا تتطابق وحدات البايت الخاصة به بالفعل مع التشفير الذي ستفترضه، ولن يتبقى أي شيء يمكن أن يخطئ في خطوة التحويل.
ما لا يغطيه هذا هو الملفات التي تضررت بسبب جولتين من التحويل الخاطئ، حيث تم فقدان البايتات الأصلية بالفعل
يمثل الملف الذي مر بتحويلين خاطئين مشكلة مختلفة. إذا تمت قراءة ملف بشكل خاطئ ثم تم حفظه في حالة القراءة الخاطئة هذه، فسيتم كتابة الأحرف غير الصحيحة كأحرف حقيقية، ولن تعد وحدات البايت الأصلية موجودة في أي مكان فيه. عند هذه النقطة، لا يوجد شيء يمكن إعادة تفسيره، لأن الملف الآن يحتوي بالفعل على النص المشوه.
تكون هذه الحالات قابلة للاسترداد في بعض الأحيان عن طريق عكس التسلسل الدقيق للتشفيرات الخاطئة، ولكن فقط عندما تكون كل خطوة معروفة ولا توجد معلومات مفقودة. يتم التخلص نهائيًا من البايت الذي أصبح حرفًا بديلاً: الاستبدال عبارة عن حرف واحد يمثل البايت الذي لا يمكن لجهاز فك التشفير استخدامه، ولا يسجل ماهية البايت. الحل الموثوق به هو العودة إلى الملف الأصلي.
الخلاصة: قم بالتوحيد القياسي على UTF-8 قبل التحويل - كيف تعمل مجموعة أدوات الترجمة على ملفك في المتصفح ولماذا يكون إخراج WebVTT UTF-8 حسب التعريف
قم بالتوحيد على UTF-8 قبل تحويل أي شيء. الملف نفسه لا يحمل أي بيان لترميزه، لذا فإن كل برنامج يفتحه يقوم بافتراض، والطريقة لمنع اختلاف الافتراضات هي جعلها كلها صحيحة. يزيل WebVTT الغموض بحكم التعريف، حيث يتطلب التنسيق UTF-8، وهو أحد الأسباب العملية لتحويل SRT إلى WebVTT للتسليم عبر الويب.
يتم تشغيل التحويل على الملف الموجود في علامة تبويب المتصفح. تحقق من النتيجة على سطر يمكنك التنبؤ بلكناته بدلاً من البحث عن أي شيء يبدو خاطئًا، لأن الملف الذي يحتوي على مجموعة من الكلمات المميزة في تسعمائة إشارة من السهل التوقيع عليه دون فحص الجزء الذي قد يفشل.