Created attachment 9216 [details] [review] Add UTF-8 charset negotiation to Z39.50 search Currently Koha has an option to specify encoding for Z39.50 target. However, that option only tell Koha what encoding is to be expected from the server. Some server support multiple encoding format that could be negotiated via "charset" option. For example OCLC WorldCat support both UTF-8 and MARC-8 and default to MARC-8. As UTF-8 should be a better option, it would be better if Koha can try to negotiate the result encoding. I made a simple patch to z3950_search.pl that just set ZOOM charset option to 'UTF-8" when Koha's Z39.50 target encoding is set to utf8 (I don't know valid value for charset option for other encoding). This work for OCLC WorldCat and some other targets. Note that I test it on Koha 3.2 and it should also work on later version as that part of code is unchanged.
Created attachment 9222 [details] [review] Bug 7967 - set charset when doing Z39.50 search Original patch from Pongtawat
Created attachment 9250 [details] [review] set charste for Z39.50 in acquision
I just notice that there is another Z39.50 client code in acquision that should also be updated (acqui/z3950_search.pl). I think it should be included in the patch (but I don't know how).
Created attachment 9667 [details] [review] Bug 7967 : Followup set encoding options for acqui/z3950_search.pl
Can we get a test plan for this?
The code that these patches touched has been moved to C4::Breeding (and concolidated into a single function) by bug 9105.
I just found that setting this charset option broke some Z39.50 servers. For example, for OhioLink server, it will freeze. Horizon Z39.50 server here seem to not like it either. So, it shouldn't be set unless needed. Since I need to set this option for OCLC to work properly for Thai language, so locally, I just hacked it to have a new option "UTF-8 with negotiation" to do this. Since it seems no one else has this problem, maybe the code should be leave as-is and this bug closed?
(In reply to Pongtawat from comment #7) > > Since it seems no one else has this problem, maybe the code should be leave > as-is and this bug closed? This is the last comment from 2013. I'll close as WONTFIX.