If a record already contains contains items with UTF-8 characters (accented characters for example), those characters become garbled when the record is modified. Example : "méthode" in field 952$3 becomes "méthode" after the record is saved.
Additionnal informations : The problem seems to happen when the character at offset 17 of the leader is a space. Koha puts a '7' there by default on new records. Example leader where the problem applies : 26489nam a2203769 a 4500
(In reply to comment #1) > Additionnal informations : > The problem seems to happen when the character at offset 17 of the leader is a > space. Koha puts a '7' there by default on new records. > > Example leader where the problem applies : 26489nam a2203769 a 4500 After doing more tests, it seems the leader isn't the cause of the problem. I found that using accented characters in the record when modifying it can cause the encoding problem on the items. Still investigating...
Created attachment 3384 [details] [review] Prevent re-encoding the items if they are already in UTF-8 in ModBiblio. I think I have found the source of the problem : In ModBiblio, the items were re-encoded in UTF-8 to fix some possible encoding mixing problems, but there was no check to see if the items were already in utf-8 before doing the re-encoding. This might have caused some encoding mixing problems in the case where the record and the item each contained utf-8 characters. Patch attached. Please test.
Signed off.
Pushed, please test
This bug is mentioned in: Bug 5883 : Prevent re-encoding the items if they are already in UTF-8 in ModBiblio. http://lists.koha-community.org/pipermail/koha-patches/2011-March/014204.html
I think I made a mistake on this patch : Encode::encode DEACTIVATES the utf-8 flag on a string, so checking if the flag is deactivated before doing the Encode::encode doesn't make any sense. I guess the problem was solved on my Koha instances because the re-encoding is never done. Reopening this bug so a good solution to this problem may be found. Maybe remove the subfield re-encoding altogether?
There have been no further reports of problems so I am marking this bug resolved.