Rikunarita-ORG/Wikinium huggingface dataset:
# ISO-IR-165[编辑]

**ISO-IR-165**《**通訊用中文多位元組字符集**》（*Codes of the Chinese graphic character set for communication*）是中國大陸於1992年為国际电信联盟电信标准化部门（CCITT） 創製之中文多位元組通訊字符集。该编码在ISO 2022下注册的名称为 ISO-IR-165，可以使用 ISO-2022-CN-EXT 进行编码。

ISO-IR-165 整合 GB 2312（包括 GB/T 6345.1-86《信息交换用汉字 32x32 点阵字模集》新增之字符及調整）以及 GB/T 8565.2-88《信息处理文本通信用编码字符集 第二部分：图形字符集》。该标准合共 8446 個字符。

## GB/T 6345.1的修订和补充

GB/T 6345.1-1986《信息交换用汉字 32x32 点阵字模集》（后续改成GB/T 6345.1-2010）包括了对 GB/T 2312 的修正和补充。相关的修订最早是由GB 5007.1–85《信息交换用汉字 24x24 点阵字模集》所加入。

GB/T 6345.1 对现有 GB/T 2312 的修订
| 区位码 | EUC码 | GB/T 2312（未修订） | GB/T 6341.1 | 备注
 |
| --- | --- | --- | --- | --- |
| 03-71
 | 0xA3E7 |  | ɡ |  |
| 79-81
 | 0xEFF1 | 鍾 | 锺 |  |

后续实践 GB/T 2312 的编码（如Windows 的代碼頁936）将 79-81 对应的汉字 Unicode 码从“鍾”改为“锺”。

GB/T 6345.1-86 也在 GB/T 2312 的基础上在第 10 区补充了ISO 646-CN 的半宽字符（3 区的字符为全宽字符）和第 8 区补充了 6 个汉语拼音字符。这些补充也在 GB/T 12345 内出现，而 GB/T 12345 也额外在第 6 区加上了 29 个竖排标点符号。

2011年發佈的 GB/T 6345.1-2010 正式在第 11 区增加了對應 8 区 32 个汉语拼音字符（包括新补充的6个字符）的半宽版本。這個補充并未在 GB 18030 内實行。

Classic Mac OS 内的简体中文编码（基于EUC-CN修改） 和 GB 18030 包含了 GB/T 6345.1 补充的 6 个汉语拼音字符（但是不包括半宽版本）和 GB/T 12345 补充的竖排标点符号。 新增的 6 个汉语拼音字符如下：

GB/T 2312 第 8 区的扩充
| 区位码 | EUC码 | 字符 | 备注
 |
| --- | --- | --- | --- |
| 08-27
 | 0xA8BB | U+0251 ɑ  |  |
| 08-28
 | 0xA8BC | U+1E3F ḿ  |  |
| 08-29
 | 0xA8BD | U+0144 ń  |  |
| 08-30
 | 0xA8BE | U+0148 ň  |  |
| 08-31
 | 0xA8BF | U+01F9 ǹ  |  |
| 08-32
 | 0xA8C0 | U+0261   |  |

## GB/T 8565.2 的修订和补充

GB/T 8565.2-1988《信息处理文本通信用编码字符集第二部分：图形字符集》也定义了 GB/T 2312 的补充字符，在 13-15 区和 90-94 区之间新增了 705 个字符，其中 15 区新增的 69 个字符是非汉字。该修订包括了 GB/T 6345.1 的修订，但是没有包括补充字符。

Unihan 资料库中引用中国大陆来源 GB/T 8565 的汉字使用 `G8` 来标示。

## CCITT 修订

ISO-IR-165 包括了 GB/T 6345.1 和 GB/T 8565.2 在 GB/T 2312 的新增补充字符。另外，ISO-IR-165 也新增了 161 个字符，其中 139 个汉字是“普通汉字和异体”。有时这些 CCITT 的新增字会和 GB/T 8565.2 混淆，包括以前的 Unihan 资料库。

CCITT 在第 6 区新增了对应第 3 区的像字符，这些字符和 Mac OS 简体中文 和 GB 18030 的新增字符相撞。

ISO-IR-165 包含了 GB/T 6345.1 的订正，但是其中有两个字符的 Unicode 映射与 GB/T 2312 和 GB/T 6345.1 扩展的映射不同。下表顯示各標準的映射和對應字形，也另附 GB 18030 的對應編碼：

| 区位码 | EUC码
 | GB/T 2312（未修订） | GB/T 6345.1 | GB/T 6345.1 映射 | ISO-IR-165 | ISO-IR-165映射 | GB 18030 | GB 18030 映射
 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 03-71
 | 0xA3E7 |  | ɡ | U+FF47 | ɡ | U+0261 |  | U+FF47
 |
| 08-32
 | 0xA8C0 | （无） |  | U+0261 |  | U+FF47 | ɡ | U+0261
 |
| 79-81
 | 0xEFF1 | 鍾 | 锺 | U+953A | 锺 | U+953A | 锺 | U+953A
 |

## 来源

* ISO-IR-165:1992（页面存档备份，存于互联网档案馆）
# Mac阿拉伯语编码

**Mac阿拉伯语编码**用于苹果机显示阿拉伯字母。

下表仅显示了后半部分（128–255），前半部分（0–127）为ASCII编码。

|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
|  | .0 | .1
 | .2 | .3
 | .4 | .5
 | .6 | .7
 | .8 | .9
 | .A | .B
 | .C | .D
 | .E | .F
 |
| 8\_
 | Ä 00C4 |   00A0 | Ç 00C7 | É 00C9 | Ñ 00D1 | Ö 00D6 | Ü 00DC | á 00E1 | à 00E0 | â 00E2 | ä 00E4 | ں 06BA | « 00AB | ç 00E7 | é 00E9 | è 00E8 |
| 9\_
 | ê 00EA | ë 00EB | í 00ED | … 2026 | î 00EE | ï 00EF | ñ 00F1 | ó 00F3 | » 00BB | ô 00F4 | ö 00F6 | ÷ 00F7 | ú 00FA | ù 00F9 | û 00FB | ü 00FC |
| A\_
 |   0020 | ! 0021 | " 0022 | # 0023 | $ 0024 | ٪ 066A | & 0026 | ' 0027 | ( 0028 | ) 0029 | \* 002A | + 002B | ، 060C | - 002D | . 002E | / 002F |
