Re: Enhancement Topics (Format and Usage Bugs)

>
> Frank Pilhofer wrote:
>   
> Indeed.  I seem to remember that we finalized on using UTF-8, with no null
> byte at the end.  Yet I can find no record of that decision in the current
> formatV3.txt document.  Rony, can you please add a note to the formatV3.txt
> file to that effect, e.g.,
>
>    Text fields are stored using the UTF-8 character encoding.  No null
>    character is stored in the record data 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.
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":

   Text fields are stored using the plain UTF-8 character encoding without
   use of encoding signatures (BOM) or leading or trailing data length markers. 
   I.e., the ASCII string "Hello World" is stored as a single
   block, with the field length set to 11.


- Wolfgang



-------------------------------------------------------------------------
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/