Openlibrary: أصلح عناوين الكتب باستخدام Unicode المشوه

تم إنشاؤها على ٢٣ يناير ٢٠١٢ · 16تعليقات · مصدر: internetarchive/openlibrary

تم الإبلاغ عن هذه المشكلة في القائمة البريدية لـ ol-tech.

I don't know how widespread this problem is, but I noticed that these
two records have messed up book titles, but if you click through to
the associated MARC records on IA, the titles get rendered correctly.

http://openlibrary.org/books/OL7155555M/The_M%C2%A9%C3%98alavik%C2%A9%C3%98agnimitra
http://openlibrary.org/books/OL7165183M/The_Vikramorva%C2%A9%C3%98s%C2%A9%C4%90iyam

Data @hornc Import 2 Identifiers MARC records Bug

مصدر

anandology

ال 16 كومينتر

كلا هذين السجلين جاءا من archive.org.

لقد بحثت في ملفات _marc.xml على archive.org. تاريخ آخر تعديل لملفي marc.xml كان في عام 2007 وتم إنشاء هذه recrods في عام 2008. يبدو أن المشكلة تتعلق بالبرنامج النصي الذي حلل تلك العناوين.

anandology في ٢٣ يناير ٢٠١٢

هناك الآلاف من سجلات استيراد مارك حيث تم تشويه الأحرف المعلمة أو التعامل معها بشكل غير صحيح. سيناريو شائع آخر هو أن اللكنات أو علامات التشكيل الأخرى قد تم استبدالها بمسافة قبل أو بعد حرف العلة.

انظر على سبيل المثال:

http://openlibrary.org/authors/OL4459814A/Heinrich_Schro_der

http://openlibrary.org/works/OL10684450W/Tonbandgera_te-Messpraxis

http://openlibrary.org/show-records/talis_openlibrary_contribution/talis-openlibrary-contribution.mrc : 299045317: 529

في كل من المؤلف والعنوان ، تم تغيير علامة التشكيل إلى مسافة بعد حرف العلة. يظهر سجل مارك المرتبط بشكل صحيح في المتصفح.

amillar503 في ٤ يونيو ٢٠١٢

👍1

هل يجب أن نفكر في إعادة الاستيراد؟ وهل # 149 ، التي تشير أيضًا إلى https://bugs.launchpad.net/openlibrary/+bug/598204 ، تبعية؟

bfalling في ٢٢ سبتمبر ٢٠١٦

لقد وجدتها مؤخرًا: https://openlibrary.org/works/OL17670297W
https://openlibrary.org/works/OL17677126W
أعمال متعددة لهذا المؤلف:
https://openlibrary.org/authors/OL2450531A/Matthieu_Joseph_Bonaventure_Orfila

hornc في ٨ مايو ٢٠١٧

https://openlibrary.org/search؟q=title٪3A+٪22 © ♭٪ 22 & mode = كل شيء لا يزال يجد أكثر من 17 مليون تطابق. هذا من أجل "é" ، وهو على الأرجح الحرف الأكثر شيوعًا. التعديلات مثل https://openlibrary.org/books/OL26303038M/Anatomie_générale_appliquée_à_la_physiologie_et_à_la_médecine؟b=3&a=1&_compare=Compare&m=diff يجب ألا تكون يدوية بالضرورة.

LeadSongDog في ٣٠ أكتوبر ٢٠١٧

hornc re تعليقك في 8 مايو ، تم إنشاء هذه الأعمال من إصدارات تم إنشاؤها من الاستيراد
https://openlibrary.org/show-records/ia : b28044277_0001
و
https://openlibrary.org/show-records/ia : b2202010x
حتى يتم إصلاحها في سجلات ia MARC ، لا توجد قيمة في إعادة الاستيراد ما لم يتم تمريرها عبر التطبيع.

LeadSongDog في ١ نوفمبر ٢٠١٧

LeadSongDog مثير للاهتمام ، فإن عرض مارك الذي قمت https://ia800202.us.archive.org/34/items/b28044277_0001/b28044277_0001_marc.xml ، فإن عرض الحرف e المشدد بشكل صحيح . قد تكون هناك مشكلة في تعيين أنواع الترميز بشكل غير صحيح؟ سأختار هذا قريبًا ، عميل المكتب المفتوح الجديد هو الآن في حالة يمكن استخدامه لإجراء تصحيحات مجمعة للبيانات.

hornc في ٣ نوفمبر ٢٠١٧

LeadSongDog ربما اكتشفت كيف يحدث
https://ia600208.us.archive.org/25/items/b2202010x/b2202010x_marc.xml

يتم عرض قبر "Secours à donner" بشكل صحيح في ترميز utf-8

قيمة a-Grave هي U + 00E0 ، وهي في النظام الثنائي (الترميز Pythonic) تساوي \xC3\xA0

