Okay so I think what is happening here is that these characters can be stored in the default 8-bit (i.e one byte per character) ISO-8859-1 charset used by ID3, there is no need to UTF-8 (multiple bytes for some chars) or UTF-16 (2 bytes) so this is what SongKong is using.
I think Mp3Tag is trying to be clever by assuming that if you are using Windows Chinese then you are not using ISO-8859-1 charset, but an 8-bit encoding version more suitable for chinese such as GB_18030 . This seems wrong as the ID3 standard does not provide support for using these different charsets.
I do have a workaround, but it would require to use Jaikoz to resave the files. In Jaikoz if you set Write V2 Tag Version to v24 to force all files to be saved using ID3v24 format and you set Default Text Encoding to use when writing ID3v24 tags to UTF-8 that will ensure it uses UTF-8 all the time instead of just when it is required. Then if you read the files with Mp3Tag it should use UTF-8 regardless of the encoding used by Windows.
You can try out Jaikoz and save changes for a limited number of files to test without needing to purchase a license