Openlibrary: मैंगल्ड यूनिकोड के साथ पुस्तक के शीर्षक को ठीक करें

ये दोनों रिकॉर्ड आर्काइव डॉट ओआरजी से आए हैं।

मैंने archive.org पर _marc.xml फाइलों को देखा है। दोनों marc.xml फ़ाइलों का अंतिम संशोधित समय 2007 में है और ये रीक्रोड 2008 में बनाए गए थे। ऐसा लगता है कि समस्या उस स्क्रिप्ट के साथ है जिसने उन शीर्षकों को पार्स किया है।

ऐसे हजारों MARC आयात रिकॉर्ड हैं जहां उच्चारण किए गए वर्णों को गलत तरीके से संभाला या संभाला गया है। एक अन्य सामान्य परिदृश्य यह है कि स्वर के पहले या बाद में उच्चारण या अन्य विशेषक चिह्नों को एक स्थान से बदल दिया गया है।

उदाहरण के लिए देखें:

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

लेखक और शीर्षक दोनों में, स्वर के बाद उमलॉट को एक स्थान में बदल दिया गया है। लिंक किया गया मार्क रिकॉर्ड ब्राउज़र में सही ढंग से दिखाई देता है।

क्या हमें फिर से आयात करने पर विचार करना चाहिए? और #149 है, जो https://bugs.launchpad.net/openlibrary/+bug/598204 , एक निर्भरता का भी संदर्भ देता है?

कुछ मुझे हाल ही में मिले हैं: https://openlibrary.org/works/OL17670297W
https://openlibrary.org/works/OL17677126W
इस लेखक के कई काम:
https://openlibrary.org/authors/OL2450531A/Matthieu_Joseph_Bonaventure_Orfila

https://openlibrary.org/search?q=title%3A+%22 ©♭%22&mode=everything अभी भी 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 जैसे संपादन आवश्यक रूप से मैन्युअल नहीं होने चाहिए।

@hornc आपकी 8 मई की टिप्पणी फिर से, उन कार्यों को आयात से बनाए गए संस्करणों से बनाया गया था
https://openlibrary.org/show-records/ia :b28044277_0001
तथा
https://openlibrary.org/show-records/ia :b2202010x
जब तक वे IA MARC रिकॉर्ड में तय नहीं हो जाते, तब तक पुन: आयात करने का कोई मूल्य नहीं है जब तक कि आयात उन्हें सामान्यीकरण के माध्यम से पारित नहीं कर देता

@LeadSongDog दिलचस्प है, आप जिस मार्क डिस्प्ले से लिंक करते हैं वह वर्णों को विकृत दिखाता है, लेकिन यदि आप एक्सएमएल प्रतिनिधित्व https://ia800202.us.archive.org/34/items/b28044277_0001/b28044277_0001_marc.xml पर क्लिक करते हैं तो उच्चारण ई का प्रदर्शन सही ढंग से . एन्कोडिंग प्रकार गलत तरीके से सेट करने में कोई समस्या हो सकती है? मैं इसे जल्द ही उठाऊंगा, नया ओपनलाइब्रेरी-क्लाइंट अब ऐसी स्थिति में है जहां इसका उपयोग थोक डेटा सुधार करने के लिए किया जा सकता है।

@LeadSongDog मुझे पता चल गया होगा कि
https://ia600208.us.archive.org/25/items/b2202010x/b2202010x_marc.xml

"Secours Donner" की a-कब्र utf-8 एन्कोडिंग में सही ढंग से प्रदर्शित होती है

a-grave U+00E0 है, जो बाइनरी (पायथोनिक नोटेशन) में \xC3\xA0

यदि उन बाइट्स को MARC8 और "रूपांतरित" के रूप में व्याख्यायित किया जाता है, तो C3 कॉपीराइट प्रतीक बन जाता है, और 'A0' एक स्थान बन जाता है, जिसे हम OL पृष्ठों पर "Secours © donner" के साथ देखते हैं।