| B\_
 | ٠ 0660 | ١ 0661 | ٢ 0662 | ٣ 0663 | ٤ 0664 | ٥ 0665 | ٦ 0666 | ٧ 0667 | ٨ 0668 | ٩ 0669 | : 003A | ؛ 061B | < 003C | = 003D | > 003E | ؟ 061F |
| C\_
 | ❊ 274A | ء 0621 | آ 0622 | أ 0623 | ؤ 0624 | إ 0625 | ئ 0626 | ا 0627 | ب 0628 | ة 0629 | ت 062A | ث 062B | ج 062C | ح 062D | خ 062E | د 062F |
| D\_
 | ذ 0630 | ر 0631 | ز 0632 | س 0633 | ش 0634 | ص 0635 | ض 0636 | ط 0637 | ظ 0638 | ع 0639 | غ 063A | [ 005B | \ 005C | ] 005D | ^ 005E | \_ 005F |
| E\_
 | ـ 0640 | ف 0641 | ق 0642 | ك 0643 | ل 0644 | م 0645 | ن 0646 | ه 0647 | و 0648 | ى 0649 | ي 064A | ً 064B | ٌ 064C | ٍ 064D | َ 064E | ُ 064F |
| F\_
 | ِ 0650 | ّ 0651 | ْ 0652 | پ 067E | ٹ 0679 | ڈ 0688 | ە 06D5 | ڤ 06A4 | گ 06AF | ڈ 0688 | ڑ 0691 | { 007B | | 007C | } 007D | ژ 0698 | ے 06D2 |
# 麦金塔中欧编码[编辑]

**麦金塔中欧编码**是使用在麦金塔电脑上用以表示中欧与东南欧洲那些使用拉丁字母的语言文字。這個編碼系統也被稱為Code Page 10029。

## 代碼列表

每个字符显示与其等效的Unicode代码点和它的十进制代码点。只显示后半段表格（代码点128–255），前半段（代码点 0–127）与ASCII编码相同。

麥金塔中歐編碼
Macintosh Central European encoding
|  | \_0
 | \_1
 | \_2
 | \_3
 | \_4
 | \_5
 | \_6
 | \_7
 | \_8
 | \_9
 | \_A
 | \_B
 | \_C
 | \_D
 | \_E
 | \_F
 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 8\_
 | Ä 00C4 128 | Ā 0100 129 | ā 0101 130 | É 00C9 131 | Ą 0104 132 | Ö 00D6 133 | Ü 00DC 134 | á 00E1 135 | ą 0105 136 | Č 010C 137 | ä 00E4 138 | č 010D 139 | Ć 0106 140 | ć 0107 141 | é 00E9 142 | Ź 0179 143 |
| 9\_
 | ź 017A 144 | Ď 010E 145 | í 00ED 146 | ď 010F 147 | Ē 0112 148 | ē 0113 149 | Ė 0116 150 | ó 00F3 151 | ė 0117 152 | ô 00F4 153 | ö 00F6 154 | õ 00F5 155 | ú 00FA 156 | Ě 011A 157 | ě 011B 158 | ü 00FC 159 |
| A\_
 | † 2020 160 | ° 00B0 161 | Ę 0118 162 | £ 00A3 163 | § 00A7 164 | • 2022 165 | ¶ 00B6 166 | ß 00DF 167 | ® 00AE 168 | © 00A9 169 | ™ 2122 170 | ę 0119 171 | ¨ 00A8 172 | ≠ 2260 173 | ģ 0123 174 | Į 012E 175 |
| B\_
 | į 012F 176 | Ī 012A 177 | ≤ 2264 178 | ≥ 2265 179 | ī 012B 180 | Ķ 0136 181 | ∂ 2202 182 | ∑ 2211 183 | ł 0142 184 | Ļ 013B 185 | ļ 013C 186 | Ľ 013D 187 | ľ 013E 188 | Ĺ 0139 189 | ĺ 013A 190 | Ņ 0145 191 |
| C\_
 | ņ 0146 192 | Ń 0143 193 | ¬ 00AC 194 | √ 221A 195 | ń 0144 196 | Ň 0147 197 | ∆ 2206 198 | « 00AB 199 | » 00BB 200 | … 2026 201 | NBSP 00A0 202 | ň 0148 203 | Ő 0150 204 | Õ 00D5 205 | ő 0151 206 | Ō 014C 207 |
| D\_
 | – 2013 208 | — 2014 209 | “ 201C 210 | ” 201D 211 | ‘ 2018 212 | ’ 2019 213 | ÷ 00F7 214 | ◊ 25CA 215 | ō 014D 216 | Ŕ 0154 217 | ŕ 0155 218 | Ř 0158 219 | ‹ 2039 220 | › 203A 221 | ř 0159 222 | Ŗ 0156 223 |
| E\_
 | ŗ 0157 224 | Š 0160 225 | ‚ 201A 226 | „ 201E 227 | š 0161 228 | Ś 015A 229 | ś 015B 230 | Á 00C1 231 | Ť 0164 232 | ť 0165 233 | Í 00CD 234 | Ž 017D 235 | ž 017E 236 | Ū 016A 237 | Ó 00D3 238 | Ô 00D4 239 |
| F\_
 | ū 016B 240 | Ů 016E 241 | Ú 00DA 242 | ů 016F 243 | Ű 0170 244 | ű 0171 245 | Ų 0172 246 | ų 0173 247 | Ý 00DD 248 | ý 00FD 249 | ķ 0137 250 | Ż 017B 251 | Ł 0141 252 | ż 017C 253 | Ģ 0122 254 | ˇ 02C7 255 |
|  | \_0 | \_1 | \_2 | \_3 | \_4 | \_5 | \_6 | \_7 | \_8 | \_9 | \_A | \_B | \_C | \_D | \_E | \_F
 |

## 參考資料
# MacOS梵文編碼[编辑]

Mac OS Devanagari| 别名 | `x-mac-devanagari` |
| 制定 | 蘋果公司 |
| 分类 | EASCII, Mac OS script |
| 拓展自 | ASCII |
| 基于 | 印度文字資訊交換碼 |

**Mac OS Devanagari**是蘋果公司基於印度文字資訊交換碼-91開發的字符集。

## 字符集

|  |
| --- |
| Mac Devanagari
 |
