http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6479
--- Comment #8 from Frédérick Capovilla <fcapovi...@live.ca> 2011-08-12 19:42:58 UTC --- It's been a while since I created that patch but here is what I understand : I remember that in the NewIssue subroutine of Serials.pm, The content of $serialseq is concatenated with a variable fetched from a SQL query and that's where the problem happen. I did some tests to check the utf-8 flag on those two variables $serialseq = variable from the form (is_utf8 = false) $recievedlist = variable from SQL (is_utf8 = true) The encoding of the data fetched from SQL differs from the encoding of the data received from the form. If two string with a different encoding gets concatenated together, the encoding of one of the string is automatically changed, and we get an encoding problem on one half of the string. Using decode on $serialseq adds the utf-8 flag, so we don't get an encoding problem when we concatenate. We don't get this encoding problem when the first item is added in $recievedlist because $recievedlist is empty and doesn't automatically get the utf-8 flag. I'm guessing Perl DBI automatically addes the utf-8 flag if it finds utf-8 characters in a string returned from a SELECT. Anyways, that's what I think is happening. Correct me if I'm wrong? -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
