WHATWG

Encoding — 符号化法

Living Standard —

この日本語訳は非公式な文書です…（翻訳更新： ）

このページは、WHATWGによる Encoding Standard を日本語に翻訳したものです。 （初公表日： ）

この文書についての詳細
このバージョン（原文 URL ）
https://encoding.spec.whatwg.org/
Participate:
GitHub whatwg/encoding (new issue, open issues)
Chat on Matrix
Commits:
https://github.com/whatwg/encoding/commits
Snapshot as of this commit
@encodings
Tests:
web-platform-tests encoding/ (ongoing work)
各国語翻訳（非規範的）
日本語（このページ）
© このページは、次による原文の許諾の下で翻訳されています：
Creative Commons Attribution 4.0 International License. Copyright © WHATWG (Apple, Google, Mozilla, Microsoft).
索引など

1. 序

UTF-8 符号化法は、 普遍的な有符号文字集合である Unicode の交換に最も適切な符号化法である。 よって，この仕様は、 新たな［ プロトコル, 形式 ］および［ 新たな文脈において配備される既存の形式 ］に対し，UTF-8 符号化法を要求する （また，それを定義する）。 The UTF-8 encoding is the most appropriate encoding for interchange of Unicode, the universal coded character set. Therefore, for new protocols and formats, as well as existing formats deployed in new contexts, this specification requires (and defines) the UTF-8 encoding.

符号化法には，他のもの（旧来の符号化法）もあり、 過去にある程度までは定義されたが， UA 間で常に同じ仕方で実装されているとは限らない。 また、 常に同じラベルを利用するとは限らず，［ 符号化法の中の未定義な区画, あるいは かつてのプロプライエタリな区画への対処 ］も相違することが多い。 この仕様は、［ 新たな実装が符号化法実装をリバースエンジニアせずに済む ］よう，および［ 既存の UA が一つに収束できる ］よう，これらの隔たりを埋めることに取り組む。 The other (legacy) encodings have been defined to some extent in the past. However, user agents have not always implemented them in the same way, have not always used the same labels, and often differ in dealing with undefined and former proprietary areas of encodings. This specification addresses those gaps so that new user agents do not have to reverse engineer encoding implementations and existing user agents can converge.

特に，この仕様は、 それらすべての符号化法を，各符号化法の［ バイト列とスカラー値列を相互に変換するアルゴリズム, 正準的な名前, 識別用のラベルたち ］とともに定義する。 また、 符号化法を成す各種アルゴリズムのうち一部を JavaScript に公開する API も定義する。 In particular, this specification defines all those encodings, their algorithms to go from bytes to scalar values and back, and their canonical names and identifying labels. This specification also defines an API to expose part of the encoding algorithms to JavaScript.

UA は、 すでに IANA Character Sets レジストリに挙げられているラベルからも有意に逸脱している。 旧来の符号化法を これ以上拡散させないため、 この仕様は前述の詳細について網羅的であり， レジストリはもう不要である。 特に，この仕様は、 符号化法を拡張するための仕組みは供さない。 User agents have also significantly deviated from the labels listed in the IANA Character Sets registry. To stop spreading legacy encodings further, this specification is exhaustive about the aforementioned details and therefore has no need for the registry. In particular, this specification does not provide a mechanism for extending any aspect of encodings.

2. セキュリティに関する背景

符号化法には、 いくつか，セキュリティの課題がある — 生産器と消費器の間で，［ 利用中にある符号化法, あるいは所与の符号化法の実装法 ］について合意されてないときに。 例えば、 2011 年には，次のような攻撃が報告された： そこでは、［ 攻撃者が何らかのフィールドを制御し得るような，JSON リソース ］内で， Shift_JIS の頭部バイト 0x82 が尾部バイト 0x22 を “隠す” ために利用された。 生産器からは，これが違法なバイト対であっても問題が見えない一方で、 消費器は，このバイト対を 1 個の U+FFFD ( � ) として復号する結果、 全体的な解釈が変わってしまう — U+0022 ( " ) は重要な区切子なので。 ［ スカラー値に対し複数バイトを利用する符号化法 ］の復号器には、 今や，違法なバイト対の事例では［ 範囲 U+0000 〜 U+007F に入るスカラー値 ］を “隠せない” ようにすることが要求される — 前述のバイト対に対しては、 出力が［ U+FFFD ( � ) ］になるよう （あいにく，これには例外があり、 gb18030 復号器は，キュー終端にある そのようなバイト 1 個を “隠して” しまう）。 There is a set of encoding security issues when the producer and consumer do not agree on the encoding in use, or on the way a given encoding is to be implemented. For instance, an attack was reported in 2011 where a Shift_JIS leading byte 0x82 was used to “mask” a 0x22 trailing byte in a JSON resource of which an attacker could control some field. The producer did not see the problem even though this is an illegal byte combination. The consumer decoded it as a single U+FFFD (�) and therefore changed the overall interpretation as U+0022 (") is an important delimiter. Decoders of encodings that use multiple bytes for scalar values now require that in case of an illegal byte combination, a scalar value in the range U+0000 to U+007F, inclusive, cannot be “masked”. For the aforementioned sequence the output would be U+FFFD U+0022. (As an unfortunate exception to this, the gb18030 decoder will “mask” up to one such byte at end-of-queue.)

これは、 より一般的には，［ 頭部バイトが伴われないときに，ASCII バイトを ASCII 符号位置でない何かへ対応付ける ］ような符号化法における課題である。 これらは， “ASCII 互換でない” 符号化法であり、 あいにく，配備済みな内容に因り要求されるが、［ ISO-2022-JP, UTF-16BE/LE ］以外のものは，サポートされない。 （他の そのような符号化法についても、 そのラベルを［ 未知な符号化法へフォールバックすることなく， replacement 符号化法に対応付けれるかどうか ］の究明が進行中にある。） 攻撃の例として、 注意深く細工された内容をリソースの中へ注入して，利用者に符号化法を上書きするよう促す結果、 例えば，スクリプトの実行へ至らすものがある。 This is a larger issue for encodings that map anything that is an ASCII byte to something that is not an ASCII code point, when there is no leading byte present. These are “ASCII-incompatible” encodings and other than ISO-2022-JP and UTF-16BE/LE, which are unfortunately required due to deployed content, they are not supported. (Investigation is ongoing whether more labels of other such encodings can be mapped to the replacement encoding, rather than the unknown encoding fallback.) An example attack is injecting carefully crafted content into a resource and then encouraging the user to override the encoding, resulting in, e.g., script execution.

［ HTML や HTML のフォーム特能 ］において見出される URL に利用される符号化器も、 その符号化法により表現できないスカラー値がある場合には，若干の情報喪失に至らせ得る。 例えば，リソースが windows-1252 符号化法を利用しているとき、 サーバは，末端利用者がフォームに手入力した "💩" と "💩" とを判別できなくなる。 Encoders used by URLs found in HTML and HTML’s form feature can also result in slight information loss when an encoding is used that cannot represent all scalar values. E.g., when a resource uses the windows-1252 encoding a server will not be able to distinguish between an end user entering “💩” and “💩” into a form.

ここに要旨した問題は、 UTF-8 を排他的に利用しているときは，消え去る。 それが、 今や，すべてに対し UTF-8 符号化法が義務付けられている理由の一つである。 The problems outlined here go away when exclusively using UTF-8, which is one of the many reasons that is now the mandatory encoding for all things.

注記： § ブラウザ UI も見よ。 See also the Browser UI chapter.

3. 各種用語

この仕様は、 Infra Standard [INFRA] に依存する。 This specification depends on the Infra Standard. [INFRA]

16 進数には "0x" が接頭される。 Hexadecimal numbers are prefixed with "0x".

算術式の中のすべての数値は整数であり、 各種演算は，次に挙げる記号で表現される：

記号 意味
+ 加算
− 減算
+= 左辺値に対する右辺値による加算【この訳による追加】
−= 左辺値に対する右辺値による減算【この訳による追加】
× 乗算
÷ 整数の除算【小数切り捨て】
% 整数の除算の剰余（ modulo ）【常に 0 以上（負な数には演算され得ない）】
<< 論理左シフト
>> 論理右シフト
& ビット AND
| ビット OR
In equations, all numbers are integers, addition is represented by "+", subtraction by "−", multiplication by "×", integer division by "/" (returns the quotient), modulo by "%" (returns the remainder of an integer division), logical left shifts by "<<", logical right shifts by ">>", bitwise AND by "&", and bitwise OR by "|".

論理右シフトの演算対象の精度は、 少なくとも 21 ビット以上にするものとする。 For logical right shifts operands must have at least twenty-one bits precision.

入出力キュー （ I/O queue ）は、 ある特定の型（ バイト, スカラー値, 符号単位 など）のアイテムたちが成すリストである。 アイテム型も含めて指定するときは、 “入出力キュー<バイト>” 等々と記される†。 【†この表記規約は、この訳に特有。】 An I/O queue is a type of list with items of a particular type (i.e., bytes or scalar values).＼

入出力キューは、 特別なアイテムとして キュー終端 （ end-of-queue ）も含み得る — それは、 当のキュー内には，それより後にアイテムは無いことを徴す。 【キュー終端の型は、形式的に，それが属する入出力キューのアイテム型と見なされる。】 End-of-queue is a special item that can be present in I/O queues of any type and it signifies that there are no more items in the queue.

注記： 入出力キューは、 2 つの仕方 — “ストリームしている” モード，していないモード — で利用され、 順に［ ネットワークから来ているデータ, メモリー内に格納された入出力データ ］を表現する。 ストリームしていないキュー内には、 最後のアイテムとして【常に】キュー終端が在る。 一方で，ストリームしている入出力キューは： There are two ways to use an I/O queue: in immediate mode, to represent I/O data stored in memory, and in streaming mode, to represent data coming in from the network. Immediate queues have end-of-queue as their last item, whereas streaming queues＼

  • キュー終端は無いこともあり、［ 入出力キューからアイテムを読み取る／ 入出力キューからアイテム列を読み取る ］演算は， 【何らかのアイテムが可用になるまで】阻まれるかもしれない。 need not have it, and so their read operation might block.
  • 次の順に演算されるものと期待される ：空として作成される, ネットワークからデータが来るに伴い，新たなアイテムがプッシュされる, 下層のネットワークストリームが close されるとき，キュー終端がプッシュされる It is expected that streaming I/O queues will be created empty, and that new items will be pushed to it as data comes in from the network. When the underlying network stream closes, an end-of-queue item is to be pushed into the queue.
  • そこから読み取るときは，阻まれるかもしれないので、 イベントループからは利用されず，代わりに並列的に利用される。 Since reading from a streaming I/O queue might block, streaming I/O queues are not to be used from an event loop. They are to be used in parallel instead.

入出力キューからアイテムを読み取る アルゴリズムは、 所与の ( 入出力キュー 入出力キュー ) に対し： To read an item from an I/O queue ioQueue, run these steps:

  1. IF［ 入出力キュー は空である ］ ：次が満たされるまで待機する ：入出力キュー のサイズ ≥ 1 If ioQueue is empty, then wait until its size is at least 1.
  2. 結果 :← 入出力キュー[ 0 ] ↓
  3. IF［ 結果 ≠ キュー終端 ］ ：入出力キュー から最初のアイテムを除去する If ioQueue[0] is end-of-queue, then return end-of-queue.Remove ioQueue[0] and return it.
  4. RETURN 結果 ↑

入出力キューからアイテム列を読み取る アルゴリズムは、 所与の ( 入出力キュー 入出力キュー, 無符号整数 個数 ) に対し： To read a number number of items from ioQueue, run these steps:

  1. Assert：［ 個数 は負でない整数である ］∨［ 個数 ＝ 不定 ］ ↑
  2. 結果 :← « » Let readItems be « ».

  3. WHILE［ 結果 のサイズ ≠ 個数 ］：

    1. アイテム :← 入出力キューからアイテムを読み取る( 入出力キュー )
    2. IF［ アイテム ＝ キュー終端 ］ ：BREAK
    3. 結果 に アイテム を付加する
    Perform the following step number times: • Append to readItems the result of reading an item from ioQueue.Remove end-of-queue from readItems.
  4. RETURN 結果 Return readItems.

【 ［ 入出力キューからアイテムを読み取る, 入出力キューからアイテム列を読み取る ］アルゴリズムは、 原文では同じ［ 名前, ID ］を伴う 2 個のアルゴリズムとして定義されているが， この訳では異なる［ 名前, ID ］を与えることにする。 】

入出力キューを覗き見る アルゴリズムは、 所与の ( 入出力キュー 入出力キュー, 無符号整数 個数 ) に対し： To peek a number number of items from an I/O queue ioQueue, run these steps:

  1. 次が満たされるまで待機する ：［ 入出力キュー のサイズ ≥ 個数 ］∨［ キュー終端 ∈ 入出力キュー ］ Wait until either ioQueue’s size is equal to or greater than number, or ioQueue contains end-of-queue, whichever comes first.
  2. 接頭辞 :← « » Let prefix be « ».

  3. 範囲 { 0 〜 個数 − 1 } を成す 各( n ) に対し： For each n in the range 1 to number, inclusive:

    1. IF［ 入出力キュー[ n ] ＝ キュー終端 ］ ：BREAK If ioQueue[n] is end-of-queue, break.
    2. 接頭辞 に 入出力キュー[ n ] を付加する Otherwise, append ioQueue[n] to prefix.
  4. RETURN 接頭辞 Return prefix.

入出力キューにプッシュする アルゴリズムは、 所与の ( 入出力キュー 入出力キュー, アイテム列 ) に対し：

  1. Assert：［ アイテム列 は 1 個のアイテムであるか［ アイテムたちが成す連列 ］である ］∧［ アイテム列 を成す どのアイテムも，その型は 入出力キュー のアイテム型である ］

  2. アイテム列 を成す 各( アイテム ) に対し：

    1. 最後の index :← 入出力キュー のサイズ − 1

    2. IF［ 入出力キュー[ 最後の index ] ＝ キュー終端 ］：

      1. IF［ アイテム ≠ キュー終端 ］ ：入出力キュー の中へ アイテム を 最後の index の前に挿入する
    3. ELSE ：入出力キュー に アイテム を付加する
To push an item item to an I/O queue ioQueue, run these steps: • If the last item in ioQueue is end-of-queue: •• If item is end-of-queue, do nothing. •• Otherwise, insert item before the last item in ioQueue. • Otherwise, append item to ioQueue.To push a sequence of items to an I/O queue ioQueue is to push each item in the sequence to ioQueue, in the given order.

入出力キューに格納し直す アルゴリズムは、 所与の ( 入出力キュー 入出力キュー, アイテム列 ) に対し：

  1. Assert：

    • アイテム列 は 1 個のアイテムであるか［ アイテムたちが成す連列 ］である
    • アイテム列 内にキュー終端は無い
    • アイテム列 を成す どのアイテムも，その型は 入出力キュー のアイテム型である
  2. 入出力キュー の先頭に アイテム列 を — アイテムたちの順序を保ったまま — 挿入する
To restore an item other than end-of-queue to an I/O queue, perform the list prepend operation. To restore a list of items excluding end-of-queue to an I/O queue, insert those items, in the given order, before the first item in the queue.

入出力キュー<バイト> « 0x92, 0xA9, キュー終端 » に バイト列 « 0xF0, 0x9F » を挿入したなら、 結果の入出力キューは « 0xF0, 0x9F, 0x92, 0xA9, キュー終端 » になり， 次回に読み取られるアイテムは 0xF0 になる。 Inserting the bytes « 0xF0, 0x9F » in an I/O queue « 0x92 0xA9, end-of-queue », results in an I/O queue « 0xF0, 0x9F, 0x92 0xA9, end-of-queue ». The next item to be read would be 0xF0.

入出力キュー 入出力キュー を［ リスト／文字列／バイト列 ］に 変換する アルゴリズムは ：RETURN 入出力キューからアイテム列を読み取る( 入出力キュー, 不定 ) To convert an I/O queue ioQueue into a list, string, or byte sequence, return the result of reading an indefinite number of items from ioQueue.

入出力キューに変換する アルゴリズムは、 所与の ( 入力 ) に対し：

  1. Assert： 入力 は次に挙げるいずれかである ：文字列（ DOMString ）／ スカラー値文字列（ USVString ）／ バイト列／ リスト
  2. IF［ 入力 はリストである ］ ：Assert ：［ 入力 を成す すべてのアイテムは同じ型である ］∧［ キュー終端 ∉ 入力 ］
  3. 入出力キュー :← 新たな入出力キュー<入力 を成すアイテムの型>
  4. 入力 を成す 各( アイテム ) に対し ：入出力キュー に アイテム を付加する
  5. 入出力キュー にキュー終端を付加する
  6. RETURN 入出力キュー
To convert a list, string, or byte sequence input into an I/O queue, run these steps: • Assert: input is not a list or it does not contain end-of-queue. • Return an I/O queue containing the items in input, in order, followed by end-of-queue.

[INFRA] 標準が型変換周りの何らかの基盤を定義するものと期待される。 whatwg/infra 課題 #319 を見よ。 The Infra standard is expected to define some infrastructure around type conversions. See whatwg/infra issue #319. [INFRA]

注記： 入出力キューがキューではなくリストとして定義されているのは、 格納し直す演算を要するからである。 しかしながら，この演算は、 この仕様が与えるアルゴリズムの内部的な詳細であり，他の標準からは利用されない。 実装は、 そのようなアルゴリズムを代替な仕方を見出して実装してもかまわない — 詳細は、 § 実装の考慮点 に。 I/O queues are defined as lists, not queues, because they feature a restore operation. However, this restore operation is an internal detail of the algorithms in this specification, and is not to be used by other standards. Implementations are free to find alternative ways to implement such algorithms, as detailed in Implementation considerations.

サロゲート対からスカラー値を得る アルゴリズムは、 所与の ( 頭部サロゲート 頭部, 尾部サロゲート 尾部 ) に対し ：RETURN 0x10000 + ( ( 頭部 − 0xD800 ) << 10 ) + ( 尾部 − 0xDC00 ) To obtain a scalar value from surrogates, given a leading surrogate leading and a trailing surrogate trailing, return 0x10000 + ((leading − 0xD800) << 10) + (trailing − 0xDC00).

【この訳に特有な表記規約】

この訳において（主にアルゴリズム内で）利用される各種記号（ ε, ← , IF, THROW, 等々）の意味や定義の詳細は、共通な慣用表現, アルゴリズムに共通して利用される表記を参照されたし。

加えて、 次に挙げる記法も利用される：

バイト列 « n1, n2, … »
数値として n1, n2 … と同じ値をとるバイトたちが成す, 挙げられた順による，新たなアイテム列を表す （括弧の中が空な “« »” と記されたときは、 空なアイテム列を表す）。
バイト « n »
バイト列 « n » と同義だが、 アイテムが 1 個だけの場合は，このように記される。
符号位置 « n »
数値として n と同じ値をとる 1 個の符号位置からなる，新たなアイテム列を表す。

（原文では，アイテムが 1 個だけの場合は — 1 個のアイテムを それのみからなるアイテム列として透過的に扱う仕組み （入出力キューに対する各種演算を見よ） を利用して — 括弧（ «, » ）で括らずに記されているが、 この訳では — “同じ値をとる” という含意を簡潔に表すため — 括弧で括ることにする。） （ “符号位置列 « … »” という記法が無いのは、 複数個の符号位置からなるアイテム列が利用される所が，一箇所しかないからである。）

Uint8Array オブジェクトを作成する アルゴリズムは… To create a Uint8Array object, given an I/O queue ioQueue and a realm realm: • Let bytes be the result of converting ioQueue into a byte sequence. • Return the result of creating a Uint8Array object from bytes in realm.

【 この訳では、 このアルゴリズムを利用しない — 代わりに，このアルゴリズムが利用するバッファソースを作成するアルゴリズム [WEBIDL] を直に呼び出す。 】

4. 符号化法

符号化法 （ encoding ）は、 スカラー値 列からバイト列への対応付け 【符号化】 および逆方向への対応付け 【復号】 を定義する。 各 符号化法には、 名前 および， 1 個以上の ラベル があてがわれている。 An encoding defines a mapping from a scalar value sequence to a byte sequence (and vice versa). Each encoding has a name, and one or more labels.

注記： この仕様は、 Unicode 標準に定義される符号化スキーム（ encoding scheme ）として，同じ名前を伴う 3 種の符号化法 — UTF-8, UTF-16LE, UTF-16BE — を定義する。 符号化法は、 BOM （ byte order mark, “バイト順マーク” ）の取り扱いにおいて符号化スキームから相違する — BOM の取り扱いは、 この仕様においては［ 符号化法自身の一部を成す代わりに，それを包装するアルゴリズムの一部を成している ］一方で， Unicode 標準においては符号化スキームの定義の一部を成す。 UTF-8 復号するアルゴリズムと一緒に利用される UTF-8 は、 同じ名前の符号化スキームに合致する。 この仕様は、 同様に命名される符号化スキームに合致するような［ UTF-16LE ／ UTF-16BE ］と組み合せて包装するアルゴリズムは，供さない。 [UNICODE] This specification defines three encodings with the same names as encoding schemes defined in the Unicode standard: UTF-8, UTF-16LE, and UTF-16BE. The encodings differ from the encoding schemes by byte order mark (also known as BOM) handling not being part of the encodings themselves and instead being part of wrapper algorithms in this specification, whereas byte order mark handling is part of the definition of the encoding schemes in the Unicode Standard. UTF-8 used together with the UTF-8 decode algorithm matches the encoding scheme of the same name. This specification does not provide wrapper algorithms that would combine with UTF-16LE and UTF-16BE to match the similarly-named encoding schemes. [UNICODE]

4.1. 符号化器と復号器

各 符号化法には、 復号器 （ decoder ）が結び付けられ， 符号化器 （ encoder ）が結び付けられ得る。 Each encoding has an associated decoder and most of them have an associated encoder.＼

［ 復号器 ／ 符号化器 ］の各インスタンスは、 ハンドラ アルゴリズムが結び付けられることに加え，状態も伴い得る。 【状態を伴うがゆえに、状態が異なる それらを別個なインスタンスとして扱う必要がある。】 Instances of decoders and encoders have a handler algorithm and might also have state.＼

