Feature hasn't been suggested before.
Describe the enhancement you want to request
Description
OpenCode currently seems to assume UTF-8 when using built-in tools such as Read, Grep, Edit, and Write.
This works well for modern projects, but it can cause problems in legacy codebases that contain files encoded with GB2312, GBK, Big5, EUC-KR, Shift-JIS, or other non-UTF-8 encodings.
For example, some older projects still contain source files encoded with non-UTF-8 encodings. When these files are read or edited as UTF-8, comments or string literals may become garbled. In some cases, using Edit or Write may also save the file back in a different or corrupted encoding, which can damage the original source file.
Expected behavior
It would be very helpful if OpenCode could support multiple file encodings in its built-in file tools, similar to editors like VS Code or Cursor.
Possible improvements:
- Detect the original file encoding when using
Read, Grep, Edit, or Write.
- Decode non-UTF-8 files correctly when displaying or processing content.
- Preserve the original file encoding when writing changes back.
- Provide a project-level configuration option to specify the default encoding.
- Optionally support explicit encoding conversion, such as GBK to UTF-8, when requested by the user.
For example:
{
"fileEncoding": "gbk"
}Why this matters
Many real-world projects still contain legacy source files in non-UTF-8 encodings. These projects are difficult to migrate completely to UTF-8 because of historical reasons, old toolchains, or compatibility requirements.
Without proper encoding support, OpenCode may produce garbled text, fail to search content correctly, or accidentally corrupt source files during editing.
Better encoding support would make OpenCode safer and more practical for legacy codebases and international users.
Suggested behavior
Ideally, OpenCode should handle file encodings in a way similar to VS Code or Cursor:
Detect the file encoding automatically when possible.
Allow users to configure the encoding manually.
Preserve the original encoding when saving.
Avoid modifying files when the encoding cannot be safely determined.
Thanks for considering this feature.
Feature hasn't been suggested before.
Describe the enhancement you want to request
Description
OpenCode currently seems to assume UTF-8 when using built-in tools such as
Read,Grep,Edit, andWrite.This works well for modern projects, but it can cause problems in legacy codebases that contain files encoded with GB2312, GBK, Big5, EUC-KR, Shift-JIS, or other non-UTF-8 encodings.
For example, some older projects still contain source files encoded with non-UTF-8 encodings. When these files are read or edited as UTF-8, comments or string literals may become garbled. In some cases, using
EditorWritemay also save the file back in a different or corrupted encoding, which can damage the original source file.Expected behavior
It would be very helpful if OpenCode could support multiple file encodings in its built-in file tools, similar to editors like VS Code or Cursor.
Possible improvements:
Read,Grep,Edit, orWrite.For example:
{ "fileEncoding": "gbk" }Why this matters
Many real-world projects still contain legacy source files in non-UTF-8 encodings. These projects are difficult to migrate completely to UTF-8 because of historical reasons, old toolchains, or compatibility requirements.
Without proper encoding support, OpenCode may produce garbled text, fail to search content correctly, or accidentally corrupt source files during editing.
Better encoding support would make OpenCode safer and more practical for legacy codebases and international users.
Suggested behavior
Ideally, OpenCode should handle file encodings in a way similar to VS Code or Cursor:
Detect the file encoding automatically when possible.
Allow users to configure the encoding manually.
Preserve the original encoding when saving.
Avoid modifying files when the encoding cannot be safely determined.
Thanks for considering this feature.