Conversion Error (ascii codec can't decode...)

What is the problem? Please be detailed.
Working on developing a form -- I had a colleague contribute to save time, but a 'bug' snuck in. I now get the following conversion error:
Conversion errors:
'ascii' codec can't decode byte 0x85 in position 182: ordinal not in range(128)

Is there a way to identify where the non-unicode character is located using this information? The form is _very _long. Thanks!

What ODK tool and version are you using? And on what device and operating system version?
Using XLSForm Offline 1.3 to convert from xlsx

What steps can we take to reproduce the problem?
Searched the forum to no avail.

What you have you tried to fix the problem?

Anything else we should know or have? If you have a test form or screenshots or logs, attach here.


Try converting your form using the online tool: It gives a more specific error message, post the message in here and we may find a solution.



That's a good idea, @A.N.M_AL-IMRAN.

@Lloyd_Banwart If you're using Excel on Windows, you may also want to try forcing a UTF-8 encoding when saving the file.

Is your file supposed to include non-ASCII characters or not? If it's not supposed to, I might try exporting as an ASCII CSV and seeing if any of the text looks strange. That might give you a hint as to where the problem is. Another tactic I might try is to remove the bottom half of the form, try converting it. If it converts, the problem is in the bottom half. Then I'd continue on chopping my form in half until I isolate the problem (basically binary search for the computer scientists out there).

1 Like

Hi Banwart,

in fact the issue is you are trying to convert 0x85 (133 Dec) to ASCII code which support (-128 , +127) and the value out of range.

when we encode data the best encoding is UTF-8 (0 , 255).

Best Regards

1 Like

Thanks for the fast and great suggestions all. I took the brute force route and started converting the form 1 module less at at time until I narrowed down the module the issues lay. Then I began narrowing down one group at a time, until I narrowed down to a single row. You see where I'm going with this. I narrowed it down to a cell (for a nearly 1,000 row form, this process took about 90 minutes).

The error lay in a cell in the calculate column. The command was "position(..)". The error occurred when a third period was entered by mistake (...) which is auto-converted in excel to 2013 to a funky character that almost looks just the same but smaller.

Anyways, problem solved, and I learned something today. So its a good day.

EDIT: I am typing "Position(..)" with two periods, but its forcing three (it appears as two on my left post screen, but three on my right 'view' screen). Perhaps a derivative of the same thing which caused my morning grief....


:scream: Sorry you had to do that, @Lloyd_Banwart! Hopefully your finding will help someone else in the future.

I think we should document the recommendation to turn off Auto Formatting when editing XLSForm.

There's an issue to provide more information when such errors occur at if someone wants to take it on.


I just wanted to share that I also came across this error, and also had to narrow it down manually to find out where the error was. I my case, it was a missing curly bracket in a relevance statement:

selected(${option1,'yes') should have been selected(${option1},'yes')

Apparently this can also cause a hard-to-comprehend ascii error. In my case, the error stated:

Conversion errors: 'ascii' codec can't decode byte 0xcd in position 198: ordinal not in range(128)

1 Like