Repository navigation
files.encoding setting is ignored on launch (must be modified to take effect) #11210
Copy link
Copy link
Closed
Labels
Feature: Doc commentsAn issue related to code comments shown in hover, completion, and signature help.An issue related to code comments shown in hover, completion, and signature help.Language ServicebugfixedCheck the Milestone for the release in which the fix is or will be available.Check the Milestone for the release in which the fix is or will be available.world readyAn issue relating string character encodings, localization translations, etc.An issue relating string character encodings, localization translations, etc.
Milestone
Description
Environment
- OS and Version: windows 11 22621.1992
- VS Code Version: 1.80.1
- C/C++ Extension Version: 1.16.3
- If using SSH remote, specify OS of remote machine: no
Bug Summary and Steps to Reproduce
Bug Summary:
Steps to reproduce:
1: When the file code is GBK, the Chinese of the IntelliSense Tooltip is displayed in garbled format;
2: When the file code is GBK and the file where the function is located is opened in advance, the Chinese display of the IntelliSense Tooltip is normal;
3: When using UTF-8 encoding format, the Tooltip of IntelliSense displays normally in Chinese.
May I ask if this situation will be updated and handled in the future?
Expected behavior:
Configuration and Logs
{
"configurations": [
{
"name": "ESP-IDF",
"compilerPath": "C:\\Espressif\\tools\\xtensa-esp32s3-elf\\esp-2021r2-patch5-8.4.0\\xtensa-esp32s3-elf\\bin\\xtensa-esp32s3-elf-gcc.exe",
"includePath": [
"${config:idf.espIdfPath}/components/**",
"${config:idf.espIdfPathWin}/components/**",
"${config:idf.espAdfPath}/components/**",
"${config:idf.espAdfPathWin}/components/**",
"${workspaceFolder}/**",
"C:/Espressif/frameworks/esp-idf-v4.4.4/components/**"
],
"browse": {
"path": [
"${config:idf.espIdfPath}/components",
"${config:idf.espIdfPathWin}/components",
"${config:idf.espAdfPath}/components/**",
"${config:idf.espAdfPathWin}/components/**",
"${workspaceFolder}"
],
"limitSymbolsToIncludedHeaders": false
},
"compileCommands": "${workspaceFolder}/build/compile_commands.json"
}
],
"version": 4
}Other Extensions
No response
Additional context
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
Feature: Doc commentsAn issue related to code comments shown in hover, completion, and signature help.An issue related to code comments shown in hover, completion, and signature help.Language ServicebugfixedCheck the Milestone for the release in which the fix is or will be available.Check the Milestone for the release in which the fix is or will be available.world readyAn issue relating string character encodings, localization translations, etc.An issue relating string character encodings, localization translations, etc.


Activity
Colengms commentedon Jul 18, 2023
Hi 袋袋有奖 (@bitssly) . I think you may be seeing the same issue as: #4753 (comment)
There are 2 related VS Code settings:
files.encodingandfiles.autoGuessEncoding. If a file contains a BOM (header), the C/C++ Extension should always be able to determine the proper encoding for it. However, if a file doesn't contain a BOM, VS Code will try to analyze the file (when opened) to 'guess' at it's encoding (iffiles.autoGuessEncodingis enabled) or fall back to thefiles.encodingsetting.For files that are open in VS Code, the C/C++ Extension will always receive their content in UTF-8 format, having already been converted (if necessary) by VS Code itself. For files that are not currently open, the C/C++ Extension does not currently attempt to replicate the behavior of VS Code's
files.autoGuessEncodingbehavior but should fall back to using the format specified byfiles.encoding.It might be possible to avoid an issue here by always using a BOM in source files that are not UTF-8. Or, set
files.encodingto the default encode for files your files. If you're already usingfiles.encoding, and it's not working as expected for unopened files, let us know, as that may be a bug. Or, if you need the behavior offiles.autoGuessEncodingto be replicated by the C/C++ Extension for files not currently open, I'd suggest 'up-voting' this issue: #4753bitssly commentedon Jul 21, 2023
Hi Colen Garoutte-Carson (@Colengms) .
This is the status of my current vscode configuration information. I have used the relevant settings, but it cannot solve the problem of garbled code.
bitssly commentedon Jul 21, 2023
Hi Colen Garoutte-Carson (@Colengms) .


I went to solve this problem and finally used the second method to solve the problem of garbled code;
1: I tried changing the GB2313 encoding format to GBK format, but the phenomenon did not improve;
2: Rolling back the C/C++version from V1.16.3 to 1.15.4 can display Chinese normally;
Colengms commentedon Jul 21, 2023
Hi 袋袋有奖 (@bitssly) . I'm unable to reproduce a regression in 1.16.3 related to this. If I set
files.encode, I see that this encoding is used to decode the header file contain the text to be displayed on hover (when it's not already open in the editor).Can you provide a simple, self-contain repro, such as in the form of a GitHub repo or zip file, that we might use to investigate the problem?
Also, in the first image in your last comment, doesn't the C/C++ Extension display the Chinese equivalent of "Reload Required"? If so, that would suggest perhaps you were not reproducing the issue with the version of the extension you thought?
4 remaining items
[-]The problem of garbled code caused by intelligent perception of file encoding[/-][+]`files.encoding` setting is ignored on launch (must be modified to take effect)[/+]bitssly commentedon Jul 25, 2023
Hi Colen Garoutte-Carson (@Colengms) .
Congratulations on finding the bug,
My phenomenon here is not very consistent with yours. In order to more intuitively reflect it, I recorded a video,
In order to reduce the impact of other plugins, I only enabled the C/C++plugin, which is version 1.16.3;
Uninstall vscode Chinese language pack;
I don't know if the regional setting of my Windows is in Chinese and it will affect this

Video_20230725100006.zip
michelleangela commentedon Jul 27, 2023
Fix available in pre-release https://github.com/microsoft/vscode-cpptools/releases/tag/v1.17.0.
bitssly commentedon Jul 27, 2023
Hi Colen Garoutte-Carson (@Colengms) , Michelle Matias (@michelleangela)
Thank you very much. After verification, the issue has been completely fixed in this version. Thank you for your efforts
pre-release https://github.com/microsoft/vscode-cpptools/releases/tag/v1.17.0
michelleangela commentedon Aug 15, 2023
Fixed in release version https://github.com/microsoft/vscode-cpptools/releases/tag/v1.17.2.