Encoding data #590
Replies: 1 comment 4 replies
|
@DFilyushin, the only advantage that the Why do you want to implement the |
|
We're talking about supporting legacy code. On the Oracle side, the stored procedure expects 1251 encoding. This sounds strange, but they then convert this set of bytes to UTF-8. This is very old and strange code. We started rewriting part of it in Python and encountered this irrational behavior. But first, we need to maintain backward compatibility, otherwise we're breaking the existing code. Second question: why was this behavior introduced at the OracleCX driver level? |
|
The second questions is far easier to answer. It wasn't introduced as it was always there! This is based on the Oracle Client libraries and their greater concern for covering every possible scenario that someone might want at some point. And my knowledge and understanding of character sets and string encodings was very poor at the time so I simply followed along. As my knowledge matured and the overall ecosystem matured, the need for this was no longer present and even in cx_Oracle the default was "utf-8" for many years already. As for your first comment, you can easily enough bypass the decode when retrieving data from the database but the driver makes every effort to avoid sending string data as anything other than UTF-8 encoded bytes, since that is what is dictated by the agreement between client and server. With the Oracle Client libraries and cx_Oracle you could set the client character set to the same value as the database character set and then proceed to send any data and none of it would be validated -- but that hole has been closed in the new driver and rightfully so! Even if the encoding was supported (and there are no plans to do so for the reasons I have already stated), it would always require sending and receiving in that encoding -- and what you are describing seems to be a violation of that anyway. |
|
Thanks for answer, @anthony-tuininga |
The second questions is far easier to answer. It wasn't introduced as it was always there! This is based on the Oracle Client libraries and their greater concern for covering every possible scenario that someone might want at some point. And my knowledge and understanding of character sets and string encodings was very poor at the time so I simply followed along. As my knowledge matured and the overall ecosystem matured, the need for this was no longer present and even in cx_Oracle the default was "utf-8" for many years already.
As for your first comment, you can easily enough bypass the decode when retrieving data from the database but the driver makes every effort to avoid sending strin…