I wanted to examine my .kmy data file with a view to possibly being able to do bulk edits on tags etc. I gunzipped the .kmy file to produce what I expected to be a stock xml file and tried to open and examine it. QXMLEdit reported an error when I tried opening the xml file (error message attached as qxmledit_error.png) KDE's kate reported an error and trying to read the xml file in Python3 using xml.etree.ElementTree module reported an error at the same place as QXMLEdit. Examining the line reported in error I have found that there is a character 0 embeded in this line at the position shown in qxmledit_error.png (i.e. between the 'k' and the double quote). I should report that kmymoney works perfectly well with the original .kml file but you may want to be aware of this in case invalid characters like this cause problems further down the line.
Created attachment 124741 [details] QXMLEdit Error Sorry, forgot to attach the screenshot - here it is
I just found this bug report, no idea how it completely slipped through the cracks. Did you ever resolve the problem? Did KMyMoney successfully read the file? Does a newer version (either 5.1.3 or a version built from master branch) work? By "character 0" do you mean the digit 0, or a null character of value 0? Null's generally do not belong in regular character strings, but I can't imagine how KMyMoney would have put it there, unless it was part of an imported transaction. I'll save any further question in case you no longer have the file, no longer use KMyMoney (I hope not,) or otherwise choose not to respond.
Created attachment 176254 [details] attachment-4036352-0.html We're going back a fair way but ... It was a character value 0 `chr(0)` and KMyMoney worked successfully with the file. Looking though my KMyMoney folder I found a saved file from that time and I've tried to open it with qxmledit and get the same bad character error message. I've tried the same with a more recent .kmy file (yes, I'm still using it, happily, thanks) with no problems so it was probably a one-off. I think I reported this mainly because I couldn't think of a way of accidentally embedding a non-printable ASCII character in an XML file - OK so Ctrl-V followed by a control char keystroke (like Ctrl-G etc) during text input works in a tty, but I don't think even that works for `chr(0)` :-) If nobody else has reported this as a problem I'd guess you can ignore it. Thanks for getting back to me :-) Alan Prescott alanjprescott@gmail.com On Sun, 1 Dec 2024 at 03:33, Jack <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=415614 > > Jack <ostroffjh@users.sourceforge.net> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Resolution|--- |WAITINGFORINFO > Status|REPORTED |NEEDSINFO > > --- Comment #2 from Jack <ostroffjh@users.sourceforge.net> --- > I just found this bug report, no idea how it completely slipped through the > cracks. Did you ever resolve the problem? Did KMyMoney successfully read > the > file? Does a newer version (either 5.1.3 or a version built from master > branch) work? By "character 0" do you mean the digit 0, or a null > character of > value 0? Null's generally do not belong in regular character strings, but > I > can't imagine how KMyMoney would have put it there, unless it was part of > an > imported transaction. I'll save any further question in case you no longer > have the file, no longer use KMyMoney (I hope not,) or otherwise choose > not to > respond. > > -- > You are receiving this mail because: > You reported the bug.
I'm closing as WORKSFORME, since it would have been a bug if KMM itself put that null char in the data, even if during an import, and you got the error with other apps, not KMM itself. As to how that character got there, you are correct - it shouldn't have happened, but we certainly won't figure it out now. I'm guessing an import, but I'm not sure, and the import code has probably changed enough.