Summary: | ModBiblio breaks MARC::File::XML | ||
---|---|---|---|
Product: | Koha | Reporter: | Magnus Enger <magnus> |
Component: | Architecture, internals, and plumbing | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | minor | ||
Priority: | P5 - low | CC: | dcook, m.de.rooy |
Version: | 20.11 | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17754 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: |
Description
Magnus Enger
2022-06-20 13:32:17 UTC
We currently have 2 other bugs that are about encoding issues on importing MARCXML data, maybe one of those can give a clue: Bug 29333 - Importing UNIMARC authorities in MARCXML UTF-8 breaks the encoding Bug 17754 - MARCXML upload in Intranet is broken (encoding) (In reply to Magnus Enger from comment #0) > Anyone got a hunch what might be causing this, or where to start looking for > a solution? I love a good encoding problem... It looks like MARC::File::XML is rewriting that position 9 to " " from "a" based on this code in MARC::File::XML::decode(): if (@leaders) { my $leader = $leaders[0]->textContent; # this bit is rather questionable $transcode_to_marc8 = substr($leader, 9, 1) eq 'a' && decideMARC8Binary($format, $enc) ? 1 : 0; substr($leader, 9, 1) = ' ' if $transcode_to_marc8; $rec->leader($leader); } But since you're setting BinaryEncoding to utf8, it shouldn't be doing that "questionable" rewrite. And like you say... it seems to work fine when you don't use ModBiblio... -- MARC::File::XML::decideMARC8Binary() uses a /o regex modifier which is heavily warned against. But I don't see how that would cause a problem here... -- It looks like C4::Biblio::GetMarcBiblio (called by ModBiblio) runs the following: MARC::File::XML->default_record_format( C4::Context->preference('marcflavour') ); That does interfere with MARC::File::XML's internal $_load_args data structure, but... that should be OK since RecordFormat should be MARC21 either way. Plus what we're really worried about is the "BinaryEncoding" anyway. -- MARC::Record::new_from_xml does call MARC::File::XML::decode... In GetMarcBiblio, we run the following: 1221 MARC::Record::new_from_xml( $marcxml, "UTF-8", 1222 C4::Context->preference('marcflavour') ); 1223 }; But that shouldn't reset anything in MARC::File::XML... -- I think the only option really is to add debugging code to MARC::File::XML and C4::Biblio to try to unpick what is happening, unfortunately. My one thread at the moment would be to try to use "UTF-8" instead of "utf8" for your BinaryEncoding and hope that it's due to a Perl bug in Perl/MARC::File::XML, but that seems very unlikely to me. If you send over that 2-3 record test set, I'd be interested in poking around with them on koha-testing-docker. |