Gfm does not retain encoding in Windows, garbles non-ASCII text

[hashchange]

Hi,

I noticed that in Windows, Gfm renders text correctly only when a preview is displayed for the first time.

Afterwards, when a change is made to the source file and the markdown preview is regenerated, characters are no longer displayed in the encoding of the source file (e.g. UTF-8). Instead, the file content is displayed as if it were encoded according to the default Windows code page. That code page normally depends on the system, or more precisely on the language settings; a typical code page for a Windows set to English would be Windows-1252.

The content of the source file is not affected, it is just a display problem in the Gfm preview.

ASCII characters survive the process intact because they are represented by the same byte sequence in all encodings. Non-ASCII characters are screwed up. An en dash, for instance, morphs from – to –, a Euro sign from € to €, and a German ä umlaut appears as ä.

I am not the first one to notice, though ;) The following reports seem to be variations of the theme and are likely to be the exact same issue, or closely related:

• Cyrillic support #64 Cyrillic support
• German umlauts (ä,ö,ü,ß) #68 German umlauts
• Chinese garbled on Windows platform #102 Chinese garbled on Windows platform

Hope that helps you to resolve the issue. Otherwise, your plugin is fantastic, and I use it all the time. Thank you!

Cheers,

Michael

[ShyykoSerhiy]

Should be fixed in v0.1.9

[ShyykoSerhiy]

Thx for the help.

[hashchange]

That did the trick :) The issue is gone in 0.1.9. Thank you for your quick response!