RFC 5137: ASCII Escaping of Unicode Characters
In plain English — editorial summary, not part of the RFC
There are a number of circumstances in which an escape mechanism is needed in conjunction with a protocol to encode characters that cannot be represented or transmitted directly. With ASCII coding, the traditional escape has been either the decimal or hexadecimal numeric value of the character, written in a variety of different ways. The move to Unicode, where characters occupy two or more octets and may be coded in several different forms, has further complicated the question of escapes. This document discusses some options now in use and discusses considerations for selecting one for use in new IETF protocols, and protocols that are now being internationalized. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Document record
- Document ID
- RFC5137
- Published
- February 2008
- Authors
- J. Klensin
- Status
- BEST CURRENT PRACTICE
- Stream
- IETF
- Area
- —
- Pages
- 13
- Also known as
- BCP137
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 6409Message Submission for MailUpdated
November 2011
- RFC 3467Role of the Domain Name System (DNS)Current
March 2003
- RFC 5335Internationalized Email HeadersObsoleted
September 2008
- RFC 7613Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and PasswordsObsoleted
August 2015
- RFC 8265Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and PasswordsCurrent
October 2017
- RFC 9839Unicode Character Repertoire SubsetsCurrent
August 2025
- RFC 6055IAB Thoughts on Encodings for Internationalized Domain NamesCurrent
February 2011
- RFC 4042UTF-9 and UTF-18 Efficient Transformation Formats of UnicodeCurrent
April 2005
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?