Closed ghost closed 1 year ago
Yes, we can probably do this. Actually, all newer files (starting from R2007) should be 'utf-8' encoded. For older files, there is a header variable $DWGCODEPAGE
which sets the proper encoding. Problem is that we initialize decoder before parsing the file. May be it is worth to remake parsing, implementing deferred text fields decoding, after overall structure is parsed. The simplest approach with UTF-8 assumption is used now because I am unaware how common are that old files in the wild. BTW can you confirm that your file has gbk
value in $DWGCODEPAGE
variable?
in header has $DWGCODEPAGE: 'gb_2312'
in header has $DWGCODEPAGE: 'gb_2312'
Ok, thanks. It seems that it also requires some mapping from possible values in this variable to a set of encodings supported by JavaScript. For now I will proceed with propagating this parameter to the viewer options.
It seems that it also requires some mapping from possible values in this variable to a set of encodings supported by JavaScript.
Just checked, my browser JS also supports gb_2312
as alias for gbk
. Not sure if it is cross-browser behavior since it is not documented.
GBK is a compatibility on GBK2312
I have added fileEncoding
option.
in
DxfFetcher.js
class TextDecoder() use paramsgbk
then can not resolve Chinese
I see this docs nodejs for textdecoder
i find has same params like
gbk
Can we consider making the encoding an optional parameter?
example: