Byte Order Mark issue importing patrons
I have a report to export a patron csv file from our student information system, suitable for use with the koha patron import tool. I want our librarians to be able to use every semester to import new freshmen and transfers to koha, without further IT assistance. They run a report, save it as a CSV file, and use that file for the import. Unfortunately, in testing this when I go to import the file I get an error message: "header row could not be parsed". I get an additional error for every row in the file, which is not surprising given the failure with the header row. I'm sure you've all heard this one before. Here's where things get different. I can open the file in Notepad++ and change the encoding to use not use a byte order mark. I save the *same file*, import that into koha, and **everything works fine**. The only thing different is the lack of a byte order mark. I cannot cause my reports tool to not use a BOM, and it's asking a lot of my librarians to edit the CSV file in this way. Is there anything I can do to tell koha to ignore that BOM? Should this be filed as a bug somewhere? In searching google on this issue, I think many others may have had this same problem in the past, but not been able to solve it. For what it's worth, I'd also love to see a koha stack exchange site, as these questions are exactly the kind of thing stack exchange excels at producing solutions for. Joel Coehoorn Director of Information Technology York College, Nebraska 402.363.5603 jcoehoorn@york.edu *The mission of York College is to transform lives through Christ-centered education and to equip students for lifelong service to God, family, and society*
I'd fill a bug on http://bugs.koha-community.org, and maybe some developer will take on the issue. My feeling is that this could be syspref-driven or even using a checkbox at the download dialog. Regards To+ On Thu, Apr 25, 2013 at 3:28 PM, Coehoorn, Joel <jcoehoorn@york.edu> wrote:
I have a report to export a patron csv file from our student information system, suitable for use with the koha patron import tool. I want our librarians to be able to use every semester to import new freshmen and transfers to koha, without further IT assistance. They run a report, save it as a CSV file, and use that file for the import.
Unfortunately, in testing this when I go to import the file I get an error message: "header row could not be parsed". I get an additional error for every row in the file, which is not surprising given the failure with the header row. I'm sure you've all heard this one before.
Here's where things get different. I can open the file in Notepad++ and change the encoding to use not use a byte order mark. I save the *same file*, import that into koha, and **everything works fine**. The only thing different is the lack of a byte order mark.
I cannot cause my reports tool to not use a BOM, and it's asking a lot of my librarians to edit the CSV file in this way. Is there anything I can do to tell koha to ignore that BOM? Should this be filed as a bug somewhere? In searching google on this issue, I think many others may have had this same problem in the past, but not been able to solve it.
For what it's worth, I'd also love to see a koha stack exchange site, as these questions are exactly the kind of thing stack exchange excels at producing solutions for.
Joel Coehoorn Director of Information Technology York College, Nebraska 402.363.5603 jcoehoorn@york.edu
*The mission of York College is to transform lives through Christ-centered education and to equip students for lifelong service to God, family, and society* _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Tomas Cohen Arazi schreef op do 25-04-2013 om 15:33 [-0300]:
I'd fill a bug on http://bugs.koha-community.org, and maybe some developer will take on the issue. My feeling is that this could be syspref-driven or even using a checkbox at the download dialog.
I think it'd be enough for Koha to ignore (or even understand) the BOM. No reason for it to be syspref controlled if you can make it do the right thing. It _might_ even be enough to tell it to open the file as UTF-8. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
Hi, On Thu, Apr 25, 2013 at 4:34 PM, Robin Sheat <robin@catalyst.net.nz> wrote:
I think it'd be enough for Koha to ignore (or even understand) the BOM. No reason for it to be syspref controlled if you can make it do the right thing. It _might_ even be enough to tell it to open the file as UTF-8.
I agree -- Koha should just Do The Right Thing. At first glance, it looks like File::BOM might be useful, though we should think about whether we want to support arbitrary character encodings. [1] http://search.cpan.org/~mattlaw/File-BOM-0.14/ Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
participants (4)
-
Coehoorn, Joel -
Galen Charlton -
Robin Sheat -
Tomas Cohen Arazi