Question: Git supports several different encoding schemes, [UTF-7](https://en.wikipedia.org/wiki/UTF-7), [UTF-8](https://en.wikipedia.org/wiki/UTF-8), and [UTF-32](https://en.wikipedia.org/wiki/UTF-32), as well as non-UTF ones.

Given this, why doesn't it support UTF-16?

There's a lot of questions that ask how to get Git to support UTF-16, but I don't think that this has been explicitly asked or answered yet.

Answer: 
Git recently has begun to understand encodings such as UTF-16. See [gitattributes](https://git-scm.com/docs/gitattributes) documentation—search for *working-tree-encoding*.

If you want .txt files to be UTF-16 without a BOM on Windows machine then add this to your *gitattributes* file:

```
*.txt text working-tree-encoding=UTF-16LE eol=CRLF

```

---

In response to [jthill's comments](https://stackoverflow.com/a/52485746/3700414):

There isn't any doubt that UTF-16 is a mess. However, consider

* [Java](https://stackoverflow.com/questions/36236364/why-java-char-uses-utf-16) uses UTF16
* As does [Microsoft](https://learn.microsoft.com/en-us/windows/desktop/intl/unicode)

Note the line *UTF16… the one used for native Unicode encoding on Windows operating systems*
* JavaScript uses [a mess](https://mathiasbynens.be/notes/javascript-encoding) between UCS-2 and UTF-16
The short form is adding support for wide characters makes everything harder. Everything that deals with any of the 8-bit ISO code pages or UTF-8 or any of the other [MBCS](https://en.wikipedia.org/wiki/Variable-width_encoding#MBCS)'s can scan/span/copy strings without much effort. Try to add support for strings whose transfer encoding contains embedded nulls and the complications to even trivial operations start bloating all your code.

I don't know of any even *claimed* advantages to UTF-16 that aren't more than undone by the downsides that show up when you actually start using it. You can identify a string boundary in any of ASCII, UTF-8, all 16 ISO/IEC-8859 sets, all the EBCDICs, plus probably a dozen more, with the same simple code. With only slight restrictions (ascii-based, with a few lines added for multiple line terminator conventions) you get basic tokenization, and transliteration to a common internal code page is basically free.

Add UTF-16 support and you just bought yourself a huge amount of added effort and complexity, but all that work enables nothing -- after saying "oh, but now it can handle UTF-16!", what *else* is now possible with all that added bloat and effort? Nothing. Everything UTF-16 can do, UTF-8 can do as well and usually much better.