|  | 0
 | 1
 | 2
 | 3
 | 4
 | 5
 | 6
 | 7
 | 8
 | 9
 | A
 | B
 | C
 | D
 | E
 | F
 |
| 8x
 | ×
 | −
 | –
 | —
 | ‘
 | ’
 | …
 | •
 | ©
 | ®
 | ™
 |  |  |  |  |  |
| 9x
 | ॥
 | ॰
 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| Ax
 |  | ँ
 | ं
 | ः
 | अ
 | आ
 | इ
 | ई
 | उ
 | ऊ
 | ऋ
 | ऎ
 | ए
 | ऐ
 | ऍ
 | ऒ
 |
| Bx
 | ओ
 | औ
 | ऑ
 | क
 | ख
 | ग
 | घ
 | ङ
 | च
 | छ
 | ज
 | झ
 | ञ
 | ट
 | ठ
 | ड
 |
| Cx
 | ढ
 | ण
 | त
 | थ
 | द
 | ध
 | न
 | ऩ
 | प
 | फ
 | ब
 | भ
 | म
 | य
 | य़
 | र
 |
| Dx
 | ऱ
 | ल
 | ळ
 | ऴ
 | व
 | श
 | ष
 | स
 | ह
 | INV | ा
 | ि
 | ी
 | ु
 | ू
 | ृ
 |
| Ex
 | ॆ
 | े
 | ै
 | ॅ
 | ॊ
 | ो
 | ौ
 | ॉ
 | ्
 | ़
 | ।
 |  |  |  |  |  |
| Fx
 |  | ०
 | १
 | २
 | ३
 | ४
 | ५
 | ६
 | ७
 | ८
 | ९
 |  |  |  |  |  |

## 參考
# 汉字内码扩展规范[编辑]

汉字内码扩展规范| GBK 字节分配。 |
| MIME / IANA | GBK |
| 别名 | CP936, MS936, windows-936, csGBK |
| 语言 | 国际，但以简体中文为主，浏览器多以GB 18030解码 |
| 标准 | GBK 1.0 |
| 现状 | 非正式国标编码，已被GB 18030取代 |
| 分类 | 扩展ASCII、变长编码、CJK |
| 拓展自 | EUC-CN |
| 前用 | GB2312 |
| 后续 | GB 18030 |

**汉字内码扩展规范**，简称**GBK**，全名为**《汉字内码扩展规范(GBK)》1.0版**，由中华人民共和国全国信息技术标准化技术委员会1995年12月1日制订，国家技术监督局标准化司和电子工业部科技与质量监督司1995年12月15日联合以《技术标函[1995]229号》文件的形式公布。 GBK共收录21886个汉字和图形符号，其中汉字（包括部首和构件）21003个，图形符号883个。

GBK为“国家标准扩展”的汉语拼音（**G**uójiā **B**iāozhǔn **K**uòzhǎn）中的“国”“标”“扩”第一个声母。英文全称Chinese Internal Code Extension Specification。

GBK 只为“技术规范指导性文件”，不属于国家标准。国家质量技术监督局于2000年3月17日推出了GB 18030-2000标准，以取代GBK。GB 18030-2000除保留全部GBK编码汉字，在第二字节把能使用范围再度进行扩展，增加了大约一百个汉字及四字节编码空间，但是将GBK作为子集全部保留。

## 历史

1993年，Unicode 1.1版本推出，收录中国大陆、台湾、日本及韩国通用字符集的汉字，总共有20,902个。中国大陆订定了等同于Unicode 1.1版本的“GB 13000.1-93”“信息技术通用多八位编码字符集（UCS）第一部分：体系结构与基本多文种平面”。

由于GB 2312-80只收录6763个汉字，有不少汉字，如部分在GB 2312-80推出以后才简化的汉字（如“啰”），部分人名用字（如中国前总理朱镕基的“镕”字），台湾及香港使用的繁体字，日语及朝鲜语汉字等，并未有收录在内。于是厂商微软利用GB 2312-80未使用的编码空间，收录GB 13000.1-93全部字符制定了GBK编码。

根据微软资料，GBK是对GB2312-80的扩展，也就是*CP936字码表（Code Page 936）*的扩展（之前CP936和GB 2312-80一模一樣），最早实现于Windows 95简体中文版。虽然GBK收录GB 13000.1-93的全部字符，但GBK是一种编码方式并向下兼容GB2312；而GB 13000.1-93等同于Unicode 1.1是一种字符集，它的几种编码方式如UTF8、UTF16LE等，与GBK完全不兼容。

## 编码方式

字符有一字节和双字节编码，`00`–`7F`范围内是第一个字节，和ASCII保持一致，此范围内严格上说有96个文字和32个控制符号。

之后的双字节中，前一字节是双字节的第一位。总体上说第一字节的范围是`81`–`FE`（也就是不含`80`和`FF`），第二字节的一部分领域在`40`–`7E`，其他领域在`80`–`FE`。

具体来说，定义的是下列字节：

GBK的编码范围
| 范围 | 第1字节 | 第2字节 | 编码数 | 字数
 |
| --- | --- | --- | --- | --- |
| 水准GBK/1 | `A1`–`A9` | `A1`–`FE` | 846 | 717
 |
| 水准GBK/2 | `B0`–`F7` | `A1`–`FE` | 6,768 | 6,763
 |
| 水准GBK/3 | `81`–`A0` | `40`–`FE` (`7F`除外) | 6,080 | 6,080
 |
| 水准GBK/4 | `AA`–`FE` | `40`–`A0` (`7F`除外) | 8,160 | 8,160
 |
| 水准GBK/5 | `A8`–`A9` | `40`–`A0` (`7F`除外) | 192 | 166
 |
| 用户定义 | `AA`–`AF` | `A1`–`FE` | 564 |  |
| 用户定义 | `F8`–`FE` | `A1`–`FE` | 658 |  |
| 用户定义 | `A1`–`A7` | `40`–`A0` (`7F`除外) | 672 |  |
| 合计： |  |  | 23,940 | 21,886
 |

双字节符号可以表达的64K空间如下图所示。绿色和黄色区域是GBK的编码，红色是用户定义区域。没有颜色区域是不正确的代码组合。

## 与其他编码的关系