إذا تم تفسير هذه البايتات على أنها MARC8 و "محولة" ، فإن C3 يصبح رمز حقوق النشر ، و "A0" يصبح مسافة ، وهو بالضبط ما نراه على صفحات OL مع "Secours © donner"

أعتقد الآن أن تسجيلات مارك تحتوي على ترميز أحرف utf-8 ، ولكن تم استيرادها إلى OL كما لو كانت MARC8 ، وهو ما يفسر التشويه.

قمت بتحويل مارك 8 يدويًا من الجداول الموجودة هنا https://memory.loc.gov/diglib/codetables/45.html سأحتاج إلى استخدام yaz أو أي شيء لاختبار ذلك بشكل صحيح ، لكن هذا سيوفر مسارًا جيدًا لإصلاح أخطاء مارك برمجيًا.

أعلم أن هناك أخطاء أخرى في تغيير رمز Unicode تؤثر على سجلات Amazon المستوردة ، لكنني أعتقد أن هذا ناتج عن تحويل غير صحيح من مجموعات أحرف Windows أو ISO

شكرًا لتعليقك LeadSongDog ، في محاولتي معرفة ما إذا كانت تسجيلات مارك خاطئة بالفعل أم لا ، أعتقد أنني عثرت على السبب الجذري للمشكلة!

hornc في ٤ نوفمبر ٢٠١٧

🎉1

hornc أي تحديثات على MARC mangling و / أو إذا قمنا بحل هذه المشكلة؟

mekarpeles في ١٣ مارس ٢٠١٨

القضية بالتأكيد لم تحل. عندما يتم إصلاح سكربت الاستيراد ، فإن bfalling اقتراح إعادة الاستيراد سيكون ضروريًا على الأرجح.

من وجهة نظر الفرز ، قد يكون من المفيد الحصول على عدد فعلي. "الآلاف" ليست نسبة كبيرة جدًا من 25 مليون طبعة.

tfmorris في ١٤ مارس ٢٠١٨

هل تم حل هذا من خلال تغييرات Python 3 الخاصة بنا أو هل يمكن لشخص ما تقديم خطوات لإعادة الإنتاج على Python 3؟

cclauss في ٦ ديسمبر ٢٠٢٠

حسنًا https://openlibrary.org/books/OL12903648M/Etudes_Conomiques_De_L 'بالتأكيد لم يتم إصلاح Ocde ، لكن ربما انتهينا من حفر الحفرة ...
كان هناك ثلاث فئات مشكلة على الأقل:

استيراد سيء للبيانات الجيدة
الاستيراد الحرفي للبيانات السيئة
البيانات السيئة في مكانها من الحالات القديمة 1 أو 2 منذ معالجتها.
الانتقال إلى py3 سيصلح الرقم 1 على الأكثر.

LeadSongDog في ٦ ديسمبر ٢٠٢٠

خطوات إعادة إنتاج فئة المشكلة 1؟

cclauss في ٦ ديسمبر ٢٠٢٠

الأمثلة السابقة أفضل من أحدثها وهو استيراد من بيانات أمازون الرديئة (التي لا ينبغي استيرادها).
https://openlibrary.org/books/OL7165183M/The_Vikramorva٪C2٪A9٪C3٪98s٪C2٪A9٪C4٪90iyam
https://openlibrary.org/authors/OL4459814A/Heinrich_Schro_der
https://openlibrary.org/books/OL13956174M/Tonbandgera_te-Messpraxis
https://openlibrary.org/books/OL26280693M/Secours_٪C2٪A9_donner_aux_personnes_empoisonn٪C2٪A9٪E2٪99٪ADes_ou_asphyxi٪C2٪A9٪E2٪99٪ADes_suivis_des_moyens_٪2٪ ،

إذا تم إصلاح الخطأ ، فيجب أن ينتج عن إعادة استيراد السجلات التشفير الصحيح. ثم تصبح المهمة ببساطة إعادة استيراد ملايين السجلات التالفة.

البحث الذي ادعى أنه أعاد 17 مليون سجل من قبل: https://openlibrary.org/search؟q=title٪3A+٪22٪C2٪A9٪E2٪99٪AD٪22&mode=everything
يعرض الآن 23.4 مليون نتيجة ، لكنني أعتقد أن هذا في الواقع خطأ منفصل ويعيد جميع الأعمال الموجودة في قاعدة البيانات.

tfmorris في ٦ ديسمبر ٢٠٢٠

tfmorris حيث أن https://openlibrary.org/search؟q=title٪3A+٪22+٪22&mode= كل شيء يحصل على نفس النتيجة ، يبدو أن نعم ، إنها حالة بسيطة للبحث عن عنوان لسلسلة فارغة بشكل فعال.

LeadSongDog في ٦ ديسمبر ٢٠٢٠

لقد أنشأت # 4223 لخطأ البحث.

tfmorris في ٧ ديسمبر ٢٠٢٠

هل كانت هذه الصفحة مفيدة؟

0 / 5 - 0 التقييمات