ハンドラは、 所与の ( 入出力キュー, 1 個のアイテム ) に対し，次に挙げるいずれかを返すアルゴリズムである：

  • 完遂

  • 1 個以上のアイテム

    【 アイテム型は、［ 符号化器の場合はバイト ／ 復号器の場合は符号位置 ］になる。 】【 Big5 復号器用のハンドラだけ， 2 個の符号位置を返す場合があり、 他の復号器用のハンドラは，常に 1 個の符号位置からなるアイテム列を返す。 】

  • エラー

    符号化器用のハンドラが返す エラー は、 常に，符号位置を伴う （復号器用のハンドラが返す エラー が符号位置を伴うことは無い）。 所与の符号位置 符号位置 を伴う エラー を作成する所では、 “エラー( 符号位置 )” のように表記される。

    【 これらの記述は、 この訳による補完 — 原文では、 （エラーは，） “省略可能な符号位置も伴い得る” としか記されていない。 】

  • 継続
A handler algorithm takes an input I/O queue and an item, and returns finished, one or more items, error optionally with a code point, or continue.

注記： 次に挙げる符号化法には、 符号化器は無い ：replacement, UTF-16BE/LE The replacement and UTF-16BE/LE encodings have no encoder.

以下で利用される エラーモード は： An error mode as used below is＼

  • 復号器においては、 次のいずれかをとる ："replacement", "fatal" "replacement" or "fatal" for a decoder and＼
  • 符号化器においては、 次のいずれかをとる ："fatal", "html" "fatal" or "html" for an encoder.

注記： XML 処理器は、 その復号器のエラーモードを "fatal" に設定することになる。 [XML] An XML processor would set error mode to "fatal". [XML]

注記： エラーモードに "html" が存在するわけは、 HTML フォームにおいては， エラー に際しても旧来の符号化器は終了させない取り扱いが要求されることに因る。 "html" エラーモードの下では、 合法な入力と判別できない連列が発され得る結果，検知されずにデータが失われ得る。 これを防ぐため、 開発者には UTF-8 符号化法の利用が強く奨励される。 [HTML] "html" exists as error mode due to HTML forms requiring a non-terminating legacy encoder. The "html" error mode causes a sequence to be emitted that cannot be distinguished from legitimate input and can therefore lead to silent data loss. Developers are strongly encouraged to use the UTF-8 encoding to prevent this from happening. [HTML]

キューを処理する アルゴリズムは、 所与の ：符号化法の［ 復号器 ／ 符号化器 ］のインスタンス coder 入出力キュー 入力, 入出力キュー 出力, エラーモード モード に対し： To process a queue given an encoding’s decoder or encoder instance encoderDecoder, I/O queue input, I/O queue output, and error mode mode:

  1. WHILE 無条件： While true:

    1. アイテム :← 入出力キューからアイテムを読み取る( 入力 ) ↓
    2. 結果 :← アイテムを処理する( アイテム, coder , 入力, 出力, モード ) Let result be the result of processing an item with the result of reading from input, encoderDecoder, input, output, and mode.
    3. IF［ 結果 ≠ 継続 ］ ：RETURN 結果 If result is not continue, then return result.

