<div dir="ltr">The reason you see ASCII values is that ASCII is a proper subset of unicode. The letter 'A' has value 65 in ASCII and also value 65 as a Unicode code point. But OpenSCAD is still a Unicode system, not an ASCII system, because the entire Unicode range is supported. So there's no need to stop at chr(255), when you also have chr(256), chr(257), and so on.<div><br></div><div>If you want to represent an array of values between 0 and 255 using a string, you can still do that, you'll just have represent 0 in a different way: pick a different code point. Or you could add an offset, and use the range chr(1) to chr(256) to represent the values 0 to 255. Of course, I'm not really sure what you're trying to do, but I hope this has helped.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 April 2015 at 12:29, Fantome <span dir="ltr"><<a href="mailto:paul@brownsbrain.com" target="_blank">paul@brownsbrain.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">doug.moen wrote<br>
<span class="">> HI Fantome. In OpenSCAD, a string is an array of Unicode "code points", it<br>
> isn't an array of bytes. Each code point in a string has a value between 1<br>
> and 0x10FFFF, except that some code point values are invalid. len(string)<br>
> is the number of code points in the string, and str[i] is the i'th code<br>
> point.<br>
><br>
> Torsten told you that internally, strings are represented in UTF-8 format.<br>
> But there are no operations in OpenSCAD that allow you to access that<br>
> internal representation. Numbers are represented internally as floating<br>
> point, but you can't access the underlying bit and byte patterns in a<br>
> float, either.<br>
><br>
> Your test program contains the word ASCII several times, but that's<br>
> misleading, you don't have access to the underlying byte representation.<br>
<br>
</span>Hello.<br>
It's interesting to hear about the inner working of this. If OpenSCAD had<br>
the ability to let users manipulate the bits the possibilities for modelling<br>
objects and systems would be increased. Just my opinion of course.<br>
<br>
When OpenScad echos/prints the chr(value), what it prints matches with the<br>
ASCII chart. This is why I named the variable ASCII_value. I don't think<br>
it's misleading. It is the ASCII value. It works for all 255 values, value 0<br>
is the only one that is ignored by OpenSCAD.<br>
<br>
For my specific application I guess I'll just figure out a work around since<br>
it seems obvious now that OpenSCAD is treating chr(0) as a 'something' that<br>
is not used in any comparison. The inner workings of OpenSCAD must have<br>
checks for a NULL character or chr(0) that equates to 'jump to the next<br>
character'. Oh well. One disappointment out of 256 values, still 99.61%<br>
satisfaction.<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://forum.openscad.org/How-to-detect-chr-0-tp12351p12405.html" target="_blank">http://forum.openscad.org/How-to-detect-chr-0-tp12351p12405.html</a><br>
<div class="HOEnZb"><div class="h5">Sent from the OpenSCAD mailing list archive at Nabble.com.<br>
<br>
_______________________________________________<br>
OpenSCAD mailing list<br>
<a href="mailto:Discuss@lists.openscad.org">Discuss@lists.openscad.org</a><br>
<a href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org" target="_blank">http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org</a><br>
<br>
</div></div></blockquote></div><br></div>