GBK向下完全兼容GB2312-80编码。支持GB2312-80编码不支持的部分中文姓，中文繁体，日文假名，还包括希腊字母以及俄语字母等字母。不过这种编码不支持韩国字，也是其在实际使用中与unicode编码相比欠缺的部分。

上述GBK/1和GBK/2的领域即GB 2312-80用通常方法编码的区域。GB 2312（正确说法是其根据EUC-CN的编码）和ISO/IEC 2022中调用GR其他的94²字符集一样，`A1`–`FE`的范围开始读取字节对。这是上图中右下角的部分。但是，GB 2312中对于`AA`–`AF`和`F8`–`FE`区域是空的，没有赋予编码。于是GBK就在这些领域里进行拓展。二者剩余部分作为用户定义区。

更重要的是，GBK进行了字节范围的扩展。ISO/IEC 2022中GR区域的字数有94²=8,836字的限制。只要放弃ISO/IEC 2022中针对图形文字和控制文字赋予严格的范围的模式，下位字节为单字节文字，上位字节对保留对应字符的功能，潜在的128²=16,384的代码位置就可以使用。GBK采用其中的一部分，第一个字节从`A1`–`FE`（每个字节有94个选项）扩展成`81`–`FE`（126个选项），第二字节的范围是`40`–`FE`（191个选项），总共有24066（126\*191）个位置。

## 與CP936字码表比較

微软在稍新一点的CP936中使用单字节 0x80 代表欧元字符（U+20AC），而《规范》之GBK编码不含此字符。

## 输入方法

* VimIM在Vim环境中，可以直接键入十进制或十六进制GBK （页面存档备份，存于互联网档案馆）码。既不需要启动输入法，也不需要码表。

* 国家标准代码
* Unicode

## 注釋

* ICU:UNICODE （页面存档备份，存于互联网档案馆）
* -GBK table （页面存档备份，存于互联网档案馆）
* 微软CP936编码表 （页面存档备份，存于互联网档案馆）
* GBK编码表 （页面存档备份，存于互联网档案馆）
# 統一碼二進制有序壓縮[编辑]

**統一碼二進制有序壓縮**（英語：Binary Ordered Compression for Unicode，縮寫：**BOCU**）是統一碼技術注解文件所定義的規範，可以兼容MIME的統一碼压缩方案。

雖然UTF-8適合廣泛使用，但對於非拉丁文和中日韓統一表意文字的文字，相較於代码页技術，它佔用了更多的空間（較高的 "字節 / 碼位" 之比）。另一方面，SCSU 佔用的空間與代碼頁差不多，但卻不相容於MIME。二進制有序壓縮則结合了UTF-8的廣泛適用性和統一碼標準壓縮方案（SCSU）的紧凑性。

这种编码旨在用于压缩短字符串，并保持码点顺序。

BOCU-1是IANA注册的字符集。

## 细节

本章節中使用的數字都是十六進制，且使用的範圍都是包含在内。

統一碼二進位有序壓縮的核心概念在於：同一種語言的字符，通常被放在鄰近位置（同一區段內），所以文件中的一個字符與前一個字符碼值的差值是小的，可以用較少的字節來編碼。

而實際作法上，不是直接使用前一個字符的碼值，而是前一固字符歸一化的碼值，即所在區段的中間值。其對應如下：

| 編碼范围
 | 歸一化碼值
 | 笔记
 |
| --- | --- | --- |
| `U+3040`至`U+309F` | `U+3070` | 平假名
 |
| `U+4E00`至`U+9FA5` | `U+7711` | 中日韓統一表意文字
 |
| `U+AC00`至`U+D7A3` | `U+C1D1` | 韩文
 |
| `U+0020` | 编码器状态保持原样 | 空格
 |
| `U+ *hhhh*00` `U+*hhhh*7F`
（不包括上述范围） | `U+hhhh40` | 中间 共128个
 |
| `U+*hhhh*80` `U+*hhhh*FF`
（不包括上述范围） | `U+*hhhh*C0` | 中间 共128个
 |

此壓縮法的規則為，码位`U+0020`使用其原本的值。其他码位（即`U+0021`到`U+D7FF`和`U+E000`到`U+10FFFF` ），則計算其與前一個字符的歸一化版本的碼值差值，並對此差值編碼。

差值的編碼規則如下：

| 差值範圍
 | 字节序列范围 （见下文） |
| --- | --- |
| `-10FF9F`到`-2DD0D` | `21` `F0` `58` `D9`到`21` `FF` `FF` `FF` |
| `-2DD0C`到`-2912` | `22` `01` `01`到`24` `FF` `FF` |
| `-2911`至`-41` | `25` `01`至`4F` `FF` |
| `-40`至`3F` | `50`到`CF` |
| `40`至`2910` | `D0` `01`到`FA` `FF` |
| `2911`至`2DD0B` | `FB` `01` `01`到`FD` `FF` `FF` |
| `2DD0C`至`10FFBF` | `FE` `01` `01` `01`至`FE` `19` `B4` `54` |

每个位元范围按字典顺序排序，但不包括以下十三个字节值`00 07 08 09 0A 0B 0C 0D 0E 0F 1A 1B 20`。例如，差值`1156B` 的編碼，其字節序`FC 06 FF`。紧接着差值`1156C` 的編碼，是字节序列`FC 10 01` （第三個字節，`FF` 跳過`00` `01`，而第二個字節，`06` 跳過`07 08 09 0A 0B 0C 0D 0E 0F` `10`）。

除了空格`U+0020`為例外，對所有ASCII字符`U+0000`到`U+007F`，编码器會重置为`U+0040`。由於上述的**按原样**包含了行尾码位`U+000D`和`U+000A` (`0D 0A` )，因此编码器在每行的开头处于已知状态。因此，单个字节的损坏最多影响一行。相比之下，UTF-8单个字节的损坏最多影响一个字符，对于SCSU来说，則可能會影响整个文档。

對於没有上述值的文本，BOCU-1亦提供了类似的穩健性，带有特殊的重置代码`0xFF`。当解码器找到这个八位字节时，它会将其状态重置为`U+0040`就像行尾一样。BOCU-1规范中不推荐使用`0xFF`复位字节，因为它与其他BOCU-1设计目标相冲突，尤其是*二进制顺序*。

