Is CL8MSWIN1251 a subset of AL16UTF16 (or other *UTF*) at all?

Question

DB: Oracle 9.2.0.1.0 on Linux
Client: 9.2.0.1.0 on Windows 2000/XP, Bulgarian regional options
Hi,
I have big trouble using CL8MSWIN1251 as a client charset, WE8ISO8859P1 as a database charset and AL16UTF16 as a national charset. I do this cause I want to make only few datas multilingual, using NCHAR datatypes. Furthermore, I chose AL16UTF16 because in some oracle docs I've read this type is most compatible with windows clients because it's fixed length and a strict superset of UCS-2.
1) It seems to me that SQL*Net converts all cyrillic characters to ? or whatever (but identical anyway) on the modification phase. Then on the fetch phase I get all ? for cyrillic.
2) When I set the client charset to WE8ISO8859P1, everything works fine, BUT I think it's not a clever idea, cause it could impose some implications in the future.
3) When I insert/update using WE8ISO8859P1 and fetch using CL8MSWIN1251, I get just incorrect characters, because of the recoding between these both.
All this makes me to think there is some bug with CL8MSWIN1251. Can someone help me?
One more question: When I set client charset to AL16UTF16, on db login the oracle client does not complain about "invalid NLS parameter" (though it's not a valid client setting), but these: OEM 2.2 shows "Connection closed", dbExpress in Borland Delphi 7 raises an exception "Mapping failed", etc. UTF8 setting for the client works, but why to recode between them, if I decide to make it the hard way and work with raw UTF16 in Delphi. For what reason the AL16UTF16 is not a valid client charset, but not treated as such?
Please, throw some light on these, especially on the first question.
With best regards,
Anton Kolev

Answer 1

Thank you for your response.
So,
In the SQL CHAR datatypes I store texts in plain english. In the NCHAR (unicode) datatypes I need to store texts in english, french, other western european languages with special accented and other characters, cyrillic in the win1251 encoding, and probably some sort of japanese in the future.
The idea is to ship the final product to different worldwide customers without modifications, they would just need to set the proper charset in their clients (and, it's usually set properly by the oracle client installer on windows). This also means there is low probability that different languages will be stored in the db at the same time. My only intent is to reduce the customizations for each customer.
Please note, that if and when I realize all the internals of this unicode stuff, there is no problem to switch the db charset to UTF, but I have to be sure it will work properly with at least cyrillic in the first place, which is not my case for now.
The tools I use are Golden32 (latest) execute&edit function and plain SQL, SQL*PLUS on Linux, Borland Delphi 7 with ADO (MDAC 2.7) or dbExpress, the table editor of DBA Studio (OEM 2.2).
My tests are quite simple for an example code, just INSERT and SELECT on a single NVARCHAR2(500) column with different client charsets (e.g. insert as 8bit charset and select as UTF etc.).
I hope this helps you to check out my problem.
With best regards,
Anton