You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you asked this question, other people may ask why not another encoding. This problem is related to the encoding used on the filesystem for filenames, the encoding used by the OS functions, as well as the character set used (e.g. unicode, or any of the many things like ASCII, GB2312, Shift-JIS). Since most software is written in C, a lot of library functions work with ASCII. Perhaps it is better to use UTF-8 instead, as UTF-8 is backward-compatible with ASCII functions.
If you're thinking about the encoding used for filenames on USB disks: the filename encoding can be specific to the OEM. So it means it can be anything at all. If you go back to the 2000s, each regional release of Windows would use a different encoding, such as GB2312 for Chinese, Shift-JIS for Japanese, ASCII for English-US etc. Windows 7/10 use UTF-16 for the Long File Name (LFN) entries on FAT. In USBHDFSD (the USB filesystem driver), it would appear that the unsupported code points are replaced with "?" characters.
The other halve to this problem, is about support for character sets for display by the application itself; not all glyphs may be supported for display.
Why not add support for GB2312 encoding? Once it's supported, I don't have to worry about using ISO images with Chinese names.
The text was updated successfully, but these errors were encountered: