No, that's completely wrong. It has nothing to do with the encoding.

Before segwit, the txid was the hash of the entire transaction. For non-segwit transactions, this is still true. But after segwit, some new data was added to transactions. This is not hashed as part of the txid, only those parts that were part of the non-segwit transaction format are hashed. The hash field was introduced for segwit as the hash of the entire segwit transaction.

When you see the txid and hash are the same, the transaction is non-segwit and both the txid and hash are hashing the entire transaction. When they are different, the transaction is a segwit transaction and txid is hashing some parts of the transaction while hash is hashing all of it.

Are you sure you are looking at correct values?
Here is an example transaction link on block explorer

The raw bytes of this transaction is:
You can use this online tool to compute SHA256 of hexadecimal input: https://cryptii.com/pipes/hash-function click on the drop down dots and select duplicate to compute it twice. It should look like this: https://i.imgur.com/LWXpRIA.jpg
As you can see the result is going to be:
Now if you look at that link from block explorer you can see that the txid is:
that is the hash result in reverse.

"Hash" is the result that you get from the hash function (double SHA256) and transaction ID is the hexadecimal representation of the that but in bitcoin we reverse it first and then encode it using base-16. So they are not exactly the same although they both represent the same value.
For example if your hash is { 1, 2, 3 } your txid is going to be 0x030201 (3 bytes is chosen for brevity otherwise length is 32 bytes).