在BOCU-1编码文本的开始处，可選擇地使用签名`U+FEFF`，其字節串列`FB EE 28`，會将初始状态由`U+0040改`为`U+FEC0`。换句话说，無法像其他大多數的統一碼编码方案一样简单地剥离簽名。若額外添加一個復位字節，使之成為字節順序`FB EE 28 FF`，則可以避免这种影响，但BOCU-1规范不推荐这种做法。

理论上，UTF-1和UTF-8可以為原始UCS-4集（使用 31 位元、上到`7FFFFFFF`）編碼。BOCU-1和UTF-16可以為現代統一碼集（`U+0000`到`U+10FFFF）`。排除 13 個受保護碼位外，BOCU-1单个位元組可以 WIKINIUM\_MATH\_PH\_0 多字节编码。BOCU-1最多需要四个位元組，包括一个前导字元和一到三个尾端位元組。尾字节编码剩余的“模243”（基数 243）差，前导字节确定尾字节数和初始差。请注意，复位字节`0xFF`不受*保护*，可以作为尾字节出现。

## 专利

在美国专利#6,737,994中，涵盖了通用BOCU算法，同時还提到了特定的BOCU-1实现IBM當時雇用了BOCU-1的两位发明者，在統一碼技术说明中指出「完全兼容的BOCU-1版本」的实现者必须联系 IBM 以申请免版税许可BOCU-1是統一碼网站上，目前唯一已知的受到知识产权限制的統一碼压缩方案。

相比之下，IBM也為UTF-EBCDIC申請专利，但它选择使文档和编码方案不要求對實施者申請許可證，而是「任何将轉換格式成为UCS标准的一部分，將對他們們免费提供」

## 参考

## 另見

* UTF-1：包含 UTF-1、UTF-8和BOCU-1设计的比较
* International Components for Unicode：一个可以在BOCU-1和其他Unicode编码之间转换的库
# UTF-16的八位元相容編碼方案[编辑]

**UTF-16的八位元相容編碼方案**（英語：Compatibility Encoding Scheme for UTF-16: 8-Bit），簡稱 **CESU-8** ，是統一碼技术报告 #26 中描述UTF-8的变体。

CESU-8 的設計，是為了能在八位元的計算環境中，提供 UTF-16 的定序。因此，報告中也明確指出，只建議用在那些需要 UTF-16 定序，**不被預期且不建議用於外部數據交換**。

CESU-8 有以下特點：

* 基本多语言平面中的字符編碼會與 UTF-8 相同，只有 增補字符會不同。
* 只有六個字節形式的增符字符是合規的，UTF-8 中的四字節形式是不合規的。
* 以 CESU-8 編碼後的字節串列以二進位方式定序，會與 UTF-16 編碼過的字節串列以二進位定序，其結果是一樣。

基本多语言平面中的字符碼位（即 U+0000 到 U+FFFF 范围内的碼位），其编码方式与 UTF-8 相同。 增補字符（即 U+10000 到 U+10FFFF 范围内的碼位），則先以同UTF-16的方式轉为代理对，然后以 UTF-8 的方式將代理對中的每個代碼进行编码。因此，对于每个統一碼增補字符，CESU-8 需要六个字节（每个代理项 3 个字节），而 UTF-8 只需要四个字节。虽然技术报告中没有具体说明，但未*配对的*代理項也會编码成为 3 个字节。非基本多文種平面的字符會被编码成`11101101 1010yyyy 10xxxxxx 11101101 1011xxxx 10xxxxxx` （yyyy 表示字符的前五位减一）。字节值 0xF0 不会出现在 CESU-8 中，因为它开始了 UTF-8 使用的 4 字节编码。

W3C 和WHATWG HTML標準禁止在HTML文檔中支援 CESU-8，因为这会導致跨網站脚本漏洞。

Java 的UTF-8修改版是 CESU-8，並將 NUL 字符 (U+0000) 的特殊超长编码，作为两字节序列`C0 80` 。

Oracle 数据库使用 CESU-8 作为其“UTF8”字符集。若要使用標準 UTF-8 ，自 Oracle 9.0 版起，可以使用字符集“AL32UTF8”。

CESU-8 是IANA註冊的字符集。

## 範例

|  |  |  |  |
| --- | --- | --- | --- |
| 碼位
 | U+0045
 | U+0205
 | U+10400
 |
| 字符
 | E
 | ȅ
 | 𐐀
 |
| UTF-8
 | 45
 | C8
 | 85
 | F0
 | 90
 | 90
 | 80
 |
| UTF-16
 | 0045
 | 0205
 | D801
 | DC00
 |
| CESU-8
 | 45
 | C8
 | 85
 | ED
 | A0
 | 81
 | ED
 | B0
 | 80
 |

## 参考

* 統一碼技術報告 #26 （页面存档备份，存于互联网档案馆）
* 修改后的 UTF-8 定义 （页面存档备份，存于互联网档案馆）
* 國際統一碼部件的转换器资源管理器中 CESU-8 的图形视图
# 統一碼標準壓縮方案[编辑]

**統一碼標準壓縮方案**（英語：Standard Compression Scheme for Unicode，縮寫：SCSU），是一種統一碼技術標準。用於減少統一碼文本所需使用的字節數，尤其是該文本中所使用的字符，主要集中在一種或幾種語言區段。它的作法主要是將 128– 255 范围内的值，动态映射到 以 128 個字符為單位的特定區段的偏移量来实现。编码器的初始条件則是ASCII和ISO-8859-1中不包含除 NULL TAB CR 和 LF 之外的 C0 控制代码的现有字符串可以被视为 SCSU 字符串。

由于大多数字母在統一碼所使用的碼位，通常會是區塊中的連續位置，所以如果文本使用小寫字母、 ASCII 標點符號或窗口內的其它標點符號，可以按每个字符一个字节进行编码（需另外加上前置成本，对常见语言通常只有 1 个字节），大多数其他标点符号可以通过非锁定移位的方式，以每個字符使用 2 個位元組进行编码。統一碼標準壓縮方案还可以在內部切換到UTF-16模式，以处理非字母语言。

SCSU 是IANA注册的字符集。

## 历史和使用

最初，是由路透社开发了 SCSU，並以此命名為「統一碼的路透社壓縮方案」（英語：Reuters Compression Scheme for Unicode，RSCU）。