अब मुझे लगता है कि इन एमएआरसी रिकॉर्ड्स में यूटीएफ -8 कैरेक्टर एन्कोडिंग हैं, लेकिन ओएल में आयात किए गए थे जैसे कि वे एमएआरसी 8 थे, जो मैंगलिंग की व्याख्या करता है।

मैंने यहां https://memory.loc.gov/diglib/codetables/45.html तालिका से मैन्युअल रूप से MARC8 रूपांतरण किया था, मुझे इसे ठीक से जांचने के लिए yaz या कुछ और का उपयोग करने की आवश्यकता होगी, लेकिन यह एक अच्छा मार्ग प्रदान करेगा प्रोग्रामिक रूप से मार्क त्रुटियों को ठीक करने के लिए।

मुझे पता है कि अमेज़ॅन आयातित रिकॉर्ड को प्रभावित करने वाली अन्य यूनिकोड मैंगलिंग त्रुटियां हैं, लेकिन मुझे लगता है कि यह विंडोज या आईएसओ वर्णसेट से गलत रूपांतरण से है

आपकी टिप्पणी के लिए धन्यवाद @LeadSongDog , यह पता लगाने की कोशिश में कि क्या एमएआरसी रिकॉर्ड वास्तव में गलत थे या नहीं, मुझे लगता है कि मैंने इस मुद्दे के मूल कारण पर ठोकर खाई है!

@hornc एमएआरसी

मुद्दा निश्चित रूप से हल नहीं हुआ है। जब आयात स्क्रिप्ट तय हो जाती है, तो @bfalling पुन: आयात करने का सुझाव सबसे अधिक आवश्यक होगा।

ट्राइएज के दृष्टिकोण से, वास्तविक गणना प्राप्त करना संभवतः उपयोगी होगा। "हजारों" 25 मिलियन संस्करणों का बहुत बड़ा प्रतिशत नहीं है।

क्या इसे हमारे पायथन 3 परिवर्तनों के साथ हल किया गया है या क्या कोई पाइथन 3 पर चरण-दर-प्रजनन प्रदान कर सकता है?

खैर https://openlibrary.org/books/OL12903648M/Etudes_Conomiques_De_L 'Ocde निश्चित रूप से तय नहीं है, लेकिन शायद हम छेद खोदने के साथ कर रहे हैं ...
कम से कम तीन समस्या वर्ग थे:

1. अच्छे डेटा का खराब आयात
2. खराब डेटा का शाब्दिक आयात
3. उपचार के बाद से 1 या 2 के पुराने मामलों से खराब डेटा।
   py3 में जाने से सबसे अधिक संख्या 1 ठीक हो जाएगी।

चरण-से-पुन: उत्पन्न समस्या कक्षा १?

पहले के उदाहरण सबसे हाल के उदाहरण से बेहतर हैं जो कि भद्दे अमेज़ॅन डेटा से आयात है (जिसे हमें आयात नहीं किया जाना चाहिए)।
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_propres_%C2%A9_reconna%C2%C2%A

यदि बग को ठीक कर दिया गया है, तो रिकॉर्ड्स को फिर से आयात करने के परिणामस्वरूप सही एन्कोडिंग होनी चाहिए। तब कार्य केवल लाखों दूषित अभिलेखों को पुन: आयात करना बन जाता है।

जिस खोज से पहले 17+ मिलियन रिकॉर्ड वापस करने का दावा किया गया था: https://openlibrary.org/search?q=title%3A+%22%C2%A9%E2%99%AD%22&mode=everything
अब 23.4M परिणाम देता है, लेकिन मुझे लगता है कि यह वास्तव में एक अलग बग है और यह डेटाबेस में सभी कार्यों को वापस कर रहा है।

@tfmorris https://openlibrary.org/search?q=title%3A+%22+%22&mode= सब कुछ एक ही परिणाम प्राप्त करता है, ऐसा लगता है कि हाँ, यह प्रभावी रूप से रिक्त स्ट्रिंग के लिए शीर्षक खोज का एक साधारण मामला है।

मैंने खोज बग के लिए #4223 बनाया है।