Summary: | Koha returns <, >, etc in the record instead of <, >, etc when fulfilling a Z39.50 request | ||
---|---|---|---|
Product: | Koha | Reporter: | Joseph Alway <jbalway> |
Component: | Z39.50 / SRU / OpenSearch Servers | Assignee: | Galen Charlton <gmcharlt> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P5 - low | CC: | fridolin.somers, gaetan.boisson, jonathan.druart, jwagner, m.de.rooy |
Version: | 3.10 | ||
Hardware: | All | ||
OS: | All | ||
See Also: | http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3326 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Attachments: | Test Record - Linux Journal |
Description
Joseph Alway
2013-01-31 19:57:51 UTC
I ran into this problem recently and we did various tests. The MARC records within Koha were clean; extracting them via Tools, Bib Export also produced clean records. Extracting them via a z39.50 connection to the Koha database produced records with the funky characters. We noticed most often the substitution of & for an ampersand. I also tested against other z39.50 targets. The problem seems to be limited to Koha's z39.50 export. We found that the problem disappeared when we tested against a site running Solr instead of zebra indexing, so it is further specific to zebra in some manner. Created attachment 14986 [details]
Test Record - Linux Journal
In theory any record with the <, >, etc characters should give the same problem.
(In reply to comment #1) > I ran into this problem recently and we did various tests. The MARC records > within Koha were clean; extracting them via Tools, Bib Export also produced > clean records. Extracting them via a z39.50 connection to the Koha database > produced records with the funky characters. We noticed most often the > substitution of & for an ampersand. I also tested against other z39.50 > targets. The problem seems to be limited to Koha's z39.50 export. > > We found that the problem disappeared when we tested against a site running > Solr instead of zebra indexing, so it is further specific to zebra in some > manner. The Linux Journal test record I attached was exported from the Koha Server I am having this issue with. I am having pretty much all of those same symptoms. I have not tried using Solr. It seems this is linked to a zebra problem indeed, see bug 3326 for more info. This also affects result pages when they are displayed via XSLT. I ran the command "sudo koha-rebuild-zebra -f kohatest" in a test machine and that seemed to fix the problem. When I ran the command for my production machine it did not do anything. They both should be setup the same. The only thing I did different in my test machine is that I commented out the opt_xml lines in the file /usr/sbin/koha-rebuild-zebra. That didn't seem to do anything, so I put it back the way it was originally by removing the comment. I confirm this bug. It appears when Zebra database is in GRS1 and when rebuild uses XML (rebuild -x) and retrieving in MARC (iso2709). See : http://search.cpan.org/~mirk/Net-Z3950-ZOOM/lib/ZOOM.pod#raw%28%29 Best solution is to avoid GRS-1. But someone must confirm it works using DOM. (In reply to Fridolin SOMERS from comment #6) > But someone must confirm it works using DOM. I confirm it works. mysql> select title from biblio where biblionumber=42; => Une Fête monstre <test> % yaz-client localhost:9998/biblios Connecting...OK. Sent initrequest. Connection accepted by v3 target. ID : 81 Name : Zebra Information Server/GFS/YAZ Version: 4.2.30 98864b44c654645bc16b2c54f822dc2e45a93031 Options: search present delSet triggerResourceCtrl scan sort extendedServices namedResultSets Elapsed: 0.001121 Z> format unimarc Z> f "Une fete monstre" Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 3, setno 1 SearchResult-1: term=Une cnt=760, term=fete cnt=29, term=monstre cnt=13 records returned: 0 Elapsed: 0.035910 Z> show Sent presentRequest (3+1). Records: 1 [biblios]Record type: Unimarc 00595nam a2200181 4500 001 142 010 $a 9879350061855 090 $a 42 100 $a 19960115 frey50 200 1 $a Une Fête monstre <test> $f Stéphanie Laslett $g ill. Nigel MacMullen $b LIVR [SKIP] Please reopen if I am wrong. |