起初統一碼聯盟认为它是一种字符编码， 在 1999 年則改变了看法：虽然它仍然被认为是一种传输用途编码语法，但有一段时间它不再被认为是一种字符编码，這是因为對同一份文件，不同的压缩器可能会产生不同的输出。 然而，在 2004 年，该决定被撤销，现在 SCSU 被认为是一种*压缩*字符编码方案，而不是简单或复合字符编码方案。

Roman Czyborra（GNU Unifont）编写了一个解压器。 IBM 相关的解压缩器可以在國際統一碼部件中找到，还有一个用 Java 编写的压缩器。 更简单的参考编解码器可作为 TR6 的附件提供。

Symbian OS是一种用于手机和其他移动设备的操作系统，它使用此壓縮方案來將字符串序列化。

SQL Server 2008 R2使用 SCSU，其壓縮針對的對象則是存储在*nchar(n)*和*nvarchar(n)*列中的統一碼值（即以UCS-2编码的字符串），其節省的空間達到了 15% 到 50% （而UTF-8只能對統一碼中的ASCII子集减少 50%），具体取决于資料的语言。

## 方案

以下部分简要描述了压缩 SCSU 流的解剖结构。有关完整说明（与解压缩器的说明相匹配），请参阅 UTS #6 文档。

### 编码方式

SCSU 以单字节模式启动，该模式使用压缩的窗口编码。使用一些指令用來轉換到UTF-16BE“統一碼”模式以及从该模式切换到单字节模式的命令。

### 窗口编码

SCSU 的核心在于使用一些窗口來定义了字节 0x80-0xff 的意義。有八个靜態窗口用于简单文字和标点符号，以及六個動態窗口（加上“半 Unicode 區段”窗口和用于补充平面的自定义窗口）用于使用更多字符。

简单和动态窗口都是通过特殊命令字符选择的。对于不适合当前块的单个字符，提供用于引用的命令字符。

## 與通用純文本壓縮方案的比较

由于 UTF-16 或 UTF-8 文本可能比在 Unicode 之前的编码中占用的空间更多，因此人们可能希望使用压缩（例如 SCSU）来缓解这一问题。 与通用压缩机相比，使用 SCSU 不一定有优势。 此外，虽然它可以用作文本编码，但由于算法的状态性质，将其用作内部文本表示时可能会出现困难，因为基本文本操作变得非常重要。

纯粹作为一种压缩算法处理，在處理超過幾 K 的文本，SCSU 不如最常用的通用算法来处理。

在某些情況下，標準壓縮方案確實是有優勢的。對於那些較短（使用的字符量不多）的文本，它可以有效壓縮文本，而大多数的全尺寸壓縮器，它們本身的開銷通常需要額外耗費数百位元組。在Symbian OS中，甚至將此標準壓縮方案用于剪贴板操作，例如剪切、复制和粘贴小字符串文本。

## 在 HTML 中

W3C 和WHATWG HTML 標準中，禁止在文档中支持統一碼標準壓縮方案，這是因为 HTML 的设计没有考虑到非 ASCII 兼容的编码。此外，已證明可以藉由浏览器对此类编码处理不当而导致的跨網站腳本漏洞。

## 另見

* 統一碼二進制有序壓縮
* 國際統一碼部件 可以在 SCSU 和其他統一碼编码之间进行转换的库
# 今昔文字鏡[编辑]

Mojikyō
Konjaku Mojikyō
今昔文字鏡| 開發者 | 石川忠久、古家時雄、文字鏡研究会 |
| 首次发布 | 1.0 / 1997年7月​（1997-07） |
| 最终版本 | 4.0（2018年12月15日​（2018-12-15）） |
| 操作系统 | Microsoft Windows |
| 文件大小 | 51MB |
| 语言 | 日语 |
| 类型 | 与字型及字符映射表绑定的字符编码 |
| 许可协议 | 专有软件 |
| 网站 | mojikyo.org |
|  |

**今昔文字鏡**（日語：今昔文字鏡／こんじゃくもじきょう）是日本AINet開發、日語：文字鏡研究會／もじきょうけんきゅうかい出版发行的一款東亞文字檢索軟件，在Windows平臺上運行。收字量龐大，最新版本收錄文字達17萬以上。所收字類型有諸橋轍次編《大漢和辭典》中的全部漢字、和製漢字、簡化字、方言字、甲骨文、篆書等各類漢字，喃字、水族文字、悉曇文字、西夏文字、變體假名、臺灣語假名等其他文字。由石川忠久担任主席的文字鏡研究會最初将其字符集、相关软件及数据以CD-ROM形式由纪伊国屋书店重新分发。

## 目标

今昔文字鏡编码本为提供完整的中日韩文字符索引。它还对古代文字中的大量字符进行编码，如甲骨文、篆书、悉昙文等。它是许多字符唯一一种字符编码，其数据也常作为Unicode提案的起点。但文字镜的收录标准比Unicode宽松许多，这使得文字镜许多字符来源可疑，甚至可能是虚构的。因此，虽然许多文字镜收录的字符尚未被Unicode收录，但因各家标准不同，并非所有文字镜字符都能收录进Unicode。

## 组成

文字镜字体(文字鏡フォント)是一系列TrueType字体，以一个ZIP格式文件封装，每种字体约有2-5兆字节；不同字体包含的字符数也不同。还有一个EXE格式的字符映射集(文字鏡MAP)，即MOCHRMAP.EXE。这允许用户浏览文字镜字体并复制、粘贴字符。相较于常规的Windows字符映射集或KCharSelect，MOCHRMAP.EXE还能显示字符的文字镜编码。为让MOCHRMAP.EXE正常工作，须安装所有字体（于C:\Windows\Fonts）。

## 编码

文字镜中字符编码常用MJXXXXXX格式，类似于Unicode所用的U+XXXX格式。例如，变体假名U+1B008 𛀈 的文字镜编码为MJ090007，Unicode编码为U+1B008。两者的不同之处在于，文字镜编码为十进制，Unicode的U+码为十六进制。

自Unicode创始开始，文字镜既影响了标准，也受到了标准的影响—来自它的字形于2002年4月18日首次出现在提交给表意文字小组(IRG)的提案中，该小组负责Unicode所有中日韩统一表意文字区块。2007年5月，文字镜提供了Unicode中西夏文的编码，到2002年10月，文字镜中已经有约6千个西夏文单字。

