UnicodeDecodeError: ‘utf-8’ codec can’t decode byte 0xae in position 23: invalid start byte
Hi,
I might help to say how you encountered the error message. It looks like something related to language encoding , possibly an unrecognized character or font.
I’ve actually seen this too, just yesterday.
In the case below, it happens when I print a Purchase Order to screen, then try to save it as a PDF.
Feels like it happened due to a recent update. Server with the problem is ERPNext v12.22.0. Could be a PyPi dependency that broke. I’m not positive yet; still working on it.
File "/erpnext/mybench/apps/frappe/frappe/utils/pdf.py", line 26, in get_pdf
print(f"1: HTML = {html}")
UnicodeEncodeError: 'ascii' codec can't encode character '\xa0' in position 7238: ordinal not in range(128)
All i did was reboot my sql server using
shutdown -h now
Then this happen
UnicodeDecodeError: ‘utf-8’ codec can’t decode byte 0xae in position 23: invalid start byte
On my machine, I haven’t found the root cause yet. But here’s what is happening:
This function:
frappe.translate.get_messages_from_file()
is trying to process these files, and failing:
- ./assets/js/libs.min.js
- ./assets/js/desk.min.js
- ./assets/js/form.min.js
- ./assets/js/control.min.js
- ./assets/js/report.min.js
Something in the minified JavaScript files isn’t Unicode. So the function crashes.
My -temporary- workaround was to introduce a try-except into ‘get_messages_from_file()
’, to prevent the crashing.
What I don’t know is:
- Is translate supposed to touch those files? In which case, the files are the problem.
- If translate is not supposed to touch them, then translate (or something calling it) is the problem.
Thank @brian_pond
for me is was a good thing i have back up. This start happen in my production server after upgrade to ERPNext: v13.9.2 (version-13) Frappe Framework: v13.9.0 (version-13). I know there another patch out but am afraid to update so am setting up test box to see if that will fix it also. i will do the try -exception as you suggest.
Interesting that you’re seeing this on v13, but I’m seeing on v12.
I have a few other installations on v13.8.0. If I upgrade to v13.9, and the errors begin happening there too? That would be great. Because then I could just compare the code between 13.8 and 13.9, and find the root cause.