Utf-8' codec can't decode byte 0xae

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.

:thinking:

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.