Issue #10883: STLLoader's binary check trips up
This commit addresses Issue #10883 in which the isBinary() check of an STL data stream can incorrectly identify a syntactically invalid but still useful ASCII STL as being binary. Namely, the ASCII STL will be identified as binary if the ASCII STL data presents a non-US-ASCII 'name' field parameter with the 'solid' or 'endsolid' keywords. E.g., solid 穿山甲 facet normal 0.7071067717164974 -0.00016366188967739515 0.707106771716591 outer loop vertex 135.89921424250542 449.7206946618269 58.1296582226351 ... endloop endfacet endsolid 穿山甲 Note that as ASCII STLs must be in US-ASCII, they may contain no characters with the high bit set. As such, the example above is syntactically invalid. However, more and more such ASCII STLs are appearing. Moreover, the isBinary() check itself is tripping up as it tries to accommodate a potentially incorrect binary STL for which the computed data length disagrees with the observed data length. So, it's something of a juggling act as the code attempts to accommodate different, broken inputs. This commit attempts to address this issue while making minimal disruption to the present code. After the data length is computed but found to not agree, this change next looks for the US-ASCII phrase 'solid' at/near the start of the data. If it is found, then the STL is declared to NOT be binary. Then, the existing check of the data for any non US-ASCII characters is performed. That is, a new check has been inserted between the length check and the 8bit character check. A more robust change might be to look for 'solid' in the first five bytes of the data and, if found, declare it ASCII from the get go.
Showing
想要评论请 注册 或 登录