Unicode escape sequences

[xfq]

https://www.w3.org/TR/2026/WD-rdf12-turtle-20260320/#sec-escapes

Note that JavaScript has three types of escapes. The \xHH form must have two hexadecimal digits; the \uHHHH form must have four; the \u{H…H} form may have 1 to 6 hexadecimal digits.

\u{H…H} is convenient because it allows for variant length of hexadecimal digits, and we recommend it. We hope rdf-turtle can also add this approach.

[afs]

Publishing data with \u{H...H} would make data, with the same semantics, invalid and inaccessible to RDF 1.1 processors even when no new features of RDF 1.2 are used. A new escape sequence form encourages "two distinct worlds" - RDF 1.1 and RDF 1.2.

RDF has wide applicable outside the web platform. For example, Python is commonly used with RDF; it supports \u and \U. IIRC This is where the original choice came from (that and triple-quoted strings).

[duerst]

\u{H...H} is definitely more convenient than '\UHHHHHHHH'. Ruby even allows several hex numbers inside \u{...}, which makes it even more convenient. But if rdf-turtle already has a way to escape non-BMP Unicode characters, even if it's not the best one, I think it should be good enough. And \UHHHHHHHH is definitely future-proof for a few hundred years :-).

[rdfguy]

The WG prefers the suggestion Martin (duerst) makes above.

[TallTed]

\u{H...H} is definitely more convenient than \UHHHHHHHH

But note that you cannot express \UHHHHHHHH in \u{H...H} -- the latter is limited to 6 Hs, i.e., you lose two hex digits in the latter.

Convenience has a price!

[kasei]

@TallTed – 

As mentioned in the WG call today, we'd only need six digits here to cover all of Unicode. But also, there's no reason that a syntax for like this has to be limited to 6 digits. For example, perl uses this syntax (using x instead of u), and allows 1–8 digits inside the braces.

[aphillips]

I was actioned by I18N to comment on this issue as it seems paired with #131.

We agree with @afs:

Publishing data with \u{H...H} would make data, with the same semantics, invalid and inaccessible to RDF 1.1 processors even when no new features of RDF 1.2 are used. A new escape sequence form encourages "two distinct worlds" - RDF 1.1 and RDF 1.2.

We do recommend the \u{H..H} syntax where it is possible to introduce it or where one has a clean sheet of paper. A variable width encoding with clear termination is less wasteful than a fixed width encoding when dealing with supplementary characters (code points > U+FFFD). Note that the first two hex digits of \U will always be 00, since the Unicode code space stops at 10FFFF, so it is a bit wasteful (proposals to expand Unicode's code space are generally published on April 1st).

We leave it to RDF to decide whether to introduce this additional, incompatible, escaping mechanism, although I suspect that you'll reject this suggestion for ecosystem coherence. You have at least one escape mechanism for supplementary code points (possibly two, if you accept our resolution to #131), not to mention just storing the characters verbatim.

[afs]

We do recommend the \u{H..H} syntax where it is possible to introduce it

What's the link for that recommendation?

The escape sequence syntax in Turtle is the same in N-Triples, N-Quads, TriG, SHACL-C, SPARQL Query, SPARQL Update, and, emerging, SHACL Rules (and in some non-W3C languages).