Openlibrary: 맹글링된 유니코드로 책 제목 수정

이 두 기록 모두 archive.org에서 가져왔습니다.

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

저자와 제목 모두에서 움라우트는 모음 뒤에 공백으로 변경되었습니다. 연결된 MARC 레코드가 브라우저에 올바르게 표시됩니다.

재수입을 고려해야 합니까? 그리고 https://bugs.launchpad.net/openlibrary/+bug/598204 도 참조하는 #149 가 종속성입니까?

내가 최근에 찾은 것: 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 여전히 1,700만 개 이상의 일치 항목을 찾습니다. 이것은 아마도 가장 일반적인 악센트 문자인 "é"에 대한 것입니다. 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 re your 5월 8일 댓글, 해당 작품은 import에서 만든 에디션으로 만들어졌습니다.
https://openlibrary.org/show-records/ia :b28044277_0001
그리고
https://openlibrary.org/show-records/ia :b2202010x
ia MARC 레코드에서 수정될 때까지 가져오기가 정규화를 통과하지 않는 한 다시 가져오기에 가치가 없습니다.

@LeadSongDog 흥미롭게도 링크한 MARC 디스플레이는 문자가 깨져 보이지만, XML 표현 https://ia800202.us.archive.org/34/items/b28044277_0001/b28044277_0001_marc.xml 을 클릭하면 악센트가 있는 e의 디스플레이가 올바르게 표시됩니다. . 인코딩 유형이 잘못 설정된 문제가 있을 수 있습니까? 곧 이것을 선택하겠습니다. 새로운 openlibrary-client는 이제 대량 데이터 수정을 수행하는 데 사용할 수 있는 상태에 있습니다.

@LeadSongDog 이 예제에서 mangling이 어떻게 발생하는지 알아
https://ia600208.us.archive.org/25/items/b2202010x/b2202010x_marc.xml

"Secours à donner"의 a-grave가 utf-8 인코딩으로 올바르게 표시됩니다.

a-grave는 U+00E0이며 바이너리(파이썬 표기법)에서는 \xC3\xA0

해당 바이트가 MARC8로 해석되고 "변환된" 경우 C3 는 저작권 기호가 되고 'A0'은 공백이 됩니다. 이는 "Secours © donner"가 있는 OL 페이지에서 볼 수 있는 것과 정확히 같습니다.

이제 이러한 MARC 레코드에 utf-8 문자 인코딩이 있다고 생각하지만 MARC8인 것처럼 OL로 가져오기 때문에 맹글링이 설명됩니다.

https://memory.loc.gov/diglib/codetables/45.html에 있는 테이블에서 수동으로 MARC8 변환을 수행했습니다. 제대로 테스트하려면 yaz 또는 무언가를 사용해야 하지만 이것은 좋은 경로를 제공할 것입니다. 프로그래밍 방식으로 MARC 오류를 수정합니다.

Amazon에서 가져온 레코드에 영향을 주는 다른 유니코드 맹글링 오류가 있다는 것을 알고 있지만 Windows 또는 ISO 문자 집합에서 잘못된 변환으로 인한 것 같습니다.

@LeadSongDog MARC 레코드가 실제로 잘못되었는지 여부를 파악하려고 시도하면서 문제의 근본 원인을 우연히 발견한 것 같습니다.

@hornc MARC 맹글링 및/또는 이 문제가 해결

문제는 확실히 해결되지 않았습니다. 가져오기 스크립트가 수정되면 @bfalling 에서 다시 가져오기 제안이 필요할 가능성이 큽니다.

분류의 관점에서 실제 개수를 얻는 것이 유용할 것입니다. "천"은 2,500만 판 중 그리 큰 비율이 아닙니다.

이것이 Python 3 변경 사항으로 해결되었거나 누군가 Python 3에서 재현 단계를 제공할 수 있습니까?

글쎄요 https://openlibrary.org/books/OL12903648M/Etudes_Conomiques_De_L 'Ocde는 확실히 수정되지 않았지만 아마도 우리는 구멍을 파는 것은 끝났을 것입니다...
적어도 세 가지 문제 클래스가 있었습니다.

1. 좋은 데이터의 잘못된 가져오기
2. 잘못된 데이터의 리터럴 가져오기
3. 수정된 이후 1 또는 2의 오래된 사례에서 잘못된 데이터가 있습니다.
   py3으로 이동하면 기껏해야 1번이 수정됩니다.

문제 클래스 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_%

버그가 수정된 경우 레코드를 다시 가져오면 올바른 인코딩이 됩니다. 그런 다음 작업은 수백만 개의 손상된 레코드를 다시 가져오는 것입니다.

이전에 1,700만 개 이상의 레코드를 반환한다고 주장된 검색: https://openlibrary.org/search?q=title%3A+%22%C2%A9%E2%99%AD%22&mode=everything
이제 2,340만 개의 결과를 반환하지만 실제로는 별도의 버그이며 데이터베이스의 모든 작업을 반환하는 것뿐이라고 생각합니다.

@tfmorris https://openlibrary.org/search?q=title%3A+%22+%22&mode=everything 이 동일한 결과를 얻으므로 예, 효과적인 공백 문자열에 대한 제목 검색의 간단한 경우인 것 같습니다.

검색 버그를 위해 #4223을 만들었습니다.