アイテムを処理する アルゴリズムは、 所与の ：アイテム アイテム, 符号化法の［ 符号化器／復号器 ］のインスタンス coder , 入出力キュー 入力, 入出力キュー 出力, エラーモード モード に対し： To process an item given an item item, encoding’s encoder or decoder instance encoderDecoder, I/O queue input, I/O queue output, and error mode mode:

  1. IF［ coder は符号化器のインスタンスである ］ ：Assert ：［ モード ≠ "replacement" ］∧［ アイテム はサロゲートではない ］ Assert: encoderDecoder is not an encoder instance or mode is not "replacement".Assert: encoderDecoder is not a decoder instance or mode is not "html".Assert: encoderDecoder is not an encoder instance or item is not a surrogate.
  2. IF［ coder は復号器のインスタンスである ］ ：Assert ：モード ≠ "html" ↑
  3. 結果 :← coder のハンドラ( 入力, アイテム ) Let result be the result of running encoderDecoder’s handler on input and item.
  4. IF［ 結果 ＝ 完遂 ］ ：入出力キューにプッシュする( 出力, « キュー終端 » )； RETURN 結果 If result is finished: • Push end-of-queue to output. • Return result.

  5. IF［ 結果 は 1 個以上のアイテムからなる ］： Otherwise, if result is one or more items:

    1. IF［ coder は復号器のインスタンスである ］ ：Assert ：結果 はサロゲートを包含しない。 Assert: encoderDecoder is not a decoder instance or result does not contain any surrogates.
    2. 入出力キューにプッシュする( 出力, 結果 ) Push result to output.

  6. ELSE IF［ 結果 は エラー である ］： Otherwise, if result is an error,＼

    1. モード に応じて： switch on mode and run the associated steps:

      • "replacement" ：入出力キューにプッシュする( 出力, « U+FFFD ( � ) » ) "replacement" • Push U+FFFD (�) to output.

      • "html"：

        1. 数字列 :← ［ 結果 を成す符号位置 ］の値を基数 10 で最短に表現するような，［ 1 個以上の［ 0x30 ( 0 ) 〜 0x39 ( 9 ) ］たちが成すバイト列
        2. 入出力キューにプッシュする( 出力, 次の並びが成すバイト列 ) ：0x26 ( & ), 0x23 ( # ), 数字列, 0x3B ( ; )
        "html" • Push 0x26 (&), 0x23 (#), followed by the shortest sequence of 0x30 (0) to 0x39 (9), inclusive, representing result’s code point’s value in base ten, followed by 0x3B (;) to output.
      • "fatal" ：RETURN 結果 "fatal" • Return result.
  7. RETURN 継続 Return continue.

4.2. 名前とラベル

UA は、 下の表に挙げる各［ 符号化法, それ用のラベルすべて ］をサポートするものとする — 他の符号化法やラベルはサポートしないものとする。 The table below lists all encodings and their labels user agents must support. User agents must not support any other encodings or labels.

注記： どの符号化法についても、 次が満たされる ：その名前を ASCII 小文字化した結果 ∈ それ用のラベルたちが成す集合 For each encoding, ASCII-lowercasing its name yields one of its labels.

【 加えて、 異なる符号化法用のラベルどうしが一致することはない。 】

作者は、 UTF-8 符号化法を利用しなければならない — その利用が識別されるよう， それ用のラベルのうち "utf-8" （ASCII 大小無視）を利用しなければならない。 Authors must use the UTF-8 encoding and must use its (ASCII case-insensitive) "utf-8" label to identify it.

［ 新たなプロトコル／ 新たな形式／ 新たな文脈において配備される既存の形式 ］には、 UTF-8 符号化法を排他的に利用しなければならない。 そのような［ プロトコルや形式 ］が公開する符号化法の［ 名前／ラベル ］は、 "utf-8" でなければならない。 New protocols and formats, as well as existing formats deployed in new contexts, must use the UTF-8 encoding exclusively. If these protocols and formats need to expose the encoding’s name or label, they must expose it as "utf-8".

ラベルから符号化法を取得する アルゴリズムは、 所与の ( 文字列 ラベル ) に対し： To get an encoding from a string label, run these steps:

  1. ラベル ← 前後の ASCII 空白列を剥ぐ( ラベル ) Remove any leading and trailing ASCII whitespace from label.
  2. IF［ ラベル は［ 下の表を成すいずれかのラベル ］に ASCII 大小無視で合致する ］ ：RETURN 合致したラベルに対応する符号化法 If label is an ASCII case-insensitive match for any of the labels listed in the table below, then return the corresponding encoding;＼
  3. RETURN 失敗 otherwise return failure.

注記： この［ ラベルを符号化法へ対応付けるアルゴリズム ］は、 Unicode Technical Standard #22 § 1.4 によるものより基本的かつ制約的である — 配備済みな内容と互換になることが必要とされるので。 This is a more basic and restrictive algorithm of mapping labels to encodings than section 1.4 of Unicode Technical Standard #22 prescribes, as that is necessary to be compatible with deployed content.

名前 Name ラベル Labels
標準の符号化法 The Encoding
UTF-8 "unicode-1-1-utf-8" "unicode11utf8" "unicode20utf8" "utf-8" "utf8" "x-unicode20utf8"
旧来の単バイト符号化法 Legacy single-byte encodings
IBM866 "866" "cp866" "csibm866" "ibm866"
ISO-8859-2 "csisolatin2" "iso-8859-2" "iso-ir-101" "iso8859-2" "iso88592" "iso_8859-2" "iso_8859-2:1987" "l2" "latin2"
ISO-8859-3 "csisolatin3" "iso-8859-3" "iso-ir-109" "iso8859-3" "iso88593" "iso_8859-3" "iso_8859-3:1988" "l3" "latin3"
ISO-8859-4 "csisolatin4" "iso-8859-4" "iso-ir-110" "iso8859-4" "iso88594" "iso_8859-4" "iso_8859-4:1988" "l4" "latin4"
ISO-8859-5 "csisolatincyrillic" "cyrillic" "iso-8859-5" "iso-ir-144" "iso8859-5" "iso88595" "iso_8859-5" "iso_8859-5:1988"
ISO-8859-6 "arabic" "asmo-708" "csiso88596e" "csiso88596i" "csisolatinarabic" "ecma-114" "iso-8859-6" "iso-8859-6-e" "iso-8859-6-i" "iso-ir-127" "iso8859-6" "iso88596" "iso_8859-6" "iso_8859-6:1987"
ISO-8859-7 "csisolatingreek" "ecma-118" "elot_928" "greek" "greek8" "iso-8859-7" "iso-ir-126" "iso8859-7" "iso88597" "iso_8859-7" "iso_8859-7:1987" "sun_eu_greek"
ISO-8859-8 "csiso88598e" "csisolatinhebrew" "hebrew" "iso-8859-8" "iso-8859-8-e" "iso-ir-138" "iso8859-8" "iso88598" "iso_8859-8" "iso_8859-8:1988" "visual"
ISO-8859-8-I "csiso88598i" "iso-8859-8-i" "logical"
ISO-8859-10 "csisolatin6" "iso-8859-10" "iso-ir-157" "iso8859-10" "iso885910" "l6" "latin6"
ISO-8859-13 "iso-8859-13" "iso8859-13" "iso885913"
ISO-8859-14 "iso-8859-14" "iso8859-14" "iso885914"
ISO-8859-15 "csisolatin9" "iso-8859-15" "iso8859-15" "iso885915" "iso_8859-15" "l9"
ISO-8859-16 "iso-8859-16"
KOI8-R "cskoi8r" "koi" "koi8" "koi8-r" "koi8_r"
KOI8-U "koi8-ru" "koi8-u"
macintosh "csmacintosh" "mac" "macintosh" "x-mac-roman"
windows-874 "dos-874" "iso-8859-11" "iso8859-11" "iso885911" "tis-620" "windows-874"
windows-1250 "cp1250" "windows-1250" "x-cp1250"
windows-1251 "cp1251" "windows-1251" "x-cp1251"
windows-1252

歴史的な “Latin1 ”, “ASCII ” の概念の関係性は、 下の注記を見よ。 See below for the relationship to historical "Latin1" and "ASCII" concepts.

"ansi_x3.4-1968" "ascii" "cp1252" "cp819" "csisolatin1" "ibm819" "iso-8859-1" "iso-ir-100" "iso8859-1" "iso88591" "iso_8859-1" "iso_8859-1:1987" "l1" "latin1" "us-ascii" "windows-1252" "x-cp1252"
windows-1253 "cp1253" "windows-1253" "x-cp1253"
windows-1254 "cp1254" "csisolatin5" "iso-8859-9" "iso-ir-148" "iso8859-9" "iso88599" "iso_8859-9" "iso_8859-9:1989" "l5" "latin5" "windows-1254" "x-cp1254"
windows-1255 "cp1255" "windows-1255" "x-cp1255"
windows-1256 "cp1256" "windows-1256" "x-cp1256"
windows-1257 "cp1257" "windows-1257" "x-cp1257"
windows-1258 "cp1258" "windows-1258" "x-cp1258"
x-mac-cyrillic "x-mac-cyrillic" "x-mac-ukrainian"
旧来の複バイト Chinese （簡体字） 符号化法 Legacy multi-byte Chinese (simplified) encodings
GBK "chinese" "csgb2312" "csiso58gb231280" "gb2312" "gb_2312" "gb_2312-80" "gbk" "iso-ir-58" "x-gbk"
gb18030 "gb18030"
旧来の複バイト Chinese （繁体字）符号化法 Legacy multi-byte Chinese (traditional) encodings
Big5 "big5" "big5-hkscs" "cn-big5" "csbig5" "x-x-big5"
旧来の複バイト Japanese 符号化法 Legacy multi-byte Japanese encodings
EUC-JP "cseucpkdfmtjapanese" "euc-jp" "x-euc-jp"
ISO-2022-JP "csiso2022jp" "iso-2022-jp"
Shift_JIS "csshiftjis" "ms932" "ms_kanji" "shift-jis" "shift_jis" "sjis" "windows-31j" "x-sjis"
旧来の複バイト Korean 符号化法 Legacy multi-byte Korean encodings
EUC-KR "cseuckr" "csksc56011987" "euc-kr" "iso-ir-149" "korean" "ks_c_5601-1987" "ks_c_5601-1989" "ksc5601" "ksc_5601" "windows-949"
旧来の諸々の符号化法 Legacy miscellaneous encodings
replacement "csiso2022kr" "hz-gb-2312" "iso-2022-cn" "iso-2022-cn-ext" "iso-2022-kr" "replacement"
UTF-16BE "unicodefffe" "utf-16be"
UTF-16LE "csunicode" "iso-10646-ucs-2" "ucs-2" "unicode" "unicodefeff" "utf-16" "utf-16le"
x-user-defined "x-user-defined"

注記： すべての符号化法とそれら用のラベルは、 規範的でないリソース indexes.json としても可用である。 All encodings and their labels are also available as non-normative encodings.json resource.

注記： サポートされる符号化法たちが成す集合は、 主として［ この標準の開発を開始した時点で，主要な各ブラウザエンジンがサポートしていた集合 ］たちの交差集合に基づくが，符号化法のうち［ 稀にしか正当に利用されていない ］かつ［ 攻撃にも利用され得る ］ものは除去してある。 一部の符号化法については、 既存の Web 内容が利用している確たる証拠はなく，それを含めることには疑問がある。 すなわち、 それらは，各ブラウザから広くサポートされていたが、 Web 内容から広く利用されているかどうかは不明瞭である。 しかしながら、 単バイト符号化法のうち［ 各ブラウザが広くサポートしていたもの／ ISO 8859 族の一部を成すもの ］を意欲的に除去する労は，為されていない。 特に，次に挙げるものを含める必要性は、 既存の内容をサポートする目的においては疑わしいが，除去する計画は無い ：IBM866, macintosh, x-mac-cyrillic, ISO-8859-3, ISO-8859-10, ISO-8859-14, ISO-8859-16 The set of supported encodings is primarily based on the intersection of the sets supported by major browser engines when the development of this standard started, while removing encodings that were rarely used legitimately but that could be used in attacks. The inclusion of some encodings is questionable in the light of anecdotal evidence of the level of use by existing Web content. That is, while they have been broadly supported by browsers, it is unclear if they are broadly used by Web content. However, an effort has not been made to eagerly remove single-byte encodings that were broadly supported by browsers or are part of the ISO 8859 series. In particular, the necessity of the inclusion of IBM866, macintosh, x-mac-cyrillic, ISO-8859-3, ISO-8859-10, ISO-8859-14, and ISO-8859-16 is doubtful for the purpose of supporting existing content, but there are no plans to remove these.

注記： windows-1252 符号化法には、 様々なラベル — "latin1", "iso-8859-1", "ascii" など — がある。 それは、 歴史的に，開発者を惑わしていた。 web 上では, および［ web に互換になるよう追求するソフトウェア ］においては、 この標準を実装することにより，これらは同義語になる： "latin1" も "ascii" も， windows-1252 用のラベルでしかない — この標準に従うソフトウェアは、 例えば 0x80 を［ “Latin1 ” ／ “ASCII ” ］用に復号するよう依頼されたときには， U+20AC ( € ) として復号することになる。 The windows-1252 encoding has various labels, such as "latin1", "iso-8859-1", and "ascii", which have historically been confusing for developers. On the web, and in any software that seeks to be web-compatible by implementing this standard, these are synonyms: "latin1" and "ascii" are just labels for windows-1252, and any software following this standard will, for example, decode 0x80 as U+20AC (€) when asked for the "Latin1" or "ASCII" decoding of that byte.

この標準を従わないソフトウェアは、 常に同じ回答を与えるとは限らない。 その根源は、 Latin1 を指定した元の文書 [ISO8859-1] が， 範囲 { 0x00 〜 0x1F } や { 0x7F 〜 0x9F } 内のバイト用には対応付けを供さなかったことにある。 同様に、 ASCII を指定した元の文書（とりわけ [ISO646] ）は， 範囲 { 0x80 〜 0xFF } 内のバイト用には対応付けを供さなかった。 このことは、 それらのバイト用に［ Latin1 ／ASCII ］符号化法を利用するよう依頼されたとき選ばれる符号位置対応付けが， ソフトウェアに応じて異なることを意味する。 ［ web ブラウザ／ブラウザに互換なソフトウェア ］は、 それらのバイトを windows-1252 — ［ Latin1 , ASCII ］の上位集合であり，この標準内に成文化された符号化法 — に則って対応付けることを選んだ。 他のソフトウェアは、 エラーを投出するか， 同型な復号法その他の対応付けを利用する。 Software that does not follow this standard does not always give the same answers. The root of this is that the original document that specified Latin1 (ISO/IEC 8859-1) did not provide any mappings for bytes in the inclusive ranges 0x00 to 0x1F or 0x7F to 0x9F. Similarly, the original documents that specified ASCII (ISO/IEC 646, among others) did not provide any mappings for bytes in the inclusive range 0x80 to 0xFF. This means different software has chosen different code point mappings for those bytes when asked to use Latin1 or ASCII encodings. Web browsers and browser-compatible software have chosen to map those bytes according to windows-1252, which is a superset of both, and this choice was codified in this standard. Other software throws errors, or uses isomorphic decoding, or other mappings. [ISO8859-1] [ISO646]

そのようなわけで，［ 実装者, 開発者 ］は、 “Latin1 ” や “ASCII ” の用語で API を公開するライブラリを利用しているときは， 気を付ける必要がある。 そのようなライブラリが，この標準に合わない回答を与えることは十分あり得る — 元の仕様において未定義なままにされたバイト用に他のふるまいを選んだ場合には。 As such, implementers and developers need to be careful whenever they are using libraries which expose APIs in terms of "Latin1" or "ASCII". It’s very possible such libraries will not give answers in line with this standard, if they have chosen other behaviors for the bytes which were left undefined in the original specifications.

4.3. 出力符号化法

符号化法から出力符号化法を取得する アルゴリズムは、 所与の ( 符号化法 符号化法 ) に対し： To get an output encoding from an encoding encoding, run these steps:

  1. IF［ 符号化法 ∈ { replacement, UTF-16BE, UTF-16LE } ］ ：RETURN UTF-8 If encoding is replacement or UTF-16BE/LE, then return UTF-8.
  2. RETURN 符号化法 Return encoding.

注記： このアルゴリズムは、 それを必要とする［ URL 構文解析 ／ HTML フォーム提出 ］にて有用になる。 The get an output encoding algorithm is useful for URL parsing and HTML form submission, which both need exactly this.

5. 索引

ほとんどの旧来の符号化法では、 【当の符号化法に特有な】 索引 が利用される。 索引とは、 エントリたちが成す有順序リストであり，それを成す各エントリは［ ポインタ, それに対応する符号位置 ］からなる。 索引の中では、 ポインタは一意であり，符号位置は重複し得る。 Most legacy encodings make use of an index. An index is an ordered list of entries, each entry consisting of a pointer and a corresponding code point. Within an index pointers are unique and code points can be duplicated.

注記： 効率的な実装は、 各符号化法に対し， 2 つの索引 — その復号器に最適化されたそれ, その符号化器に最適化されたそれ — を備えることになろう。 An efficient implementation likely has two indexes per encoding. One optimized for its decoder and one for its encoder.

索引 【のデータを供するリソース（以下を見よ）】 から，ポインタとそれに対応する符号位置を見出すためには：

  1. 行リスト は，そのリソースの内容を U+000A LF で一連の “行” に分割した結果とする。
  2. 行リスト から［ 空行 ／ U+0023 ( # ) から開始する行 ］をすべて除去する。

  3. 行リスト の各行に対し，行を U+0009 TAB で分割した結果を成す：

    • 1 個目のアイテムがポインタ（ 10 進表記）を与える。
    • 2 個目のアイテムが対応する符号位置（ 16 進表記）を与える。
    • 他のアイテムは関連しない。
To find the pointers and their corresponding code points in an index, let lines be the result of splitting the resource’s contents on U+000A LF. Then remove each item in lines that is the empty string or starts with U+0023 (#). Then the pointers and their corresponding code points are found by splitting each item in lines on U+0009 TAB. The first subitem is the pointer (as a decimal number) and the second is the corresponding code point (as a hexadecimal number). Other subitems are not relevant.

注記： 各索引の冒頭には、 変更の有無を記すため， Identifier と Date 【識別子と日付】 が記されている。 Identifier の変化は、 索引に変更が加えられたことを表す。 To signify changes an index includes an Identifier and a Date. If an Identifier has changed, so has the index.

索引 の中で ポインタ が指す 索引符号位置 とは、 索引 内に ポインタ は［ 在るならば，それに対応する符号位置 ／ 無いならば null ］である。 The index code point for pointer in index is the code point corresponding to pointer in index, or null if pointer is not in index.
索引 の中で 符号位置 を指す 索引ポインタ とは、 索引 内に 符号位置 に対応するポインタは［ 在るならば，それらのうち最初の ポインタ ／ 無いならば null ］である。 The index pointer for codePoint in index is the first pointer corresponding to codePoint in index, or null if codePoint is not in index.

注記： 各 索引には，規範的でない視覚化があり、 索引 jis0208 には， Shift_JIS 視覚化も別にある。 加えて，基本多言語面（ BMP（ Basic Multilingual Plane ）, U+0000 〜 U+FFFF ）における被覆域の視覚化もある。 ただし、［ 索引 gb18030 範囲群 ／ 索引 ISO-2022-JP カタカナ ］には，これらの視覚化はない。 There is a non-normative visualization for each index other than index gb18030 ranges and index ISO-2022-JP katakana. index jis0208 also has an alternative Shift_JIS visualization. Additionally, there is visualization of the Basic Multilingual Plane coverage of each index other than index gb18030 ranges and index ISO-2022-JP katakana.

視覚化における凡例 The legend for the visualizations is:
表示 説明
対応する符号位置は無い。 Unmapped
 UTF-8 で 2 バイト。 Two bytes in UTF-8
 UTF-8 で 2 バイト, かつ 符号位置は、 前のポインタの符号位置の直後に続く。 Two bytes in UTF-8, code point follows immediately the code point of previous pointer
 UTF-8 で 3 バイト（私用領域でない） Three bytes in UTF-8 (non-PUA)
 UTF-8 で 3 バイト（私用領域でない）, かつ 符号位置は、 前のポインタの符号位置の直後に続く。 Three bytes in UTF-8 (non-PUA), code point follows immediately the code point of previous pointer
 私用領域 Private Use
 私用領域, かつ 符号位置は、 前のポインタの符号位置の直後に続く。 Private Use, code point follows immediately the code point of previous pointer
 UTF-8 で 4 バイト Four bytes in UTF-8
 UTF-8 で 4 バイト, かつ 符号位置は、 前のポインタの符号位置の直後に続く。 Four bytes in UTF-8, code point follows immediately the code point of previous pointer
 先に現れているものと重複する符号位置に対応する。 Duplicate code point already mapped at an earlier index
 CJK 互換漢字（ CJK Compatibility Ideograph ） CJK Compatibility Ideograph
 CJK 統合漢字拡張 A CJK Unified Ideographs Extension A

この仕様が定義する索引のうち，単バイト索引でないものには、 それぞれに自前のテーブルがあり，以下に与えられる： 【視覚化／被覆域のテーブルは巨大なことに注意】 These are the indexes defined by this specification, excluding index single-byte, which have their own table:

名前 索引 視覚化 基本多言語面（ BMP ）の被覆域 備考
索引 Big5 index-big5.txt 索引 Big5 視覚化 索引 Big5 BMP 被覆域 これは、 香港増補字符集（ Hong Kong Supplementary Character Set ）, および他の共通な拡張と一式で、 Big5 標準に合致する。 This matches the Big5 standard in combination with the Hong Kong Supplementary Character Set and other common extensions.
索引 EUC-KR index-euc-kr.txt 索引 EUC-KR 視覚化 索引 EUC-KR BMP 被覆域 これは、 KS X 1001 標準と統合ハングルコード（ Unified Hangul Code ）に合致する。 Windows Codepage 949 としてもよく知られている。 これ全体で、 Unicode のハングル音節文字（ Hangul Syllables ）ブロックを覆う。 ハングルブロックのうち，視覚化における左上隅がポインタ 9026 にあるもの 【？】 は、 Unicode 順に並ぶ。 Taken separately 【？】, この索引における残りのハングル音節文字も、 Unicode 順に並ぶ。 This matches the KS X 1001 standard and the Unified Hangul Code, more commonly known together as Windows Codepage 949. It covers the Hangul Syllables block of Unicode in its entirety. The Hangul block whose top left corner in the visualization is at pointer 9026 is in the Unicode order. Taken separately, the rest of the Hangul syllables in this index are in the Unicode order, too.
索引 gb18030 index-gb18030.txt 索引 gb18030 視覚化 索引 gb18030 BMP 被覆域 これは、 2 バイトに符号化される符号位置用の GB18030-2022 標準に合致する — ただし，配備済みな内容と互換になるよう、 0xA3 0xA0 は U+3000 へ対応付けられる。 この索引全体で、 Unicode の CJK 統合漢字（ CJK Unified Ideographs ）ブロックを覆う。 そのブロック内のエントリのうち，視覚化における（最初の） U+3000 IDEOGRAPHIC SPACE より上または左にあるものは、 Unicode 順に並ぶ。 This matches the GB18030-2022 standard for code points encoded as two bytes, except for 0xA3 0xA0 which maps to U+3000 IDEOGRAPHIC SPACE to be compatible with deployed content. This index covers the CJK Unified Ideographs block of Unicode in its entirety. Entries from that block that are above or to the left of (the first) U+3000 in the visualization are in the Unicode order.
索引 gb18030 範囲群 index-gb18030-ranges.txt この索引は、 すべての符号位置を挙げていくと項目数が 100 万を超えてしまう点で，他のすべてと異なる （ 207 面の範囲と自明な範囲検査により，きれいに表現できるが）。 したがって、 4 バイトに符号化される符号位置用に限り，表面的には GB18030-2000 標準に合致する。 その改訂 GB18030-2005 用の変更は、 この索引が付随する［ 索引 gb18030 範囲群符号位置, 索引 gb18030 範囲群ポインタ ］用のアルゴリズムにより，インラインに取り扱われる。 その改訂 GB18030-2022 用の変更に関する取り扱いも、 私用領域に属する符号位置へ対応付けられるバイト列の個数をこれ以上増やさないようにするため，他と異なる — 関連する［ 私用領域に属する各符号位置 ］は、 それまでの対応付けとの互換性を保全するよう， gb18030 符号化器において ある表を通して直に対応付けられる。 This index works different from all others. Listing all code points would result in over a million items whereas they can be represented neatly in 207 ranges combined with trivial limit checks. It therefore only superficially matches the GB18030-2000 standard for code points encoded as four bytes. The change for the GB18030-2005 revision is handled inline by the index gb18030 ranges code point and index gb18030 ranges pointer algorithms below that accompany this index. And the changes for the GB18030-2022 revision are handled differently again to not further increase the number of byte sequences mapping to Private Use code points. The relevant Private Use code points are mapped in the gb18030 encoder directly through a side table to preserve compatibility with how they were mapped before.
索引 jis0208 index-jis0208.txt 索引 jis0208 視覚化, 索引 Shift_JIS 視覚化 索引 jis0208 BMP 被覆域 IBM と NEC によるかつてのプロプライエタリ拡張も含まれている， JIS X 0208 標準。 This is the JIS X 0208 standard including formerly proprietary extensions from IBM and NEC.
索引 jis0212 index-jis0212.txt 索引 jis0212 視覚化 索引 jis0212 BMP 被覆域 JIS X 0212 標準。 これを利用するのは、 EUC-JP 復号器に限られる （符号化器からは利用されない） — 広くサポートされていないので。 This is the JIS X 0212 standard. It is only used by the EUC-JP decoder due to lack of widespread support elsewhere.
索引 ISO-2022-JP カタカナ index-iso-2022-jp-katakana.txt

これは、 Unicode 正規化形（ Normalization Form ） KC に従って，半角カタカナを全角カタカナへ対応付ける。 ただし：

  • U+FF9E ( ﾞ ) は、 U+309B ( ゛ ) へ対応付ける — U+3099 ( ゙ ) ではなく 【いずれも，濁点】
  • U+FF9F ( ﾟ ) は、 U+309C ( ゜ ) へ対応付ける — U+309A ( ゚ ) ではなく 【いずれも，半濁点】

これを利用するものは、 ISO-2022-JP 符号化器に限られる。 [UNICODE]

This maps halfwidth to fullwidth katakana as per Unicode Normalization Form KC, except that U+FF9E (ﾞ) and U+FF9F (ﾟ) map to U+309B (゛) and U+309C (゜) rather than U+3099 (◌゙) and U+309A (◌゚). It is only used by the ISO-2022-JP encoder. [UNICODE]

ポインタ が指す 索引 gb18030 範囲群符号位置 は、 次の手続きが返す符号位置である： The index gb18030 ranges code point for pointer is the return value of these steps:

  1. IF［ 39419 < ポインタ < 189000 ］∨［ 1237575 < ポインタ ］ ：RETURN null If pointer is greater than 39419 and less than 189000, or pointer is greater than 1237575, then return null.
  2. IF［ ポインタ ＝ 7457 ］ ：RETURN 符号位置 U+E7C7 If pointer is 7457, then return code point U+E7C7.
  3. オフセット :← 索引 gb18030 範囲群の中で ポインタ を超えない最後のポインタ Let offset be the last pointer in index gb18030 ranges that is less than or equal to pointer and let codePointOffset be its corresponding code point.
  4. 符号位置オフセット :← オフセット が指している符号位置 ↑
  5. RETURN 次を値にとる符号位置 ：符号位置オフセット + ポインタ − オフセット Return a code point whose value is codePointOffset + pointer − offset.

符号位置 を指す 索引 gb18030 範囲群ポインタ は、 次の手続きが返すポインタである： The index gb18030 ranges pointer for codePoint is the return value of these steps:

  1. IF［ 符号位置 ＝ U+E7C7 ］ ：RETURN ポインタ 7457 If codePoint is U+E7C7, then return pointer 7457.
  2. オフセット :← 索引 gb18030 範囲群の中で 符号位置 を超えない最後の符号位置 Let offset be the last code point in index gb18030 ranges that is less than or equal to codePoint and let pointerOffset be its corresponding pointer.
  3. ポインタオフセット :← オフセット に対応するポインタ ↑
  4. RETURN 次を値にとる符号位置 ：ポインタオフセット + 符号位置 − オフセット Return a pointer whose value is pointerOffset + codePoint − offset.

符号位置 を指す 索引 Shift_JIS ポインタ は、 次の手続きが返すポインタである： The index Shift_JIS pointer for codePoint is the return value of these steps:

  1. 索引 :← 索引 jis0208 から［ ポインタが範囲 { 8272 〜 8835 } に入るエントリ ］すべてを除外した索引 Let index be index jis0208 excluding all entries whose pointer is in the range 8272 to 8835, inclusive.

    注記： 索引 jis0208 は、 重複する符号位置を包含するので、 これらのエントリの除外により，後続の符号位置が利用されるようになる。 The index jis0208 contains duplicate code points so the exclusion of these entries causes later code points to be used.

  2. RETURN 索引 の中で 符号位置 を指す索引ポインタ Return the index pointer for codePoint in index.

符号位置 を指す 索引 Big5 ポインタ は、 次の手続きが返すポインタである： The index Big5 pointer for codePoint is the return value of these steps:

  1. 索引 :← 索引 Big5 から［ ポインタが ( (0xA1 − 0x81) × 157 ) 未満のエントリ ］すべてを除外した索引 Let index be index Big5 excluding all entries whose pointer is less than (0xA1 - 0x81) × 157.

    注記： 香港増補字符集（ Hong Kong Supplementary Character Set ）拡張をリテラルとして返さないようにする。 Avoid returning Hong Kong Supplementary Character Set extensions literally.

  2. IF［ 符号位置 ∈ { U+2550 ( ═ ), U+255E ( ╞ ), U+2561 ( ╡ ), U+256A ( ╪ ), U+5341 ( 十 ), U+5345 ( 卅 ) } ］ ：RETURN 索引 の中で 符号位置 に対応する最後の ポインタ If codePoint is U+2550 (═), U+255E (╞), U+2561 (╡), U+256A (╪), U+5341 (十), or U+5345 (卅), then return the last pointer corresponding to codePoint in index.

    注記： 他にも重複している符号位置はあるが、 それら用には，最初の ポインタが利用されることになる。 There are other duplicate code points, but for those the first pointer is to be used.

  3. RETURN 索引 の中で 符号位置 を指す索引ポインタ Return the index pointer for codePoint in index.

注記： すべての索引は、 規範的でないリソース indexes.json としても可用である （索引 gb18030 範囲群の形式は、 範囲を表現できるようにするため，少し異なるものにされている）。 All indexes are also available as a non-normative indexes.json resource. (Index gb18030 ranges has a slightly different format here, to be able to represent ranges.)

6. 他の標準用のフック

注記： 次に挙げる各種アルゴリズム（以下に定義される）は、 他の仕様からの利用が意図されている： The algorithms defined below (UTF-8 decode, UTF-8 decode without BOM, UTF-8 decode without BOM or fail, and UTF-8 encode) are intended for usage by other standards.

各標準は、 UTF-8 符号化する（および，旧来の符号化法を利用して符号化する）アルゴリズムに渡す［ 入力用の入出力キュー† ］が，実質的にはスカラー値が成す入出力キューである — すなわちサロゲートは包含しない — ことを確保すること。 Standards are to ensure that the input I/O queues they pass to UTF-8 encode (as well as the legacy encode) are effectively I/O queues of scalar values, i.e., they contain no surrogates.

これらのフック （および，Unicode に復号する, 符号化法を利用して符号化する）は、［ 入力用の入出力キュー† ］の全体が消費されるまで call 元を阻む。 各出力トークンを，ストリームの中にプッシュされるたびに利用するためには、 call 元は，［ 当のフックを呼び出すときに，空な［ 出力用の入出力キュー†† ］を伴わせて、 そこから並列的に読み取る ］こと。 BOM も失敗もそのままに UTF-8 復号するを利用するときには，少し配慮が必要になることに注意 — 復号している間にエラーが見出された場合、 キュー終端は，［ 出力用の入出力キュー ］の中へプッシュされなくなるので。 【† 各アルゴリズムにおける 入出力キュー 引数／†† 出力 引数】 These hooks (as well as decode and encode) will block until the input I/O queue has been consumed in its entirety. In order to use the output tokens as they are pushed into the stream, callers are to invoke the hooks with an empty output I/O queue and read from it in parallel. Note that some care is needed when using UTF-8 decode without BOM or fail, as any error found during decoding will prevent the end-of-queue item from ever being pushed into the output I/O queue.

UTF-8 復号する アルゴリズムは、 所与の ( 入出力キュー<バイト> 入出力キュー, 入出力キュー<スカラー値> 出力（省略時は « » ）) に対し： To UTF-8 decode an I/O queue of bytes ioQueue given an optional I/O queue of scalar values output (default « »), run these steps:

  1. バッファ :← 入出力キューを覗き見る( 入出力キュー, 3 ) Let buffer be the result of peeking three bytes from ioQueue,＼ ↓converted to a byte sequence.
  2. IF［ ( バッファ[0], バッファ[1], バッファ[2] ) ＝ ( 0xEF, 0xBB, 0xBF ) ］ ：入出力キューからアイテム列を読み取る( 入出力キュー, 3 ) （結果は利用しない。） If buffer is 0xEF 0xBB 0xBF, then read three bytes from ioQueue. (Do nothing with those bytes.)
  3. 復号器 :← UTF-8 の復号器の新たなインスタンス ↓
  4. キューを処理する( 復号器, 入出力キュー, 出力, "replacement" ) Process a queue with an instance of UTF-8’s decoder, ioQueue, output, and "replacement".
  5. RETURN 出力 Return output.

BOM はそのままに UTF-8 復号する アルゴリズムは、 所与の ( 入出力キュー<バイト> 入出力キュー, 入出力キュー<スカラー値> 出力（省略時は « » ）) に対し： To UTF-8 decode without BOM an I/O queue of bytes ioQueue given an optional I/O queue of scalar values output (default « »), run these steps:

  1. 復号器 :← UTF-8 の復号器の新たなインスタンス ↓
  2. キューを処理する( 復号器, 入出力キュー, 出力, "replacement" ) Process a queue with an instance of UTF-8’s decoder, ioQueue, output, and "replacement".
  3. RETURN 出力 Return output.

BOM も失敗もそのままに UTF-8 復号する アルゴリズムは、 所与の ( 入出力キュー<バイト> 入出力キュー, 入出力キュー<スカラー値> 出力（省略時は « » ）) に対し： To UTF-8 decode without BOM or fail an I/O queue of bytes ioQueue given an optional I/O queue of scalar values output (default « »), run these steps:

  1. 復号器 :← UTF-8 の復号器の新たなインスタンス ↓
  2. エラーになり得る :← キューを処理する( 復号器, 入出力キュー, 出力, "fatal" ) Let potentialError be the result of processing a queue with an instance of UTF-8’s decoder, ioQueue, output, and "fatal".
  3. IF［ エラーになり得る ＝ エラー ］ ：RETURN 失敗 If potentialError is an error, then return failure.
  4. RETURN 出力 Return output.

UTF-8 符号化する アルゴリズムは、 所与の ( 入出力キュー<スカラー値> 入出力キュー, 入出力キュー<バイト> 出力（省略時は « » ）) に対し ：RETURN 符号化法を利用して符号化する( 入出力キュー, UTF-8, 出力 ) To UTF-8 encode an I/O queue of scalar values ioQueue given an optional I/O queue of bytes output (default « »), return the result of encoding ioQueue with encoding UTF-8 and output.

6.1. 各標準用の旧来のフック

注記： 各標準は、 互換性を得るために必要な場合を除き，次に挙げるアルゴリズムを利用しないことが強く奨励される ：Unicode に復号する／ BOM を sniff する／ 符号化法を利用して符号化する Standards are strongly discouraged from using decode, BOM sniff, and encode, except as needed for compatibility.＼

これらの旧来のフックを必要としている標準は、 次の利用も必要になると見込まれる ：ラベルから符号化法を取得する（ラベルを符号化法に転換するため）／ 符号化法から出力符号化法を取得する（符号化法を別の符号化法 — 符号化法を利用して符号化するときに渡すそれに相応しいもの — に転換するため） Standards needing these legacy hooks will most likely also need to use get an encoding (to turn a label into an encoding) and get an output encoding (to turn an encoding into another encoding that is suitable to pass into encode).

［ URL %-符号化法の極めて限定的な事例 ］用に，符号化器エラーに対するカスタムな取り扱いが必要になる。 ［ 符号化器を取得する／符号化するか失敗する ］アルゴリズムは、 そのために利用される。 他のアルゴリズムは、 直に利用されないことになる。 For the extremely niche case of URL percent-encoding, custom encoder error handling is needed. The get an encoder and encode or fail algorithms are to be used for that. Other algorithms are not to be used directly.

Unicode に復号する アルゴリズムは、 所与の ( 入出力キュー<バイト> 入出力キュー, フォールバック符号化法 符号化法, 入出力キュー<スカラー値> 出力（省略時は « » ）) に対し： To decode an I/O queue of bytes ioQueue given a fallback encoding encoding and an optional I/O queue of scalar values output (default « »), run these steps:

  1. BOM 符号化法 :← BOM を sniff する( 入出力キュー ) Let BOMEncoding be the result of BOM sniffing ioQueue.

  2. IF［ BOM 符号化法 ≠ null ］： If BOMEncoding is non-null:

    1. 符号化法 ← BOM 符号化法 Set encoding to BOMEncoding.
    2. N :← ［ BOM 符号化法 ＝ UTF-8 ならば 3 ／ 他の場合は 2 ］ ↓
    3. 入出力キューからアイテム列を読み取る( 入出力キュー, N ) （結果は利用しない。） Read three bytes from ioQueue, if BOMEncoding is UTF-8; otherwise read two bytes. (Do nothing with those bytes.)

    注記： 配備済みな内容との互換性を得るため、 BOM は他より優先される。 HTTP が利用される文脈においては、 これは， `Content-Type` ヘッダの意味論に対する違反である。 For compatibility with deployed content, the byte order mark is more authoritative than anything else. In a context where HTTP is used this is in violation of the semantics of the `Content-Type` header.

  3. 復号器 :← 符号化法 の復号器の新たなインスタンス ↓
  4. キューを処理する( 復号器, 入出力キュー, 出力, "replacement" ) Process a queue with an instance of encoding’s decoder, ioQueue, output, and "replacement".
  5. RETURN 出力 Return output.

BOM を sniff する アルゴリズムは、 所与の ( 入出力キュー<バイト> 入出力キュー ) に対し： To BOM sniff an I/O queue of bytes ioQueue, run these steps:

  1. BOM :← 次の結果をバイト列に変換した結果 ：入出力キューを覗き見る( 入出力キュー, 3 ) Let BOM be the result of peeking 3 bytes from ioQueue, converted to a byte sequence.

  2. 下の表内の 各( 行 ) に対し，挙げられた順に ：IF［ BOM は 行 の 1 列目に与えるバイト列から開始している ］ ：RETURN 行 の 2 列目に与える符号化法 For each of the rows in the table below, starting with the first one and going down, if BOM starts with the bytes given in the first column, then return the encoding given in the cell in the second column of that row. Otherwise, return null.

    BOM 符号化法
    0xEF 0xBB 0xBF UTF-8
    0xFE 0xFF UTF-16BE
    0xFF 0xFE UTF-16LE
    Byte order mark｜Encoding 0xEF 0xBB 0xBF｜UTF-8 0xFE 0xFF｜UTF-16BE 0xFF 0xFE｜UTF-16LE
  3. RETURN null ↑

注記： Unicode に復号するアルゴリズムには、［ BOM が見出されたので、 供された符号化法は利用していないこと ］を call 元に通信する仕方が無い。 このフックは、 その事への対処法であり，Unicode に復号する前に呼び出されることになる†。 それは、［ BOM が見出されたなら それに対応する符号化法 ／ 他の場合は null ］を返す。 【†特に，HTML の構文解析アルゴリズムは、入力ストリームを Unicode に復号する前に，符号化法を sniff するアルゴリズムにて これを呼び出す。】 This hook is a workaround for the fact that decode has no way to communicate back to the caller that it has found a byte order mark and is therefore not using the provided encoding. The hook is to be invoked before decode, and it will return an encoding corresponding to the byte order mark found, or null otherwise.

符号化法を利用して符号化する アルゴリズムは、 所与の ( 入出力キュー<スカラー値> 入出力キュー, 符号化法 符号化法, 入出力キュー<バイト> 出力（省略時は « » ） ) に対し： To encode an I/O queue of scalar values ioQueue given an encoding encoding and an optional I/O queue of bytes output (default « »), run these steps:

  1. 符号化器 :← 符号化器を取得する( 符号化法 ) Let encoder be the result of getting an encoder from encoding.
  2. キューを処理する( 符号化器, 入出力キュー, 出力, "html" ) Process a queue with encoder, ioQueue, output, and "html".
  3. RETURN 出力 Return output.

注記： これは、 HTML フォーム用の旧来のフックである。 UTF-8 符号化するを被せた方が、 決して エラー を誘発しないので安全である。 [URL] This is a legacy hook for HTML forms. Layering UTF-8 encode on top is safe as it never triggers errors. [HTML]

符号化器を取得する アルゴリズムは、 所与の ( 符号化法 符号化法 ) に対し： To get an encoder from an encoding encoding:

  1. Assert： 符号化法 ∉ { replacement, UTF-16BE, UTF-16LE } Assert: encoding is not replacement or UTF-16BE/LE.
  2. RETURN 符号化法 の符号化器のインスタンス Return an instance of encoding’s encoder.

符号化するか失敗する アルゴリズムは、 所与の ( 入出力キュー<スカラー値> 入出力キュー, 符号化器のインスタンス 符号化器 , 入出力キュー<バイト> 出力 ) に対し： To encode or fail an I/O queue of scalar values ioQueue given an encoder instance encoder and an I/O queue of bytes output, run these steps:

  1. エラーになり得る :← キューを処理する( 符号化器, 入出力キュー, 出力, "fatal" ) Let potentialError be the result of processing a queue with encoder, ioQueue, output, and "fatal".
  2. 入出力キューにプッシュする( 出力, « キュー終端 » ) Push end-of-queue to output.
  3. IF［ エラーになり得る は エラー である ］ ：RETURN エラー の符号位置の値 If potentialError is an error, then return error’s code point’s value.
  4. RETURN null Return null.

注記： これは、 URL %-符号化法 [URL] 用の旧来のフックである。 call 元は、 符号化器のインスタンスを生きたまま保つ必要がある — ISO-2022-JP 符号化器が エラー を返すときに とり得る状態は、 2 つあるので。 それはまた，call 元が［ エラーを何らかの仕方で符号化するようなバイト列 ］を発する場合、 それらの各バイトは， 範囲 { 0x00 〜 0x7F } に入る, かつ［ 0x0E, 0x0F, 0x1B, 0x5C, 0x7E ］以外にする必要があることを意味する。 This is a legacy hook for URL percent-encoding. The caller will have to keep an encoder instance alive as the ISO-2022-JP encoder can be in two different states when returning an error. That also means that if the caller emits bytes to encode the error in some way, these have to be in the range 0x00 to 0x7F, inclusive, excluding 0x0E, 0x0F, 0x1B, 0x5C, and 0x7E. [URL]

特に，ISO-2022-JP 符号化器が Roman 状態にある下で エラー を返す場合、 call 元は， 0x5C ( \ ) を出力し得ない — それは、 U+005C ( \ ) として復号されなくなるので。 この理由から，符号化するか失敗するを意図されない目的に利用している応用 — U+005C ( \ ) を置換構文【エスケープ法】（例： \u2603 ）の一部として利用している，JavaScript や CSS など — は、 次のいずれかで対処すること ：ISO-2022-JP 符号化器を そのような置換スキームと併用しないよう，配慮する／ 置換構文が，符号化器を必ず通過するようにする（URL %-符号化法とは対照的に） In particular, if upon returning an error the ISO-2022-JP encoder is in the Roman state, the caller cannot output 0x5C (\) as it will not decode as U+005C (\). For this reason, applications using encode or fail for unintended purposes ought to take care to prevent the use of the ISO-2022-JP encoder in combination with replacement schemes, such as those of JavaScript and CSS, that use U+005C (\) as part of the replacement syntax (e.g., \u2603) or make sure to pass the replacement syntax through the encoder (in contrast to URL percent-encoding).

返り値は、［ エラー が生じなければ null ／ 他の場合は 符号化し得ない符号位置を表現している数値 ］になる。 数値が返された場合，call 元は、［ 同じ符号化器のインスタンス, 新たな出力用の入出力キュー ］を給して，再び呼び出す必要があることになる。 The return value is either the number representing the code point that could not be encoded or null, if there was no error. When it returns non-null the caller will have to invoke it again, supplying the same encoder instance and a new output I/O queue.

7. API

この節では Web IDL [WEBIDL] の各種用語を利用する。 ブラウザ UA は、 この API をサポートするものとする。 JavaScript 実装は、 この API をサポートするべきである。 他の UA ／プログラミング言語は、 必要に応じて相応しい API （これではないかもしれない）を利用することが奨励される。 This section uses terminology from Web IDL. Browser user agents must support this API. JavaScript implementations should support this API. Other user agents or programming languages are encouraged to use an API suitable to their needs, which might not be this one. [WEBIDL]

次の例は、 TextEncoder オブジェクトを利用して，文字列の配列を ArrayBuffer に符号化する。 結果は次を内容とする Uint8Array になる： 先頭が（ Uint32Array としての）文字列の個数，その後は： 最初の文字列の（ Uint32Array としての）長さ, UTF-8 に符号化されたその文字列データ，
2 番目の文字列の（ Uint32Array としての）長さ, その文字列データ，
… 等々と続く。 The following example uses the TextEncoder object to encode an array of strings into an ArrayBuffer. The result is a Uint8Array containing the number of strings (as a Uint32Array), followed by the length of the first string (as a Uint32Array), the UTF-8 encoded string data, the length of the second string (as a Uint32Array), the string data, and so on.

function encodeArrayOfStrings(strings) {
  var encoder, encoded, len, bytes, view, offset;

  encoder = new TextEncoder();
  encoded = [];

  len = Uint32Array.BYTES_PER_ELEMENT;
  for (var i = 0; i < strings.length; i++) {
    len += Uint32Array.BYTES_PER_ELEMENT;
    encoded[i] = encoder.encode(strings[i]);
    len += encoded[i].byteLength;
  }

  bytes = new Uint8Array(len);
  view = new DataView(bytes.buffer);
  offset = 0;

  view.setUint32(offset, strings.length);
  offset += Uint32Array.BYTES_PER_ELEMENT;
  for (var i = 0; i < encoded.length; i += 1) {
    len = encoded[i].byteLength;
    view.setUint32(offset, len);
    offset += Uint32Array.BYTES_PER_ELEMENT;
    bytes.set(encoded[i], offset);
    offset += len;
  }
  return bytes.buffer;
}

次の例は、［［ 前の例, または UTF-8 以外の符号化法に等価なアルゴリズム ］により生産される形式に符号化されたデータ ］を含んでいる ArrayBuffer を復号して、 元の，文字列たちが成す配列に戻す。 The following example decodes an ArrayBuffer containing data encoded in the format produced by the previous example, or an equivalent algorithm for encodings other than UTF-8, back into an array of strings.

function decodeArrayOfStrings(buffer, encoding) {
  var decoder, view, offset, num_strings, strings, len;

  decoder = new TextDecoder(encoding);
  view = new DataView(buffer);
  offset = 0;
  strings = [];

  num_strings = view.getUint32(offset);
  offset += Uint32Array.BYTES_PER_ELEMENT;
  for (var i = 0; i < num_strings; i++) {
    len = view.getUint32(offset);
    offset += Uint32Array.BYTES_PER_ELEMENT;
    strings[i] = decoder.decode(
      new DataView(view.buffer, offset, len));
    offset += len;
  }
  return strings;
}

7.1. インタフェース mixin TextDecoderCommon

interface mixin TextDecoderCommon {
  readonly attribute DOMString encoding;
  readonly attribute boolean fatal;
  readonly attribute boolean ignoreBOM;
};

TextDecoderCommon インタフェース mixin は、［ TextDecoder, TextDecoderStream ］オブジェクトで共有される共通な取得子を定義する。 これらの各オブジェクトには、 次に挙げるものが結び付けられる： The TextDecoderCommon interface mixin defines common getters that are shared between TextDecoder and TextDecoderStream objects. These objects have an associated:

  • 符号化法 ：ある符号化法 encoding • An encoding.
  • 復号器 ：ある［ 復号器のインスタンス ］ decoder • A decoder instance.
  • 入出力キュー ：ある入出力キュー<バイト> I/O queue • An I/O queue of bytes.
  • BOM は無視するか ：ある真偽値 — 初期時は false とする。 ignore BOM • A boolean, initially false.
  • BOM を見つけたか ：ある真偽値 — 初期時は false とする。 BOM seen • A boolean, initially false.
  • エラーモード ：あるエラーモード — 初期時は "replacement" とする。 error mode • An error mode, initially "replacement".

入出力キューを直列化する アルゴリズムは、 所与の ( TextDecoderCommon 復号器, 入出力キュー<スカラー値> 入出力キュー ) に対し： The serialize I/O queue algorithm, given a TextDecoderCommon decoder and an I/O queue of scalar values ioQueue, runs these steps:

  1. 出力 :← 空文字列 Let output be the empty string.

  2. WHILE 無条件： While true:

    1. アイテム :← 入出力キューからアイテムを読み取る( 入出力キュー ) Let item be the result of reading from ioQueue.
    2. IF［ アイテム ≠ キュー終端 ］ ：RETURN 出力 If item is end-of-queue, then return output.

    3. IF［ 復号器 の符号化法 ∈ { UTF-8, UTF-16BE, UTF-16LE } ］∧［ 復号器 の BOM は無視するか ＝ false ］∧［ 復号器 の BOM を見つけたか ＝ false ］： If decoder’s encoding is UTF-8 or UTF-16BE/LE, and decoder’s ignore BOM and BOM seen are false:

      1. 復号器 の BOM を見つけたか ← true Set decoder’s BOM seen to true.
      2. IF［ アイテム ＝ U+FEFF BOM ］ ：CONTINUE If item is U+FEFF BOM, then continue.
    4. 出力 に アイテム を付加する Append item to output.

注記： このアルゴリズムは、 API の利用者に もっと制御を与えるため，［ プラットフォームの他所で利用される，Unicode に復号する アルゴリズム ］とは、 BOM の取り扱いに関して意図的に異なるものにされている。 This algorithm is intentionally different with respect to BOM handling from the decode algorithm used by the rest of the platform to give API users more control.

encoding 取得子手続きは ：RETURN ASCII 小文字化する( これ°の符号化法の名前 ) The encoding getter steps are to return this’s encoding’s name, ASCII lowercased.

fatal 取得子手続きは ：RETURN IS［ これ°のエラーモード ＝ "fatal" ］ The fatal getter steps are to return true if this’s error mode is "fatal"; otherwise false.

ignoreBOM 取得子手続きは ：RETURN これ°の BOM は無視するか The ignoreBOM getter steps are to return this’s ignore BOM.

7.2. インタフェース TextDecoder

dictionary TextDecoderOptions {
  boolean fatal = false;
  boolean ignoreBOM = false;
};

dictionary TextDecodeOptions {
  boolean stream = false;
};

[Exposed=*]
interface TextDecoder {
  constructor(optional DOMString label = "utf-8", optional TextDecoderOptions options = {});

  USVString decode(optional AllowSharedBufferSource input, optional TextDecodeOptions options = {});
};

TextDecoder includes TextDecoderCommon;

【 利用中なブラウザでこの特能を試す 】

各 TextDecoder オブジェクトには、 真偽値をとる 書き出さないか が結び付けられ，初期時は false をとるとする。 A TextDecoder object has an associated do not flush, which is a boolean, initially false.

decoder = new TextDecoder([label = "utf-8" [, options]])
新たな TextDecoder オブジェクト を返す。 Returns a new TextDecoder object.
label が次を満たす場合、 RangeError が投出される ：［ ラベルでない ］∨［ replacement 用のラベルである ］ If label is either not a label or is a label for replacement, throws a RangeError.
decoder . encoding
符号化法の名前を小文字化して返す。 Returns encoding’s name, lowercased.
decoder . fatal
エラーモード ＝ "fatal" ならば true を返す。 他の場合は false を返す。 Returns true if error mode is "fatal"; otherwise false.
decoder . ignoreBOM
BOM は無視するかの値を返す。 Returns the value of ignore BOM.
decoder . decode([input [, options]])
input を 符号化法の復号器にかけた結果を返す。 input を断片化して処理するときは、 options の stream メンバを true にした下で，このメソッド 0 回以上呼び出してから， options を省略して（または その stream メンバを false にして） 1 回だけ呼び出すことで行える。 後者の呼び出しに input もないならば、 両引数とも省略するのが最も簡明になる。 Returns the result of running encoding’s decoder. The method can be invoked zero or more times with options’s stream set to true, and then once without options’s stream (or set to false), to process a fragmented input. If the invocation without options’s stream (or set to false) has no input, it’s clearest to omit both arguments.
var string = "", decoder = new TextDecoder(encoding), buffer;
while(buffer = next_chunk()) {
  string += decoder.decode(buffer, {stream:true});
}
string += decoder.decode(); // キュー終端
エラーモード ＝ "fatal" の下で， 符号化法の復号器が エラー を返した場合、 TypeError が投出される。 If the error mode is "fatal" and encoding’s decoder returns error, throws a TypeError.

new TextDecoder(label, options) 構築子手続きは： The new TextDecoder(label, options) constructor steps are:

  1. 符号化法 :← ラベルから符号化法を取得する( label ) Let encoding be the result of getting an encoding from label.
  2. IF［ 符号化法 ∈ { 失敗, replacement } ］ ：THROW RangeError If encoding is failure or replacement, then throw a RangeError.
  3. これ°の 符号化法 ← 符号化法 Set this’s encoding to encoding.
  4. IF［ options[ "fatal" ] ＝ true ］ ：これ°のエラーモード ← "fatal" If options["fatal"] is true, then set this’s error mode to "fatal".
  5. これ°の BOM は無視するか ← options[ "ignoreBOM" ] Set this’s ignore BOM to options["ignoreBOM"].

decode(input, options) メソッド手続きは： The decode(input, options) method steps are:

  1. IF［ これ°の書き出さないか ＝ false ］ ：これ°の復号器 ← これ°の符号化法の復号器の新たなインスタンス； これ°の入出力キュー ← 入出力キュー<バイト> « キュー終端 »； これ°の BOM を見つけたか ← false If this’s do not flush is false, then set this’s decoder to a new instance of this’s encoding’s decoder, this’s I/O queue to the I/O queue of bytes « end-of-queue », and this’s BOM seen to false.
  2. これ°の書き出さないか ← options[ "stream" ] Set this’s do not flush to options["stream"].

  3. IF［ input ≠ ε ］： If input is given,＼

    1. 複製 :← input に保持されたバイト列の複製を取得する ↓
    2. 入出力キューにプッシュする( これ°の入出力キュー, 複製 ) then push a copy of input to this’s I/O queue.

    注記： 実装には、 この複製を避けるよう実装することが強く奨励される。 そうするときは、 input が変更されても，後の decode() の call に影響しないようにする必要がある。 Implementations are strongly encouraged to use an implementation strategy that avoids this copy. When doing so they will have to make sure that changes to input do not affect future calls to decode().

    SharedArrayBuffer オブジェクトにより公開されるメモリーは、［ 実装用に概して利用されるプログラミング言語 ］のメモリーモデルに要求される data race freedom な特質を固守しない。 実装するときは、 SharedArrayBuffer オブジェクトが公開するメモリーにアクセスするときに適切な便宜性†を利用するよう配慮すること。 【†そのようなアクセスに その種の特質が備わるよう指示する，言語特有な構文など】 The memory exposed by SharedArrayBuffer objects does not adhere to data race freedom properties required by the memory model of programming languages typically used for implementations. When implementing, take care to use the appropriate facilities when accessing memory exposed by SharedArrayBuffer objects.

  4. 出力 :← 入出力キュー<スカラー値> « キュー終端 » Let output be the I/O queue of scalar values « end-of-queue ».

  5. WHILE 無条件： While true:

    1. アイテム :← 入出力キューからアイテムを読み取る( これ°の入出力キュー ) Let item be the result of reading from this’s I/O queue.

    2. IF［ アイテム ＝ キュー終端 ］∧［ これ°の書き出さないか ＝ true ］ ：RETURN 入出力キューを直列化する( これ°, 出力 ) If item is end-of-queue and this’s do not flush is true, then return the result of running serialize I/O queue with this and output.

      注記： ストリーム処理では、［ これ°の書き出さないか ＝ true ］のとき，ここでキュー終端を取り扱うことなく，それを false にしない仕方で働く。 この仕方により，これ°の復号器は、 後続の呼び出しにおいて，このアルゴリズムの最初の段で一新されることなく，その状態は保全される。 The way streaming works is to not handle end-of-queue here when this’s do not flush is true and to not set it to false. That way in a subsequent invocation this’s decoder is not set anew in the first step of the algorithm and its state is preserved.

    3. 結果 :← アイテムを処理する( アイテム, これ°の復号器, これ°の入出力キュー, 出力, これ°のエラーモード ) Otherwise:Let result be the result of processing an item with item, this’s decoder, this’s I/O queue, output, and this’s error mode.
    4. IF［ 結果 ＝ 完遂 ］ ：RETURN 入出力キューを直列化する( これ°, 出力 ) If result is finished, then return the result of running serialize I/O queue with this and output.
    5. IF［ 結果 ＝ エラー ］ ：THROW TypeError Otherwise, if result is error, throw a TypeError.

7.3. インタフェース mixin TextEncoderCommon

interface mixin TextEncoderCommon {
  readonly attribute DOMString encoding;
};

TextEncoderCommon インタフェース mixin は、［ TextEncoder, TextEncoderStream ］オブジェクトで共有される共通な取得子を定義する。 The TextEncoderCommon interface mixin defines common getters that are shared between TextEncoder and TextEncoderStream objects.

encoding 取得子手続きは ：RETURN "utf-8" The encoding getter steps are to return "utf-8".

7.4. インタフェース TextEncoder

dictionary TextEncoderEncodeIntoResult {
  unsigned long long read;
  unsigned long long written;
};

[Exposed=*]
interface TextEncoder {
  constructor();

  [NewObject] Uint8Array encode(optional USVString input = "");
  TextEncoderEncodeIntoResult encodeInto(USVString source, [AllowShared] Uint8Array destination);
};
TextEncoder includes TextEncoderCommon;

注記： TextEncoder オブジェクトは、 UTF-8 しかサポートしないので，構築子に label 引数は無い。 また、 スカラー値バッファを要求する符号化器は無いので， stream オプションもない。 A TextEncoder object offers no label argument as it only supports UTF-8. It also offers no stream option as no encoder requires buffering of scalar values.

encoder = new TextEncoder()
新たな TextEncoder オブジェクト を返す。 Returns a new TextEncoder object.
encoder . encoding
"utf-8" を返す。 Returns "utf-8".
encoder . encode([input = ""])
input を UTF-8 の符号化器にかけた結果を返す。 Returns the result of running UTF-8’s encoder.
encoder . encodeInto(source, destination)
source を渡して UTF-8 符号化器を走らせた結果を destination の中に格納して，その進捗をオブジェクトとして返す — 結果の ：read は source から変換された符号単位数になる ／ written は destination 内で改変されたバイト数になる Runs the UTF-8 encoder on source, stores the result of that operation into destination, and returns the progress made as an object wherein read is the number of converted code units of source and written is the number of bytes modified in destination.

new TextEncoder() 構築子手続きは、 何もしない。 The new TextEncoder() constructor steps are to do nothing.

encode(input) メソッド手続きは： The encode(input) method steps are:

  1. 入力 :← 入出力キューに変換する( input ) Convert input to an I/O queue of scalar values.
  2. 出力 :← 入出力キュー<バイト> « キュー終端 » Let output be the I/O queue of bytes « end-of-queue ».
  3. 符号化器 :← UTF-8 の符号化器の新たなインスタンス ↓

  4. WHILE 無条件： While true:

    1. アイテム :← 入出力キューからアイテムを読み取る( 入力 ) Let item be the result of reading from input.
    2. 結果 :← アイテムを処理する( アイテム, 符号化器, 入力, 出力, "fatal" ) Let result be the result of processing an item with item, an instance of the UTF-8 encoder, input, output, and "fatal".

    3. Assert： 結果 は エラー でない Assert: result is not an error.

      注記： UTF-8 符号化器が エラー を返すことはない。 The UTF-8 encoder cannot return error.

    4. IF［ 結果 ＝ 完遂 ］：

      1. 出力 ← 出力 をバイト列に変換する
      2. RETURN バッファソースを作成する( Uint8Array, 出力, これ°に関連する realm )
      If result is finished, then return the result of creating a Uint8Array object given output and this’s relevant realm.

encodeInto(source, destination) メソッド手続きは： The encodeInto(source, destination) method steps are:

  1. read :← 0 Let read be 0.
  2. written :← 0 Let written be 0.
  3. 符号化器 :← UTF-8 符号化器の新たなインスタンス Let encoder be an instance of the UTF-8 encoder.

  4. 利用されないキュー :← 入出力キュー<スカラー値> « キュー終端 » Let unused be the I/O queue of scalar values « end-of-queue ».

    注記： 以下で呼び出されるハンドラアルゴリズムには，この引数が要求されるが、 UTF-8 符号化器は，それを利用しない。 The handler algorithm invoked below requires this argument, but it is not used by the UTF-8 encoder.

  5. source ← 入出力キューに変換する( source ) Convert source to an I/O queue of scalar values.

  6. WHILE 無条件： While true:

    1. アイテム :← 入出力キューからアイテムを読み取る( source ) Let item be the result of reading from source.
    2. 結果 :← 符号化器 のハンドラ( 利用されないキュー, アイテム ) Let result be the result of running encoder’s handler on unused and item.
    3. IF［ 結果 ＝ 完遂 ］ ：BREAK If result is finished, then break.Otherwise:
    4. IF［ written + 結果 を成すバイト数 > destination のバイト長さ ］ ：BREAK If destination’s byte length − written is greater than or equal to the number of bytes in result:
    5. read += ［ アイテム ≤ U+FFFF ならば 1 ／ 他の場合は 2 ］ • If item is greater than U+FFFF, then increment read by 2. • Otherwise, increment read by 1.

    6. 配列バッファビューの中へバイト列を書き込む( destination, 結果, written ) • Write the bytes in result into destination, with startingOffset set to written.

      上述した SharedArrayBuffer オブジェクト用の警告を見よ。 See the warning for SharedArrayBuffer objects above.

    7. written += 結果 を成すバイト数 • Increment written by the number of bytes in result.Otherwise, break.
  7. RETURN « read → read, written → written » Return «[ "read" → read, "written" → written ]».

encodeInto() メソッドを利用すれば、 文字列を既存の ArrayBuffer オブジェクトの中へ符号化できる。 下における様々な詳細は，読者への宿題として残しておくが、 この例は，このメソッドの用法の一つをデモる： The encodeInto() method can be used to encode a string into an existing ArrayBuffer object. Various details below are left as an exercise for the reader, but this demonstrates an approach one could take to use this method:

function convertString(buffer, input, callback) {
  let bufferSize = 256,
      bufferStart = malloc(buffer, bufferSize),
      writeOffset = 0,
      readOffset = 0;
  while (true) {
    const view = new Uint8Array(buffer, bufferStart + writeOffset, bufferSize - writeOffset),
          {read, written} = cachedEncoder.encodeInto(input.substring(readOffset), view);
    readOffset += read;
    writeOffset += written;
    if (readOffset === input.length) {
      callback(bufferStart, writeOffset);
      free(buffer, bufferStart);
      return;
    }
    bufferSize *= 2;
    bufferStart = realloc(buffer, bufferStart, bufferSize);
  }
}

7.5. インタフェース TextDecoderStream

[Exposed=*]
interface TextDecoderStream {
  constructor(optional DOMString label = "utf-8", optional TextDecoderOptions options = {});
};
TextDecoderStream includes TextDecoderCommon;
TextDecoderStream includes GenericTransformStream;
decoder = new TextDecoderStream([label = "utf-8" [, options]])
新たな TextDecoderStream オブジェクトを返す。 Returns a new TextDecoderStream object.
label が次を満たす場合、 RangeError が投出される ：［ ラベルでない ］∨［ replacement 用のラベルである ］ If label is either not a label or is a label for replacement, throws a RangeError.
decoder . encoding
符号化法の名前を小文字化して返す。 Returns encoding’s name, lowercased.
decoder . fatal
エラーモード ＝ "fatal" ならば true を返す。 他の場合は false を返す。 Returns true if error mode is "fatal", and false otherwise.
decoder . ignoreBOM
BOM は無視するかの値を返す。 Returns the value of ignore BOM.
decoder . readable
可読ストリームを返す。 そのチャンクたちは、 writable に書き込まれたチャンクたちに対し，符号化法の復号器を走らせた結果の文字列たちになる。 Returns a readable stream whose chunks are strings resulting from running encoding’s decoder on the chunks written to writable.
decoder . writable
可書ストリームを返す。 それは、 AllowSharedBufferSource 型のチャンクたちを受容して — readable に可用にされる前に — 符号化法の復号器にかける。 Returns a writable stream which accepts AllowSharedBufferSource chunks and runs them through encoding’s decoder before making them available to readable.

これは概して、 ReadableStream ソースの pipeThrough メソッドを介して利用されることになる。 Typically this will be used via the pipeThrough() method on a ReadableStream source.

var decoder = new TextDecoderStream(encoding);
byteReadable
  .pipeThrough(decoder)
  .pipeTo(textWritable);
エラーモード ＝ "fatal" かつ符号化法の復号器は エラー を返す場合、 readable, writable とも TypeError でエラーにされることになる。 If the error mode is "fatal" and encoding’s decoder returns error, both readable and writable will be errored with a TypeError.

new TextDecoderStream(label, options) 構築子手続きは： The new TextDecoderStream(label, options) constructor steps are:

  1. 符号化法 :← ラベルから符号化法を取得する( label ) Let encoding be the result of getting an encoding from label.
  2. IF［ 符号化法 ∈ { 失敗, replacement } ］ ：THROW RangeError If encoding is failure or replacement, then throw a RangeError.
  3. これ°の符号化法 ← 符号化法 Set this’s encoding to encoding.
  4. IF［ options[ "fatal" ] ＝ true ］ ：これ°のエラーモード ← "fatal" If options["fatal"] is true, then set this’s error mode to "fatal".
  5. これ°の BOM は無視するか ← options[ "ignoreBOM" ] Set this’s ignore BOM to options["ignoreBOM"].
  6. これ°の復号器 ← これ°の符号化法の復号器の新たなインスタンス Set this’s decoder to a new instance of this’s encoding’s decoder,＼
  7. これ°の入出力キュー ← 新たな入出力キュー<バイト> and set this’s I/O queue to a new I/O queue.
  8. 形式変換ストリーム ← 新たなオブジェクト( TransformStream, これ°に関連する realm ) ↓

  9. 形式変換ストリーム を設定しておく — 次を与える下で：

    Let transformAlgorithm be an algorithm which takes a chunk argument and runs the decode and enqueue a chunk algorithm with this and chunk.Let flushAlgorithm be an algorithm which takes no arguments and runs the flush and enqueue algorithm with this.Let transformStream be a new TransformStream.Set up transformStream with transformAlgorithm set to transformAlgorithm and flushAlgorithm set to flushAlgorithm.
  10. これ°の形式変換 ← 形式変換ストリーム Set this’s transform to transformStream.

チャンクを復号してエンキューする アルゴリズムは、 所与の ( TextDecoderStream オブジェクト 復号器, チャンク ) に対し： The decode and enqueue a chunk algorithm, given a TextDecoderStream object decoder and a chunk, runs these steps:

  1. バッファソース :← IDL 値に変換する( チャンク, AllowSharedBufferSource ) Let bufferSource be the result of converting chunk to an AllowSharedBufferSource.

  2. 入出力キューにプッシュする( 復号器 の入出力キュー, 次の結果 ) ：バッファソース に保持されたバイト列の複製を取得する Push a copy of bufferSource to decoder’s I/O queue.

    上述した SharedArrayBuffer オブジェクト用の警告を見よ。 See the warning for SharedArrayBuffer objects above.

  3. 出力 :← 入出力キュー<スカラー値> « キュー終端 » Let output be the I/O queue of scalar values « end-of-queue ».

  4. WHILE 無条件： While true:

    1. アイテム :← 入出力キューからアイテムを読み取る( 復号器 の入出力キュー ) Let item be the result of reading from decoder’s I/O queue.

    2. IF［ アイテム ＝ キュー終端 ］： If item is end-of-queue:

      1. 出力チャンク :← 入出力キューを直列化する( これ°, 出力 ) Let outputChunk be the result of running serialize I/O queue with decoder and output.
      2. IF［ 出力チャンク ≠ 空文字列 ］ ：復号器 の形式変換にチャンクをエンキューする( 出力チャンク ) If outputChunk is not the empty string, then enqueue outputChunk in decoder’s transform.
      3. RETURN Return.
    3. 結果 :← アイテムを処理する( アイテム, 復号器 の復号器, 復号器 の入出力キュー, 出力, 復号器 のエラーモード ) Let result be the result of processing an item with item, decoder’s decoder, decoder’s I/O queue, output, and decoder’s error mode.
    4. IF［ 結果 ＝ エラー ］ ：THROW TypeError If result is error, then throw a TypeError.

書き出してエンキューする アルゴリズムは、 入力 ReadableStream オブジェクトからのデータの終端を取り扱う — それは、 所与の ( TextDecoderStream オブジェクト 復号器 ) に対し： The flush and enqueue algorithm, which handles the end of data from the input ReadableStream object, given a TextDecoderStream object decoder, runs these steps:

  1. 出力 :← 入出力キュー<スカラー値> « キュー終端 » Let output be the I/O queue of scalar values « end-of-queue ».

  2. WHILE 無条件： While true:

    1. アイテム :← 入出力キューからアイテムを読み取る( 復号器 の入出力キュー ) Let item be the result of reading from decoder’s I/O queue.
    2. 結果 :← アイテムを処理する( アイテム, 復号器 の復号器, 復号器 の入出力キュー, 出力, 復号器 のエラーモード ) Let result be the result of processing an item with item, decoder’s decoder, decoder’s I/O queue, output, and decoder’s error mode.

    3. IF［ 結果 ＝ 完遂 ］： If result is finished:

      1. 出力チャンク :← 入出力キューを直列化する( これ°, 出力 ) Let outputChunk be the result of running serialize I/O queue with decoder and output.
      2. IF［ 出力チャンク ≠ 空文字列 ］ ：復号器 の形式変換にチャンクをエンキューする( 出力チャンク ) If outputChunk is not the empty string, then enqueue outputChunk in decoder’s transform.
      3. RETURN Return.
    4. ELSE IF［ 結果 ＝ エラー ］ ：THROW TypeError Otherwise, if result is error, throw a TypeError.

7.6. インタフェース TextEncoderStream

[Exposed=*]
interface TextEncoderStream {
  constructor();
};

TextEncoderStream includes TextEncoderCommon;
TextEncoderStream includes GenericTransformStream;

各 TextEncoderStream オブジェクトには、 次に挙げるものが結び付けられる： A TextEncoderStream object has an associated:

  • 符号化器 ：ある［ 符号化器のインスタンス ］

    【 下に注記されるとおり， UTF-8 のそれしかとらない。 また、 復号器のときと違って，状態を保持するフィールドは無い。 】

    encoder • An encoder instance.
  • 頭部サロゲート ： null ／頭部サロゲート — 初期時は null とする。 leading surrogate • Null or a leading surrogate, initially null.

注記： TextEncoderStream オブジェクトは UTF-8 しかサポートしないので、 ラベル 引数を提供しない。 A TextEncoderStream object offers no label argument as it only supports UTF-8.

encoder = new TextEncoderStream()
新たな TextEncoderStream オブジェクトを返す。 Returns a new TextEncoderStream object.
encoder . encoding
"utf-8" を返す。 Returns "utf-8".
encoder . readable
可読ストリームを返す。 その各チャンクは、 writable に書き込まれたチャンクたちに対し UTF-8 の符号化器を走らせた結果の Uint8Array になる。 Returns a readable stream whose chunks are Uint8Arrays resulting from running UTF-8’s encoder on the chunks written to writable.
encoder . writable
可書ストリームを返す。 それは、 文字列チャンクたちを受容して — readable に可用にされる前に — UTF-8 の符号化器にかける。 Returns a writable stream which accepts string chunks and runs them through UTF-8’s encoder before making them available to readable.

これは概して、 ReadableStream ソースの pipeThrough メソッドを介して利用されることになる。 Typically this will be used via the pipeThrough() method on a ReadableStream source.

textReadable
  .pipeThrough(new TextEncoderStream())
  .pipeTo(byteWritable);

new TextEncoderStream() 構築子手続きは： The new TextEncoderStream() constructor steps are:

  1. これ°の符号化器 ← UTF-8 の符号化器の新たなインスタンス Set this’s encoder to an instance of the UTF-8 encoder.
  2. 形式変換ストリーム ← 新たなオブジェクト( TransformStream, これ°に関連する realm ) ↓

  3. 形式変換ストリーム を設定しておく — 次を与える下で：

    Let transformAlgorithm be an algorithm which takes a chunk argument and runs the encode and enqueue a chunk algorithm with this and chunk.Let flushAlgorithm be an algorithm which runs the encode and flush algorithm with this.Let transformStream be a new TransformStream.Set up transformStream with transformAlgorithm set to transformAlgorithm and flushAlgorithm set to flushAlgorithm.
  4. これ°の形式変換 ← 形式変換ストリーム Set this’s transform to transformStream.

チャンクを符号化してエンキューする アルゴリズムは、 所与の ( TextEncoderStream オブジェクト 符号化器, チャンク ) に対し： The encode and enqueue a chunk algorithm, given a TextEncoderStream object encoder and chunk, runs these steps:

  1. 入力 :← IDL 値に変換する( チャンク, DOMString ) Let input be the result of converting chunk to a DOMString.

  2. 入力 ← 入出力キューに変換する( 入力 ) Convert input to an I/O queue of code units.

    注記： DOMString 型から変換しているので、 結果の入出力キューのアイテム型は，スカラー値ではなく符号単位になる。 そのようにしているのは、［ 2 つのチャンクに分割されたサロゲートペアを，適切なスカラー値に組み立て直せるようにする ］ためであり，他のふるまいは USVString と一致する。 特に，孤立したサロゲートは U+FFFD ( � ) に置換されることになる。 DOMString, as well as an I/O queue of code units rather than scalar values, are used here so that a surrogate pair that is split between chunks can be reassembled into the appropriate scalar value. The behavior is otherwise identical to USVString. In particular, lone surrogates will be replaced with U+FFFD (�).

  3. 出力 :← 入出力キュー<バイト> « キュー終端 » Let output be the I/O queue of bytes « end-of-queue ».

  4. WHILE 無条件： While true:

    1. アイテム :← 入出力キューからアイテムを読み取る( 入力 ) Let item be the result of reading from input.

    2. IF［ アイテム ＝ キュー終端 ］： If item is end-of-queue:

      1. 出力 ← 出力 をバイト列に変換する Convert output into a byte sequence.

      2. IF［ 出力 は空でない ］： If output is not empty:

        1. チャンク :← バッファソースを作成する( Uint8Array, 出力, 符号化器 に関連する realm ) Let chunk be the result of creating a Uint8Array object given output and encoder’s relevant realm.
        2. 符号化器 の形式変換にチャンクをエンキューする( チャンク ) Enqueue chunk into encoder’s transform.
      3. RETURN Return.
    3. 結果 :← 符号単位をスカラー値に変換する( 符号化器, アイテム, 入力 ) Let result be the result of executing the convert code unit to scalar value algorithm with encoder, item and input.
    4. IF［ 結果 ≠ 継続 ］ ：アイテムを処理する( 結果, 符号化器 の符号化器, 入力, 出力, "fatal" ) If result is not continue, then process an item with result, encoder’s encoder, input, output, and "fatal".

符号単位をスカラー値に変換する アルゴリズムは、 所与の ( TextEncoderStream オブジェクト 符号化器, 符号単位 アイテム, 入出力キュー<符号単位> 入力 ) に対し： The convert code unit to scalar value algorithm, given a TextEncoderStream object encoder, a code unit item, and an I/O queue of code units input, runs these steps:

  1. IF［ 符号化器 の頭部サロゲート ≠ null ］： If encoder’s leading surrogate is non-null:

    1. 頭部サロゲート :← 符号化器 の頭部サロゲート Let leadingSurrogate be encoder’s leading surrogate.
    2. 符号化器 の頭部サロゲート ← null Set encoder’s leading surrogate to null.
    3. IF［ アイテム は尾部サロゲートである ］ ：RETURN サロゲート対からスカラー値を得る( 頭部サロゲート, アイテム ) If item is a trailing surrogate, then return a scalar value from surrogates given leadingSurrogate and item.
    4. 入出力キューに格納し直す( 入力, アイテム ) Restore item to input.
    5. RETURN U+FFFD ( � ) Return U+FFFD (�).
  2. IF［ アイテム は頭部サロゲートである ］ ：符号化器 の頭部サロゲート ← アイテム； RETURN 継続 If item is a leading surrogate, then set encoder’s leading surrogate to item and return continue.
  3. IF［ アイテム は尾部サロゲートである ］ ：RETURN U+FFFD ( � ) If item is a trailing surrogate, then return U+FFFD (�).
  4. RETURN アイテム Return item.

注記： これは， [INFRA] による［ 文字列をスカラー値文字列に変換するアルゴリズム ］と等価になるが、 2 つの文字列に分割されたサロゲートペアも許容する。 [INFRA] This is equivalent to the "convert a string into a scalar value string" algorithm from the Infra Standard, but allows for surrogate pairs that are split between strings. [INFRA]

符号化して書き出す アルゴリズムは、 所与の ( TextEncoderStream オブジェクト 符号化器 ) に対し： The encode and flush algorithm, given a TextEncoderStream object encoder, runs these steps:

  1. IF［ 符号化器 の頭部サロゲート ≠ null ］： If encoder’s leading surrogate is non-null:

    1. バイト列 :← バイト列 0xEF 0xBF 0xBD

      注記： これは、 U+FFFD ( � ) を成す UTF-8 バイト列である。

      ↓

    2. チャンク :← バッファソースを作成する( Uint8Array, バイト列, 符号化器 に関連する realm ) Let chunk be the result of creating a Uint8Array object given « 0xEF, 0xBF, 0xBD » and encoder’s relevant realm.This is U+FFFD (�) in UTF-8 bytes.

    3. 符号化器 の形式変換にチャンクをエンキューする( チャンク ) Enqueue chunk into encoder’s transform.

8. 標準の符号化法

【 この “標準の” は “The” の対訳であり、 およそ， “規範とされるべき唯一無二の” を意味する。 】

8.1. UTF-8

8.1.1. UTF-8 復号器

注記： BOM は、 ラベルより優先される — その方が配備済みな内容において正確になるものと見出されたので。 したがって，それは、 UTF-8 復号器アルゴリズムの一部を成さない — 代わりに［ Unicode に復号する／UTF-8 復号する ］アルゴリズムの一部を成す。 A byte order mark has priority over a label as it has been found to be more accurate in deployed content. Therefore it is not part of the UTF-8 decoder algorithm, but rather the decode and UTF-8 decode algorithms.

各［ UTF-8 の復号器 ］には、 次に挙げるものが結び付けられる： UTF-8’s decoder has an associated:

  • UTF-8 符号位置 ：ある無符号整数 — 初期時は 0 とする。 UTF-8 code point • ↓
  • UTF-8 出現バイト数 ：ある無符号整数 — 初期時は 0 とする。 UTF-8 bytes seen • ↓
  • UTF-8 要バイト数 ：ある無符号整数 — 初期時は 0 とする。 UTF-8 bytes needed • Each a number, initially 0.
  • UTF-8 下限 ：あるバイト — 初期時は 0x80 とする。 UTF-8 lower boundary • A byte, initially 0x80.
  • UTF-8 上限 ：あるバイト — 初期時は 0xBF とする。 UTF-8 upper boundary • A byte, initially 0xBF.

UTF-8 の復号器のハンドラは、 所与の ( 入出力キュー, バイト ) に対し： UTF-8’s decoder’s handler, given ioQueue and byte, runs these steps:

  1. IF［ バイト ＝ キュー終端 ］∧［ UTF-8 要バイト数 ≠ 0 ］ ：UTF-8 要バイト数 ← 0； RETURN エラー If byte is end-of-queue and UTF-8 bytes needed is not 0, then set UTF-8 bytes needed to 0 and return error.
  2. IF［ バイト ＝ キュー終端 ］ ：RETURN 完遂 If byte is end-of-queue, then return finished.

  3. IF［ UTF-8 要バイト数 ＝ 0 ］： If UTF-8 bytes needed is 0,＼

    1. バイト に応じて： based on byte:

      • 0x00 〜 0x7F ：RETURN 符号位置 « バイト » 0x00 to 0x7F • Return a code point whose value is byte.

      • 0xC2 〜 0xDF： 0xC2 to 0xDF

        1. UTF-8 要バイト数 ← 1 Set UTF-8 bytes needed to 1.
        2. UTF-8 符号位置 ← バイト & 0x1F （ バイト の下位 5 ビット ） Set UTF-8 code point to byte & 0x1F.The five least significant bits of byte.

      • 0xE0 〜 0xEF： 0xE0 to 0xEF

        1. IF［ バイト ＝ 0xE0 ］ ：UTF-8 下限 ← 0xA0 If byte is 0xE0, then set UTF-8 lower boundary to 0xA0.
        2. IF［ バイト ＝ 0xED ］ ：UTF-8 上限 ← 0x9F If byte is 0xED, then set UTF-8 upper boundary to 0x9F.
        3. UTF-8 要バイト数 ← 2 Set UTF-8 bytes needed to 2.
        4. UTF-8 符号位置 ← バイト & 0xF （ バイト の下位 4 ビット ） Set UTF-8 code point to byte & 0xF.The four least significant bits of byte.

      • 0xF0 〜 0xF4： 0xF0 to 0xF4

        1. IF［ バイト ＝ 0xF0 ］ ：UTF-8 下限 ← 0x90 If byte is 0xF0, then set UTF-8 lower boundary to 0x90.
        2. IF［ バイト ＝ 0xF4 ］ ：UTF-8 上限 ← 0x8F If byte is 0xF4, then set UTF-8 upper boundary to 0x8F.
        3. UTF-8 要バイト数 ← 3 Set UTF-8 bytes needed to 3.
        4. UTF-8 符号位置 ← バイト & 0x7 （ バイト の下位 3 ビット ） Set UTF-8 code point to byte & 0x7.The three least significant bits of byte.
      • その他 ：RETURN エラー Otherwise • Return error.
    2. RETURN 継続 Return continue.

  4. IF［ バイト ∉ { UTF-8 下限 〜 UTF-8 上限 } ］： If byte is not in the range UTF-8 lower boundary to UTF-8 upper boundary, inclusive:

    1. ( UTF-8 符号位置, UTF-8 要バイト数, UTF-8 出現バイト数 ) ← ( 0, 0, 0 ) Set UTF-8 code point, UTF-8 bytes needed, and UTF-8 bytes seen to 0,＼
    2. ( UTF-8 下限, UTF-8 上限 ) ← ( 0x80, 0xBF ) set UTF-8 lower boundary to 0x80, and set UTF-8 upper boundary to 0xBF.
    3. 入出力キューに格納し直す( 入出力キュー, バイト ) Restore byte to ioQueue.
    4. RETURN エラー Return error.
  5. ( UTF-8 下限, UTF-8 上限 ) ← ( 0x80, 0xBF ) Set UTF-8 lower boundary to 0x80 and UTF-8 upper boundary to 0xBF.

  6. UTF-8 符号位置 ← (UTF-8 符号位置 << 6) | (バイト & 0x3F) Set UTF-8 code point to (UTF-8 code point << 6) | (byte & 0x3F)

    注記： UTF-8 符号位置内の既存のビットを左へ 6 ビット シフトして，空いた下位 6 ビットに バイト の下位 6 ビットをあてがう。 Shift the existing bits of UTF-8 code point left by six places and set the newly-vacated six least significant bits to the six least significant bits of byte.

  7. UTF-8 出現バイト数 += 1 Increase UTF-8 bytes seen by one.
  8. IF［ UTF-8 出現バイト数 ≠ UTF-8 要バイト数 ］ ：RETURN 継続 If UTF-8 bytes seen is not equal to UTF-8 bytes needed, then return continue.
  9. 符号位置 :← UTF-8 符号位置 Let codePoint be UTF-8 code point.
  10. ( UTF-8 符号位置, UTF-8 要バイト数, UTF-8 出現バイト数 ) ← ( 0, 0, 0 ) Set UTF-8 code point, UTF-8 bytes needed, and UTF-8 bytes seen to 0.
  11. RETURN 符号位置 « 符号位置 » Return a code point whose value is codePoint.

注記： UTF-8 復号器における上の拘束は、 Unicode 標準の “Best Practices for Using U+FFFD” に準じる。 他のふるまいは、 Encoding 標準の下では許可されない （同じ結果を達成するなら、 他のアルゴリズムでも十分であり，むしろ奨励される）。 [UNICODE] The constraints in the UTF-8 decoder above match “Best Practices for Using U+FFFD” from the Unicode standard. No other behavior is permitted per the Encoding Standard (other algorithms that achieve the same result are fine, even encouraged). [UNICODE]

8.1.2. UTF-8 符号化器

UTF-8 の符号化器のハンドラは、 所与の ( 利用されないキュー, 符号位置 ) に対し： UTF-8’s encoder’s handler, given unused and codePoint, runs these steps:

  1. IF［ 符号位置 ＝ キュー終端 ］ ：RETURN 完遂 If codePoint is end-of-queue, then return finished.
  2. IF［ 符号位置 ∈ ASCII 符号位置 ］ ：RETURN バイト « 符号位置 » If codePoint is an ASCII code point, then return a byte whose value is codePoint.

  3. ( count, オフセット ) ← 符号位置 が属する範囲に応じて ：{ U+0080 〜 U+07FF } ならば ( 1, 0xC0 ) ／ { U+0800 〜 U+FFFF } ならば ( 2, 0xE0 ) ／ { U+10000 〜 U+10FFFF } ならば ( 3, 0xF0 ) Set count and offset based on the range codePoint is in:U+0080 to U+07FF, inclusive • 1 and 0xC0 U+0800 to U+FFFF, inclusive • 2 and 0xE0 U+10000 to U+10FFFF, inclusive • 3 and 0xF0

  4. バイト列 :← バイト « ( 符号位置 >> ( 6 × count ) ) + オフセット » Let bytes be a byte sequence whose first byte is (codePoint >> (6 × count)) + offset.

  5. WHILE［ count > 0 ］： While count is greater than 0:

    1. temp ← 符号位置 >> ( 6 × ( count − 1 ) ) Set temp to codePoint >> (6 × (count − 1)).
    2. バイト列 に ( 0x80 | ( temp & 0x3F ) ) を付加する Append to bytes 0x80 | (temp & 0x3F).
    3. count −= 1 Decrease count by one.
  6. RETURN バイト列 Return bytes bytes, in order.

注記： このアルゴリズムは、 Unicode 標準に述べられるものと一致する結果を得るが，完全さのためここに含められている。 [UNICODE] This algorithm has identical results to the one described in the Unicode standard. It is included here for completeness. [UNICODE]

9. 旧来の単バイト符号化法

符号化法のうち［ 各バイトが， 1 個の符号位置に対応するか, どの符号位置にも対応しないもの ］は、 単バイト符号化法 と総称される。 すべての単バイト符号化法が、 同じ［ 復号器, 符号化器 ］を共有する。 単バイト復号器／単バイト符号化器から参照される 単バイト索引 は、 利用中にある単バイト符号化法に依存し，次の表で定義される。 ［ ISO-8859-8, ISO-8859-8-I ］を除くすべての単バイト符号化法は、 それぞれに一意な索引を持つ。 An encoding where each byte is either a single code point or nothing, is a single-byte encoding. Single-byte encodings share the decoder and encoder. Index single-byte, as referenced by the single-byte decoder and single-byte encoder, is defined by the following table, and depends on the single-byte encoding in use. All but two single-byte encodings have a unique index.

【 被覆域のテーブルは巨大なことに注意。 】【 視覚化テーブルの各 cell の色については、 凡例を見よ。 】

名前 索引 視覚化 基本多言語面（ BMP ）の被覆域
IBM866 index-ibm866.txt 索引 IBM866 視覚化 索引 IBM866 BMP 被覆域
ISO-8859-2 index-iso-8859-2.txt 索引 ISO-8859-2 視覚化 索引 ISO-8859-2 BMP 被覆域
ISO-8859-3 index-iso-8859-3.txt 索引 ISO-8859-3 視覚化 索引 ISO-8859-3 BMP 被覆域
ISO-8859-4 index-iso-8859-4.txt 索引 ISO-8859-4 視覚化 索引 ISO-8859-4 BMP 被覆域
ISO-8859-5 index-iso-8859-5.txt 索引 ISO-8859-5 視覚化 索引 ISO-8859-5 BMP 被覆域
ISO-8859-6 index-iso-8859-6.txt 索引 ISO-8859-6 視覚化 索引 ISO-8859-6 BMP 被覆域
ISO-8859-7 index-iso-8859-7.txt 索引 ISO-8859-7 視覚化 索引 ISO-8859-7 BMP 被覆域
ISO-8859-8 index-iso-8859-8.txt 索引 ISO-8859-8 視覚化 索引 ISO-8859-8 BMP 被覆域
ISO-8859-8-IISO-8859-8 と同じ
ISO-8859-10 index-iso-8859-10.txt 索引 ISO-8859-10 視覚化 索引 ISO-8859-10 BMP 被覆域
ISO-8859-13 index-iso-8859-13.txt 索引 ISO-8859-13 視覚化 索引 ISO-8859-13 BMP 被覆域
ISO-8859-14 index-iso-8859-14.txt 索引 ISO-8859-14 視覚化 索引 ISO-8859-14 BMP 被覆域
ISO-8859-15 index-iso-8859-15.txt 索引 ISO-8859-15 視覚化 索引 ISO-8859-15 BMP 被覆域
ISO-8859-16 index-iso-8859-16.txt 索引 ISO-8859-16 視覚化 索引 ISO-8859-16 BMP 被覆域
KOI8-R index-koi8-r.txt 索引 KOI8-R 視覚化 索引 KOI8-R BMP 被覆域
KOI8-U index-koi8-u.txt 索引 KOI8-U 視覚化 索引 KOI8-U BMP 被覆域
macintosh index-macintosh.txt 索引 macintosh 視覚化 索引 macintosh BMP 被覆域
windows-874 index-windows-874.txt 索引 windows-874 視覚化 索引 windows-874 BMP 被覆域
windows-1250 index-windows-1250.txt 索引 windows-1250 視覚化 索引 windows-1250 BMP 被覆域
windows-1251 index-windows-1251.txt 索引 windows-1251 視覚化 索引 windows-1251 BMP 被覆域
windows-1252 index-windows-1252.txt 索引 windows-1252 視覚化 索引 windows-1252 BMP 被覆域
windows-1253 index-windows-1253.txt 索引 windows-1253 視覚化 索引 windows-1253 BMP 被覆域
windows-1254 index-windows-1254.txt 索引 windows-1254 視覚化 索引 windows-1254 BMP 被覆域
windows-1255 index-windows-1255.txt 索引 windows-1255 視覚化 索引 windows-1255 BMP 被覆域
windows-1256 index-windows-1256.txt 索引 windows-1256 視覚化 索引 windows-1256 BMP 被覆域
windows-1257 index-windows-1257.txt 索引 windows-1257 視覚化 索引 windows-1257 BMP 被覆域
windows-1258 index-windows-1258.txt 索引 windows-1258 視覚化 索引 windows-1258 BMP 被覆域
x-mac-cyrillic index-x-mac-cyrillic.txt 索引 x-mac-cyrillic 視覚化 索引 x-mac-cyrillic BMP 被覆域

注記： レイアウト方向に波及することから、 ISO-8859-8 と ISO-8859-8-I の符号化法の名前は異なるものにされている。 歴史的に、 このことは ISO-8859-6 と "ISO-8859-6-I" についても該当していたが、 それはもはや成立しない。 ISO-8859-8 and ISO-8859-8-I are distinct encoding names, because ISO-8859-8 has influence on the layout direction. And although historically this might have been the case for ISO-8859-6 and "ISO-8859-6-I" as well, that is no longer true.

9.1. 単バイト復号器

単バイト符号化法の復号器のハンドラは、 所与の ( 利用されないキュー, バイト ) に対し： Single-byte encodings’s decoder’s handler, given unused and byte, runs these steps:

  1. IF［ バイト ＝ キュー終端 ］ ：RETURN 完遂 If byte is end-of-queue, then return finished.
  2. IF［ バイト ∈ ASCII バイト ］ ：RETURN 符号位置 « バイト » If byte is an ASCII byte, then return a code point whose value is byte.
  3. 符号位置 :← 単バイト索引 の中で ( バイト − 0x80 ) が指す索引符号位置 Let codePoint be the index code point for byte − 0x80 in index single-byte.
  4. IF［ 符号位置 ＝ null ］ ：RETURN エラー If codePoint is null, then return error.
  5. RETURN 符号位置 « 符号位置 » Return a code point whose value is codePoint.

9.2. 単バイト符号化器

単バイト符号化法 の符号化器のハンドラは、 所与の ( 利用されないキュー, 符号位置 ) に対し： Single-byte encodings’s encoder’s handler, given unused and codePoint, runs these steps:

  1. IF［ 符号位置 ＝ キュー終端 ］ ：RETURN 完遂 If codePoint is end-of-queue, then return finished.
  2. IF［ 符号位置 ∈ ASCII 符号位置 ］ ：RETURN バイト « 符号位置 » If codePoint is an ASCII code point, then return a byte whose value is codePoint.
  3. ポインタ :← 単バイト索引 の中で 符号位置 を指す索引ポインタ Let pointer be the index pointer for codePoint in index single-byte.
  4. IF［ ポインタ ＝ null ］ ：RETURN エラー( 符号位置 ) If pointer is null, then return error with codePoint.
  5. RETURN バイト « ポインタ + 0x80 » Return a byte whose value is pointer + 0x80.

10. 旧来の複バイト Chinese （簡体字） 符号化法

10.1. GBK

10.1.1. GBK 復号器

GBK の復号器は，gb18030 の復号器である。 GBK’s decoder is gb18030’s decoder.

10.1.2. GBK 符号化器

GBK の符号化器は，［ GBK 用か ← true ］にされた gb18030 の符号化器である。 GBK’s encoder is gb18030’s encoder with its is GBK set to true.

注記： GBK を gb18030に対する全くの別名にしないのは、 GBK の符号化器により生成された内容を［ 旧来のサーバや他の消費器を非互換化する機会を減らすよう，保守的に移行する ］ためである。 Not fully aliasing GBK with gb18030 is a conservative move to decrease the chances of breaking legacy servers and other consumers of content generated with GBK’s encoder.

10.2. gb18030

10.2.1. gb18030 復号器

各［ gb18030 の復号器 ］には、 次に挙げるものが結び付けられる： gb18030’s decoder has an associated:

  • gb1 ：あるバイト — 初期時は 0 とする。 gb18030 first • ↓
  • gb2 ：あるバイト — 初期時は 0 とする。 gb18030 second • ↓
  • gb3 ：あるバイト — 初期時は 0 とする。 gb18030 third • Each a byte, initially 0x00.

gb18030 の復号器のハンドラは、 所与の ( 入出力キュー, バイト ) に対し： gb18030’s decoder’s handler, given ioQueue and byte, runs these steps:

  1. IF［ バイト ＝ キュー終端 ］： ↓

    1. IF［ ( gb1 , gb2 , gb3 ) ＝ ( 0x00, 0x00, 0x00 ) ］ ：RETURN 完遂 If byte is end-of-queue and gb18030 first, gb18030 second, and gb18030 third are 0x00, then return finished.
    2. ( gb1 , gb2 , gb3 ) ← ( 0x00, 0x00, 0x00 ) If byte is end-of-queue, and gb18030 first, gb18030 second, or gb18030 third is not 0x00, then set gb18030 first, gb18030 second, and gb18030 third to 0x00, and＼
    3. RETURN エラー return error.

  2. IF［ gb3 ≠ 0x00 ］： If gb18030 third is not 0x00:

    1. IF［ バイト ∉ { 0x30 〜 0x39 } ］： If byte is not in the range 0x30 to 0x39, inclusive:

      1. 入出力キューに格納し直す( 入出力キュー, バイト列 « gb2 , gb3 , バイト » ) Restore « gb18030 second, gb18030 third, byte » to ioQueue.
      2. ( gb1 , gb2 , gb3 ) ← ( 0x00, 0x00, 0x00 ) Set gb18030 first, gb18030 second, and gb18030 third to 0x00.
      3. RETURN エラー Return error.
    2. 符号位置 :← 次に与えるポインタが指す索引 gb18030 範囲群符号位置 ：(( gb1 − 0x81 ) × ( 10 × 126 × 10 )) + (( gb2 − 0x30 ) × ( 10 × 126 )) + (( gb3 − 0x81 ) × 10 ) + ( バイト − 0x30 ) Let codePoint be the index gb18030 ranges code point for ((gb18030 first − 0x81) × (10 × 126 × 10)) + ((gb18030 second − 0x30) × (10 × 126)) + ((gb18030 third − 0x81) × 10) + byte − 0x30.
    3. ( gb1 , gb2 , gb3 ) ← ( 0x00, 0x00, 0x00 ) Set gb18030 first, gb18030 second, and gb18030 third to 0x00.
    4. IF［ 符号位置 ＝ null ］ ：RETURN エラー If codePoint is null, then return error.
    5. RETURN 符号位置 « 符号位置 » Return a code point whose value is codePoint.

  3. IF［ gb2 ≠ 0x00 ］： If gb18030 second is not 0x00:

    1. IF［ バイト ∈ { 0x81 〜 0xFE } ］ ：gb3 ← バイト ； RETURN 継続 If byte is in the range 0x81 to 0xFE, inclusive, then set gb18030 third to byte and return continue.
    2. 入出力キューに格納し直す( 入出力キュー, バイト列 « gb2 , バイト » ) Restore « gb18030 second, byte » to ioQueue,＼
    3. ( gb1 , gb2 ) ← ( 0x00, 0x00 ) set gb18030 first and gb18030 second to 0x00, and＼
    4. RETURN エラー return error.

  4. IF［ gb1 ≠ 0x00 ］： If gb18030 first is not 0x00:

    1. IF［ バイト ∈ { 0x30 〜 0x39 } ］ ：gb2 ← バイト ； RETURN 継続 If byte is in the range 0x30 to 0x39, inclusive, then set gb18030 second to byte and return continue.
    2. 頭部 :← gb1 Let leading be gb18030 first.
    3. gb1 ← 0x00 Set gb18030 first to 0x00.
    4. ポインタ :← null Let pointer be null.
    5. オフセット :← ［ バイト ∈ { 0x00 〜 0x7E } ならば 0x40 ／ 他の場合は 0x41 ］ Let offset be 0x40 if byte is less than 0x7F; otherwise 0x41.
    6. IF［ バイト ∈ { 0x40 〜 0x7E, 0x80 〜 0xFE } ］ ：ポインタ ← ( 頭部 − 0x81 ) × 190 + ( バイト − オフセット ) If byte is in the range 0x40 to 0x7E, inclusive, or 0x80 to 0xFE, inclusive, then set pointer to (leading − 0x81) × 190 + (byte − offset).
    7. 符号位置 :← ポインタ に応じて ： null ならば null ／ 他の場合は 索引 gb18030 の中で ポインタ が指す索引符号位置 Let codePoint be null if pointer is null; otherwise the index code point for pointer in index gb18030.
    8. IF［ 符号位置 ≠ null ］ ：RETURN 符号位置 « 符号位置 » If codePoint is non-null, then return a code point whose value is codePoint.
    9. IF［ バイト ∈ ASCII バイト ］ ：入出力キューに格納し直す( 入出力キュー, バイト ) If byte is an ASCII byte, then restore byte to ioQueue.
    10. RETURN エラー Return error.
  5. IF［ バイト ∈ { 0x81 〜 0xFE } ］ ：gb1 ← バイト ； RETURN 継続 ↓
  6. RETURN バイト に応じて ：ASCII バイトならば 符号位置 « バイト » ／ 0x80 ならば 符号位置 « U+20AC ( € ) » ／ 0xFF ならば エラー If byte is an ASCII byte, then return a code point whose value is byte.If byte is 0x80, then return code point U+20AC (€).If byte is in the range 0x81 to 0xFE, inclusive, then set gb18030 first to byte and return continue.Return error.

10.2.2. gb18030 符号化器

各［ gb18030 の符号化器 ］には、 次に挙げるものが結び付けられる： gb18030’s encoder has an associated＼

  • GBK 用か ：ある真偽値 — 初期時は false とする。 is GBK, which is a boolean, initially false.

gb18030 の符号化器のハンドラは、 所与の ( 利用されないキュー, 符号位置 ) に対し： gb18030’s encoder’s handler, given unused and codePoint, runs these steps:

  1. IF［ 符号位置 ＝ キュー終端 ］ ：RETURN 完遂 If codePoint is end-of-queue, then return finished.
  2. IF［ 符号位置 ∈ ASCII 符号位置 ］ ：RETURN バイト « 符号位置 » If codePoint is an ASCII code point, then return a byte whose value is codePoint.

  3. IF［ 符号位置 ＝ U+E5E5 ］ ：RETURN エラー( 符号位置 ) If codePoint is U+E5E5, then return error with codePoint.

    注記： 配備済みな内容との互換性を得るため、 索引 gb18030 は［ 0xA3 0xA0 ］を U+E5E5 ではなく U+3000 IDEOGRAPHIC SPACE へ対応付けている。 したがって、 それは往復し得ない。 Index gb18030 maps 0xA3 0xA0 to U+3000 IDEOGRAPHIC SPACE rather than U+E5E5 for compatibility with deployed content. Therefore it cannot roundtrip.

  4. IF［ GBK 用か ＝ true ］∧［ 符号位置 ＝ U+20AC ( € ) ］ ：RETURN バイト « 0x80 » If is GBK is true and codePoint is U+20AC (€), then return byte 0x80.

  5. 下の表を成す 各( 行 ) に対し ：IF［ 符号位置 ＝ 行 の 1 列目に挙げられる符号位置 ］ ：RETURN 行 の 2 列目に挙げられるバイト列 If there is a row in the table below whose first column is codePoint, then return the two bytes on the same row listed in the second column:

    符号位置 バイト列
    U+E78D 0xA6 0xD9
    U+E78E 0xA6 0xDA
    U+E78F 0xA6 0xDB
    U+E790 0xA6 0xDC
    U+E791 0xA6 0xDD
    U+E792 0xA6 0xDE
    U+E793 0xA6 0xDF
    U+E794 0xA6 0xEC
    U+E795 0xA6 0xED
    U+E796 0xA6 0xF3
    U+E81E 0xFE 0x59
    U+E826 0xFE 0x61
    U+E82B 0xFE 0x66
    U+E82C 0xFE 0x67
    U+E832 0xFE 0x6D
    U+E843 0xFE 0x7E
    U+E854 0xFE 0x90
    U+E864 0xFE 0xA0

    注記： この非対称な符号化器表は、 GB18030-2005 標準との互換性を保全する。 索引 gb18030 範囲群における説明も見よ。 This asymmetric encoder table preserves compatibility with the GB18030-2005 standard. See also the explanation at index gb18030 ranges.

  6. ポインタ :← 索引 gb18030 の中で 符号位置 を指す索引ポインタ Let pointer be the index pointer for codePoint in index gb18030.

  7. IF［ ポインタ ≠ null ］： If pointer is non-null:

    1. 頭部 :← ( ポインタ ÷ 190 ) + 0x81 Let leading be pointer / 190 + 0x81.
    2. 尾部 :← ポインタ % 190 Let trailing be pointer % 190.
    3. オフセット :← ［ 尾部 ∈ { 0x00 〜 0x3E } ならば 0x40 ／ 他の場合は 0x41 ］ Let offset be 0x40 if trailing is less than 0x3F, otherwise 0x41.
    4. RETURN バイト列 « 頭部, ( 尾部 + オフセット ) » Return two bytes whose values are leading and trailing + offset.
  8. IF［ GBK 用か ＝ true ］ ：RETURN エラー( 符号位置 ) If is GBK is true, then return error with codePoint.
  9. ポインタ ← 符号位置 を指す索引 gb18030 範囲群ポインタ Set pointer to the index gb18030 ranges pointer for codePoint.
  10. byte1 :← ポインタ ÷ ( 10 × 126 × 10 ) Let byte1 be pointer / (10 × 126 × 10).
  11. ポインタ ← ポインタ % ( 10 × 126 × 10 ) Set pointer to pointer % (10 × 126 × 10).
  12. byte2 :← ポインタ ÷ ( 10 × 126 ) Let byte2 be pointer / (10 × 126).
  13. ポインタ ← ポインタ % ( 10 × 126 ) Set pointer to pointer % (10 × 126).
  14. byte3 :← ポインタ ÷ 10 Let byte3 be pointer / 10.
  15. byte4 :← ポインタ % 10 Let byte4 be pointer % 10.
  16. RETURN バイト列 « ( byte1 + 0x81 ), ( byte2 + 0x30 ), ( byte3 + 0x81 ), ( byte4 + 0x30 ) » Return four bytes whose values are byte1 + 0x81, byte2 + 0x30, byte3 + 0x81, byte4 + 0x30.

11. 旧来の複バイト Chinese （繁体字）符号化法

11.1. Big5

11.1.1. Big5 復号器

各［ Big5 の復号器 ］には、 次に挙げるものが結び付けられる： Big5’s decoder has an associated＼

  • Big5 頭部 ：あるバイト — 初期時は 0x00 とする。 Big5 leading, which is a byte, initially 0x00.

Big5 の復号器のハンドラは、 所与の ( 入出力キュー, バイト ) に対し： Big5’s decoder’s handler, given ioQueue and byte, runs these steps:

  1. IF［ バイト ＝ キュー終端 ］：

    1. IF［ Big5 頭部 ≠ 0x00 ］ ：Big5 頭部 ← 0x00 ； RETURN エラー
    2. RETURN 完遂
    If byte is end-of-queue and Big5 leading is not 0x00, then set Big5 leading to 0x00 and return error.If byte is end-of-queue and Big5 leading is 0x00, then return finished.

  2. IF［ Big5 頭部 ≠ 0x00 ］： If Big5 leading is not 0x00:

    1. 頭部 :← Big5 頭部 Let leading be Big5 leading.
    2. Big5 頭部 ← 0x00 Set Big5 leading to 0x00.
    3. ポインタ :← null Let pointer be null.
    4. オフセット :← ［ バイト ∈ { 0x00 〜 0x7E } ならば 0x40 ／ 他の場合は 0x62 ］ Let offset be 0x40 if byte is less than 0x7F; otherwise 0x62.
    5. IF［ バイト ∈ { 0x40 〜 0x7E, 0xA1 〜 0xFE } ］ ：ポインタ ← ( 頭部 − 0x81 ) × 157 + ( バイト − オフセット ) If byte is in the range 0x40 to 0x7E, inclusive, or 0xA1 to 0xFE, inclusive, then set pointer to (leading − 0x81) × 157 + (byte − offset).

    6. IF［ 下の表の中で， 1 列目が ポインタ に等しい行がある ］ ：RETURN 同じ行の 2 列目に与える符号位置列（ 2 個の 符号位置からなる） If there is a row in the table below whose first column is pointer, then return the two code points listed in its second column (the third column is irrelevant):

      ポインタ 符号位置 注記（この段には関連しない）
      1133 U+00CA U+0304 Ê̄ ( LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND MACRON )
      1135 U+00CA U+030C Ê̌ ( LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND CARON )
      1164 U+00EA U+0304 ê̄ ( LATIN SMALL LETTER E WITH CIRCUMFLEX AND MACRON )
      1166 U+00EA U+030C ê̌ ( LATIN SMALL LETTER E WITH CIRCUMFLEX AND CARON )
      Pointer｜Code points｜Notes 1133｜U+00CA U+0304｜Ê̄ (LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND MACRON) 1135｜U+00CA U+030C｜Ê̌ (LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND CARON) 1164｜U+00EA U+0304｜ê̄ (LATIN SMALL LETTER E WITH CIRCUMFLEX AND MACRON) 1166｜U+00EA U+030C｜ê̌ (LATIN SMALL LETTER E WITH CIRCUMFLEX AND CARON)

      注記： 索引は単独の符号位置に制限されるので、 これらのポインタにはこの表が利用される。 Since indexes are limited to single code points this table is used for these pointers.

    7. 符号位置 :← ［ ポインタ ＝ null ならば null ／ 他の場合は 索引 Big5 の中で ポインタ が指す索引符号位置 ］ Let codePoint be null if pointer is null; otherwise the index code point for pointer in index Big5.
    8. IF［ 符号位置 ≠ null ］ ：RETURN 符号位置 « 符号位置 » If codePoint is non-null, then return a code point whose value is codePoint.
    9. IF［ バイト ∈ ASCII バイト ］ ：入出力キューに格納し直す( 入出力キュー, バイト ) If byte is an ASCII byte, restore byte to ioQueue.
    10. RETURN エラー Return error.
  3. IF［ バイト ∈ ASCII バイト ］ ：RETURN 符号位置 « バイト » If byte is an ASCII byte, then return a code point whose value is byte.
  4. IF［ バイト ∈ { 0x81 〜 0xFE } ］ ：Big5 頭部 ← バイト ； RETURN 継続 If byte is in the range 0x81 to 0xFE, inclusive, then set Big5 leading to byte and return continue.
  5. RETURN エラー Return error.

11.1.2. Big5 符号化器

Big5 の符号化器のハンドラは、 所与の ( 利用されないキュー, 符号位置 ) に対し： Big5’s encoder’s handler, given unused and codePoint, runs these steps:

  1. IF［ 符号位置 ＝ キュー終端 ］ ：RETURN 完遂 If codePoint is end-of-queue, then return finished.
  2. IF［ 符号位置 ∈ ASCII 符号位置 ］ ：RETURN バイト « 符号位置 » If codePoint is an ASCII code point, then return a byte whose value is codePoint.
  3. ポインタ :← 符号位置 を指す索引 Big5 ポインタ Let pointer be the index Big5 pointer for codePoint.
  4. IF［ ポインタ ＝ null ］ ：RETURN エラー( 符号位置 ) If pointer is null, then return error with codePoint.
  5. 頭部 :← ( ポインタ ÷ 157 ) + 0x81 Let leading be pointer / 157 + 0x81.
  6. 尾部 :← ポインタ % 157 Let trailing be pointer % 157.
  7. オフセット :← ［ 尾部 ∈ { 0x00 〜 0x3E } ならば 0x40 ／ 他の場合は 0x62 ］ Let offset be 0x40 if trailing is less than 0x3F, otherwise 0x62.
  8. RETURN バイト列 « 頭部, ( 尾部 + オフセット) »» Return two bytes whose values are leading and trailing + offset.

12. 旧来の複バイト Japanese 符号化法

12.1. EUC-JP

12.1.1. EUC-JP 復号器

各［ EUC-JP の復号器 ］には、 次に挙げるものが結び付けられる： EUC-JP’s decoder has an associated:

  • EUC-JP jis0212 か ：ある真偽値 — 初期時は false とする。 EUC-JP jis0212 • A boolean, initially false.
  • EUC-JP 頭部 ：あるバイト — 初期時は 0x00 とする。 EUC-JP leading • A byte, initially 0x00.

EUC-JP の復号器のハンドラは、 所与の ( 入出力キュー, バイト ) に対し： EUC-JP’s decoder’s handler, given ioQueue and byte, runs these steps:

  1. IF［ バイト ＝ キュー終端 ］： ↓

    1. IF［ EUC-JP 頭部 ≠ 0x00 ］ ：EUC-JP 頭部 ← 0x00 ； RETURN エラー If byte is end-of-queue and EUC-JP leading is not 0x00, then set EUC-JP leading to 0x00 and return error.
    2. ELSE ：RETURN 完遂 If byte is end-of-queue and EUC-JP leading is 0x00, then return finished.
  2. IF［ EUC-JP 頭部 ＝ 0x8E ］∧［ バイト ∈ { 0xA1 〜 0xDF } ］ ：EUC-JP 頭部 ← 0x00 ； RETURN 符号位置 « 0xFF61 − 0xA1 + バイト » If EUC-JP leading is 0x8E and byte is in the range 0xA1 to 0xDF, inclusive, then set EUC-JP leading to 0x00 and return a code point whose value is 0xFF61 − 0xA1 + byte.
  3. IF［ EUC-JP 頭部 ＝ 0x8F ］∧［ バイト ∈ { 0xA1 〜 0xFE } ］ ：EUC-JP jis0212 か ← true ； EUC-JP 頭部 ← バイト ； RETURN 継続 If EUC-JP leading is 0x8F and byte is in the range 0xA1 to 0xFE, inclusive, then set EUC-JP jis0212 to true, set EUC-JP leading to byte, and return continue.

  4. IF［ EUC-JP 頭部 ≠ 0x00 ］： If EUC-JP leading is not 0x00:

    1. 頭部 :← EUC-JP 頭部 Let leading be EUC-JP leading.
    2. EUC-JP 頭部 ← 0x00 Set EUC-JP leading to 0x00.
    3. 符号位置 :← null Let codePoint be null.

    4. IF［ 頭部 ∈ { 0xA1 〜 0xFE } ］∧［ バイト ∈ { 0xA1 〜 0xFE } ］：

      1. 索引 :← EUC-JP jis0212 かに応じて ：false ならば索引 jis0208 ／ true ならば 索引 jis0212
      2. 符号位置 ← 索引 の中で ( ( 頭部 − 0xA1 ) × 94 + バイト − 0xA1 ) が指す索引符号位置
      If leading and byte are both in the range 0xA1 to 0xFE, inclusive, then set codePoint to the index code point for (leading − 0xA1) × 94 + byte − 0xA1 in index jis0208 if EUC-JP jis0212 is false and in index jis0212 otherwise.
    5. EUC-JP jis0212 か ← false Set EUC-JP jis0212 to false.
    6. IF［ 符号位置 ≠ null ］ ：RETURN 符号位置 « 符号位置 » If codePoint is non-null, then return a code point whose value is codePoint.
    7. IF［ バイト ∈ ASCII バイト ］ ：入出力キューに格納し直す( 入出力キュー, バイト ) If byte is an ASCII byte, then restore byte to ioQueue.
    8. RETURN エラー Return error.
  5. IF［ バイト ∈ ASCII バイト ］ ：RETURN 符号位置 « バイト » If byte is an ASCII byte, then return a code point whose value is byte.
  6. IF［ バイト ∈ { 0x8E, 0x8F, 0xA1 〜 0xFE } ］ ：EUC-JP 頭部 ← バイト ； RETURN 継続 If byte is 0x8E, 0x8F, or in the range 0xA1 to 0xFE, inclusive, then set EUC-JP leading to byte and return continue.
  7. RETURN エラー Return error.

12.1.2. EUC-JP 符号化器

EUC-JP の符号化器のハンドラは、 所与の ( 利用されないキュー, 符号位置 ) に対し： EUC-JP’s encoder’s handler, given unused and codePoint, runs these steps:

  1. 結果 :← 符号位置 に応じて ：キュー終端 ならば 完遂 ／ ASCII 符号位置ならば バイト « 符号位置 » ／ U+00A5 ( ¥ ) ならば バイト « 0x5C » ／ U+203E ( ‾ ) ならば バイト « 0x7E » ／ U+FF61 ( ｡ ) 〜 U+FF9F ( ﾟ ) ならば バイト列 « 0x8E, ( 符号位置 − 0xFF61 + 0xA1 ) » ／ 他の場合は null If codePoint is end-of-queue, then return finished.If codePoint is an ASCII code point, then return a byte whose value is codePoint.If codePoint is U+00A5 (¥), then return byte 0x5C.If codePoint is U+203E (‾), then return byte 0x7E.If codePoint is in the range U+FF61 (｡) to U+FF9F (ﾟ), inclusive, then return two bytes whose values are 0x8E and codePoint − 0xFF61 + 0xA1.
  2. IF［ 結果 ≠ null ］ ：RETURN 結果 ↑
  3. IF［ 符号位置 ＝ U+2212 ( − ) ］ ：符号位置 ← U+FF0D ( － ) If codePoint is U+2212 (−), then set it to U+FF0D (－).

  4. ポインタ :← 索引 jis0208 の中で 符号位置 を指す索引ポインタ Let pointer be the index pointer for codePoint in index jis0208.

    注記： ポインタ は、 null でなければ，索引 jis0208 とポインタ演算の資質に因り 8836 未満になる。 If pointer is non-null, it is less than 8836 due to the nature of index jis0208 and the index pointer operation.

  5. IF［ ポインタ ＝ null ］ ：RETURN エラー( 符号位置 ) If pointer is null, then return error with codePoint.
  6. 頭部 :← ( ポインタ ÷ 94 ) + 0xA1 Let leading be pointer / 94 + 0xA1.
  7. 尾部 :← ( ポインタ % 94 ) + 0xA1 Let trailing be pointer % 94 + 0xA1.
  8. RETURN バイト列 « 頭部, 尾部 » Return two bytes whose values are leading and trailing.

12.2. ISO-2022-JP

12.2.1. ISO-2022-JP 復号器

各［ ISO-2022-JP の復号器 ］には、 次に挙げるものが結び付けられる： ISO-2022-JP’s decoder has an associated:

  • ISO-2022-JP 復号器状態 ：ある状態 — 初期時は ASCII とする。 ISO-2022-JP decoder state • A state, initially ASCII.
  • ISO-2022-JP 復号器出力状態 ：ある状態 — 初期時は ASCII とする。 ISO-2022-JP decoder output state • A state, initially ASCII.
  • ISO-2022-JP 頭部 ：あるバイト — 初期時は 0x00 とする。 ISO-2022-JP leading • A byte, initially 0x00.
  • ISO-2022-JP 出力するか ：ある真偽値 — 初期時は false とする。 ISO-2022-JP output • A boolean, initially false.

ISO-2022-JP の復号器のハンドラは、 所与の ( 入出力キュー, バイト ) に対し，ISO-2022-JP 復号器状態に応じて： ISO-2022-JP’s decoder’s handler, given ioQueue and byte, runs these steps, switching on ISO-2022-JP decoder state:

ASCII ASCII

バイト に応じて： Based on byte:

Roman Roman

バイト に応じて： Based on byte:

カタカナ katakana

バイト に応じて： Based on byte:

頭部バイト Leading byte

バイト に応じて： Based on byte:

尾部バイト Trailing byte

バイト に応じて： Based on byte:

エスケープ開始 Escape start
  1. IF［ バイト ∈ { 0x24, 0x28 } ］ ：ISO-2022-JP 頭部 ← バイト ； ISO-2022-JP 復号器状態 ← エスケープ ； RETURN 継続 If byte is either 0x24 or 0x28, then set ISO-2022-JP leading to byte, ISO-2022-JP decoder state to escape, and return continue.
  2. IF［ バイト ≠ キュー終端 ］ ：入出力キューに格納し直す( 入出力キュー, バイト ) If byte is not end-of-queue, then restore byte to ioQueue.
  3. ISO-2022-JP 出力するか ← false Set ISO-2022-JP output to false,＼
  4. ISO-2022-JP 復号器状態 ← ISO-2022-JP 復号器出力状態 ISO-2022-JP decoder state to ISO-2022-JP decoder output state, and＼
  5. RETURN エラー return error.
エスケープ Escape
  1. 頭部 :← ISO-2022-JP 頭部 Let leading be ISO-2022-JP leading and＼
  2. ISO-2022-JP 頭部 ← 0x00 set ISO-2022-JP leading to 0x00.
  3. 状態 :← ( 頭部, バイト ) に応じて ：( 0x28, 0x42 ) ならば ASCII ／ ( 0x28, 0x4A ) ならば Roman ／ ( 0x28, 0x49 ) ならば カタカナ ／ ( 0x24, 0x40 ) ならば 頭部バイト ／ ( 0x24, 0x42 ) ならば 頭部バイト ／ 他の場合は null Let state be null.If leading is 0x28 and byte is 0x42, then set state to ASCII.If leading is 0x28 and byte is 0x4A, then set state to Roman.If leading is 0x28 and byte is 0x49, then set state to katakana.If leading is 0x24 and byte is either 0x40 or 0x42, then set state to leading byte.

  4. IF［ 状態 ≠ null ］： If state is non-null:

    1. ISO-2022-JP 復号器状態 ← 状態 ↓
    2. ISO-2022-JP 復号器出力状態 ← 状態 Set ISO-2022-JP decoder state and ISO-2022-JP decoder output state to state.
    3. 出力 :← ISO-2022-JP 出力するか Let output be the value of ISO-2022-JP output.
    4. ISO-2022-JP 出力するか ← true Set ISO-2022-JP output to true.
    5. RETURN 出力 に応じて ：false ならば 継続 ／ true ならば エラー Return continue, if output is false, and error otherwise.
  5. IF［ バイト ＝ キュー終端 ］ ：入出力キューに格納し直す( 入出力キュー, 頭部 ) If byte is end-of-queue, then restore leading to ioQueue;＼
  6. ELSE ：入出力キューに格納し直す( 入出力キュー, バイト列 « 頭部, バイト » ) otherwise, restore « leading, byte » to ioQueue.
  7. ISO-2022-JP 出力するか ← false Set ISO-2022-JP output to false,＼
  8. ISO-2022-JP 復号器状態 ← ISO-2022-JP 復号器出力状態 ISO-2022-JP decoder state to ISO-2022-JP decoder output state and＼
  9. RETURN エラー return error.

12.2.2. ISO-2022-JP 符号化器

注記： ISO-2022-JP 符号化器は、［ 複数の出力を連結した結果を対応する復号器にかけたとき， エラー になり得る ］ような，唯一の符号化器である。 The ISO-2022-JP encoder is the only encoder for which the concatenation of multiple outputs can result in an error when run through the corresponding decoder.

U+00A5 ( ¥ ) を符号化した結果は [ 0x1B 0x28 0x4A 0x5C 0x1B 0x28 0x42 ] になる。 その結果に同じ結果を連結してから復号した結果は、 [ U+00A5 U+FFFD U+00A5 ] になる。 Encoding U+00A5 (¥) gives 0x1B 0x28 0x4A 0x5C 0x1B 0x28 0x42. Doing that twice, concatenating the results, and then decoding yields U+00A5 U+FFFD U+00A5.

各［ ISO-2022-JP の符号化器 ］には、 次に挙げるものが結び付けられる： ISO-2022-JP’s encoder has an associated＼

  • ISO-2022-JP 符号化器状態 ：ASCII ／ Roman ／ jis0208 — 初期時は ASCII とする ISO-2022-JP encoder state which is ASCII, Roman, or jis0208, initially ASCII.

ISO-2022-JP の符号化器のハンドラは、 所与の ( 入出力キュー, 符号位置 ) に対し： ISO-2022-JP’s encoder’s handler, given ioQueue and codePoint, runs these steps:

  1. IF［ 符号位置 ＝ キュー終端 ］： ↓

    1. IF［ ISO-2022-JP 符号化器状態 ≠ ASCII ］ ：ISO-2022-JP 符号化器状態 ← ASCII ； RETURN バイト列 « 0x1B, 0x28, 0x42 » If codePoint is end-of-queue and ISO-2022-JP encoder state is not ASCII, then set ISO-2022-JP encoder state to ASCII and return three bytes 0x1B 0x28 0x42.
    2. RETURN 完遂 If codePoint is end-of-queue and ISO-2022-JP encoder state is ASCII, then return finished.

  2. IF［ ISO-2022-JP 符号化器状態 ∈ { ASCII , Roman } ］∧［ 符号位置 ∈ { U+000E, U+000F, U+001B } ］ ：RETURN エラー( U+FFFD ( � ) ) If ISO-2022-JP encoder state is ASCII or Roman, and codePoint is U+000E, U+000F, or U+001B, then return error with U+FFFD (�).

    注記： 攻撃を防ぐため、 ここでは，［ 符号位置 ではなく， U+FFFD ( � ) ］を返す。 This returns U+FFFD (�) rather than codePoint to prevent attacks.

  3. IF［ ISO-2022-JP 符号化器状態 ＝ ASCII ］∧［ 符号位置 ∈ ASCII 符号位置 ］ ：RETURN バイト « 符号位置 » If ISO-2022-JP encoder state is ASCII and codePoint is an ASCII code point, then return a byte whose value is codePoint.

  4. IF［ ISO-2022-JP 符号化器状態 ＝ Roman ］：

    1. 結果 :← 符号位置 に応じて ：U+005C ( \ ), U+007E ( ~ ) 以外の ASCII 符号位置ならば バイト « 符号位置 » ／ U+00A5 ( ¥ ) ならば バイト « 0x5C » ／ U+203E ( ‾ ) ならば バイト « 0x7E » ／ 他の場合は null
    2. IF［ 結果 ≠ null ］ ：RETURN 結果 ↑
    If ISO-2022-JP encoder state is Roman and codePoint is an ASCII code point, excluding U+005C (\) and U+007E (~), or is U+00A5 (¥) or U+203E (‾): • If codePoint is an ASCII code point, then return a byte whose value is codePoint. • If codePoint is U+00A5 (¥), then return byte 0x5C. • If codePoint is U+203E (‾), then return byte 0x7E.
  5. IF［ 符号位置 ∈ ASCII 符号位置 ］∧［ ISO-2022-JP 符号化器状態 ≠ ASCII ］ ：入出力キューに格納し直す( 入出力キュー, 符号位置 )； ISO-2022-JP 符号化器状態 ← ASCII ； RETURN バイト列 « 0x1B, 0x28, 0x42 » If codePoint is an ASCII code point, and ISO-2022-JP encoder state is not ASCII, then restore codePoint to ioQueue, set ISO-2022-JP encoder state to ASCII, and return three bytes 0x1B 0x28 0x42.
  6. IF［ 符号位置 ∉ { U+00A5 ( ¥ ), U+203E ( ‾ ) } ］∧［ ISO-2022-JP 符号化器状態 ≠ Roman ］ ：入出力キューに格納し直す( 入出力キュー, 符号位置 )； ISO-2022-JP 符号化器状態 ← Roman ； RETURN バイト列 « 0x1B, 0x28, 0x4A » If codePoint is either U+00A5 (¥) or U+203E (‾), and ISO-2022-JP encoder state is not Roman, then restore codePoint to ioQueue, set ISO-2022-JP encoder state to Roman, and return three bytes 0x1B 0x28 0x4A.
  7. IF［ 符号位置 ＝ U+2212 ( − ) ］ ：符号位置 ← U+FF0D ( － ) If codePoint is U+2212 (−), then set it to U+FF0D (－).
  8. IF［ 符号位置 ∈ { U+FF61 ( ｡ ) 〜 U+FF9F ( ﾟ ) } ］ ：符号位置 ← 索引 ISO-2022-JP カタカナの中で ( 符号位置 − 0xFF61 ) が指す索引符号位置 If codePoint is in the range U+FF61 (｡) to U+FF9F (ﾟ), inclusive, then set it to the index code point for codePoint − 0xFF61 in index ISO-2022-JP katakana.

  9. ポインタ :← 索引 jis0208 の中で 符号位置 を指す索引ポインタ Let pointer be the index pointer for codePoint in index jis0208.

    注記： ポインタ は、 null でなければ，索引 jis0208 とポインタ演算の資質に因り 8836 未満になる。 If pointer is non-null, it is less than 8836 due to the nature of index jis0208 and the index pointer operation.

  10. IF［ ポインタ ＝ null ］： If pointer is null:

    1. IF［ ISO-2022-JP 符号化器状態 ＝ jis0208 ］ ：入出力キューに格納し直す( 入出力キュー, 符号位置 )； ISO-2022-JP 符号化器状態 ← ASCII ； RETURN バイト列 « 0x1B, 0x28, 0x42 » If ISO-2022-JP encoder state is jis0208, then restore codePoint to ioQueue, set ISO-2022-JP encoder state to ASCII, and return three bytes 0x1B 0x28 0x42.
    2. RETURN エラー( 符号位置 ) Return error with codePoint.
  11. IF［ ISO-2022-JP 符号化器状態 ≠ jis0208 ］ ：入出力キューに格納し直す( 入出力キュー, 符号位置 )； ISO-2022-JP 符号化器状態 ← jis0208 ； RETURN バイト列 « 0x1B, 0x24, 0x42 » If ISO-2022-JP encoder state is not jis0208, then restore codePoint to ioQueue, set ISO-2022-JP encoder state to jis0208, and return three bytes 0x1B 0x24 0x42.
  12. 頭部 :← ( ポインタ ÷ 94 ) + 0x21 Let leading be pointer / 94 + 0x21.
  13. 尾部 :← ( ポインタ % 94 ) + 0x21 Let trailing be pointer % 94 + 0x21.
  14. RETURN バイト列 « 頭部, 尾部 » Return two bytes whose values are leading and trailing.

12.3. Shift_JIS

12.3.1. Shift_JIS 復号器

各［ Shift_JIS の復号器 ］には、 次に挙げるものが結び付けられる： Shift_JIS’s decoder has an associated＼

  • Shift_JIS 頭部 ：あるバイト — 初期時は 0x00 とする。 Shift_JIS leading, which is a byte, initially 0x00.

Shift_JIS の復号器のハンドラは、 所与の ( 入出力キュー, バイト ) に対し： Shift_JIS’s decoder’s handler, given ioQueue and byte, runs these steps:

  1. IF［ バイト ＝ キュー終端 ］： ↓

    1. IF［ Shift_JIS 頭部 ≠ 0x00 ］ ：Shift_JIS 頭部 ← 0x00 ； RETURN エラー If byte is end-of-queue and Shift_JIS leading is not 0x00, then set Shift_JIS leading to 0x00 and return error.
    2. ELSE ：RETURN 完遂 If byte is end-of-queue and Shift_JIS leading is 0x00, then return finished.

  2. IF［ Shift_JIS 頭部 ≠ 0x00 ］： If Shift_JIS leading is not 0x00:

    1. 頭部 :← Shift_JIS 頭部 Let leading be Shift_JIS leading.
    2. Shift_JIS 頭部 ← 0x00 Set Shift_JIS leading to 0x00.
    3. ポインタ :← null Let pointer be null.
    4. オフセット :← ［ バイト ∈ { 0x00 〜 0x7E } ならば 0x40 ／ 他の場合は 0x41 ］ Let offset be 0x40 if byte is less than 0x7F; otherwise 0x41.
    5. 頭部オフセット :← ［ 頭部 ∈ { 0x00 〜 0x9F } ならば 0x81 ／ 他の場合は 0xC1 ］ Let leadingOffset be 0x81 if leading is less than 0xA0; otherwise 0xC1.
    6. IF［ バイト ∈ { 0x40 〜 0x7E, 0x80 〜 0xFC } ］ ：ポインタ ← ( 頭部 − 頭部オフセット ) × 188 + バイト − オフセット If byte is in the range 0x40 to 0x7E, inclusive, or 0x80 to 0xFC, inclusive, then set pointer to (leading − leadingOffset) × 188 + byte − offset.

    7. IF［ ポインタ ∈ { 8836 〜 10715 } ］ ：RETURN 符号位置 « 0xE000 − 8836 + ポインタ » If pointer is in the range 8836 to 10715, inclusive, then return a code point whose value is 0xE000 − 8836 + pointer.

      注記： これは EUDC として周知な，旧来の Windows によるものと相互運用可能にする。 This is interoperable legacy from Windows known as EUDC.

      【 EUDC — いわゆる外字用の機能。 】【 8836 = 94 × 94 は Shift_JIS （ JIS X 0208 ）の区点番号の総数。 結果の符号位置は Unicode 私用領域に入る。 】

    8. 符号位置 :← ［ ポインタ ＝ null ならば null ／ 他の場合は 索引 jis0208 の中で ポインタ が指す索引符号位置 ］ Let codePoint be null if pointer is null; otherwise the index code point for pointer in index jis0208.
    9. IF［ 符号位置 ≠ null ］ ：RETURN 符号位置 « 符号位置 » If codePoint is non-null, then return a code point whose value is codePoint.
    10. IF［ バイト ∈ ASCII バイト ］ ：入出力キューに格納し直す( 入出力キュー, バイト ) If byte is an ASCII byte, then restore byte to ioQueue.
    11. RETURN エラー Return error.
  3. IF［ バイト ∈ { ASCII バイト, 0x80} ］ ：RETURN 符号位置 « バイト » If byte is an ASCII byte or 0x80, then return a code point whose value is byte.
  4. IF［ バイト ∈ { 0xA1 〜 0xDF } ］ ：RETURN 符号位置 « 0xFF61 + ( バイト − 0xA1 ) » If byte is in the range 0xA1 to 0xDF, inclusive, then return a code point whose value is 0xFF61 − 0xA1 + byte.
  5. IF［ バイト ∈ { 0x81 〜 0x9F, 0xE0 〜 0xFC } ］ ：Shift_JIS 頭部 ← バイト ； RETURN 継続 If byte is in the range 0x81 to 0x9F, inclusive, or 0xE0 to 0xFC, inclusive, then set Shift_JIS leading to byte and return continue.
  6. RETURN エラー Return error.

12.3.2. Shift_JIS 符号化器

Shift_JIS の符号化器のハンドラは、 所与の ( 利用されないキュー, 符号位置 ) に対し： Shift_JIS’s encoder’s handler, given unused and codePoint, runs these steps:

  1. 結果 :← 符号位置 に応じて ：キュー終端 ならば 完遂 ／ ASCII 符号位置ならば バイト « 符号位置 » ／ U+0080 ならば バイト « 符号位置 » ／ U+00A5 ( ¥ ) ならば バイト « 0x5C » ／ U+203E ( ‾ ) ならば バイト « 0x7E » ／ U+FF61 ( ｡ ) 〜 U+FF9F ( ﾟ ) ならば バイト « ( 符号位置 − 0xFF61 ) + 0xA1 » ／ 他の場合は null If codePoint is end-of-queue, then return finished.If codePoint is an ASCII code point or U+0080, then return a byte whose value is codePoint.If codePoint is U+00A5 (¥), then return byte 0x5C.If codePoint is U+203E (‾), then return byte 0x7E.If codePoint is in the range U+FF61 (｡) to U+FF9F (ﾟ), inclusive, then return a byte whose value is codePoint − 0xFF61 + 0xA1.
  2. IF［ 結果 ≠ null ］ ：RETURN 結果 ↑
  3. IF［ 符号位置 ＝ U+2212 ( − ) ］ ：符号位置 ← U+FF0D ( － ) If codePoint is U+2212 (−), then set it to U+FF0D (－).
  4. ポインタ :← 符号位置 を指す索引 Shift_JIS ポインタ Let pointer be the index Shift_JIS pointer for codePoint.
  5. IF［ ポインタ ＝ null ］ ：RETURN エラー( 符号位置 ) If pointer is null, then return error with codePoint.
  6. 頭部 :← ( ポインタ ÷ 188 ) Let leading be pointer / 188.
  7. 頭部オフセット :← ［ 頭部 ∈ { 0x00 〜 0x1E } ならば 0x81 ／ 他の場合は 0xC1 ］ Let leadingOffset be 0x81 if leading is less than 0x1F; otherwise 0xC1.
  8. 尾部 :← ポインタ % 188 Let trailing be pointer % 188.
  9. オフセット :← ［ 尾部 ∈ { 0x00 〜 0x3E } ならば 0x40 ／ 他の場合は 0x41 ］ Let offset be 0x40 if trailing is less than 0x3F; otherwise 0x41.
  10. RETURN バイト列 « ( 頭部 + 頭部オフセット ), ( 尾部 + オフセット ) » Return two bytes whose values are leading + leadingOffset and trailing + offset.

13. 旧来の複バイト Korean 符号化法

13.1. EUC-KR

13.1.1. EUC-KR 復号器

各［ EUC-KR の復号器 ］には、 次に挙げるものが結び付けられる： EUC-KR’s decoder has an associated＼

  • EUC-KR 頭部 ：あるバイト — 初期時は 0x00 とする。 EUC-KR leading, which is a byte, initially 0x00.

EUC-KR の復号器のハンドラは、 所与の ( 入出力キュー, バイト ) に対し： EUC-KR’s decoder’s handler, given ioQueue and byte, runs these steps:

  1. IF［ バイト ＝ キュー終端 ］： ↓

    1. IF［ EUC-KR 頭部 ≠ 0x00 ］ ：EUC-KR 頭部 ← 0x00 ； RETURN エラー If byte is end-of-queue and EUC-KR leading is not 0x00, then set EUC-KR leading to 0x00 and return error.
    2. ELSE ：RETURN 完遂 If byte is end-of-queue and EUC-KR leading is 0x00, then return finished.

  2. IF［ EUC-KR 頭部 ≠ 0x00 ］： If EUC-KR leading is not 0x00:

    1. 頭部 :← EUC-KR 頭部 Let leading be EUC-KR leading.
    2. EUC-KR 頭部 ← 0x00 Set EUC-KR leading to 0x00.
    3. ポインタ :← null Let pointer be null.
    4. IF［ バイト ∈ { 0x41 〜 0xFE } ］ ：ポインタ ← ( 頭部 − 0x81 ) × 190 + ( バイト − 0x41 ) If byte is in the range 0x41 to 0xFE, inclusive, then set pointer to (leading − 0x81) × 190 + (byte − 0x41).
    5. 符号位置 :← ［ ポインタ ＝ null ならば null ／ 他の場合は 索引 EUC-KR の中で ポインタ が指す索引符号位置 ］ Let codePoint be null if pointer is null; otherwise the index code point for pointer in index EUC-KR.
    6. IF［ 符号位置 ≠ null ］ ：RETURN 符号位置 « 符号位置 » If codePoint is non-null, then return a code point whose value is codePoint.
    7. IF［ バイト ∈ ASCII バイト ］ ：入出力キューに格納し直す( 入出力キュー, バイト ) If byte is an ASCII byte, then restore byte to ioQueue.
    8. RETURN エラー Return error.
  3. IF［ バイト ∈ ASCII バイト ］ ：RETURN 符号位置 « バイト » If byte is an ASCII byte, then return a code point whose value is byte.
  4. IF［ バイト ∈ { 0x81 〜 0xFE } ］ ：EUC-KR 頭部 ← バイト ； RETURN 継続 If byte is in the range 0x81 to 0xFE, inclusive, then set EUC-KR leading to byte and return continue.
  5. RETURN エラー Return error.

13.1.2. EUC-KR 符号化器

EUC-KR の符号化器のハンドラは、 所与の ( 利用されないキュー, 符号位置 ) に対し： EUC-KR’s encoder’s handler, given unused and codePoint, runs these steps:

  1. IF［ 符号位置 ＝ キュー終端 ］ ：RETURN 完遂 If codePoint is end-of-queue, then return finished.
  2. IF［ 符号位置 ∈ ASCII 符号位置 ］ ：RETURN バイト « 符号位置 » If codePoint is an ASCII code point, then return a byte whose value is codePoint.
  3. ポインタ :← 索引 EUC-KR の中で 符号位置 を指す索引ポインタ Let pointer be the index pointer for codePoint in index EUC-KR.
  4. IF［ ポインタ ＝ null ］ ：RETURN エラー( 符号位置 ) If pointer is null, then return error with codePoint.
  5. 頭部 :← ( ポインタ ÷ 190 ) + 0x81 Let leading be pointer / 190 + 0x81.
  6. 尾部 :← ( ポインタ % 190 ) + 0x41 Let trailing be pointer % 190 + 0x41.
  7. RETURN バイト列 « 頭部, 尾部 » Return two bytes whose values are leading and trailing.

14. 旧来の諸々の符号化法

14.1. replacement

注記： replacement 符号化法は、 サーバとクライアントにおける 符号化法のサポートの不一致を突く，ある種の攻撃を防ぐためのものである。 The replacement encoding exists to prevent certain attacks that abuse a mismatch between encodings supported on the server and the client.

14.1.1. replacement 復号器

各［ replacement の復号器 ］には、 次に挙げるものが結び付けられる： replacement’s decoder has an associated＼

  • replacement エラーは返したか ：ある真偽値 — 初期時は false とする。 replacement error returned, which is a boolean, initially false.

replacement の復号器のハンドラは、 所与の ( 利用されないキュー, バイト ) に対し： replacement’s decoder’s handler, given unused and byte, runs these steps:

  1. IF［ バイト ＝ キュー終端 ］ ：RETURN 完遂 If byte is end-of-queue, then return finished.
  2. IF［ replacement エラーは返したか ＝ false ］ ：replacement エラーは返したか ← true ； RETURN エラー If replacement error returned is false, then set replacement error returned to true and return error.
  3. RETURN 完遂 Return finished.

【 replacement には、 符号化器は無い。 】

14.2. UTF-16BE/LE に共通な基盤

UTF-16BE/LE は、［ UTF-16BE ／ UTF-16LE ］の総称である。 UTF-16BE/LE is UTF-16BE or UTF-16LE.

14.2.1. 共用 UTF-16 復号器

注記： BOM はラベルより優先される。 それは，配備済みな内容において、 どのラベルよりも正確であることが見出されているので。 したがって，それは、 共用 UTF-16 復号器の一部ではなく，Unicode に復号する アルゴリズムの一部を成す。 A byte order mark has priority over a label as it has been found to be more accurate in deployed content. Therefore it is not part of the shared UTF-16 decoder algorithm, but rather the decode algorithm.

各［ 共用 UTF-16 復号器 ］には、 次に挙げるものが結び付けられる： shared UTF-16 decoder has an associated:

  • UTF-16 頭部バイト ： null ／あるバイト — 初期時は null とする。 UTF-16 leading byte • Null or a byte, initially null.
  • UTF-16 頭部サロゲート ： null ／ある頭部サロゲート — 初期時は null とする。 UTF-16 leading surrogate • Null or a leading surrogate, initially null.
  • UTF-16BE 復号器用か ：ある真偽値 — 初期時は false とする。 is UTF-16BE decoder • A boolean, initially false.

共用 UTF-16 復号器のハンドラは、 所与の ( 入出力キュー, バイト ) に対し： shared UTF-16 decoder’s handler, given ioQueue and byte, runs these steps:

  1. IF［ バイト ＝ キュー終端 ］： ↓

    1. IF［ UTF-16 頭部バイト ≠ null ］∨［ UTF-16 頭部サロゲート ≠ null ］ ：UTF-16 頭部バイト ← null ； UTF-16 頭部サロゲート ← null ； RETURN エラー If byte is end-of-queue and either UTF-16 leading byte or UTF-16 leading surrogate is non-null, then set UTF-16 leading byte and UTF-16 leading surrogate to null, and return error.
    2. ELSE ：RETURN 完遂 If byte is end-of-queue and UTF-16 leading byte and UTF-16 leading surrogate are null, then return finished.
  2. IF［ UTF-16 頭部バイト ＝ null ］ ：UTF-16 頭部バイト ← バイト ； RETURN 継続 If UTF-16 leading byte is null, then set UTF-16 leading byte to byte and return continue.
  3. 符号単位 :← UTF-16BE 復号器用かに応じて ：true ならば ( ( UTF-16 頭部バイト << 8 ) + バイト ) ／ false ならば ( ( バイト << 8 ) + UTF-16 頭部バイト ) Let codeUnit be the result of: • is UTF-16BE decoder is true •• (UTF-16 leading byte << 8) + byte. • is UTF-16BE decoder is false •• (byte << 8) + UTF-16 leading byte.
  4. UTF-16 頭部バイト ← null Set UTF-16 leading byte to null.

  5. IF［ UTF-16 頭部サロゲート ≠ null ］： If UTF-16 leading surrogate is non-null:

    1. 頭部サロゲート :← UTF-16 頭部サロゲート Let leadingSurrogate be UTF-16 leading surrogate.
    2. UTF-16 頭部サロゲート ← null Set UTF-16 leading surrogate to null.
    3. IF［ 符号単位 は尾部サロゲートである ］ ：RETURN サロゲート対からスカラー値を得る( 頭部サロゲート, 符号単位 ) If codeUnit is a trailing surrogate, then return a scalar value from surrogates given leadingSurrogate and codeUnit.
    4. byte1 :← 符号単位 >> 8 Let byte1 be codeUnit >> 8.
    5. byte2 :← 符号単位 & 0x00FF Let byte2 be codeUnit & 0x00FF.
    6. バイト列 :← UTF-16BE 復号器用かに応じて ：true ならば バイト列 « byte1, byte2 » ／ false ならば バイト列 « byte2, byte1 » Let bytes be a list of two bytes whose values are byte1 and byte2, if is UTF-16BE decoder is true; otherwise byte2 and byte1.
    7. 入出力キューに格納し直す( 入出力キュー, バイト列 ) Restore bytes to ioQueue and return error.
    8. RETURN エラー ↑
  6. IF［ 符号単位 は頭部サロゲートである ］ ：UTF-16 頭部サロゲート ← 符号単位 ； RETURN 継続 If codeUnit is a leading surrogate, then set UTF-16 leading surrogate to codeUnit and return continue.
  7. IF［ 符号単位 は尾部サロゲートである ］ ：RETURN エラー If codeUnit is a trailing surrogate, then return error.
  8. RETURN 符号位置 « 符号単位 » Return code point codeUnit.

14.3. UTF-16BE

14.3.1. UTF-16BE 復号器

UTF-16BE の復号器は、［ UTF-16BE 復号器用か ← true ］にされた共用 UTF-16 復号器である。 UTF-16BE’s decoder is shared UTF-16 decoder with its is UTF-16BE decoder set to true.

14.4. UTF-16LE

注記： 配備済みな内容に対処するため、 "utf-16" は UTF-16LE 用のラベルにされている。 "utf-16" is a label for UTF-16LE to deal with deployed content.

14.4.1. UTF-16LE 復号器

UTF-16BE の復号器は、 共用 UTF-16 復号器である。 UTF-16LE’s decoder is shared UTF-16 decoder.

14.5. x-user-defined

注記： これは形の上では単バイト符号化法であるが、 アルゴリズム的に実装できるので，別々に定義される。 While technically this is a single-byte encoding, it is defined separately as it can be implemented algorithmically.

14.5.1. x-user-defined 復号器

x-user-defined の復号器のハンドラは、 所与の ( 利用されないキュー, バイト ) に対し： x-user-defined’s decoder’s handler, given unused and byte, runs these steps:

  1. RETURN バイト に応じて ：キュー終端ならば 完遂 ／ ASCII バイトであるならば 符号位置 « バイト » ／ 他の場合は 符号位置 « 0xF780 + バイト − 0x80 » If byte is end-of-queue, then return finished.If byte is an ASCII byte, then return a code point whose value is byte.Return a code point whose value is 0xF780 + byte − 0x80.

14.5.2. x-user-defined 符号化器

x-user-defined の符号化器のハンドラは、 所与の ( 利用されないキュー, 符号位置 ) に対し： x-user-defined’s encoder’s handler, given unused and codePoint, runs these steps:

  1. RETURN 符号位置 に応じて ：キュー終端ならば 完遂 ／ ASCII 符号位置ならば バイト « 符号位置 » ／ U+F780 〜 U+F7FF ならば バイト « 符号位置 − 0xF780 + 0x80 » ／ 他の場合は エラー( 符号位置 ) If codePoint is end-of-queue, then return finished.If codePoint is an ASCII code point, then return a byte whose value is codePoint.If codePoint is in the range U+F780 to U+F7FF, inclusive, then return a byte whose value is codePoint − 0xF780 + 0x80.Return error with codePoint.

15. ブラウザ UI

ブラウザには、 リソースの符号化法に対する上書きを可能化させないことが奨励される。 にもかかわらず，その種の特能が在る場合、 前述したセキュリティの課題から， ブラウザは UTF-16BE/LE をオプションとして提供するべきでない。 ブラウザは、 リソースが UTF-16BE/LE を利用して復号された場合でも， この特能を不能化するべきである。 Browsers are encouraged to not enable overriding the encoding of a resource. If such a feature is nonetheless present, browsers should not offer UTF-16BE/LE as an option, due to the aforementioned security issues. Browsers should also disable this feature if the resource was decoded using UTF-16BE/LE.

実装の考慮点

この標準における符号化法用の復号器は、 格納し直す演算を備える入出力キューをサポートする代わりに， 次により実装することもできる： Instead of supporting I/O queues with arbitrary restore, the decoders for encodings in this standard could be implemented with:

  1. 読み取った現在のバイトを元に戻す能 The ability to unread the current byte.
  2. ISO-2022-JP 用の単バイト（ 0x24 ／ 0x28 ）バッファ ↓

  3. gb18030 用の単バイト（ ASCII バイト ）バッファ A single-byte buffer for gb18030 (an ASCII byte) and ISO-2022-JP (0x24 or 0x28).

    gb18030 に対しては、［ gb3 ≠ 0x00 ］の間に不正なバイトに出くわしたときは、 gb2 は，次回に返すことになる単バイトバッファの中に移動でき、 gb3 が — 単バイトバッファを返して空にした後， 0x00 でないことを検査したなら — 新たな gb1 になる。 これは、 gb18030 における 1 個目と 3 個目のバイト範囲が一致するので可能になる。 For gb18030 when hitting a bogus byte while gb18030 third is not 0x00, gb18030 second could be moved into the single-byte buffer to be returned next, and gb18030 third would be the new gb18030 first, checked for not being 0x00 after the single-byte buffer was returned and emptied. This is possible as the range for the first and third byte in gb18030 is identical.

ISO-2022-JP 符号化器には，追加の状態として ISO-2022-JP 符号化器状態が必要になるが、 それ以外では、 この標準におけるどの符号化法用にも，その符号化器に追加の［ 状態／バッファ ］は要求されない。 The ISO-2022-JP encoder needs ISO-2022-JP encoder state as additional state, but other than that, none of the encoders for encodings in this standard require additional state or buffers.

謝辞

年月に渡り、 符号化法を相互運用可能なものにするために，たくさんの方々が助力され、 この標準の目標へ近付けてきた。 同様に多くの方々の助力が，この標準を現在の姿に仕立て上げてきた。 特に，次の方々に感謝する： There have been a lot of people that have helped make encodings more interoperable over the years and thereby furthered the goals of this standard. Likewise many people have helped making this standard what it is today.

With that, many thanks to Adam Rice, Alan Chaney, Alexander Shtuchkin, Allen Wirfs-Brock, Andreu Botella, Aneesh Agrawal, Arkadiusz Michalski, Asmus Freytag, Ben Noordhuis, Bnaya Peretz, Boris Zbarsky, Bruno Haible, Cameron McCormack, Charles McCathieNeville, Christopher Foo, CodifierNL, David Carlisle, Domenic Denicola, Dominique Hazaël-Massieux, Doug Ewell, Erik van der Poel, 譚永鋒 (Frank Yung-Fong Tang), Glenn Maynard, Gordon P. Hemsley, Henri Sivonen, Ian Hickson, J. King, James Graham, Jeffrey Yasskin, John Tamplin, Joshua Bell, 村井純 (Jun Murai), 신정식 (Jungshik Shin), Jxck, 강 성훈 (Kang Seonghoon), 川幡太一 (Kawabata Taichi), Ken Lunde, Ken Whistler, Kenneth Russell, 田村健人 (Kent Tamura), Leif Halvard Silli, Luke Wagner, Maciej Hirsz, Makoto Kato, Mark Callow, Mark Crispin, Mark Davis, Martin Dürst, Masatoshi Kimura, Mattias Buelens, Ms2ger, Nigel Megitt, Nigel Tao, Norbert Lindenberg, Øistein E. Andersen, Peter Krefting, Philip Jägenstedt, Philip Taylor, Richard Ishida, Robbert Broersma, Robert Mustacchi, Ryan Dahl, Sam Sneddon, Shawn Steele, Simon Montagu, Simon Pieters, Simon Sapin, Stephen Checkoway, 寺田健 (Takeshi Terada), Vyacheslav Matva, Wolf Lammen, and 成瀬ゆい (Yui Naruse) for being awesome.

This standard is written by Anne van Kesteren (Apple, annevk@annevk.nl). The API chapter was initially written by Joshua Bell (Google).

知的財産権

Copyright © WHATWG (Apple, Google, Mozilla, Microsoft). This work is licensed under a Creative Commons Attribution 4.0 International License. To the extent portions of it are incorporated into source code, such portions in the source code are licensed under the BSD 3-Clause License instead.

This is the Living Standard. Those interested in the patent-review version should view the Living Standard Review Draft.