In our previous episode, Hans-Peter Diettrich said:
storage, we'll have to take that into account.
(16-bit codepages were designed into OS/2 and Windows NT before utf-8 even
existed)
Right, both systems were developed by Microsoft :-]
A cooperation between IBM and Microsoft starting
In our previous episode, Hans-Peter Diettrich said:
While it certainly is a stupid (Microsoft) idea to use UTF-16 for file
storage, we'll have to take that into account.
(16-bit codepages were designed into OS/2 and Windows NT before utf-8 even
existed)
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
While it certainly is a stupid (Microsoft) idea to use UTF-16 for file
storage, we'll have to take that into account.
(16-bit codepages were designed into OS/2 and Windows NT before utf-8 even
existed)
Right,
On 26/11/14 21:25, Hans-Peter Diettrich wrote:
Jonas Maebe schrieb:
On 26/11/14 17:41, Tomas Hajny wrote:
BTW, in this context - can users choose UTF16BE on little endian
platforms (and vice versa)?
No, because we do not have any routines that allow a user to set/change
the codepage of a
On 26 Nov 14, at 17:23, Jonas Maebe wrote:
On 26/11/14 17:21, Sven Barth wrote:
Yes, nevertheless the header record is the same for UnicodeString and
AnsiString and thus it also has a codepage field which is always
initialized to CP_UTF16 however.
It can also be CP_UTF16BE (which it is
On 26/11/14 17:41, Tomas Hajny wrote:
BTW, in this context - can users choose UTF16BE on little endian
platforms (and vice versa)?
No, because we do not have any routines that allow a user to set/change
the codepage of a unicodestring (either at run time or at compile time).
Jonas
Jonas Maebe schrieb:
On 26/11/14 17:41, Tomas Hajny wrote:
BTW, in this context - can users choose UTF16BE on little endian
platforms (and vice versa)?
No, because we do not have any routines that allow a user to set/change
the codepage of a unicodestring (either at run time or at compile
