Character problems
I've been trying to import some records to Koha 2.2.9 system (both with Koha's internal breeding.pl tool and bulkmarcimport.pl), but I can't seem to get all the UTF-8 characters to work right. While breeding.pl seems to break nearly all the special characters, bulkmarcimport.pl does a much better job. There are however some problematic characters with bulkmarcimport.pl also. For example a with umlauts (ä) works, but followed by n (än) it becomes a mess, very strange... I've been thinking about doing a database-wide search-replace to fix the broken characters, but how should I proceed with that? Is it a very good idea in the first place or is there a better way to fix the characters? Thanks! -Pasi-
Pasi -- I suggest we attempt to resolve the problem with the importer, and then reimport. Some other members on the list will be able to speak to your question better that I can, however. The data is represented in several places in the database, so it is not trivial to accomplish a mass-replace. And presumably you would want to import new data at some later point, regardless. --Joe Atzberger On Tue, Apr 15, 2008 at 5:50 AM, Pasi <pasi.korkalo@oululainen.com> wrote:
I've been trying to import some records to Koha 2.2.9 system (both with Koha's internal breeding.pl tool and bulkmarcimport.pl), but I can't seem to get all the UTF-8 characters to work right. While breeding.pl seems to break nearly all the special characters, bulkmarcimport.pl does a much better job. There are however some problematic characters with bulkmarcimport.pl also. For example a with umlauts (ä) works, but followed by n (än) it becomes a mess, very strange...
I've been thinking about doing a database-wide search-replace to fix the broken characters, but how should I proceed with that? Is it a very good idea in the first place or is there a better way to fix the characters?
Thanks! -Pasi-
Joe Atzberger <ohiocore@...> writes:
Pasi --I suggest we attempt to resolve the problem with the importer, and then reimport. Some other members on the list will be able to speak to your question better that I can, however. The data is represented in several places in the database, so it is not trivial to accomplish a mass-replace. And presumably you would want to import new data at some later point, regardless.--Joe Atzberger
This is what I ended up doing: 1. dump the whole koha database to a file with mysqldump 2. fix broken characters on that file with unix's sed 3. drop the existing koha database and create a new one 3. restore the data from the fixed file Granted, it's not a very elegant solution, but seemed to work just fine. I'm not actually sure if the problem is with the import-tools or with the data itself.
Unfortunately the same problem seems to exist with Z39.50 searches... None of the special characters seem to work with Z39.50. Any advice on this?
Unfortunately the same problem seems to exist with Z39.50 searches... None of the special characters seem to work with Z39.50. Any advice on this? There are known problems with 2.2.x and character encoding. I'd highly suggest you upgrade to 3.0, where the problems are fixed the 'right' way. The installation documentation for 3.0 has some pointers on how to make sure your system is
On Wed, Apr 16, 2008 at 5:49 AM, Pasi <pasi.korkalo@oululainen.com> wrote: properly configured to take full advantage of its Unicode support. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
participants (3)
-
Joe Atzberger -
Joshua Ferraro -
Pasi