ANSI Char

[ThiagoPostigoTM]

My local website (study purposes) is completely encoded in ANSI, even if my natural language is pt-br (portuguese Brazil).
When I try to navigate (from server itself or from any other device OS-independent), our special chars (á, à, ã, â, é, ê, í, ó, õ, ô, ú, ç) are showed something like different, sometimes as "?" sometimes as a retangle with an "X" inside, among others (unknown), etc.

SimpleWebServer v1.2.8 (installed today, 08-17-2023).
Microsoft Windows 10 64-bit 22H2 build 19045.3324.

In the image above, all our special chars are replaced with "�", accessed directly from server.

Sorry if this has a solution already, but I can't find it and sorry for my bad english...

[ethanaobrien]

This is most definitely an encoding issue. I'm not sure how we can send the proper coding, as the server assumes utf8

[ethanaobrien]

@terreng see this - https://github.com/terreng/simple-web-server/blob/1343dbd802742071b1d759ffd30e3b0751250283/WSC/handlers.js#L111C30-L111C30

If setting it in the html file works, that still poses an issue for non html files. Example json files

Is it possible for us to detect the encoding when sending the file

Edit: we could possibly use this
https://stackoverflow.com/a/50045951
I don't know the speed limitations though. Maybe add an option whether or not to check for other text encoding options?

[terreng]

I don't know a lot about different character encodings, but I know that auto-detecting the encoding is imperfect. I think your suggestion to make it an option probably makes the most sense, although this issue can also be fixed by the user by simply saving the files with UTF-8 encoding.

[terreng]

@ethanaobrien What do you think? Implement an option to check for other encodings, or just leave ANSI as unsupported and move on?

[ethanaobrien]

I think it'd be easy to detect the encoding, there's likely an npm package. I think we should implement the ability to detect the encoding, but lock it behind an advanced option, since it will not be 100% accurate, as you said in a previous message

Rust we might need to call it unsupported. I'll have to figure that out