<div dir="ltr"><div>As for needing a different subject for the email: I'm lumping together 2 new related attribute names: "charset=..." and "data_type=string|char" so that the information stored in char variables in netcdf-3 files can be easily and unambiguously interpreted.</div><div><br></div>You are correct. My proposal is for netcdf-3 files since they only support chars, not true strings.<div><br></div><div>As for "encoding" vs "charset", I'm open to different names. I chose "charset" because that is the name used in HTML and is widely used in other places. Yes, XML uses "encoding". To me, the word "charset" seems preferable because it is more specific than "encoding" (which also has a more general purpose meaning).</div><div><br></div><div>As for full Unicode support via UTF-8 vs UTF-16: Since netcdf-3 only supports 8bit chars, the 16bit UTF-16 is not an option. Yes, in UTF-8, characters are encoded via different number of bytes. Yes, this would take pre-planning on the file writers part (precompute the max length needed). Yes, the writer and the reader would have to handle this correctly. But UTF-8 is the only way I know of to support full Unicode using only 8bit chars for the underlying storage. It is very widely used. Every modern piece of software that can read or write text files supports it. It is the default for both XML and HTML 5.</div><div><br></div><div>Full Unicode support seems very useful. Other charsets support only a 255 character subset of full Unicode.  So UTF-8 is the only way to support a wide range of characters in a given string variable. </div><div><br></div><div>If the file writer doesn't need full Unicode, they can use <span style="font-size:12.8px">"ISO-8859-1" (which is compatible with 7bit ASCII) or some other charset in which each character has a fixed size (1 8bit char).</span></div><div><span style="font-size:12.8px"><br></span></div><div><br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 22, 2017 at 10:03 AM, Chris Barker <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>**</div><div>NOTE: this looks like it got tacked on to another thread -- please start a new thread for a new topic. (or gamil messed up...)</div><div>**</div><div><br></div>Sorry for being dense here, but I'm confused. I see in the netCDF(4) spec:<br><br><div>"""</div><div>The atomic external types supported by the netCDF interface are:<br>...<br>NC_CHAR 8-bit character byte<br>...</div><div>NC_STRING variable length character string *<br>...</div><div>"""</div><div><br>So shouldn't one use a 2-D (or higher dim) array of NC_CHAR type if that's indeed what you have?<br><br>Or is this about supporting netcdf3, which doesn't (I don't think) have a string type?</div><div><br></div><div>It does have a BYTE type, which I would be inclined to use for a CHAR. But then I suppose you'd need to tell readers that it was intended to be a character...</div><div><br></div><div>Other notes: </div><div><br></div><div>Do folks want/need to support full Unicode characters? If so I think you'd need a 4 byte type -- cal it NC_UCHAR? -- and anything else would be variable-length, which would kind of kill the whole point of a character type...</div><div><br></div><div>Small note: I'd prefer "encoding" to "charset" -- at least if you want to support "full" unicode, rather than only one-byte-per-char encodings.</div><div><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="m_4225601954721408237h5">> > The only charsets which are recommended are "ISO-8859-1" and "UTF-8".<br>
</div></div></blockquote></div></div></div></blockquote><div><br></div><div>UTF-8 is problematic because it uses a variable number of bytes per character (codepoint?). </div><div><br></div><div>If we want to support proper Unicode, then we need to either:</div><div><br></div><div>use a variable-length string type (the netcdf 4 NC_STRING type?)</div><div><br></div><div>or</div><div><br></div><div>Use 4 bytes per char.</div><div><br></div><div>Since UTF-* is a superset of ascii, it can be dangerous -- folks can say "this is UTF-*", and if they only happen to use the ASCII subset, al works fine, and then someone goes and tries to put a weird high-codepoint character in there, and all goes to heck.</div><div><br></div><div>I see that netcdf4 supports UTF-8 for names within the file (variable names, dimension names, etc), but that works because the number of bytes is known and constant once created.</div><div><br></div><div>Again, I'm maybe speaking from ignorance, I haven't dug into Unicode and CF And netcdf in any depth at all.</div><div><br></div><div><span style="color:rgb(80,0,80)">> > --- An Example: Encoding three Strings: "It", "Book", and "5 &euro;".</span><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="m_4225601954721408237h5">
> > The Unicode code point for the Euro symbol is 20AC (in hexadecimal),<br>
> > which is 8364 (in decimal).<br>
> > The Euro symbol is encoded in UTF-8 as 3 bytes: E2 82 AC (in hexadecimal).<br>
> > So a file would store these strings in a char array as:<br>
> >   dimensions<br>
> >     words = 3;<br>
> >     strLen = 5;<br>
> >   char myWords[words][strLen] = "It[0][0][0]", "Book[0]", "5 [E2][82][AC]";<br>
> >     charset = "UTF-8";<br>
</div></div></blockquote></div></div></div></blockquote><div><br></div><div>this is tough -- how do you know what strLen should be? You could get UTF-8 characters chopped off if it was too short.</div><div><br></div><div>Though I suppose that's a problem for the file writer to figure out.</div><div><br></div><div>-CHB</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_4225601954721408237gmail_signature" data-smartmail="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            <a href="tel:(206)%20526-6959" value="+12065266959" target="_blank">(206) 526-6959</a>   voice<br>7600 Sand Point Way NE   <a href="tel:(206)%20526-6329" value="+12065266329" target="_blank">(206) 526-6329</a>   fax<br>Seattle, WA  98115       <a href="tel:(206)%20526-6317" value="+12065266317" target="_blank">(206) 526-6317</a>   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Sincerely,<br><br>Bob Simons<br>IT Specialist<br>Environmental Research Division<br>NOAA Southwest Fisheries Science Center <br>99 Pacific St., Suite 255A      (New!)<br>Monterey, CA 93940               (New!) <br>Phone: (831)333-9878            (New!<span style="font-size:13.3333339691162px">)</span><div>Fax:   (831)648-8440<br>Email: <a href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a><br><br>The contents of this message are mine personally and <br>do not necessarily reflect any position of the <br>Government or the National Oceanic and Atmospheric Administration.<br><>< <>< <>< <>< <>< <>< <>< <>< <>< <br><br></div></div></div>
</div>