cx_Oracle could use an encoding 'raw' which would lead to returning bytes instead of unicode strings without any conversion. That way, conversion and fixing of corrupt strings can be done on Python level instead of cx_Oracle level.

Also, legacy database content with mixed encodings can be supported then. It would work like the utl_raw.cast_to_raw function but without the length limitation of 4000 bytes. In fact, it would work like in python 2.7 now.

For testing, there also should be a way to write data. Eg this table could be supported:

create table translations (encoding varchar2(20), content varchar2(1000))
insert into translations (encoding, content) values ('utf-8', 'abë'.encode('utf-8'))
insert into translations (encoding, content) values ('windows-1252', 'abë'.encode('windows-1252'))

Additional advantage is that legacy 2.7 Python code now might have already encoding and decoding in place. In case Py27 code still runs, it would make moving this to 3.8 easier because no changes on the Python level are needed then.

This change of course would only apply to the py3 version of cx_Oracle since in Py2 this is already how it worked.