Hi, Sean - I'd like to register my interest/concern in this issue too. I am currently testing V38.2 and coincidentally switching to Python3 for our extensive circuits code. I noted some encoding issues and initially assumed them to be due to the Python2 -> Python3 transition. But I had gone through a previous phase of tests on V37.2 + Python3 with no noted encode issues, and having read this thread I now suspect I am witnessing the same issue as Jared.
Is there any way you can share the detail of the now resolved issue so I can be more confident that this is also my issue? Unless V39.x is released soon, this issue on V38 may enforce a pause to our conversion/test/update plan, so I would like to check the data that appears to force us into that pause.
Thanks and regards - Edwin Bolton
------------------------------
Edwin Bolton
------------------------------
Original Message:
Sent: Thu November 12, 2020 01:13 PM
From: Sean Mc Cann
Subject: Encoding Issues in v38.2
Just an update, you should see this fixed in v39.0
------------------------------
Sean Mc Cann
Original Message:
Sent: Tue October 27, 2020 02:20 PM
From: Jared Fagel
Subject: Encoding Issues in v38.2
Is anyone else suddenly experiencing encoding issues after the v38.2 upgrade?
It used to be the case that passing UTF-8 from a variable into a field was fine (ie if it came from a function as "results" in the post-processor). This no longer appears to be the case, and is now returning errors.
Here is a simple example character that is suddenly causing us headaches: →
------------------------------
Jared Fagel
Cyber Security Analyst I
Public Utility
------------------------------