Summary: | UTF-8 characters in items (952) get encoded wrong when the record is modified. | ||
---|---|---|---|
Product: | Koha | Reporter: | Frédérick Capovilla <fcapovilla> |
Component: | Cataloging | Assignee: | Frédérick Capovilla <fcapovilla> |
Status: | CLOSED FIXED | QA Contact: | Bugs List <koha-bugs> |
Severity: | normal | ||
Priority: | PATCH-Sent (DO NOT USE) | CC: | chris, julian.maurice, katrin.fischer, koha.sekjal |
Version: | 3.4 | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Attachments: | Prevent re-encoding the items if they are already in UTF-8 in ModBiblio. |
Description
Frédérick Capovilla
2011-03-16 14:19:04 UTC
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. |