Unicode标准的Unihan数据库将文字镜称作“日本国字集”，缩写“JK”。例如，U+2B679 𫙹 （⿰魚嵐）在日语中读作blizzard（ブリザード|burizādo），其J源就等于JK-66038。所有带JK前缀的J源Unicode字符都来自文字镜。据字符编码、东亚语言专家小林剑所说，截至Unicode 13.0，Unicode中有782个表意文字来自文字镜，分布在2个Unicode区段：中日韩统一表意文字扩展区C中367个，中日韩统一表意文字扩展区E中415个。不是所有文字镜来源的Unicode字符(JK前缀J源)都跟文字镜字体相同，一些字符的形状在最终编码之前被改变了，调查显示文字镜分配的字形有误。

### 区段

截至2006年9月 (2006-09)，它共编码了17,4975个字符。其中有15,0366个字符属于扩展CJK文字区。许多编码的字符被认为是过时的或不必要的，且没被任何其他字符集编码，包括国际标准Unicode。每个文字镜字符都有一个独特的编号，许多字符的编号组成区段。

文字镜依传统康熙部首排序将中日韩文字放在不同区段中。含字极多的常见部首，如人部、辵部进一步依笔画数排序。

### 无统一性

文字镜不像Unicode那样试图搭建统一汉字集，没有尝试紧凑编码，也没有将所有常用字符维持在U+FFFF以下。

Unicode则依据中日韩汉字的出现频率分为若干块，最常见的位于基本多文种平面，较生僻的位于辅助多文种平面。

例如，人部有分别来自中国和日本的MJ054435(令)、MJ059031(令)两个字符，Unicode中均为U+4EE4 <control-4EE4> 。

## 许可

今昔文字镜是有限制性许可的专有软件。最初，文字镜研究所试图阻止其字符数据的滥用，并威胁那些发布字符集转换表的人。2010年7月，文字镜研究所放弃了以法律阻止多个日本用户发布转换表或将文字镜编码字符转换为Unicode或其他字符的努力。单纯的数据，有时包括字体，在许多司法管辖区被认为是共同财产，因为它们不符合原创性门槛。

然而，由于这一遗留问题，GlyphWiki从2020年起不再允许使用文字镜数据。

## 书写系统

### 至今存活

* 汉语：汉字
* 日语：日本汉字、日语假名（含变体假名）
* 朝鲜语：朝鲜汉字
* 拉丁字母及变音符号
* 西里尔字母及变音符号

### 死文字

* 古汉语
	+ 甲骨文
	+ 篆书
* 台湾语假名
* 越南语：喃字
* 梵语：悉昙文
* 西夏文
* 水书

## 歷史

今昔文字鏡開發於1985年，1996年电子化。1997年7月，大修館書店以CD-ROM形式發佈其1.0版本，當時只收有不到8萬個字。1999年，在TrueType上搭載的2.0版本發售。

2001年收錄西夏文字，并發佈“今昔文字鏡　單漢字10万字版”，收錄字數約102,300。同年收錄楷書。“文字鏡Web”網站也開始出現。

2006年發佈“今昔文字鏡　單漢字15万字版”（4.0版），發佈專業版“Indexfont Ver. 1.0”。

2008年3月末“文字鏡Web”關閉。6月初“今昔文字鏡 UnicodeEdition”發售。

2010年3月15日，發佈專業版“Indexfont Ver. 2.0”。

2015年，开发者之一、社长古家时雄去世，改由石川忠久接手，於次年散會。为作纪念，文字镜最新版开始作为免费软件上传到互联网档案馆。

至今(2017年)，今昔文字鏡的網路版都還在重新構築當中。

2018年12月15日，4.0版本发布。次日，石川忠久宣布此为文字镜最终版。

## 注釋

* 株式会社エーアイ・ネット
* ~~今昔文字鏡~~（现在会跳转到日文维基百科的此条目）
* ~~文字鏡研究会Archive.today的存檔，存档日期2020-01-01~~（现在会跳转到日文维基百科的此条目）
* 大漢和辞典的文字番号
# Unicode控制字符[编辑]

**Unicode控制字符**（英語：Unicode control characters）是用于控制文本解释或者显示，而不可见或不占空间的Unicode字符。

## ISO 6429控制字符（C0与C1）

控制字符U+0000‐U+001F 与U+007F来自ASCII。此外，ISO 8859字符集定义了U+0080‐U+009F。二者都定义在ISO 6429中，常被称为C0与C1控制字符。

大部分这些字符在Unicode文本处理中没有明确作用。字符U+0000 <control-0000> ，NUL、U+0009 <control-0009> ，HT、U+000A <control-000A> ，LF、U+000D <control-000D> ，CR、U+0085 <control-0085> ，NEL常用于格式化字符。

## Unicode引入的分隔符

为了简化几种换行字符，Unicode引入了它自己的分隔符来格式化文本：

* U+2028 LINE SEPARATOR ，HTML：`&#8232;`，LSEP
* U+2029 PARAGRAPH SEPARATOR ，HTML：`&#8233;`，PSEP

## 语言标记

Unicode以前定义了标签，包含了128个字符表示语言标签，但现在已经过时了。这些字符实际上镜像了128个ASCII字符。用于表示随后的文本属于IETF語言標籤（BCP 47）所指的特定语言。例如，表示随后文本使用美国英语（en-us），用字符串开始为Language Tag character（U+E0001）后跟序列：Tag Small Letter e（U+E0065）、Tag Small Letter n（U+E006E）、Tag Hyphen-minus（U+E002D）、Tag Small Letter u（U+E0075）、Tag Small Letter s（U+E0073）。

这种语言标签自身不会被显示。但可提供用于文本处理的信息。例如，中日韩统一汉字的文本，指明是韩语而非日文，可以把一些字符用韩语特有的字形来表示。另一个例子，把数字0‐9用语言特定的字形表示。

语言标记字符U+E0001、U+E0020‐U+E007E、U+E007F 已经被Unicode 5.1（2008）宣布过时，不再作为语言标记使用。

Unicode 8.0（2015）宣布U+E0020‐U+E007E不再是过时，用于未来表示除了语言标签以外的的其他用途。（U+E0001 LANGUAGE TAG与U+E007F CANCEL TAG仍然过时）。

## 行间标注

3个格式化字符用于支持旁註標記（U+FFF9、U+FFFA、U+FFFB）。

## 双向文本控制

