A bug and thinking about utf8 encoding
I noticed that the 1.11.3.0 - 1.11.7.0 version changelog included a change to the FILE_Exists function, and then noticed that some of my files named in Chinese were not running through thinbasic.exe anymore.
I then did some experiments and confirmed that this was due to an utf8 encoding issue, and that plain English path scripts were working.
However, I converted the path to utf8 encoding and started thinbasic.exe, but still can not run, and in a pure English path of the script, through the #include reference to external scripts, and must use utf8 encoding to run properly.
Irresponsible guess, maybe because thinbasic.exe is through the call FILE_Exists, FILE_Load and other functions to load the script file, and these functions in later versions changed to utf8 encoding support, which led to all this problem?
Multi-language encoding support is a great thing, and I initially suggested that the author make changes in this regard, but then in time I realized that this might not be a very good choice.
OEM coding always follows the windows distribution and is the preferred language for each country version of windows, usually we classify it as ANSI like, the advantage of this coding is that there is no cost of understanding and it is very easy to use, unless it is a systematic project that needs to be available to all countries and there is a need to be compatible with multiple languages on one PC, otherwise unicode is not a necessary choice.
Of course, this doesn't mean I'm against unicode, but one of the more frustrating reasons for me is that when extensions like UI, File, etc. add support for utf8, it becomes more complicated to manipulate multiple languages, and in the last year when I've been training people around me to program in thinbasic, I've often had to explain to them why this area needs to be character I often had to explain to people around me when I was training them to use thinbasic for programming in the last year why character encoding was needed in this area, and then what character encoding was and why there were so many of them.
Of course, this confusion may be caused by the fact that thinbasic does not make all functions firm when utf8. If all functions were utf8, then the encoding conversion would not be valid, but obviously not, which means that a lot of encoding conversion operations are needed when calling the system API, which reduces the efficiency of software execution.
The BASIC like language has always been known for its simplicity, so maybe it's time for me to suggest to the authors to eliminate utf8, or maybe we can change the encoding to switchable? For example, set the encoding by some command, and after switching, the function will automatically convert the text according to the set encoding, but this is a big job and takes a long time.
The above is my thinking and discussion about this matter, but thinbasic.exe can not run under the non-ascii path of the problem is real, perhaps in future versions, we can prioritize this problem will be fixed.
Translated with www.DeepL.com/Translator (free version)
