When searching Koha using a Z39.50 client you get <, >, etc returned in the record instead of <, >, etc.
I have installed a fresh version of debian and koha 3.10.2. I have imported a "fresh" record using the Z39.50 search. I grabbed the "Linux Journal" record from the LC Z39.50 server.
I have connected to Koha's Z39.50 server using the following command: yaz-client -c /etc/koha/zebradb/ccl.properties localhost:9999/biblios
I run the command find linux and then show. I get a record that returns < and >, etc. instead of <, >, etc.
This also happens when I connect to Koha's Z39.50 server using TLC's Cataloging module. So, multiple Z39.50 clients having the same issue with Koha's Z39.50 server giving them < xml entities instead of the correct character <, etc.
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
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).
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
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
Z> format unimarc
Z> f "Une fete monstre"
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
Sent presentRequest (3+1).
[biblios]Record type: Unimarc
00595nam a2200181 4500
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
Please reopen if I am wrong.