Using Unicode: Difference between revisions
No edit summary |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Unicode 14.0 | Unicode 15.1 was released September 2023. | ||
Unicode 14.0 was released September 14, 2021. | |||
There is no "Unicode 13.1", but Emoji 13.1 was released in September 2020 under the auspices of the Unicode Consortium. Unicode 13.0 was released in March 2020. | |||
Good references include: | Good references include: | ||
| Line 22: | Line 24: | ||
** Mathematical sans-serif bold (U1D5D4+): 𝗔𝗕𝗖𝗗𝗘𝗙𝗚𝗛𝗜𝗝𝗞𝗟𝗠𝗡𝗢𝗣𝗤𝗥𝗦𝗧𝗨𝗩𝗪𝗫𝗬𝗭 | ** Mathematical sans-serif bold (U1D5D4+): 𝗔𝗕𝗖𝗗𝗘𝗙𝗚𝗛𝗜𝗝𝗞𝗟𝗠𝗡𝗢𝗣𝗤𝗥𝗦𝗧𝗨𝗩𝗪𝗫𝗬𝗭 | ||
** Mathematical sans-serif italic (U1D608+): 𝘈𝘉𝘊𝘋𝘌𝘍𝘎𝘏𝘐𝘑𝘒𝘓𝘔𝘕𝘖𝘗𝘘𝘙𝘚𝘛𝘜𝘝𝘞𝘟𝘠𝘡 | ** Mathematical sans-serif italic (U1D608+): 𝘈𝘉𝘊𝘋𝘌𝘍𝘎𝘏𝘐𝘑𝘒𝘓𝘔𝘕𝘖𝘗𝘘𝘙𝘚𝘛𝘜𝘝𝘞𝘟𝘠𝘡 | ||
** Mathematical sans-serif | ** Mathematical sans-serif italic bold (U1D63C+): 𝘼𝘽𝘾𝘿𝙀𝙁𝙂𝙃𝙄𝙅𝙆𝙇𝙈𝙉𝙊𝙋𝙌𝙍𝙎𝙏𝙐𝙑𝙒𝙓𝙔𝙕 | ||
** Mathematical script: 𝒜ℬ𝒞𝒟ℰℱ𝒢ℋℐ𝒥𝒦ℒℳ𝒩𝒪𝒫𝒬ℛ𝒮𝒯𝒰𝒱𝒲𝒳𝒴𝒵 | ** Mathematical script: 𝒜ℬ𝒞𝒟ℰℱ𝒢ℋℐ𝒥𝒦ℒℳ𝒩𝒪𝒫𝒬ℛ𝒮𝒯𝒰𝒱𝒲𝒳𝒴𝒵 | ||
** Mathematical script bold: 𝓐𝓑𝓒𝓓𝓔𝓕𝓖𝓗𝓘𝓙𝓚𝓛𝓜𝓝𝓞𝓟𝓠𝓡𝓢𝓣𝓤𝓥𝓦𝓧𝓨𝓩 | ** Mathematical script bold: 𝓐𝓑𝓒𝓓𝓔𝓕𝓖𝓗𝓘𝓙𝓚𝓛𝓜𝓝𝓞𝓟𝓠𝓡𝓢𝓣𝓤𝓥𝓦𝓧𝓨𝓩 | ||
| Line 39: | Line 41: | ||
* Monospace (U1D7F6+): 𝟶𝟷𝟸𝟹𝟺𝟻𝟼𝟽𝟾𝟿 | * Monospace (U1D7F6+): 𝟶𝟷𝟸𝟹𝟺𝟻𝟼𝟽𝟾𝟿 | ||
* Seven-segment (U1FBF0+): 🯰🯱🯲🯳🯴🯵🯶🯷🯸🯹 | * Seven-segment (U1FBF0+): 🯰🯱🯲🯳🯴🯵🯶🯷🯸🯹 | ||
==UTF-8== | |||
The One True Encoding, almost always. See [https://www.ietf.org/rfc/rfc3629.txt RFC 3629] and Annex D of ISO/IEC 10646. | |||
UTF-8 encoding yields up to four bytes per encoded codepoint. Valid ASCII (all characters less than 0x80) are directly encoded using a single byte. This four byte maximum arises from RFC 3629 §3, which defines UTF-8 on codepoints through only 0x10FFFF (suitable for handling the 17 defined Planes as of Unicode 14); if the 10646 maximum of U+7FFFFFFF is considered, UTF-8 would encode up to six bytes. | |||
The 2048 codepoints U+D800 through U+DFFF cannot be encoded in UTF-8; they are metapoints intended for use with UTF-16. | |||
Along with the octets F5--FF, C0 and C1 never appear in valid UTF-8. ASCII characters never show up as parts of other, multibyte characters. | |||
Octets of the form 10xxxxxx are continuation bytes, and can only be found after a valid initial byte. | |||
== [[libc]] == | == [[libc]] == | ||
* Ensure the proper locales are present, and being regenerated on package updates. <tt>locale -a</tt> will list all available locales. You want en_US. | * Ensure the proper locales are present, and being regenerated on package updates. <tt>locale -a</tt> will list all available locales. You want <tt>en_US.UTF-8</tt> or the appropriate regional equivalent (use <tt>C.UTF-8</tt> for an agnostic UTF-8 encoding): <tt>locale -a | grep UTF-8$</tt> should generate output. On [[Debian]], run <tt>dpkg-reconfigure locales</tt> to select generated locales and rebuild the locale database (it uses [[libc|libc's]] <tt>localedef</tt>). | ||
* Ensure that you're exposing a UTF-8-enabled locale to setlocale(3) and friends: <tt>LANG=en_US.UTF-8</tt> should be exported in your environment (the various LC_* variables can override LANG for certain subsets of context, while LC_ALL overrides other LC_* values). On [[Debian]], configure /etc/default/locale via <tt>dpkg-reconfigure locales</tt> (which subsequently drives <tt>update-locale</tt> from the same package). This file is sourced by pam configs and /etc/init.d files. | * Ensure that you're exposing a UTF-8-enabled locale to setlocale(3) and friends: <tt>LANG=en_US.UTF-8</tt> should be exported in your environment (the various LC_* variables can override LANG for certain subsets of context, while LC_ALL overrides other LC_* values). On [[Debian]], configure /etc/default/locale via <tt>dpkg-reconfigure locales</tt> (which subsequently drives <tt>update-locale</tt> from the same package). This file is sourced by pam configs and /etc/init.d files. | ||