Re: Enhancement Topics (Format and Usage Bugs)
"Frank Pilhofer" <[email protected]> Tue, 08 May 2007 17:52:04 -0400
| Newsgroups | gmane.comp.security.passwordsafe.devel |
|---|---|
| Message-ID | <[email protected]> |
On Tue, 08 May 2007 02:53:27 -0400, Wolfgang Keller <[email protected]> wrote: > > The definition is still to weak or misleading. Without being an expert > in this, I know that UTF-8 may come with something they call "BOM" as a > prefix token. Moreover, UTF-8 encoding is a bit-format, not a text > format and I would not expect that null bytes are to be excluded from > being a valid part of it. So I suggest the following text as definition > for "Text": > Hi Wolfgang and all, BOMs ("Byte Order Marks") may be used with UTF-16 or UTF-32 to indicate that a code unit sequence is serialized in either big or little endian order. UTF-8 is byte oriented, and has no need for BOMs. Let's just delegate the responsibility to the appropriate party, with the appropriate references. Text fields are stored using the UTF-8 encoding scheme (see definition D-39 of the Unicode Standard 4.0 at http://www.unicode.org/versions/Unicode4.0.0/ch03.pdf). Note that a Unicode string (D-29a) does not contain any terminating NUL character that might exist in a C language implementation; consequently, no NUL character is stored or counted as part of the field length. I.e., the ASCII string "Hello World" is stored as a single block, with the field length set to 11. We could strike the second sentence, because it is implicit from the first, but given that I have been recently bitten by an incompatibility involving the null character recently, I'd like to see it included. Frank -- Frank Pilhofer, [email protected] ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/