Unicode characters not rendering properly via WSL #452

Closed
opened 2026-01-30 21:52:43 +00:00 by claunia · 4 comments
Owner

Originally created by @wkbrd on GitHub (Nov 10, 2018).

Originally assigned to: @adiviness on GitHub.

  • Your Windows build number: 10.0.18277.1000

  • What you're doing and what's happening:
    Attempting to view the contents of a UTF-8 file via WSL does not show the contents of the file.

  1. Create a new file on Linux with UTF-8 characters, such as: 国際
  2. Within WSL, attempt view file using vi. Question mark characters will be shown instead.
  • What's wrong / what should be happening instead:

When using vi, expecting to see 国際. Note this problem reproduces with a local file to WSL as well as over an ssh connection. Characters show properly when using PuTTy.

Originally created by @wkbrd on GitHub (Nov 10, 2018). Originally assigned to: @adiviness on GitHub. * Your Windows build number: 10.0.18277.1000 * What you're doing and what's happening: Attempting to view the contents of a UTF-8 file via WSL does not show the contents of the file. 1. Create a new file on Linux with UTF-8 characters, such as: 国際 2. Within WSL, attempt view file using vi. Question mark characters will be shown instead. * What's wrong / what should be happening instead: When using vi, expecting to see 国際. Note this problem reproduces with a local file to WSL as well as over an ssh connection. Characters show properly when using PuTTy.
claunia added the Product-ConhostArea-RenderingResolution-Duplicate labels 2026-01-30 21:52:43 +00:00
Author
Owner

@zadjii-msft commented on GitHub (Nov 12, 2018):

Is this unique to WSL, or does this issue also repro in a normal cmd/powershell window?

@zadjii-msft commented on GitHub (Nov 12, 2018): Is this unique to WSL, or does this issue also repro in a normal cmd/powershell window?
Author
Owner

@bitcrazed commented on GitHub (Nov 12, 2018):

Same behavior in WSL and PowerShell.

image

This is most likely caused by a combination of the following:

  1. The glyph for the characters in question likely not available in the currently selected font (Consolas)
  2. Because Console uses GDI to render text, and since GDI does not support font-fallback (a mechanism for dynamically finding and loading a font that does contain the required glyph), Console is unable to render the requested glyph.

We are very aware of this limitation (e.g. see #190) and are working on a set of changes to remedy this issue in a future OS release.

@bitcrazed commented on GitHub (Nov 12, 2018): Same behavior in WSL and PowerShell. ![image](https://user-images.githubusercontent.com/961950/48375373-9a11ef80-e67c-11e8-863d-1f5f57207799.png) This is most likely caused by a combination of the following: 1. The glyph for the characters in question likely not available in the currently selected font (Consolas) 1. Because Console uses GDI to render text, and since GDI does not support font-fallback (a mechanism for dynamically finding and loading a font that does contain the required glyph), Console is unable to render the requested glyph. We are very aware of this limitation (e.g. see #190) and are working on a set of changes to remedy this issue in a future OS release.
Author
Owner

@zadjii-msft commented on GitHub (Nov 12, 2018):

I'm going to close this as a dupe of #190 then.

@zadjii-msft commented on GitHub (Nov 12, 2018): I'm going to close this as a dupe of #190 then.
Author
Owner

@willi84 commented on GitHub (Jul 4, 2021):

as a workaround try this:
https://stackoverflow.com/a/68236169
install all the fonts and set up "Dejavu sans mono for powerline"

image

@willi84 commented on GitHub (Jul 4, 2021): as a workaround try this: https://stackoverflow.com/a/68236169 install all the fonts and set up "Dejavu sans mono for powerline" ![image](https://user-images.githubusercontent.com/6207308/124392600-e9f2c880-dcf6-11eb-903f-4bc184ef97e2.png)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#452