Editing UTF-16 (section)

=== U+D800 to U+DFFF (surrogates) ===
{{Refimprove section|date=August 2023}}
The official Unicode standard says that no UTF forms, including UTF-16, can encode the surrogate code points. Since these will never be assigned a character, there should be no reason to encode them. However, Windows allows unpaired surrogates in filenames<ref>{{cite web |title=Maximum Path Length Limitation |url=https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation |website=Microsoft | date=2022-07-18 |access-date=2022-10-10 |quote=[…] the file system treats path and file names as an opaque sequence of WCHARs}}</ref> and other places, which generally means they have to be supported by software in spite of their exclusion from the Unicode standard.

UCS-2, UTF-8, and [[UTF-32]] can encode these code points in trivial and obvious ways, and a large amount of software does so, even though the standard states that such arrangements should be treated as encoding errors.

It is possible to unambiguously encode an ''unpaired surrogate'' (a high surrogate code point not followed by a low one, or a low one not preceded by a high one) in the format of UTF-16 by using a code unit equal to the code point. The result is not valid UTF-16, but the majority of UTF-16 encoder and decoder implementations do this when translating between encodings.{{citation needed|date=October 2011}}<!-- Python 2.6 decode of UTF16 does this on Linux, and it correctly handles surrogate pairs. All "CESU" decoders do it too, though they also mis-translate correct surrogate pairs into 2 characters. -->