Yuck. I've never seen that. Perhaps it comes up more often in databasey sorts of applications (which I generally avoid anyway). In the MIME world, there's scope to mislabel an encoding as a similar encoding, but generally people are pretty clear about whether something's already in UTF-8 or not.
(That said, I have recently been receiving Japanese spam which is actually encoded in Shift-JIS but claims to be ISO-2022-JP, which is a particularly disgusting combination. If it were really in EUC-JP that would at least be vaguely internally consistent, in the sense that one could construct a subset of full ISO-2022 containing both. I can only assume such spam is directed at people whose MUA is both configured in Shift-JIS and ignores character set headers, and it seems astonishing to me that there are enough such people to make spam like that worthwhile...)
Yuck. I've never seen that. Perhaps it comes up more often in databasey sorts of applications (which I generally avoid anyway).
No, what comes up in database-y applications is typically a set of tables in a cross-border customer system being accessed and updated by non-Unicode-aware clients, each of which may be using a different local character set...
...and then someone else comes along and installs a Unicode-aware client on some subset of the customer terminals which expects all this data to be in UTF-8. (For bonus marks, these may then also be used to edit some records.)
Afterwards, another person will come and ask me how to make sure all the records display correctly everywhere. Laughter typically ensues - at least until I realise that they're really not joking.
(A proprietary ISAM-based beastie. The system in question dates from rather a while before Unicode even existed, so it's just about excusable. Its as-yet-unreleased replacement mercifully does do the Right Things and manages to use a Real Database to boot.)
Unless you accidentally get yourself employed by my orkplace, you probably can, yes.
Then again, this (http://thedailywtf.com/forums/thread/97990.aspx) story is about one of the two largest companies in our market (we were recently bought by the other one), so as horrifying as the thought is, it's pretty safe to say that It Could Be Worse. Much worse.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(That said, I have recently been receiving Japanese spam which is actually encoded in Shift-JIS but claims to be ISO-2022-JP, which is a particularly disgusting combination. If it were really in EUC-JP that would at least be vaguely internally consistent, in the sense that one could construct a subset of full ISO-2022 containing both. I can only assume such spam is directed at people whose MUA is both configured in Shift-JIS and ignores character set headers, and it seems astonishing to me that there are enough such people to make spam like that worthwhile...)
No, what comes up in database-y applications is typically a set of tables in a cross-border customer system being accessed and updated by non-Unicode-aware clients, each of which may be using a different local character set...
...and then someone else comes along and installs a Unicode-aware client on some subset of the customer terminals which expects all this data to be in UTF-8. (For bonus marks, these may then also be used to edit some records.)
Afterwards, another person will come and ask me how to make sure all the records display correctly everywhere. Laughter typically ensues - at least until I realise that they're really not joking.
(A proprietary ISAM-based beastie. The system in question dates from rather a while before Unicode even existed, so it's just about excusable. Its as-yet-unreleased replacement mercifully does do the Right Things and manages to use a Real Database to boot.)
Then again, this (http://thedailywtf.com/forums/thread/97990.aspx) story is about one of the two largest companies in our market (we were recently bought by the other one), so as horrifying as the thought is, it's pretty safe to say that It Could Be Worse. Much worse.