While working with ICU I decided to create a new class for handling Unicode strings – because the class DBString has some limitations and I did not want to change the original DBString implementation just to fit my needs. I try not to access this class directly, but only via methods – perhaps in the future, when Instantiations introduced its own Unicode class I can simply switch to their class.
Instances of DBString can be used to hold double-byte characters – suitable for UTF16 characters. But within their implementation there seems to be a mixture of DBCS or Unicode support – I have not fully understand this.
But after all DBString as a superclass for my new Unicode class seems to be good choice. As John O’Keefe from Instantiations pointed out, instances of Character already have more than enough internal storage room to store UTF16 oriented characters (they are immediate objects). But in the future one might see problems, because Character is not able to hold UTF32 characters and this means, that streaming over Unicode-streams may be a problem.
But using DBString brings some more problems when entering UTF16 API calls. The first problem is “asPSZ”.This could be used, when using API-calls expecting true 16-bit UTF-16 strings. “asPSZ” from DBStrings does not this at all – it creates a ByteaArray holding a mixture of one-byte and two-byte representation of its string.
Therefore I introduced a new “asPSZ” method working as expected. Some other methods may not be called on this new class – like the int8At: method, which would damage the UTF16 string – but in general the new class does its work.