Repository navigation
File encoding specified in "files.encoding" setting is not honored #414
Description
In my workspace's settings.json
{
"files.encoding": "gbk"
}
These is still encoding problem in the auto completetion.
{{ message }}
In my workspace's settings.json
{
"files.encoding": "gbk"
}
These is still encoding problem in the auto completetion.
Activity
sean-mcmanus commentedon Dec 19, 2016
I'm not able to repro the problem. From your screenshot, it looks like you may be using another C++ extension for auto-completion, because our extensions doesn't provide test like that. Can you provide a sample that repros this? I created a file with GBK encoding and I didn't see a problem.
strrchr commentedon Dec 20, 2016
The gbk file should contain chinese characters.
Such as: 中文字符中文字符中文字符
sean-mcmanus commentedon Dec 20, 2016
Okay, I am able to repro the bug now. Thanks. I don't know how you got the text write(sprint ("%s..."... to appear, but I was able to get a repro via int func2(string s = "中文字符中文字符中文字符") {...
sean-mcmanus commentedon Mar 22, 2017
This bug was fixed a while ago.
sean-mcmanus commentedon Mar 22, 2017
Oops, it's not fixed. Looks like we don't handle GBK encoding correctly.
sean-mcmanus commentedon Mar 22, 2017
It looks like "most" functionality is broken when it interacts with 2-byte GBK encoding Chinese characters. Our code assumes UTF-8 characters are being used and we never check the encoding.
[-]Auto completetion should follow files.encoding in workspace settings[/-][+]Support file encodings other than UTF-8[/+]6 remaining items
hushunding commentedon Apr 26, 2020
I also have same problem，when mouse over function same time cannot get right tip。
all file use gbk coding
when function/variable/macro is not defined in same file，the comment is wrong
but is correct if define in same file
it seem langue server can not get the correct coding of files that are not opened.
Colengms commentedon Jun 4, 2020
We should be handling UTF8, UTF16LE and UTF16BE properly, as these are detectable based on some header bytes within the file. There appear to be issues with file encodings that aren't detectable this way. GBK, GB2312 and GB18030 just look like UTF8 to us. Files opened within VS Code are provided to us in UTF8, with VS Code having already done the proper conversion from encodings it supports, if configured to do so. It uses 2 settings:
or:
We're not currently considering these settings when opening files directly from disk, such as when scanning header files for doc comments. We should use the encoding specified by
files.encoding, if present, whenever we encounter a file without header bytes.It looks like there are similar issues in VS related to this (we share IntelliSense code with VS) that would need to be addressed as well
[-]Support file encodings other than UTF-8[/-][+]File encoding specified in "files.encoding" setting is not honored[/+]sean-mcmanus commentedon Sep 2, 2020
Fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/0.30.0-insiders4 . Let us know if you see any remaining bugs with non-UTF-8 encodings.
Colengms commentedon Sep 2, 2020
Note that the C/C++ Extension will now use the file encoding specified in
files.encoding, if there is no (known/supported) BOM detected in the file, and it's not UTF-16 (BE or LE). However, we are not currently replicating the behavior of VS Code'sfiles.autoGuessEncoding, which uses the jschardet library to detect the encoding of a file.sean-mcmanus commentedon Sep 3, 2020
Colen Garoutte-Carson (@Colengms) Should we open an issue to track the potential files.autoGuessEncoding?
Colengms commentedon Sep 3, 2020
Sean McManus (@sean-mcmanus) That would be: #4753