Unicode支持从左到右、从右到左，或者其混合排版，而不需要任何特殊字符。但为了处理一些特殊情形，Unicode定义了12个字符（U+061C、U+200E、U+200F、U+202A、U+202B、U+202C、U+202D、U+202E、U+2066、U+2067、U+2068、U+2069）以帮助控制嵌入式双向文本最大125层深。

## 异体字选择器

中日韩汉字、拉丁字母的双拼连写等等，在Unicode中被视作异体字。有些专名（如地名、姓名）必须使用某个异体字。为此，Unicode 3.2与4.0定义了256个异体字选择器，可选择前一个字符的最多256个可能的异体字。

## 控制字符的图片

Unicode在**Control Pictures**块中提供图形表示C0控制字符以及其他控制符。

|  |
| --- |
| **控制图形**[1][2] 官方Unicode Consortium码位图表 (PDF)
 |
|  | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D | E | F
 |
| U+240x
 | ␀
 | ␁
 | ␂
 | ␃
 | ␄
 | ␅
 | ␆
 | ␇
 | ␈
 | ␉
 | ␊
 | ␋
 | ␌
 | ␍
 | ␎
 | ␏
 |
| U+241x
 | ␐
 | ␑
 | ␒
 | ␓
 | ␔
 | ␕
 | ␖
 | ␗
 | ␘
 | ␙
 | ␚
 | ␛
 | ␜
 | ␝
 | ␞
 | ␟
 |
| U+242x
 | ␠
 | ␡
 | ␢
 | ␣
 | ␤
 | ␥
 | ␦
 | ␧
 | ␨
 | ␩
 |  |  |  |  |  |  |
| U+243x
 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
| **备注**
1.**^** 截至Unicode版本 16.0
2.**^** 灰区指示未使用的码位 |

* Specials (Unicode block)
* ISO 2047
# 2023年乍得宪法公投[编辑]

2023年12月17日，乍得就新宪法举行了宪法公投。该宪法草案在2021年总统伊德里斯·代比去世后拟定，并已于2023年6月27日获得国家过渡委员会批准。公投的初步结果于2023年12月24日公布，并于12月28日经乍得最高法院确认生效。

## 背景

自2021年4月总统伊德里斯·代比去世以来，乍得一直由其子穆罕默德·代比的军政府领导。该国于2021年至2022年间由过渡军事委员会执政，随后由国家过渡委员会接替，目的是将乍得过渡为文官执政及民主制度。乍得军事当局将此次宪法公投描述为推动国家向民主过渡的重要一步，为2024年举行选举铺平道路。

## 公投活动

### 支持

此次宪法公投中的“支持”选项得到了由穆罕默德·代比将军领导的军事主导国家过渡委员会支持，此外前执政党爱国拯救运动和由总理萨利赫·凯布扎博领导的主要反对党乍得国家民主联盟亦支持新宪法。

一些支持公投的人士认为，该宪法赋予乍得人民更多自由和自主权，使他们可以自行选举地方代表。也有人反对“反对”阵营要求将乍得改为联邦制国家的主张，认为这将“把乍得分裂成若干个微型国家”。

### 反对

部分小型反对派和叛乱团体支持在宪法公投中投下“反对”票，更有甚者表示将抵制此次公投。抵制者指出军政府在公投过程中掌握过多控制权，还称此次投票是幌子，其目的是让军事领导层继续掌控乍得政权。国际关系专家菲德尔·阿马基耶·奥乌苏也认为，此次公投是为了给穆罕默德·代比的统治提供合法性。

大多数“反对”阵营人士反对新宪法中维持中央集权的体制，转而主张建立联邦制国家，认为中央集权体制未能推动国家发展。乍得记者与记者网络在2023年初进行的一项调查显示，71%的乍得人支持联邦制。尽管如此，新宪法仍保留单一制国家结构，但下放了一部分权力至地方政府和经选举产生的地方代表。

## 投票执行

此次公投因在选民登记过程及用于实施公投的基础设施和技术审查方面缺乏透明而受到批评。

## 拟议的修改和内容

新草案旨在复刻1996年宪法的要素，其中重要条款如下：

* 乍得被界定为一个实行分權的单一制国家，採半总统制的政府体制（此举撤销了2018年宪法中确立的完全总统制变更）。
* 宪法草案确认设立参议院，即立法机关的上议院，该机构早在2018年宪法中被设想设立，但一直未实施。
* 司法独立性得到加强，司法最高委员会的主席将由最高法院院长担任（根据现行宪法，最高法院院长仅为第二副主席，位列总统和司法部长之后）。
* 国家选举管理局将被设立为一个独立且常设的机构，负责所有选举及公投相关事务。它将取代此前直接隶属于政府的国家独立选举委员会。
* 高等司法法院（此前为最高法院的一个分庭）将再次成为独立机构。该法院为唯一有权审判共和国总统、主要机构负责人、政府成员及其同谋（在叛国等重大案件中）的司法机构。
* 宪法委员会（此前为最高法院的第三分庭）将恢复其权力，负责“审查法律、国际条约与协定、组织法以及涉及公共自由和基本权利的其他法律的合宪性”。该委员会还负责为当选总统主持就职宣誓、裁决全国性选举争议，并调解国家机构运作及公共权力机关活动的合法性。
* 设立独立的行政机构－国家人权委员会，旨在促进和保障人权与基本自由。
* 共和国调解员将被设立为“一个独立的行政机构，负责协助和平解决冲突，受理关于公共行政、自主社区、公共机构及其他履行公共服务职能实体运作方面的投诉”。

## 投票结果

2023年12月24日，根据乍得宪法公投组织全国委员会的数据显示，“支持”选项以86%的得票率获采纳，而“反对”选项的得票率仅为14%。12月28日，乍得最高法院正式确认了这一结果。

| 選擇 | 票数 | % |
| --- | --- | --- |
| 支持 | 4,220,365 | 85.90 |
| 反对 | 692,804 | 14.10 |
| 总共 | 4,913,169 | 100.00 |
|  |
| 有效票数 | 4,913,169 | 94.87 |
| 无效及空白票数 | 265,445 | 5.13 |
| 总票数 | 5,178,614 | 100.00 |
| 已登记选民／投票率 | 8,237,768 | 62.86 |
| 资料来源：Cour suprême |

* Text of the new constitution