JIS X 0208

JIS X 0208
エイリアス	JIS C 6226
言語	日本語; 英語; ロシア; ブルガリア語; 部分的なサポート: ギリシャ語; 中国語;
標準	JIS X 0208:1978年から1997年
分類	ISO 2022; DBCS; CJKエンコード;
拡張機能	ARIB STD B24 漢字; NEC PC98 DBCS; JIS X 0213平面 1;
エンコード形式	シフト JIS ("SJIS"); ISO-2022-JP（「JIS」）; EUC-JP（「UJIS」）;
先行	JIS X 0201
後継者	JIS X 0213
その他の関連エンコーディング	関連補足: JIS X 0212 その他の ISO 2022 CJK DBCS: KS X 1001; GB 2312; 9566 号;
	ヴ; t; e;

JIS X 0208は、日本工業規格として定められた2 バイト文字セットで、日本語の文章、地名、人名などを記述するのに適した 6879 個の図形文字が含まれています。現在の規格の正式名称は、情報交換用の7ビットおよび8ビットの2バイトコード化漢字セット（7ビット及び8ビットの2バイト情報交換用記号化漢字セット、ナナビットオヨビハチビットノニ-）です。バイト情報コウカンヨウフゴウカカンジシュウゴウ）。 1978 年にJIS C 6226として制定され、1983 年、1990 年、1997 年に改訂されました。IBMではコードページ 952とも呼ばれます。 1978 年バージョンは、 IBM によってコードページ 955とも呼ばれます。

使用範囲と互換性

JIS X 0208 が定める文字セットは、主にデータ処理システムとそれに接続された機器間、またはデータ通信システム相互間の情報交換( jōhō kōkan )を目的としています。この文字セットは、データ処理やテキスト処理に使用できます。

文字セットの部分的な実装は互換性があるとは考えられていない。最初の標準の起草委員会が第1水準と第2水準の間で文字を区別するように注意し、第2標準ではいくつかの異体字（異体字）をレベル間でシャッフルするなどのことが起こった場所があるため、少なくとも第1および第2標準では、漢字以外と第1水準のみの実装の日本語コンピュータシステムが開発対象として検討された時期があったと推測される。しかし、初期のNEC PC-9801などの例は存在したが、そのような実装が互換性があると指定されたことは一度もない。^[1]

JIS X 0208:1997規格には互換性に関する規定があるが、現時点では、この規格は互換性を証明するものではなく、自己互換性の宣言に相当する公式の製造基準でもないと一般に考えられている。^[2]そのため、事実上のJIS X 0208「互換」製品は存在しないと考えられている。JIS X 0208には「準拠」や「対応」などの用語が含まれているが、これらの用語の意味は人によって異なる。

コードチャート

リードバイト

最初のエンコードバイトは、行またはセル番号に 0x20 を加えた値、つまり 10 進数で 32 に相当します (以下を参照)。したがって、0x21 で始まるコードセットの行番号は 1 で、セル 1 の継続バイトは 0x21 (または 33) になります。

漢字以外の文字に使用されるリードバイトについては、そのリードバイトでエンコードされた文字を一覧表示するこのページの表へのリンクが提供されます。漢字に使用されるリードバイトについては、ウィクショナリーの漢字索引の適切なセクションへのリンクが提供されます。

非漢字行

文字セット 0x21 (行番号 1、特殊文字)

ベンダーによっては、このセットに対して、以下のものとは少し異なる Unicode マッピングを使用しています。たとえば、Microsoft は区点 1-29 (JIS 0x213D) を U+2015 (横棒) にマッピングしていますが、 ^[3]Apple はそれを U+2014 (エムダッシュ) にマッピングしています。^[4]同様に、Microsoft は区点 1-61 (JIS 0x215D) を U+FF0D ^[3] (U+002D ハイフンマイナスの全角形式) にマッピングしていますが、Apple はそれを U+2212 (マイナス記号) にマッピングしています。^[4] 波ダッシュの Unicode マッピングもベンダーによって異なります。以下の脚注のセルを参照してください。

ASCII およびJISCII句読点 (ここでは黄色の背景で表示) は、Shift JIS、EUC-JP 、 ISO 2022 -JPなど、 JIS X 0208 とASCIIまたはJIS X 0201を組み合わせたエンコードで使用される場合、半角および全角フォームブロックへの代替マッピングを使用することがあります。

文字セット 0x22 (行番号 2、特殊文字)

このセットの文字のほとんどは 1983 年に追加されましたが、文字 0x2221 ～ 0x222E (区点 2-1 ～ 2-14、または下の表の最初の行) は例外で、これらの文字は 1978 年の元の標準バージョンに含まれていました。

文字セット 0x23 (行番号 3、数字とローマ字)

このセットには、句読点と記号を除いたISO 646不変セットのサブセット（したがって、ASCIIとJIS X 0201ローマ字セットの両方のサブセット）が含まれており、西洋アラビア数字と基本ラテンアルファベットの両方の大文字と小文字で構成されています。このセットの文字は、EUC-JP、 Shift JIS 、 ISO 2022- JPなど、JIS X 0208 と ASCII または JIS X 0201 を組み合わせたエンコードで使用される場合、半角および全角フォームブロックへの代替Unicodeマッピングを使用することがあります。

この行と完全に一致するKPS 9566 の行 3 を比較してください。 KS X 1001とGB 2312 の行 3を比較対照してください。この行には、英数字のサブセットだけでなく、 ISO 646の各国のバリエーションがすべて含まれています。

文字セット 0x24 (行番号 4、ひらがな)

この行には日本語のひらがなが含まれています。

この行と一致するGB 2312 の行 4 を比較してください。同じレイアウトを使用しているが異なる行にある KPS 9566 の行 10とKS X 1001 を比較対照してください。

文字セット 0x25 (行番号 5、カタカナ)

この行には日本語のカタカナが含まれています。

この行と一致するGB 2312 の行 5 を比較してください。同じレイアウトを使用しているが行が異なるKPS 9566 の行 11とKS X 1001 を比較対照してください。JIS X 0201で使用されているかなり異なるカタカナレイアウトを対比してください。

文字セット 0x26 (行番号 6、ギリシャ語)

この行には、発音区別記号や末尾のシグマのない現代ギリシャ語アルファベットの基本的なサポートが含まれています。

GB 2312 と GB 12345 の行 6とKPS 9566 の行 6 を比較してください。これらは同じレイアウトで同じギリシャ文字を含んでいますが、GB 12345 では垂直表示形式が追加され、 KPS 9566 ではローマ数字が追加されています。 KS X 1001 の行 5 を比較対照してください。これはギリシャ文字をオフセットして、ローマ数字を最初に含めるようにしています。

文字セット 0x27 (行番号 7、キリル文字)

この行には現代のロシア語のアルファベットが含まれており、キリル文字の他の形式を表すには必ずしも十分ではありません。

この行と一致するGB 2312 の行 7 を比較してください。同じレイアウトを使用している (ただし行は異なる) KS X 1001 の行 12とKPS 9566 の行 5 を比較対照してください。

文字セット 0x28 (行番号 8、ボックス描画)

このセットのすべての文字は 1983 年に追加されたもので、1978 年の標準の最初の改訂版には存在しませんでした。

拡張文字セット 0x2D (行番号 13、NEC 特殊文字)

JIS X 0208規格の9行目から15行目は空白のままです。

しかし、 NECによって最初に導入された行 13 の次のレイアウトは、一般的な拡張です。これは、Windows-932 ^[3] ( HTML5で使用されるWHATWGエンコード標準と一致しています)、 MacJapaneseのPostScript バリアント (ただし、KanjiTalkバージョン 7 以降では、通常のバリアントではありません) ^[5]、およびJIS X 0213 (JIS X 0208 の後継) で使用されています。^[5]^[6] Windows-932/WHATWG および JIS X 0213 による他の拡張とは異なり、2 つは衝突するのではなく一致するため、この行の大部分のデコードは、JIS X 0213 による他の拡張よりも適切にサポートされています。

漢字の行

コード構造

コードポイントを表現するために、1バイトコードでは列番号や行番号、 2バイトコードでは区点番号を使用します。コードに依存せずに文字を識別する方法として、文字名を使用します。

シングルバイトコード

JIS X 0208グラフィック文字コードのほとんどは、それぞれ少なくとも 7 ビットの 2 バイトで表されます。ただし、すべての制御文字とプレーンスペース(表意文字スペースを除く) は、 1 バイトコードで表されます。1 バイトコードのビット組み合わせ(ビットとくみあわせ)を表すために、列番号と行番号という 2 つの 10 進数が使用されます。0 から 7 まで、または 0 から 15 まで数えた 7 ビットのうちの上位 3 ビットまたは 8 ビットのうちの上位 4 ビットが列番号を形成します。0 から 15 まで数えた 4 ビットの下位が行番号を形成します。各 10 進数は 1 つの 16 進数に対応します。たとえば、グラフィック文字 "スペース" に対応するビット組み合わせは、7 ビット数では 010 0000、8 ビット数では 0010 0000 です。列/行表記では、これは 2/0 と表されます。同じ 1 バイトコードのその他の表現には、16 進数の 0x20 や、1 つの 10 進数としての 32 などがあります。

コードポイントとコード番号

2バイトコードは94の番号付きグループに配置され、それぞれが行（区、ku、文字通り「セクション」）と呼ばれます。各行には94の番号付きコードが含まれ、それぞれがセル（点、 ten 、文字通り「ポイント」）と呼ばれます。^[j]これにより、合計8836（94×94）のコードポイントが可能になります（ただし、すべてが割り当てられているわけではありません。以下を参照してください）。これらは、94行94列のコード表に標準で配置されています。

行番号とセル番号（標準 JIS X 0208 コードではそれぞれ 1 から 94 の番号が付けられる）は区点（くてん）ポイントを形成し、これは 2 バイトコードポイントを表すために使用されます。コード番号または区点番号（区点番号、kuten bangō）は、「行-セル」の形式で表され、行番号とセル番号はハイフンで区切られます。たとえば、文字「亜」は行 16、セル 1 にコードポイントがあるため、コード番号は「16-01」と表されます。

7ビットの JIS X 0208 (JIS X 0202 / ISO-2022-JPで切り替えられる可能性がある) では、両方のバイトが 0x21 (行またはセル番号 1 に使用) から 0x7E (行またはセル番号 94 に使用) までの 94 バイトの範囲でなければなりません。これは、スペースを除いた 7 ビット ASCII 印刷文字に使用される範囲と正確に一致します。したがって、エンコードされたバイトは、各番号に 0x20 (32) を追加することによって取得されます。^[7]たとえば、上記の 16-01 (「亜」) の例は、バイトで表されます0x30 0x21。8 ビットのEUC-JPでは、代わりに 0xA1 から 0xFE (上位ビットを 1 に設定) の範囲を使用しますが、シフト JISなどの他のエンコードでは、より複雑な変換が使用されます。シフト JIS には、JIS X 0208 自体に必要な量よりも多くのエンコードスペースが含まれています。 JIS X 0208のシフトJIS特有の拡張では、94を超える行番号が使用される。^[8]

この構造は中国大陸のGB 2312では区位; qūwèiとして知られており、韓国の KS C 5601 (現在はKS X 1001 ) でも使用されている。韓国の KS C 5601 では、区と十はそれぞれhang ^[9] ( 행 ;行; haeng ) とyol ^[9] ( 열 ;列; yeol ) として知られている。後のJIS X 0213では、この構造を拡張して、行の平面(面、men、文字通り「顔」)を複数持つようにした。これはCNS 11643でも使用されている構造であり、CCCIIで使用される構造に関連している。

未割り当てのコードポイント

2バイトコードのうち、9行目から15行目と85行目から94行目は、空き領域（あきりょういき）つまり文字が割り当てられていないコードポイントです。また、他の行のいくつかのセルも、基本的に未割り当てのコードポイントです。

これらの空き領域には、基本的に使用すべきでないコードポイントが含まれています。関係者間で事前に合意されている場合を除き、割り当てられていないコードポイントには、情報交換用の文字（外字）を割り当てないでください。

未割り当てのコードポイントに文字を割り当てる場合でも、標準で定義されているグラフィック文字を割り当てたり、同じ文字を複数の未割り当てのコードポイントに割り当てたりしないでください。また、セット内で文字が重複しないようにしてください。

また、未割り当てのコードポイントに文字を割り当てる場合、漢字のグリフの統一には注意が必要です。たとえば、25行66セルは「高い」または「高価」を意味する漢字に相当しますが、中央に「口」の文字に似た要素がある形式（高）と、同じ場所に梯子のような構造を持つあまり一般的ではない形式（髙）の両方が同じコードポイントに含まれます。したがって、ポイント25-66を「口」形式に限定し、後者の「梯子」形式を未割り当てのコードポイントに割り当てることは、技術的には標準に違反することになります。

しかし実際には、Windows-932やMacJapaneseなど、ベンダー固有のShift JISバリアントのいくつかは、ベンダー拡張を JIS X 0208 のエンコード空間の未割り当て行にエンコードします。また、JIS X 0208 で割り当てられていないコードのほとんどは、新しいJIS X 0213標準によって割り当てられます。

キャラクター名

JIS X 0208 の各文字には名前が付けられています。文字名を使用することで、コードに頼らずに文字を識別することができます。文字名は他の文字セット標準、特にユニバーサルコード化文字セット(UCS/ Unicode ) と調整されているため、これは Unicode などの文字セットへの文字マッピングの 1 つのソースになる可能性があります。たとえば、ISO/IEC 646国際参照バージョン ( US-ASCII ) の列 4 行 1 にある文字と、JIS X 0208 の行 3 セル 33 にある文字は、どちらも「LATIN CAPITAL LETTER A」という名前です。したがって、ASCII の 4/1 にある文字と JIS X 0208 の 3-33 にある文字は同じ文字と見なすことができます (ただし、実際には、ASCII が別途提供されるエンコーディングのため、JIS X 0208 文字には別のマッピングが使用されます)。逆に、ASCII 文字 2/2 (引用符)、2/7 (アポストロフィ)、2/13 (ハイフンマイナス)、および 7/14 (チルダ) は、この標準には存在しない文字であると判断できます。

非漢字の文字名は大文字のローマ字、スペース、ハイフンを使用する。非漢字には日本語通用名が与えられているが、これらの名前に関する規定は存在しない。^{[k]一方、漢字の名前は、}UCS / Unicodeのコードの対応する16進表現に従って機械的に設定される。漢字の名前は、 Unicodeコードポイントの前に「CJK UNIFIED IDEOGRAPH-」を付けることによって得ることができる。たとえば、行16のセル1（亜）はUCSのU+4E9Cに対応するため、「CJK UNIFIED IDEOGRAPH-4E9C」という名前になります。漢字には日本語の通用名は与えられていない。

漢字セット

概要

JIS X 0208 は、1 バイトあたり 7 ビットまたは8 ビットの 2 バイトコードに対応する 6879 個のグラフィカル文字のセットを規定しています。JIS X 0208 では、これを漢字集合 (漢字集) と呼び、6355個の漢字と、ラテン文字や仮名などの524 個の非漢字(非漢字)が含まれます。

特殊文字: 行 1 と行 2 を占めます。「表意文字スペース」 ( )、日本語のカンマ、ピリオドなど、 18 個の記述記号(記述記号、きじゅつきごう)があります。濁点や半濁点などの8 つの発音記号。仮名または漢字に準じるもの、仮名または漢字に準じるもの、反復記号などの10 文字。 22かっこ記号(括弧記号、かっこきごう) ; 45 の数学記号(学術記号、学術季語) ;通貨記号と郵便記号を含む32 個の単位記号、合計 147 文字。
数字: 3 行目の一部を占めます。「0」から「9」までの 10 桁の数字です。
ラテン文字: 3 行目の一部を占めます。英語のアルファベットの大文字と小文字の 26 文字、合計 52 文字です。
ひらがな: 4 行目を占めます。48 個の無声仮名 (旧式の「 wi 」と「 we 」を含む)、20 個の濁点仮名、 5 個の半濁点仮名、軟口蓋化音および同化音用の小仮名 10 個の合計 83 文字が含まれます。
カタカナ: 行 5 を占めます。86 文字があります。ひらがなに相当するカタカナに加えて、小さなカ/ケカナ (ヶ月/ヶ) とヴカナ (ヴ) があります。
ギリシャ文字: 6 行目を占めます。ギリシャ語アルファベットの大文字と小文字の 24 文字 (最後のシグマを除く) で、合計 48 文字です。
キリル文字: 7 行目を占めます。ロシア語アルファベットの大文字と小文字の 33 文字、合計 66 文字です。
箱描き文字: 8 行目を占有します。細いセグメント、太いセグメント、および細いセグメントと太いセグメントの混合、合計 32 個。
漢字: レベル1の16行目から47行目までの2965文字と、レベル2の48行目から84行目までの3390文字の合計6355文字です。

特殊文字、数字、ラテン文字

漢字セットの特殊文字については、 ISO/IEC 646 :1991の国際参照バージョン (IRV) のグラフィック文字セット ( ASCIIに相当) の一部の文字が JIS X 0208 にはありません。前述の 4 つの文字「QUOTATION MARK」、「APOSTROPHE」、「HYPHEN-MINUS」、および「TILDE」があります。最初の 3 つは、漢字セットで異なるコードポイントに分割されています (Nishimura、1978、JIS X 0221-1:2001 規格、セクション 3.8.7)。IRV の「TILDE」には、漢字セット内に対応する文字がありません。

次の表では、問題の ISO/IEC 646:1991 IRV 文字が、JIS X 0208 の複数の同等文字と比較されています。ただし、IRV 文字「TILDE」は、JIS X 0208 の「WAVE DASH」と比較されています。「記号」列のエントリは UCS/Unicode コードポイントを使用しているため、表示の詳細は異なる場合があります。

JIS X 0208 に正確に相当しない ASCII/IRV 文字には、後に JIS X 0213 によってコードポイントが割り当てられました。これらも以下にリストされており、Microsoft による 4 つの文字のマッピングもリストされています。

^ ab 「NEC による IBM 拡張機能の選択」より。JIS X 0208 では割り当てられていないコードポイントを占有します。
^ ab 「IBM 拡張」より。JIS X 0208 の範囲外ですが、Shift_JIS でエンコード可能です。
^ Microsoft は JIS のマイナス記号をハイフンマイナスの全角形式として扱います。
^ ab 波ダッシュは、例えばマイクロソフトなどでは、チルダの全角形式として扱われることがある（チルダ § 波ダッシュの Unicode および Shift JIS エンコードを参照）。ASCII / IRV チルダは、チルダアクセント記号（˜）として現れることもあれば、同じ曲率のダッシュ（∼）として現れることもある曖昧なコードポイントであるが、Windows-1252ではスペースアクセントが別のコードポイントを持っているため、ダッシュの方が一般的である。チルダアクセント用の JIS X 0208 文字はない。JIS X 0213 の文字 1-2-18 は、コード表ではチルダアクセントとして示されている。^[6]

これは、漢字セットが世界で最も普及している非上位互換の文字セットであることを意味し、この規格の弱点の 1 つとして数えられています。

漢字セットと IRV セットに共通する 90 個の特殊文字、数字、ラテン文字があっても、この規格は ISO/IEC 646 の配列には従いません。これらの 90 個の文字は行 1 (句読点) と行 3 (文字と数字) に分割されていますが、行 3 は 62 個の文字と数字のみ ISO 646 の配列に従います (たとえば、4/1ISO 646 の ("A") は2/3 4/1、JIS X 0208 では (つまり 3-33) になります)。

漢字セット内の数字やラテン文字などが「全角英数字」であり、元の実装がIRVと比較して異なる解釈で登場した原因については、これらの非互換性によるものと考えられます。

最初の標準以来、丸数字、測定単位名の合字、ローマ数字などの合成文字（合成文字）を表現することは可能であったが^{[10]、独立した}区点コードポイントは与えられていなかった。情報システムを製造する個々の企業は、文字の構成によって顧客の要求に応じてこれらの文字を表現するよう努力することはできるが、それらを標準に追加することを要求する企業はなく、代わりにそれらを外字として独自に提供することを選択している。

第 4 標準 (1997 年) では、これらすべての文字は現在の位置の前進を伴う文字、つまりスペーシング文字として明示的に定義されました。さらに、文字の合成によって作成してはならないと規定されました。このため、おそらく行 2 セル 82 のオングストローム記号 ( Å ) を除いて、ラテン文字を分音記号で表すことはまったく許可されなくなりました。

ひらがなとカタカナ

JIS X 0208 のひらがなとカタカナは、 JIS X 0201 とは異なり、文字の一部として濁点と半濁点の記号を含んでいます。また、 JIS X 0201 には含まれていないカタカナのヰ（ウィ）とヱ（ウィー）（どちらも現代の日本語では廃止されています）や小文字のヮ（ワ）も含まれています。

JIS X 0208 のかなの配列は、JIS X 0201 のカタカナの配列とは異なります。JIS X 0201 では、五十音は「を」で始まり、五十音順にソートされた小仮名が続き、その後に全角が続きます。かな、これも五十音順です（ウォァィゥェォャッュョッペラエオ……ラリルレロワン）。一方、JIS X 0208では、同じ基本かながグループ化されるように、五十音順、次に「小仮名、全角仮名、濁点付き仮名、半濁点付き仮名」の順にソートされています。その派生語 (ぁあぃいぅうぇえぉお……っつづ……はばぱひびぴふぶぷへべぺほぼぽ……ゎわゐよさをん）。この順序は、かな辞書の参照をより簡単にソートするために選択されました（安岡、2006）。^[l]

前述のように、この規格では、JIS X 0201で以前定義されたカタカナの順序が、JIS X 0208では踏襲されていません。JIS X 0201のカタカナが「半角カナ」となっているのは、この規格のカタカナとの非互換性から生じたものと考えられます。この点も、この規格の弱点の一つです。

漢字

この基準の漢字がどのような資料から選ばれたのか、なぜ第1水準と第2水準に分かれているのか、どのように配置されているのかは、第4基準（1997年）で詳しく説明されています。その説明によると、次の4つの漢字リストに含まれる漢字は、第1基準（1978年）の6349字に反映されています。

標準コード用漢字表（試案）（標準コード用漢字表（試案）、兵順講堂用漢字表（思案））この表は、情報処理学会
漢字コード委員会が1971年に作成したものです。下記「対応分析結果」に掲載されています。、これは 6086 文字のようです。
行政情報処理用基本漢字(行政情報処理用基本漢字、ぎょうせいじょうほうしょりようきほん漢字)
1975 年に行政管理庁によって選定された 2817 文字で構成されています。選定のためのデータとして、「標準コード用漢字表（暫定）」をはじめ、複数の漢字表を対比させた「行政情報処理用漢字の対応分析結果及び使用頻度等に関する報告書」を作成した。「普通漢字選択」（行政情報処理用標準漢字のための漢字の使用頻度および対応分析結果、行政情報処理基準漢字検定の為の漢字の検討）対応分析結果、略して「対応分析結果」。
日本生命収容人名漢字（にほんせいめいしゅうようじんめいかんじ）
「対応分析結果」を構成する漢字リストの1つ。3044文字から構成されています。現在は存在しません。元のリストは最初の起草委員会には存在せず、この漢字リストは「対応分析結果」に従うように標準に反映されました。
国土行政区画総覧用漢字（こくどうぎょうせいくかくそうらんしよう漢字）
「対応分析結果」を構成する漢字表の一つで、3251字からなる。日本地理データセンターが編纂する全国行政地名の一覧表『国土行政区画総覧』に使用されている漢字です。当初の起草委員会はリスト自体を調査しませんでした。このリストで使用されている漢字は「対応分析結果」に準拠しています。

第2水準では4字、第3水準では2字がそれぞれ第2水準に追加され、漢字の総数は6355字となった。また、第2水準では字形の変更や水準間の転置が行われ、第3水準でも字形の変更が行われた。これらについては後述。

レベル分割

第 1 レベルの漢字 2,965 字は、行 16 から 47 を占めます。第 2 レベルの漢字 3,390 字は、行 48 から 84 を占めます。

水準1では、当用漢字、当用漢字訂正案、人名用漢字をベースに、複数の漢字グリフ表に共通する字を選定した。また、JIS C 6260（「都道府県識別コード」（現JIS X 0401））とJIS C 6261（「市区町村識別コード」（現JIS X 0402））を参考にし、日本の都道府県、市区町村などの漢字をほぼ全て水準1に配置した。^[m]さらに、専門家による修正も加えられた。

第2水準は、前述の4大表に掲載されている漢字のうち、第1水準に採用されなかった漢字が対象となっている。後述するように、第1水準の漢字は発音順に並べられていたため、発音が判別しにくい漢字の中には、その基準で第1水準から第2水準に移行したものもあった（西村、1978）。

これらの決定により、大体において、第1水準にはより頻繁に使用される漢字が、第2水準にはより頻繁に使用されない漢字が含まれるが、もちろん、それらは当時の基準で判断されたものであり、時が経つにつれて、翔や煌など、第2水準の漢字がより頻繁に使用されるようになり、逆に、糎や粍など、第1水準の漢字がより頻繁に使用されなくなったものもある。現在の常用漢字のうち、30字が第2水準に該当し、^[n] 、塡󠄀、剝󠄀、頰󠄀の3字は完全に欠落している。^[o]現在の人名用漢字のうち、192字が第2水準に該当し、^{[p] 、} 105字は標準に含まれていない。^[q]

配置

レベル 1 の漢字は、それぞれの「代表的読み」（つまり、この規格の目的のためだけに選ばれた標準的な読み）の順に並べられています。この場合の漢字の読みは、音読みでも訓読みでもかまいません。読みは五十音順に並べられています。^[r]原則として、音読み（漢音）が代表的読みとみなされます。漢字に音読みが複数ある場合は、使用頻度が優勢であると判断される読みが代表的読みとして使用されます（JIS C 6226-1978 規格、セクション 3.4）。音読みがないか、音読みがあまり知られておらず一般的に使用されていない少数の漢字については、訓読みが代表的読みとして採用されました。動詞の訓読みを代表的読みとして使用する必要がある場合は、連用形（修子形ではなく）が使用されます。

例えば、16行目の1～41のセルには、読みが「あ」で始まる41文字が並んでいます。このうち、訓読みでは16-10（葵：音読み「き」、訓読み「あおい」）や16-32（粟：音読み「ぞく」「しょく」、訓読み「あわ」）など22文字が入っています。16-09（逢：音読み「ほう」、訓読み「あ（い）」）や16-23（扱：音読み「そう」「きゅう」、訓読み「あつか」）は、代表読みに使われる連用形動詞のほんの一例です。

異なる漢字間で代表音読みが同じ場合は、音読みの漢字を訓読みの漢字より前に配置します。音読みまたは訓読みが複数の漢字間で同じ場合は、主な部首と画数によって順序付けます。

水準 1 でも水準 2 でも、板字は典型字に忠実に従うように配列されています。たとえば水準 2 では、49 行 88 セル (劍) の直後の文字は、一般的な規則 (この場合は画数) から外れ、49-88 の 3 つの異体字 (劔、劒、剱) が含まれます。^[s]

レベル 2 の漢字は、主な部首と画数の順に並べられています。異なる漢字でもこの 2 つの特性が同じ場合は、読み方で並べられています。

出典不明の漢字

漢字の中には、総合的な漢字辞典には載っていない、出典が不明な漢字もあると指摘されている。例えば、最初の標準が制定されてからわずか1年後、田島（1979）は、角川書店の大型漢字辞典『新字源』にも『大漢和辞典』にも載っていない、略字として意味をなさない漢字を63字確認したと報告し、漢字辞典に載っていない漢字は出典が明確なものから選ぶことが望ましいと指摘した。これらの漢字は幽霊文字、幽霊漢字などと呼ばれるようになった。

第四版起草委員会も、出典不明の漢字の存在を問題視し、初版起草委員会がどのような出典を参考にしたのかを調査したところ、初版起草委員会は漢字収集に「対応分析結果」に大きく依存していたことが判明した。起草委員会が「対応分析結果」を調査したところ、漢字セットに含まれていて漢字網羅辞典に載っていない漢字の多くは、「対応分析結果」に記載されている「日本人名登録漢字」や「全国行政区一覧漢字」から来ていると思われることが判明した。

「対応分析結果」で参照されている「日本人個人登録氏名漢字」については、原典が存在しないことが確認された。「全国行政区一覧」については、第4版起草委員会の笹原弘之が、第1版の開発途中のページに載っている漢字を検討したほか、多くの古文書やNTT電話帳データベースの人名用例を多数参照した。

この徹底的な調査により、委員会は、出典を確信をもって説明できない漢字の数を、隣の表に示すように 12 個にまで減らすことができました。これらのうち、いくつかの字形は、書き写しの誤りによって生じたと推測されています。特に、「妛」は、印刷工が「山」と「女」を切り貼りして「𡚴」を作ろうとしたときにできたと考えられます。その際にできた影が線と間違えられ、「妛」になりました (常用漢字辞典にその図があります)。

漢字異体字の統一

第 4 標準 (1997 年) の仕様によると、統合(包摂、hōsetsu 、 Unicodeの「統合」で使用される用語とは異なりますが、ほぼ同じ概念です)とは、文字の異なる文字形式に関係なく、文字に同じコードポイントを割り当てる操作です。第 4 標準では、許可されるグリフが制限されています。特定の異字グリフがグラフィミックコードポイントに統合される範囲は明確に定義されています。

さらに、この規格の仕様によれば、グリフ（字体、文字通り「文字の体」）は、文字のグラフィカルな表現に関する抽象的な概念であり、文字形状（字形、文字通り「文字の形状」、ある意味では「グリフ」でもあるが、標準化の目的で異なるレベルで区別されている）は、グリフが実際にとるグラフィカルな形状としての表現である（たとえば、グリフが手書き、印刷、画面に表示されるなど）。単一のグリフに対して、具体的かつ視覚的に異なる文字形状が無限に存在する可能性がある。1つのグリフの文字形状間のバリエーションは、「デザインの差」と呼ばれる。

グリフが 1つのコードポイントに統合される範囲は、そのコードポイントの「例示字体」と、その例示字体に適用できる「統合基準」によって決まります。つまり、コードポイントの例示字体はそのコードポイントに適用され、例示字体を構成する部分が統合基準に従って置き換えられたグリフも、そのコードポイントに適用されます。

たとえば、33-46 のグリフの例 (僧) は、部首 9 (亻) と、最終的にソ仮名 (曽) を生み出した漢字で構成されています。また、統合基準 101 には、3 つの漢字が表示されています。最初の漢字は、日本語で最もよく見られる形式 (曽) を取ります。2 番目は、最初の 2 画が部首 12 (数字の 8 を表す漢字の数字:八) を形成する、より伝統的な形式 (曾) を含みます。3 番目は、部首 12 が反転していることを除いて 2 番目と似ています (曾)。したがって、3 つの順列 (僧、僧、僧)はすべて、33 行目のセル 46 のコードポイントに適用されます。

第 4 標準には、初版の正誤表の 1 つを含めて、186 の統一基準があります。

コードポイントの例のグリフが複数の部分グリフで構成されている場合、各部分に統合基準を適用できます。 1 つの部分グリフに統合基準を適用した後は、その部分にそれ以上の統合基準を適用することはできません。また、結果のグリフが別のコードポイントのグリフと完全に一致する場合、統合基準を適用することはできません。

例示グリフは、そのコードポイントの単なる例示に過ぎず、標準によって「承認」されたグリフではありません。また、統一基準は、一般的に使用される漢字に対してのみ、またこの標準のコードポイントに物事を割り当てる目的でのみ使用する必要があります。標準では、一般的に使用されない漢字を例示グリフと統一基準に基づいて作成しないように要求しています。

漢字セットの漢字は、統一基準に従って完全に一貫して選択されているわけではありません。たとえば、41-7は、統一基準72によれば、3画目と4画目が交差する形（彥）と交差しない形（彦）の両方に対応していますが、20-73は交差しない形（顔）にのみ対応し、80-90は交差する形（顏）にのみ対応しています。

第4版では「統一」「統一基準」「例字形」という用語が採用された。第1版から第3版まで、漢字と漢字間の関係は「独立」「対応」「同値」の3種類に分類され、同値と認められる字は「一点に集約される」と説明された。「同値」には、全く同じ形の漢字のほか、字体の違いによる違いがある漢字や字形の差が小さい漢字も含まれていた。

第1規格では、「この規格は、文字の形状の詳細を規定するものではない」（3.1項）と規定され、「この規格は、文字及びその符号の一般的な概念を規定することを目的とするものであり、文字の形状のデザインなどは適用範囲外である」とされている。第2、第3規格でも、文字の形状の具体的なデザインは適用範囲外である旨の注記（1項の注記）が付されている。第4規格でも、「この規格は、図形文字及びそのビットパターンを規定するものであり、個々の文字の使用、具体的なデザインなどは、この規格の適用範囲外である」と規定されている（JIS X 0208:1997、1項）。

互換性の統一基準

第 4 の規格では、「過去の規格との互換性を維持するための包摂規準」（過去の規格との互換性を維持するための統一基準）が定義されています。適用対象は、JIS C 6226-1983 以降の規格と JIS C 6226-1978 との間で字形が大きく異なる 29 コードポイントに限定されます。 29 コードポイントのうち、JIS C 6226-1983 以降の字形は「A」、JIS C 6226-1978 以降の字形は「B」で表示されます。それぞれに、「A」と「B」の両方のグリフを適用できます。ただし、標準との互換性を主張するには、各コードポイントに「A」形式が使用されているか、「B」形式が使用されているかを明示的に示す必要があります。

文字エンコーディング

JIS X 0208で規定されている符号化方式

JIS X 0208:1997 では、第 7 条と付録 1 および 2 を組み合わせて、合計 8 つのエンコード方式を定義しています。

以下の説明では、「CL」（制御左）、「GL」（グラフィック左）、「CR」（制御右）、「GR」（グラフィック右）領域は、それぞれ、列/行表記で、0/0 から 1/15、2/1 から 7/14、8/0 から 9/15、10/1 から 15/14 です。各コードでは、2/0 にグラフィック文字「SPACE」、7/15 に制御文字「DELETE」が割り当てられています。CL領域には、 C0 制御文字（JIS X 0211で定義され、 ISO/IEC 6429と一致する）が割り当てられています。

漢字の7ビットエンコーディング: 規格自体に規定されています。JIS X 0208 の 2 バイトセットが GL 領域に割り当てられます。
漢字の8ビットエンコーディング: 標準自体に規定されています。7 ビットエンコーディングと同じですが、8 ビットバイトで定義されています。CR 領域は未使用の場合もあれば、 JIS X 0211 のC1 制御文字をエンコードする場合もあります。GR 領域は未使用です。
国際基準版 + 漢字7ビットエンコーディング: 標準規格自体に規定されています。シフトイン制御文字は、ISO/IEC 646 :1991 IRV（国際参照バージョン、 US-ASCIIに相当）をGL領域に指定します。シフトアウトは、 JIS X 0208 ダブルバイトセットを同じ領域に指定します。
ラテン文字 + 漢字の 7 ビットエンコーディング: 規格自体に規定されています。IRV+7 ビットと同様ですが、ISO/IEC 646:IRV がISO/IEC 646:JP ( JIS X 0201のローマ字セット) に置き換えられています。
国際基準版 + 漢字用8ビットエンコーディング: 規格自体に規定されています。ISO/IEC 646:IRV は GL 領域に、JIS X 0208 は GR 領域に割り当てられています。これは実質的にEUC-JPのサブセットであり、 JIS X 0201の半角カタカナとJIS X 0212の補助漢字を除いたものです。
ラテン文字 + 漢字の8ビットエンコーディング: 標準規格自体に規定されています。IRV+8 ビットと同様ですが、ISO/IEC 646:IRV が ISO/IEC 646:JP に置き換えられています。
シフトコード文字セット: 付録 1:「シフト記号化表現」に規定。シフト JISの正式な定義。
RFC 1468 コード化文字セット: 付録2「RFC 1468符号化表現」（RFC 1468符号化表現）に規定されています。RFC 1468で正式に定義されているISO-2022-JPに似ていますが、 8ビットバイトで定義されています。一方、ISO-2022-JPは7ビットバイトで定義されています。

第4標準で規定されているエンコーディングのうち、「シフト」コード化文字セットのみがIANAに登録されています。^[11]ただし、他のいくつかのエンコーディングは、他の場所で定義されているIANA登録エンコーディング（EUC-JPおよびISO-2022-JP）と密接に関連しています。

JIS X 0202 / ISO 2022 のエスケープシーケンス

JIS X 0208 は、ISO 2022 /JIS X 0202 (ISO-2022-JP はそのサブセット)内で使用できます。 JIS X 0208 を 4 つの ISO 2022 コードセットのそれぞれに指定するためのエスケープシーケンスを以下に示します。ここで、「ESC」は制御文字「エスケープ」(0x1B、つまり 1/11) を指します。

ESC 2/4 で始まるエスケープシーケンスは、マルチバイト文字セットを選択します。ESC 2/6 で始まるエスケープシーケンスは、今後の文字セット選択のリビジョンを指定します。JIS C 6226:1978 は、マルチバイト 94 セット識別子バイト 4/0 (ASCII に相当@) によって識別されます。JIS C 6226:1983 / JIS X 0208:1983 は、マルチバイト 94 セット識別子バイト 4/2 ( B) によって識別されます。JIS X 0208:1990 も 94 セット識別子バイト 4/2 によって識別されますが、リビジョン識別子 4/0 () で区別できます@。

ASCII と JIS X 0201 の重複エンコーディング

この規格の漢字セットを ISO/IEC 646:1991 IRV グラフィック文字セット ( ASCII ) または JIS X 0201 のラテン文字用グラフィック文字セット ( JIS-Roman ) のいずれかで使用する場合、両方のセットに共通する文字の扱いが問題になります。特別な対策を講じない限り、両方のセットに含まれる文字がすべて 1 対 1 でマッピングされるわけではなく、1 つの文字に複数のコードポイントが割り当てられる場合があります。つまり、エンコーディングが重複する可能性があります。

JIS X 0208:1997では、文字が両セットに共通する場合、基本的に漢字セット内のコードポイント（2つのコードポイントのうちの1つ）の使用を禁止し、重複したエンコードを排除しています。同じ名前の文字は同じ文字であると判断されます。

たとえば、ASCII のビットパターン 4/1 に対応する文字の名前と、漢字セットの行 3 セル 33 に対応する文字の名前は、どちらも「LATIN CAPITAL LETTER A」です。漢字の国際参照バージョン + 8 ビットコードでは、ビットパターン 4/1 によっても、漢字セットの行 3 セル 33 (10/3 12/1) に対応するビットパターンによっても、文字「A」(つまり「LATIN CAPITAL LETTER A」) が表現されます。この規格では、重複するエンコードを排除するために、「10/3 12/1」ビットパターンの使用を禁止しています。

漢字セットのコードポイントの文字を「全角文字」として扱い、ASCII や JIS-Roman の文字を別の文字として扱う実装を考慮して、漢字セットのコードポイントの使用は、下位互換性のためにのみ許可されます。たとえば、下位互換性のために、漢字の国際参照バージョン + 8 ビットコードにおける 10/3 12/1 を全角の「A」に対応するものと見なすことが許可されています。

漢字セットを ASCII または JIS-Roman と併用する場合、標準に厳密に従っていても、文字の一意のエンコードは保証されません。たとえば、漢字の国際参照バージョン + 8 ビットコードでは、文字 "HYPHEN-MINUS" のビットパターン 2/13 を使用してハイフンを表すこと、および文字 "HYPHEN" の漢字セットの行 1 セル 30 (ビットパターン 10/1 11/14) を使用してハイフンを表すことが有効です。さらに、標準ではどちらを何に使用するか定義されていないため、ハイフンには一意のエンコードが 1 つ割り当てられません。同じ問題がマイナス記号、引用符などにも影響します。

また、漢字セットを別コードとして利用したとしても、文字の一意のエンコードが実現される保証はありません。しかし、多くの場合、1行目1セル目の全角「IDEOGRAPHIC SPACE」と半角スペース（2/0）が共存しています。この2つをどのように区別すべきかは自明ではなく、標準でも規定されていません。

実際に使用されているエンコード方式の比較

^つまり、 8 ビットのクリーンな伝送は必要ありません。
^ つまり、特定の文字をエンコードするために使用されるシーケンスは、前の文字が何であったかに関係なく、常に同じです。状態 (コンピューターサイエンス)を参照してください。
^ ab ISO-2022-JP はステートフルエンコーディングです。すべての文字セットは 0x21～7E でエンコードされ、ANSI エスケープを使用して切り替えられます。したがって、初期状態では ASCII ですが、非 ASCII 文字のシーケンス全体を ASCII バイトでエンコードできます。
^ JIS X 0201 カタカナは JIS X 0202 および ISO 2022 で使用できますが、共通の拡張機能ではありますが、基本 ISO-2022-JP プロファイルには含まれていません。
^ JIS X 0212 は JIS X 0202 および ISO 2022 で使用可能であり、ISO-2022-JP-1 および ISO-2022-JP-2 プロファイルに含まれていますが、基本 ISO-2022-JP プロファイルには含まれていません。
^ Shift_JIS の 0x21–7E の 1 バイト文字は、8 ビット JIS X 0201 のスーパーセットとなるため、適切にはISO-646-JPですが、多くの場合、2 か所のみが異なる ASCII としてデコードされます (必ずしも表示されるとは限りません)。
^ 一部の (すべてではない) ASCII バイトは、Shift_JIS の 2 バイト文字の 2 番目のバイトとして表示されますが、最初のバイトとして表示されることはありません。したがって、2 つ以上の ASCII バイトのシーケンスでは、2 番目のバイト以降は必ず ASCII (または ISO-646-JP) 文字になります。
^ ab パック形式の EUC は ISO 2022 メカニズムに基づいており、文字セット指定が事前に調整されています。文字セット指定のエスケープとシフトのロックは回避されますが、単一シフトの使用は非ステートフルな方法で実装できます。ただし、ISO 2022 の制約は従われます。
^ EUC-JPの1バイト文字0x21～7Eは一般にASCIIとみなされますが、ISO-646-JPとして扱われることもあります。
^ Shift_JIS とは異なり、EUC-JP は、JIS X 0201 カタカナ (シングルシフト付き) の表現が異なるため、事前の変換なしではプレーンな 8 ビット JIS X 0201 入力を処理できません。
^ EUC-JP の JIS X 0212 は必ずしも実装されているわけではありません。
^ エンコーディング自体の特性に加えて、Unicode 形式には、基礎となる文字セットに起因するさらなる利点があります。Unicode は JIS コード化文字に限定されず、UCS 全体 (JIS コード化文字の全レパートリーを含む) を表現できるため、国際的な使用に適しています。また、Unicode は、より広範な基本レパートリーと指定された私的使用領域により、独自の拡張機能の衝突による悪影響も少なくなります。
^ UTF-8 でエンコードされたテキストのビット単位のフレームシフトのほとんどは無効な UTF-8 を生成しますが、1 ビット以上フレームシフトしても有効な UTF-8 のままになる文字シーケンスを構築することは可能です。
^ Microsoft のみ。
^ GB 18030 と GBK は GB/T 2312 の EUC-CN 形式の拡張ですが、EUC-JP (または元の EUC-CN) とは異なり、EUC または ISO 2022 の制約には従いません。
^ 理論上、UTF-32 は 32 ビットのダブルワードのみで自己同期しますが、21 ビットの値を表すために 32 ビットの値を使用するということは、実際には、UTF-32 には各文字の上位に少なくとも 11 個の連続したゼロビットが含まれることを意味します。これは通常、関係するコードポイントに応じて、文字の境界に揃えるために使用できます。

歴史

日本工業規格は制定、再確認、または改訂されてから5年が経過するまで、以前の規格は再確認、改訂、または廃止の手続きを経ます。制定以来、3回の改訂が行われており、現在は4番目の規格が有効です。

最初の標準

最初の規格は、1978年1月1日に通商産業大臣によって制定されたJIS C 6226-1978 「情報交換用漢字記号系」（Jōhō Kōkan'yō Kanji Fugōkei）です。略して78JISとも呼ばれます。工業技術院の委託を受けて、JIPDEC漢字コード標準化調査研究委員会が原案を作成しました。委員長は森口重一でした。

このコードには、453の非漢字（ひらがな、カタカナ、ローマ字、ギリシャ語、キリル文字、句読点を含む）と6349の漢字（第1水準漢字2965字、第2水準漢字3384字）の合計6802文字が含まれていた。^[12]まだボックス描画文字は含まれていなかった。標準自体は、写研株式会社の石井明朝書体で設定された。

第二標準

2番目の規格JIS C 6226-1983 「情報交換用漢字記号系」（Jōhō Kōkan'yō Kanji Fugōkei）は、 1983年9月1日に最初の規格を改訂した。83JISとも呼ばれる。産業技術総合研究所の委託を受けて、JIPDEC漢字コード関連JIS委員会が原案を作成した。委員長は本岡徹であった。

第2次規格の原案は、常用漢字の公布、人名用漢字の施行、郵政省による日本語テレテックスの標準化などの要因を考慮して作成され、さらに、JIS C 6234-1983（24ピクセルマトリクスプリンタ文字形式、現在のJIS X 9052）に合わせるために次の修正が行われました。

特殊文字の追加: 特殊文字には39文字が追加されました。この39文字は、JICST勧告やJIS Z 8201-1981（数学記号）やJIS Z 8202-1982（量・単位・化学記号）などの規格から、組成で表現できないものが選ばれました。
新たに追加されたボックス描画文字: 32個のボックス描画文字が追加されました。
板字コードポイントの交換: 22の異体字の漢字のコードポイントが入れ替わり、レベル2の異体はレベル1に移動され、その逆も同様となった。^[12]^[13]たとえば、最初の標準の（レベル1の）36行目セル59（壺）は、（レベル2の）52行目セル68に移動され、もともと52行目セル68（壷）にあったポイントは、今度は36行目セル59に移動された。
第2レベルの漢字の追加: 第1水準の3文字と第2水準の1文字に、第2水準の漢字として、84行目のこれまで割り当てられていなかったコードポイントに新しいコードポイントが与えられた。それらの各コードポイントの板字は、新たに元の場所に割り当てられました。 ^[14]たとえば、第2標準の84行目のセル1（堯）は、第1水準の漢字（尭）として第22行目のセル38に含まれていない別の形を収容するためにそこに移動されました。
文字形態の改変: 約300字の漢字の字形が改正された。^[15]

約300字の漢字字形の変更の中には、康熙字典の字形であった第一水準字形の多くが異体字、特により簡略化された字形（例えば、略字や拡張新字体）に変更された。例えば、大幅に変更されたために批判の対象となることが多いコードポイントには、18行10セル（78JIS:鷗、83JIS:鴎）と38行34セル（78JIS:瀆、83JIS:涜）があります。

康熙字形の異体字から離れた小さな変更が多数ありました。たとえば、25 行目の 84 セル (鵠) では、画の一部が失われました。また、第 1 水準の漢字の一部のグリフが康熙字形ではない場合、一部は康熙字形に変更されました。たとえば、80 行目の 49 セル (靠) では、画の一部が追加されました (つまり、25-84 で失われた画の同じ部分)。

第一基準の本来の意図を明らかにするために、これらは第四基準の統一基準のパラメータに該当することになった。上記の例（「鵠」と「靠」）の形式の違いは、統一基準42（構成要素「告」に関して）のパラメータに該当する。^[t]

字形の変更点の大部分は、第1水準漢字と第2水準漢字の相違点である。具体的には、第1水準漢字の方が第2水準漢字よりも簡略化が頻繁に行われ、第1水準漢字に適用された簡略化（例：「潑」を「溌」、「醱」を「醗」）は、第2水準漢字には原則適用されなかった（「撥」はそのまま）。前述の25-84（鵠）と80-49（靠）も同様に、前者は第1水準、後者は第2水準であるため、異なる扱いが与えられた。それでも、水準に関係なく変更された部分もあり、たとえば、「戸」と「冬」の構成要素を含む字は、第1水準漢字と第2水準漢字で異なる扱いを受けなかった。

ただし、29 個のコードポイント (前述の問題のある 18-10 や 38-34 など) については、4 番目の標準で継承された形式が最初の標準の本来の意図と矛盾しています。これらのコードポイントについては、以前の標準との互換性を維持するための特別な統一基準があります。

日本工業規格（情報関連分野）に新しい「X」カテゴリが導入されたとき、2番目の規格は1987年3月1日にJIS X 0208-1983 ^[12]に改名されました。

第三標準

3番目の規格JIS X 0208-1990 「情報交換用漢字記号」（Jōhō Kōkan'yō Kanji Fugō）は、 1990年9月1日に2番目の規格を改訂したものです。略して90JISとも呼ばれます。産業技術総合研究所の委託を受けて、日本規格協会のJIS X 0208改訂委員会が草案を作成しました。委員長は田島一雄でした。

225字の漢字が変更され、第2水準に2字（84-05「凜」と84-06「熙」）が追加された。これは、すでに含まれていた2字（49-59「凛」と63-70「煕」）の板字化解除であった。一部の変更と2つの追加は、1990年3月に追加された118字の人名用漢字に対応していた。 ^[12]標準自体は平成明朝で設定された。

第4標準

第4規格JIS X 0208:1997 「情報交換用7ビットおよび8ビットの全角符号化漢字集合」 （7ビット及び8ビットの2バイト情報交換用記号化漢字セット、ナナビットオヨビハチビットノ）二バイト情報公監用扶護加漢字習合）は、 1997 年 1 月 20 日に第 3 の規格を改訂しました。97JISとも呼ばれます。短い。産総研の委託を受けて、JSAのコード化文字セット調査研究委員会が草案を作成した。委員長は芝野康二氏であった。

この改訂の基本方針は、文字セットの変更は行わず、あいまいな規定を明確にし、比較的使いやすい規格にすることであった。追加、削除、コードポイントの並べ替えは行わず、例のグリフも例外なくそのまま残した。ただし、規格の規定は全面的に書き直し、または補足した。第3版は解説なしで65ページだったが、第4版は解説なしで374ページとなった。

改訂の主なポイントは次のとおりです。

エンコード方式の定義: 第3規格までは、JIS X 0202のコード拡張に基づいたエンコード方式のみが定義されていました。これは、コード化された文字セットとしては異例なことです。第4規格では、コード拡張を目的としたエスケープシーケンスを使用しないエンコード方式が定義されました。
未割り当てコードポイントの使用の一般的な禁止と未割り当てコードポイントの使用方法の定義: 第3版では、規格外の説明で、一部の未割り当てコードポイントについては外字を割り当ててもよい箇所があるかのような記述がありました。第4版では、未割り当てコードポイントの使用は原則禁止と明記されました。また、未割り当てコードポイントの使用条件も明記されました。
重複したエンコーディングの一般的な排除: 各文字には、他の規格の文字名に対応する「文字名」が与えられ、また、ISO/IEC 646 の国際基準版や JIS X 0201 と併用するためのエンコード方式も規定されました。JIS X 0208 をいずれかと併用する場合、同じ名前の文字に割り当てられた 2 つのコードポイントのうち、1 つだけが許可されるため、エンコードの重複は基本的に排除されました。
漢字の由来の調査: これまで標準に収録された漢字のうち、『康熙字典』にも『大漢和辞典』にも収録されていない漢字が特定された。そこで、これらの漢字が最初の標準の編纂時にどのような目的で収録され、どのような出典から来たのかが調査された。
漢字統一基準の定義: 初版の起草資料などをもとに、各コードポイントが表すグリフの範囲について初版の趣旨を再現するとともに、漢字グリフの統一基準を明確にしました。
事実上の標準を含める: 第 4 標準の時点では、Shift JISとISO-2022-JPのエンコード方式が、それぞれパーソナルコンピューティングと電子メールのデファクトスタンダードとなっていました。これらのエンコード方式は、「Shift-Coded Representation」と「RFC 1468-Coded Representation」(前述) として含まれていました。

後継者

JIS X 0213（拡張漢字）は、「JIS X 0208が当初から意図していた現代の日本語をエンコードするのに十分な文字セットを提供することを目標に」設計されました。^[16] JIS X 0208の漢字セットを拡張した文字セットを定義します。JIS X 0213の起草者は、JIS X 0208からJIS X 0213への移行を推奨しており、その利点の1つは、JIS X 0213が表外漢字グリフリストや新しい人名用漢字と互換性があることです。

起草者の予想に反して、JIS X 0213 の採用は 2000 年の制定以来、決して速いペースではありませんでした。JIS X 0213:2004 の起草委員会は (2004 年に) 「『情報システムの大多数が共通して使用できるのは JIS X 0208 のみである』という状況が依然として続いている」と書いています (JIS X 0213:2000、附属書 1:2004、セクション 2.9.7)。

パーソナルコンピューティング分野で主流のオペレーティングシステム(したがって、主流のデスクトップ環境) であるMicrosoft Windowsでは、 2006 年 11 月にリリースされたWindows Vista以降、JIS X 0213 のレパートリーが組み込まれています。Mac OS Xは、バージョン 10.1 (2001 年リリース)以降、JIS X 0213 と互換性があります。Linuxなどの多くのUnix 系 OS では、必要に応じて (オプションで) JIS X 0213 をサポートできます。したがって、時間が経てば、パーソナルコンピュータでの JIS X 0213 のサポートは、最終的な採用の妨げにはならないと考えられます。

JIS X 0213 の起草者の中には、JIS X 0213 が採用される前に、JIS X 0208 と JIS X 0213 が混在することを期待する人もいます (佐藤、2004)。しかし、JIS X 0208 は今のところ使用され続けており、標準として存続すると予測する人も多くいます。JIS X 0213 が JIS X 0208 に取って代わって一般的な使用法となるには、克服しなければならない障壁があります。

現在日本の携帯電話で使用されている文字レパートリーは、JIS X 0208 に基づいています^{[いつ? ]。これらを JIS X 0213 互換に移行するという公式発表された計画はまったくありません。携帯電話は、}電子メールの送信やWorld Wide Webへのアクセスに広く普及し、一般的に利用されている媒体であり、現在では日本語のテキスト通信の普及の一端を担っています (日本の携帯電話文化を参照)。そのため、携帯電話の普及が他の場所での使用を妨げています。
JIS X 0213 は、統一基準の観点では JIS X 0208 と厳密に上位互換ではありません (後述)。JIS X 0208 を使用し、その統一基準を厳密に遵守している大規模なアーカイブ (書誌データベースや青空文庫など) の場合、すべてのデータを JIS X 0213 に変換し、同じテキストの完全性基準を維持することは非常に困難な作業になると考えられます。
実際には、多くのシステムで JIS X 0208 に未割り当てのコードポイントが定義され、使用されています。たとえば、Windows では IBM や NEC の拡張文字やユーザー定義文字領域が割り当てられています ( Windows-932を参照)。携帯電話では、そのような場所に絵文字が割り当てられています。これらの外字のコードポイントは、JIS X 0213 コードが使用するコードポイントと競合するため、これらのシステムを JIS X 0208 から JIS X 0213 に移行するには、多少の困難が伴います。UCS / Unicodeに移行して、そこから JIS X 0213 レパートリーを使用する計画もありますが、システム管理者は、UCS/Unicode のサロゲートペアや文字構成の実装が十分に安定していると判断できるまでは、それらの実装を必要とする JIS X 0213 レパートリーを使用することを躊躇することになるでしょう。
JIS X 0213 によって提供される改善は、主に、JIS X 0208 にすでに存在する文字ほど頻繁に使用されない文字の領域にあります。余分なグリフの使用を減らすために実装する必要があるグリフの数はほぼ 2 倍になるため、多くの場合、特にリソースが制限されている場合は、投資収益率が低くなる可能性があります。

実装

JIS X 0208 / JIS C 6226 は主に文字セットであり、厳密に定義された文字エンコーディングではないため、いくつかの企業が独自の文字セットのエンコーディングを実装しています。

Apple : MacJapanese (Shift_JIS ベース)
富士通：JEF漢字コード（EBCDICベース）
日立：KEIS（EBCDICベース）
IBM : IBM-932およびIBM-942 (どちらも Shift_JIS ベース)を含む各種
Microsoft : Windows-932 (Shift JIS ベース)
NEC : JIPS

これらのいくつかは、標準の未割り当て領域の代わりにベンダー固有の文字割り当てを組み込んでいます。これには、Windows-932 と MacJapanese、およびNECのPC98文字エンコーディングが含まれます。IBM-932 と IBM-942 にもベンダー割り当てが含まれていますが、これらは JIS X 0208 に使用される領域外に含まれています。

他の規格との関係

ISO/IEC 646 IRV および ASCII

前述のとおり、漢字セットは ISO/IEC 646:1991 IRV (ASCII) グラフィック文字セットと上位互換性がありません。漢字セットと IRV グラフィック文字セットは、JIS X 0208 (漢字の場合は IRV + 7 ビットコード、漢字の場合は IRV + 8 ビットコード) で指定されているように一緒に使用できます。EUC-JPでも一緒に使用できます。

JIS X 0201

漢字セットには、 JIS X 0201のラテン文字のグラフィック文字セットに含まれる 3 つの文字(2/2 (引用符)、2/7 (アポストロフィ)、および 2/13 (ハイフンマイナス)) が含まれていません。漢字セットには、JIS X 0201 のカタカナのグラフィック文字セットに含まれるすべての文字が含まれています。

JIS X 0208 で規定されているように、漢字セットとラテン文字のグラフィック文字セットは一緒に使用できます (ラテン文字 + 漢字用 7 ビットコード、ラテン文字 + 漢字用 8 ビットコード)。 JIS X 0208 で規定されているように、漢字セット、ラテン文字のグラフィック文字セット、および JIS X 0201 のカタカナのグラフィック文字セットは一緒に使用できます (シフトコード化文字セット、つまりシフト JIS )。 EUC-JPでは、漢字セットとカタカナのグラフィック文字セットを一緒に使用できます。

JIS X 0212

JIS X 0212 (補助漢字) は、JIS X 0208 にない文字を必要とする情報処理の目的で、コードポイントを持つ追加の文字を定義します。メインの JIS X 0208 漢字セット内で文字を割り当てるのではなく、補助文字を含む 94 x 94 の 2 番目の漢字セットを定義します。

JIS X 0212 は、 EUC-JPで JIS X 0208 と一緒に使用できます。また、JIS X 0208 と JIS X 0212 はどちらも UCS/Unicode の漢字統合のソース標準であるため、両方のセットの漢字を 1 つの Unicode 形式の文書に含めることができます。

JIS X 0208第2版で変更されたコードポイントのうち、JIS X 0212では28のコードポイントが変更前の字形を反映している。^[17]また、JIS X 0212では、JIS X 0208が非漢字として割り当てていた「閉印」（1行目セル26の〆）を漢字（ 16行目セル17の乄）として再割り当てしている。これら以外にJIS X 0212とJIS X 0208に共通する文字はなく、単独では汎用性がない。

しかし、JIS X 0208の第4版では、JIS X 0212との関連が全く定義されていませんでした。これは、第4版JIS X 0208規格の起草委員会が、JIS X 0212の選択および識別方法について批判的な意見を持っていたためだと考えられています。^[18]文字の意味や選択の根拠が適切に文書化されておらず、目的の漢字がそのレパートリーの漢字と一致するかどうかを識別することが困難でした。^[19]第4版のテキストでは、JIS X 0212の文字選択の問題点を指摘するとともに、「文字の選択が不可能なだけでなく、併用も不可能であると考えられるため、JIS X 0212との関連が全く定義されていません。」（セクション3.3.1）と述べています。

JIS X 0213

JIS X 0213（拡張漢字）は、JIS X 0208の漢字セットを拡張した漢字セットを定義しています。この規格によれば、「JIS X 0208が当初から意図していた現代の日本語をエンコードするのに十分な文字セットを提供することを目標に設計されています。」^[16]

JIS X 0213 の漢字セットには、JIS X 0208 の漢字セットで表現できるすべての文字が組み込まれており、多くの追加が行われている。合計で、JIS X 0213 は 94 x 94 の 2 つの面(面、面)内に 1183 の非漢字と 10,050 の漢字 (合計 11,233 文字)を定義している。最初の面 (非漢字および第 1 水準から第 3 水準の漢字) は JIS X 0208 に基づいており、2 番目の面 (第 4 水準の漢字) は JIS X 0212 の未割り当て行内に収まるように設計されており、EUC-JPで使用できる。^{[20] JIS X 0213 では、Shift_JIS の変種である}Shift_JISx0213も定義されており、JIS X 0213 全体をエンコードできる。

ほとんどの場合、JIS X 0213 プレーン 1 は JIS X 0208 のスーパーセットです。ただし、JIS X 0213 の一部のコードポイントには、JIS X 0208 とは異なる統合基準が適用されます。その結果、統合されたために 1 つの JIS X 0208 コードポイントで表されていた漢字グリフの一部のペアには、JIS X 0213 では別のコードポイントが割り当てられます。たとえば、JIS X 0208 の行 33 セル 46 のグリフ (上記の「僧」) は、右側のコンポーネントにより、いくつかの異形を統合します。 JIS X 0213では、2つの形式（構成要素「丷」を含む形式）が第1面第33行第46セルに統合されており、もう1つの形式（構成要素「八」を含む形式）は第1面第14行第41セルに配置されている。したがって、JIS X 0208第33行第46セルをJIS X 0213第1面第33行第46セルにマッピングするか、第1面第14行第41セルにマッピングするかは自動的には決定できない。^[u]これにより、JIS X 0213起草委員会が認めているように、JIS X 0213がJIS X 0208と上位互換であると考えられる範囲が制限される。^[21]

しかし、大部分は、 JIS X 0208のm行nセルは、JIS X 0213の1面m行nセルに対応しており、実際には大きな混乱は生じません。これは、ほとんどの書体がJIS X 0208に例示されているグリフを使用するようになり、ほとんどのユーザーが統一基準を意識していないためです。

ISO/IEC 10646 と Unicode

JIS X 0208 の漢字セットは、ISO/IEC 10646 (UCS) およびUnicodeにおける漢字統合の元のソース標準の 1 つです。JIS X 0208 のすべての漢字は、UCS/Unicode の基本多言語面(BMP)の独自のコードポイントに対応しています。

JIS X 0208 の非漢字も、BMP の独自のコードポイントに対応しています。ただし、一部の特殊文字については、一部のシステムでは UCS/Unicode の対応 (JIS X 0208:1997 で指定された文字名に基づく) とは異なる対応を実装しています。

脚注

説明的

^ ギリシャ語の発音区別符号と末尾のシグマが欠落しています。
^ abcd (撤回)
^ JISおよびApple: U+2014。Unicode
、^[b] MicrosoftおよびWHATWG: U+2015。
^ MicrosoftおよびWHATWG: U+FF5E。Unicode
、^[b] JISおよびApple: U+301C。
^ MicrosoftおよびWHATWG: U+2225。Unicode
、^[b] JISおよびApple: U+2016。
^ Microsoft: U+FF0D。Unicode
、^[b] JIS および Apple: U+2212。WHATWG
: デコード時に U+FF0D、例外的にエンコード時に両方。
^ abcd JIS X 0213で追加
^ 平成以前のオリジナルバージョンの拡張機能には存在しない。コード位置はNECまたはMicrosoftによって選択された。^[5] Macintosh PostScriptには存在しない。
^ abcdefghi 1983年に2行目に追加され重複した。JIS X 0213ではここではエンコードされていない（割り当てられていないまま）が、^{[5] MicrosoftとWHATWGではここでは重複エンコードされている。Macintosh PostScriptエンコードに関しては、}macOSライブラリ関数でデコードされた形式にPrivate Use U+F87Fが付加され、ラウンドトリップが可能になっている。
^ エスケープシーケンスに使用する符号化文字セットの国際登録簿に登録されているコード表にあるように、第4次規格（1997年）以前は、区と点を英語でそれぞれsection、positionと呼んでいた。英語が変わった背景としては、ISO/IEC 10646-1:1993を翻訳したJIS X 0221-1995（UCS）規格では、group、plane、row、cellをそれぞれgun（群）、men（面）、ku（区）、ten（点）と訳せるようになっている。ただし、JIS X 0208のrowとcellとUCSのrowとcellは別の概念である。
^ キャラクター名はローマ字で表記され、国際的に使用されているため、生物の学名のような国際的な慣習と言えます。このアナロジーで言えば、キャラクターの日本語の通称は生物の通称に似ています。
^ かな順検索や並び替えをフル機能で実現するには、単語の読みや繰り返し記号などを考慮する必要があります。日本語文字列の並び替えは、JIS X 4061（日本語文字列の照合順序）に規定されています。
^安岡（2001a）によれば、 いくつか偶然の見落としがあったようだ。例えば、印旛郡の旛（58-57）と熊本県酒々井郡の泗（61-89）はレベル1には含まれていないと指摘している。
^ リスト:丼 · 傲慢 · 対策を講じる · 言い換え · 臭い · 対策を立てる · · 怖い · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ( · ) 󠄁曖󠄀楷󠄀鬱󠄀璧󠄀瘍󠄀箋󠄀籠󠄀緻󠄀羞󠄀訃󠄀諧󠄀貪󠄀踪󠄀辣󠄀錮
^ 常用漢字「𠮟󠄀」は、正式な異体字である「叱」のみに含まれています。
^ リスト:乘 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·。凛Ơ欧 ·対策を剩 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·: · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·專 · · · · · · · 峽 · 崚 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 󠄁拜󠄀拂󠄀搜󠄀搖󠄀攝󠄀收󠄀敍󠄀昊󠄀昴󠄀晏󠄀晄󠄀晝󠄀晨󠄀晟󠄀暉󠄀曉󠄀檜󠄀栞󠄀條󠄀梛󠄀椰󠄀榮󠄀樂󠄀樣橙العلى المزية المزية المزيل 󠄀漱󠄀滯󠄀澁󠄀澪󠄀濕󠄀煌󠄀燒󠄀燎󠄀燿󠄀爭󠄀爲󠄀狹· 默loid · 獸 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·祕loidん· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·: · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·。 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·。釀󠄀釉瓊瓊瓊瓊瓊瓊· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·るためためにのためにのためにのためにのためにのために。
^ リスト:焰 · · · · · · 鷗 · Whole · 繫 · · · · · · · 繫 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·。禱󠄀萊󠄀蠟󠄀增󠄀德󠄀橫󠄀瀨󠄀猪󠄀神󠄀祥󠄀福󠄁綠󠄀緖󠄀薰 · · · · · · 諸 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · *海󠄀渴󠄀漢󠄁器󠄁祈󠄀虛󠄀響󠄁勤󠄁謹󠄀揭󠄀擊󠄀穀󠄀祉󠄁視󠄁煮󠄀社󠄁者󠄁臭󠄁祝󠄀暑󠄁署󠄀涉󠄀狀󠄀節󠄁祖󠄁僧󠄁層󠄁巢󠄀憎󠄀贈󠄁卽󠄀嘆󠄀著󠄁徵󠄀禎󠄁突󠄁難󠄀梅󠄀繁󠄁晚 · · · · · · · · · · · · · · · · · · · · · · · · · · · · ( · )淚 · loid · 類 · ® ® · 曆 · 糸 · 歷 · 糸 · 練 · · 練 · 期 · 鍊 · · · · · · · · ·
^ 19行目の30番目と31番目のセルでは、代表的な読みの順序が逆になっています。その結果、正しい順序は「蛙（かえる）」の次に「馨（かおり）」であるところ、「かおり」が「蛙」の前にくるように位置が入れ替わっています。
^ さらに、主に使用される異体字 (剣) はレベル 1 の行 23 セル 85 にあり、もう 1 つの異体字 (釼) はレベル 2 の行 78 セル 63 に「金」の部首を持つものとしてグループ化されています。
^ 統一基準内のどのグリフを使用するかという問題は、書体デザイナーに委ねられています。それに応じて（およびエンドユーザーの状況に応じて）、これら 2 つのどちらも、またはどちらか一方が康熙様式の形式に従わない可能性があります。
^ これは、ISO/IEC 646 の「HYPHEN-MINUS」を JIS X 0208 の「HYPHEN」または「MINUS SIGN」のどちらにマッピングすべきかという問題と同じ不確実性です。

参考脚注

^ 「なぜ日本はiPodを作らなかったのか」ガトゥンカ、2008年5月5日。
^ JIS X 0208は、2007年1月17日に 経済産業省が発表した新JISマークの表示対象システム一覧には含まれていなかった。
^ abc Steele, Shawn (1998 年 4 月 15 日). 「CP932.TXT: cp932 から Unicode へのテーブル」. Microsoft.(Shift_JIS 形式のコード; SJIS 0x815C = 1-29 = JIS 0x213D; SJIS 0x817C = 1-61 = JIS 0x215D)
^ ab 「Mac OS 日本語エンコードから Unicode 2.1 以降へのマップ (外部バージョン)」。Apple。(Shift_JIS 形式のコード; SJIS 0x815C = 1-29 = JIS 0x213D; SJIS 0x817C = 1-61 = JIS 0x215D)
^ abcd Lunde, Ken (2019年3月21日) . 「日本の元号合字の簡単な歴史」. CJK Type Blog . Adobe Inc.
^ abc 日本工業規格委員会. ISO-IR-233: 情報交換用日本語図形文字セット、第 1 面 (ISO-IR 228 の更新) (PDF) . ITSCJ/ IPSJ .
^ Unicode, Inc. (2011年10月14日). 「JIS X 0208 (1990) から Unicode へ」.
^ van Kesteren, Anne、「インデックス jis0208」、エンコーディング標準、WHATWG
^ ab Jungshik Shin (2011年10月14日). 「KSX1001.TXT: KS X 1001 から Unicode への表」. Unicode, Inc.
^ JIS C 6225-1979（情報交換用日本語図形文字セットの制御文字コード）は、組版の始めと終わりに制御文字を規定した。JIS C 6225は1987年に JIS X 0207と改名され、1997年に廃止された。
^ IANA文字セットでは、Shift JISはJIS X 0208:1997付録1を参照して定義されています。
^ abcd 「15. JIS X 0208の歴史」(PDF)、IBM Japanese Graphic Character Set for Extended UNIX Code (EUC)、IBM、p. 371、2017年12月8日のオリジナルからアーカイブ(PDF) 、 2017年12月8日取得
^ Lunde, Ken. 「付録 Q § 78-vs-83-3」CJKV 情報処理 (補足資料) O'Reilly.ハイフンを省略した区点コードが含まれていることに注意してください。
^ Lunde, Ken. 「付録 Q § 78-vs-83-2」。CJKV情報処理 (補足資料)。O'Reilly。ハイフンを省略した区点コードが含まれていることに注意してください。
^ 野村 (1984) によれば、コードポイント間の移動を含めて変更された文字形式の数は 294 である。柴野 (1997a) および第 4 標準のテキストによれば、変更された文字形式の数は 300 である。
^ ab 日本語原文: 「JIS X 0208が当初記号化を意図していた現代日本語を記号化するために十分な文字セットを提供することを目的として設計された」
^ Lunde, Ken. 「付録 Q § TJ2」。CJKV 情報処理 (補足資料)。O'Reilly。ハイフンを省略した区点コードが含まれていることに注意してください。
^ たとえば、第 4 規格の起草委員会委員長を務めた芝野幸治 (1997a) は、選定方法について次のように述べています。「誤った理解」（原文日本語：「JIS X 0208の文字セット選定の表層的理解に基づくものであり、間違った理解である」） 10000文字を超えています。」 (日本語原文: 「1万字を越える一連の文字セットの検討としては、大きな問題がある」 )
^ 丸川一志. 「JIS 文字セット - JIS X 0212:1990」. 2005年5月22日時点のオリジナルよりアーカイブ。
^ Chang, Hyeshik (2021 年 10 月 31 日). 「CJKCodecs の Readme」. cPython . Python Software Foundation.
^ JIS X 0213:2000 5.3.2 節、JIS X 0213:2000 附属書 1:2004 3.2.2 節

参照

JISコード文字セット
- JIS X 0201「情報交換用7ビット及び8ビット符号化文字集合」
- JIS X 0202「情報技術-文字コードの構造及び拡張技術」（ISO/IEC 2022）
- JIS X 0208「情報交換のための7ビットおよび8ビットの2バイト符号化漢字セット」
- JIS X 0211「符号化文字集合の制御機能」（ISO/IEC 6429）
- JIS X 0212「情報交換用補助日本語図形文字集合のコード」
- JIS X 0213「情報交換のための7ビットおよび8ビットの2バイト符号化拡張漢字セット」
- JIS X 0221「国際多オクテット符号化文字セット（UCS）」（ISO/IEC 10646）
拡張心字体
ヘルプ:日本語

参考文献

引用の目的上、これらの日本語名は、ローマ字表記の場合は西洋風の順序で表記され、ローマ字表記でない場合は東洋風の順序で表記されます。

西村裕彦 [西村恕彦]、1978 年。漢字 JIS [漢字の JIS ]。標準化ジャーナル[標準化ジャーナル]、171: 3–8。
野村雅昭 [野村雅昭]、1984 年。JIS C 6226: 情報交換用漢字コードの改正 [ JIS C 6226 情報交換用漢字シンボル系の改正]。標準化ジャーナル[標準化ジャーナル]、14 (3): 4–9。
緒方勝弘 [小形克宏]、2006a。 [永久リンク‍ ] JIS C 6226-1983 (83JIS) で変更された例字形のうち、97JIS に統一されなかったもの [ JIS C 6226-1983 (83JIS) で例示文字体を変更したうち、97JIS で包摂されませんでしたたもの] ^{[永久リンク切れ‍ ]} (2007 年 1 月 29 日にアクセス)。
緒方勝弘 [小形克宏]、2006b。 [永久デッドリンク‍ ] JIS C 6226-1983 (83JIS) で変更された例字形のうち統一の範囲に入ったもの [ JIS C 6226-1983 (83JIS) 例示字体変更のうち、包摂の範囲内だったもの] ^{[永久リンク切れ‍ ]} (2007 年 1 月 29 日にアクセス)。
Satō,Takayuki [佐藤敬幸], 2004. JIS X 0213（情報交換用7ビットおよび8ビット全角符号化拡張漢字セット）の改正について [ JIS X 0213 (7ビット及び8ビットの2バイト交換情報)用記号化拡張漢字セット）の修正について]。標準化ジャーナル[標準化ジャーナル]、34 (4): 8–12。
芝野耕司、 1997a。 JIS X 0208（情報交換用7ビットおよび8ビットの2バイト符号化漢字セット）の改正について [ JIS X0208 (7ビット及び8ビットの2バイト情報交換用記号化漢字セット)の改正について]。標準化ジャーナル[標準化ジャーナル]、27 (3): 8–12。
芝野耕司、 1997b。 JIS漢字の拡張計画 [ JIS漢字の拡張計画]。標準化ジャーナル[標準化ジャーナル]、27 (7): 5–11。
Shibano, Kouji [芝野耕司], 2000. JIS X 0213 (情報交換用の 7 ビットおよび 8 ビットの 2 バイト符号化拡張漢字セット) の制定 [ JIS X 0213 (7ビット及び8ビットの2バイト情報交換用シンボル)化拡張漢字セット)の制定]。標準化ジャーナル[標準化ジャーナル]、30 (3): 3–7。
芝野耕司 [芝野耕司] 2001. JIS 漢字について [漢字について]。標準化と品質管理[標準化と品質管理]、54 (8): 44–50。
芝野耕司（編者）、2002年。JIS漢字辞典増補改訂版『増補改訂JIS漢字字典』。東京: 日本規格協会 ( ISBN 4-542-20129-5 )。
芝野耕司 [芝野耕司]、2002年。漢字と日本語処理技術の開発: 漢字コードの標準化[漢字・日本語処理技術の発展: 漢字コードの標準化]。情報処理学会誌[情報処理], 43 (12): 1362–1367
田島一夫 [田嶋一夫]、1979年。 JIS漢字表の使用に関する問題: 漢字処理システムにおける漢字の設計と取り扱い [JIS漢字表の利用上の問題: 漢字処理システムにおける漢字のデザインと管理]。情報処理学会誌［情報管理］，21 (10): 753–761．
内田富雄 [内田富雄]、1990年。JIS X 0212 (情報交換用漢字コード - 補助漢字) [ JIS X 0212 (情報交換用漢字記号―補助漢字) の制定]。標準化ジャーナル[標準化ジャーナル]、20 (11): 6–11。
安岡孝一 [安岡孝一]、2001a。日本の最新文字コード事情 (前編) [日本における最新文字コード事情 (前編) ]。システム、制御および情報[システム/制御/情報]、45 (9): 528–535。
安岡孝一 [安岡孝一]、2001b。日本の最新文字コード事情（後編） [日本における最新文字コード事情 (後編) ]。システム、制御および情報[システム/制御/情報]、45 (12): 687–694。
安岡孝一 [安岡孝一]、2006 第17回「東洋人のコンピュータ利用法」にて「JIS漢字案(1976年)とJIS C 6226-1978の異同」研究」[東洋学へのコンピュータ利用]研究セミナー。 3-51。
安岡孝一 [安岡孝一] & 安岡素子 [安岡素子]、2006 年。文字コードの歴史: ヨーロッパ、アメリカ、および日本[文字記号の歴史: 欧米と日本編]。東京：共立出版（ISBN 4-32012102-3）。

外部リンク

IPSJ/ITSCJが主管する国際登録簿。
- 日本語文字セット JIS C 6226-1978
- 日本語文字セット JIS C 6226-1983
- 更新登録 87 情報交換用日本語グラフィック文字セット
日本工業標準調査会データベース検索（最新の規格はこちらからご覧いただけます。）
(日本語)日本規格協会データベース検索: (最新規格のコピーはこちらからご購入いただけます)
JIS X 0208および0213規格における統一関連規定
サイバーライブラリアン - JIS漢字一覧

[w31jnec-21] 「NEC による IBM 拡張機能の選択」より。JIS X 0208 では割り当てられていないコードポイントを占有します。

[w31jibm-22] 「IBM 拡張」より。JIS X 0208 の範囲外ですが、Shift_JIS でエンコード可能です。

[23] Microsoft は JIS のマイナス記号をハイフンマイナスの全角形式として扱います。

[wavedash-24] 波ダッシュは、例えばマイクロソフトなどでは、チルダの全角形式として扱われることがある（チルダ § 波ダッシュの Unicode および Shift JIS エンコードを参照）。ASCII / IRV チルダは、チルダアクセント記号（˜）として現れることもあれば、同じ曲率のダッシュ（∼）として現れることもある曖昧なコードポイントであるが、Windows-1252ではスペースアクセントが別のコードポイントを持っているため、ダッシュの方が一般的である。チルダアクセント用の JIS X 0208 文字はない。JIS X 0213 の文字 1-2-18 は、コード表ではチルダアクセントとして示されている。^[6]

[35] ^つまり、 8 ビットのクリーンな伝送は必要ありません。

[36] つまり、特定の文字をエンコードするために使用されるシーケンスは、前の文字が何であったかに関係なく、常に同じです。状態 (コンピューターサイエンス)を参照してください。

[state2022-37] ISO-2022-JP はステートフルエンコーディングです。すべての文字セットは 0x21～7E でエンコードされ、ANSI エスケープを使用して切り替えられます。したがって、初期状態では ASCII ですが、非 ASCII 文字のシーケンス全体を ASCII バイトでエンコードできます。

[38] JIS X 0201 カタカナは JIS X 0202 および ISO 2022 で使用できますが、共通の拡張機能ではありますが、基本 ISO-2022-JP プロファイルには含まれていません。

[39] JIS X 0212 は JIS X 0202 および ISO 2022 で使用可能であり、ISO-2022-JP-1 および ISO-2022-JP-2 プロファイルに含まれていますが、基本 ISO-2022-JP プロファイルには含まれていません。

[40] Shift_JIS の 0x21–7E の 1 バイト文字は、8 ビット JIS X 0201 のスーパーセットとなるため、適切にはISO-646-JPですが、多くの場合、2 か所のみが異なる ASCII としてデコードされます (必ずしも表示されるとは限りません)。

[41] 一部の (すべてではない) ASCII バイトは、Shift_JIS の 2 バイト文字の 2 番目のバイトとして表示されますが、最初のバイトとして表示されることはありません。したがって、2 つ以上の ASCII バイトのシーケンスでは、2 番目のバイト以降は必ず ASCII (または ISO-646-JP) 文字になります。

[eucstateless-42] パック形式の EUC は ISO 2022 メカニズムに基づいており、文字セット指定が事前に調整されています。文字セット指定のエスケープとシフトのロックは回避されますが、単一シフトの使用は非ステートフルな方法で実装できます。ただし、ISO 2022 の制約は従われます。

[43] EUC-JPの1バイト文字0x21～7Eは一般にASCIIとみなされますが、ISO-646-JPとして扱われることもあります。

[44] Shift_JIS とは異なり、EUC-JP は、JIS X 0201 カタカナ (シングルシフト付き) の表現が異なるため、事前の変換なしではプレーンな 8 ビット JIS X 0201 入力を処理できません。

[45] EUC-JP の JIS X 0212 は必ずしも実装されているわけではありません。

[46] エンコーディング自体の特性に加えて、Unicode 形式には、基礎となる文字セットに起因するさらなる利点があります。Unicode は JIS コード化文字に限定されず、UCS 全体 (JIS コード化文字の全レパートリーを含む) を表現できるため、国際的な使用に適しています。また、Unicode は、より広範な基本レパートリーと指定された私的使用領域により、独自の拡張機能の衝突による悪影響も少なくなります。

[47] UTF-8 でエンコードされたテキストのビット単位のフレームシフトのほとんどは無効な UTF-8 を生成しますが、1 ビット以上フレームシフトしても有効な UTF-8 のままになる文字シーケンスを構築することは可能です。

[48] Microsoft のみ。

[49] GB 18030 と GBK は GB/T 2312 の EUC-CN 形式の拡張ですが、EUC-JP (または元の EUC-CN) とは異なり、EUC または ISO 2022 の制約には従いません。

[50] 理論上、UTF-32 は 32 ビットのダブルワードのみで自己同期しますが、21 ビットの値を表すために 32 ビットの値を使用するということは、実際には、UTF-32 には各文字の上位に少なくとも 11 個の連続したゼロビットが含まれることを意味します。これは通常、関係するコードポイントに応じて、文字の境界に揃えるために使用できます。

[1] ギリシャ語の発音区別符号と末尾のシグマが欠落しています。

[uniwith-6] (撤回)

[7] JISおよびApple: U+2014。Unicode
、^[b] MicrosoftおよびWHATWG: U+2015。

[8] MicrosoftおよびWHATWG: U+FF5E。Unicode
、^[b] JISおよびApple: U+301C。

[9] MicrosoftおよびWHATWG: U+2225。Unicode
、^[b] JISおよびApple: U+2016。

[10] Microsoft: U+FF0D。Unicode
、^[b] JIS および Apple: U+2212。WHATWG
: デコード時に U+FF0D、例外的にエンコード時に両方。

[nu213-13] JIS X 0213で追加

[14] 平成以前のオリジナルバージョンの拡張機能には存在しない。コード位置はNECまたはMicrosoftによって選択された。^[5] Macintosh PostScriptには存在しない。

[dup1983-15] 1983年に2行目に追加され重複した。JIS X 0213ではここではエンコードされていない（割り当てられていないまま）が、^{[5] MicrosoftとWHATWGではここでは重複エンコードされている。Macintosh PostScriptエンコードに関しては、}macOSライブラリ関数でデコードされた形式にPrivate Use U+F87Fが付加され、ラウンドトリップが可能になっている。

[kuten-16] エスケープシーケンスに使用する符号化文字セットの国際登録簿に登録されているコード表にあるように、第4次規格（1997年）以前は、区と点を英語でそれぞれsection、positionと呼んでいた。英語が変わった背景としては、ISO/IEC 10646-1:1993を翻訳したJIS X 0221-1995（UCS）規格では、group、plane、row、cellをそれぞれgun（群）、men（面）、ku（区）、ten（点）と訳せるようになっている。ただし、JIS X 0208のrowとcellとUCSのrowとcellは別の概念である。

[20] キャラクター名はローマ字で表記され、国際的に使用されているため、生物の学名のような国際的な慣習と言えます。このアナロジーで言えば、キャラクターの日本語の通称は生物の通称に似ています。

[26] かな順検索や並び替えをフル機能で実現するには、単語の読みや繰り返し記号などを考慮する必要があります。日本語文字列の並び替えは、JIS X 4061（日本語文字列の照合順序）に規定されています。

[27] ^安岡（2001a）によれば、 いくつか偶然の見落としがあったようだ。例えば、印旛郡の旛（58-57）と熊本県酒々井郡の泗（61-89）はレベル1には含まれていないと指摘している。

[28] リスト:丼 · 傲慢 · 対策を講じる · 言い換え · 臭い · 対策を立てる · · 怖い · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ( · ) 󠄁曖󠄀楷󠄀鬱󠄀璧󠄀瘍󠄀箋󠄀籠󠄀緻󠄀羞󠄀訃󠄀諧󠄀貪󠄀踪󠄀辣󠄀錮

[29] 常用漢字「𠮟󠄀」は、正式な異体字である「叱」のみに含まれています。

[30] リスト:乘 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·。凛Ơ欧 ·対策を剩 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·: · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·專 · · · · · · · 峽 · 崚 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 󠄁拜󠄀拂󠄀搜󠄀搖󠄀攝󠄀收󠄀敍󠄀昊󠄀昴󠄀晏󠄀晄󠄀晝󠄀晨󠄀晟󠄀暉󠄀曉󠄀檜󠄀栞󠄀條󠄀梛󠄀椰󠄀榮󠄀樂󠄀樣橙العلى المزية المزية المزيل 󠄀漱󠄀滯󠄀澁󠄀澪󠄀濕󠄀煌󠄀燒󠄀燎󠄀燿󠄀爭󠄀爲󠄀狹· 默loid · 獸 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·祕loidん· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·: · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·。 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·。釀󠄀釉瓊瓊瓊瓊瓊瓊· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·るためためにのためにのためにのためにのためにのために。

[31] リスト:焰 · · · · · · 鷗 · Whole · 繫 · · · · · · · 繫 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·。禱󠄀萊󠄀蠟󠄀增󠄀德󠄀橫󠄀瀨󠄀猪󠄀神󠄀祥󠄀福󠄁綠󠄀緖󠄀薰 · · · · · · 諸 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · *海󠄀渴󠄀漢󠄁器󠄁祈󠄀虛󠄀響󠄁勤󠄁謹󠄀揭󠄀擊󠄀穀󠄀祉󠄁視󠄁煮󠄀社󠄁者󠄁臭󠄁祝󠄀暑󠄁署󠄀涉󠄀狀󠄀節󠄁祖󠄁僧󠄁層󠄁巢󠄀憎󠄀贈󠄁卽󠄀嘆󠄀著󠄁徵󠄀禎󠄁突󠄁難󠄀梅󠄀繁󠄁晚 · · · · · · · · · · · · · · · · · · · · · · · · · · · · ( · )淚 · loid · 類 · ® ® · 曆 · 糸 · 歷 · 糸 · 練 · · 練 · 期 · 鍊 · · · · · · · · ·

[32] 19行目の30番目と31番目のセルでは、代表的な読みの順序が逆になっています。その結果、正しい順序は「蛙（かえる）」の次に「馨（かおり）」であるところ、「かおり」が「蛙」の前にくるように位置が入れ替わっています。

[33] さらに、主に使用される異体字 (剣) はレベル 1 の行 23 セル 85 にあり、もう 1 つの異体字 (釼) はレベル 2 の行 78 セル 63 に「金」の部首を持つものとしてグループ化されています。

[55] 統一基準内のどのグリフを使用するかという問題は、書体デザイナーに委ねられています。それに応じて（およびエンドユーザーの状況に応じて）、これら 2 つのどちらも、またはどちらか一方が康熙様式の形式に従わない可能性があります。

[61] これは、ISO/IEC 646 の「HYPHEN-MINUS」を JIS X 0208 の「HYPHEN」または「MINUS SIGN」のどちらにマッピングすべきかという問題と同じ不確実性です。

[2] 「なぜ日本はiPodを作らなかったのか」ガトゥンカ、2008年5月5日。

[3] ^ JIS X 0208は、2007年1月17日に 経済産業省が発表した新JISマークの表示対象システム一覧には含まれていなかった。

[ms932-4] Steele, Shawn (1998 年 4 月 15 日). 「CP932.TXT: cp932 から Unicode へのテーブル」. Microsoft.(Shift_JIS 形式のコード; SJIS 0x815C = 1-29 = JIS 0x213D; SJIS 0x817C = 1-61 = JIS 0x215D)

[macjapanese-5] 「Mac OS 日本語エンコードから Unicode 2.1 以降へのマップ (外部バージョン)」。Apple。(Shift_JIS 形式のコード; SJIS 0x815C = 1-29 = JIS 0x213D; SJIS 0x817C = 1-61 = JIS 0x215D)

[lundenec13-11] Lunde, Ken (2019年3月21日) . 「日本の元号合字の簡単な歴史」. CJK Type Blog . Adobe Inc.

[iso-ir-233-12] 日本工業規格委員会. ISO-IR-233: 情報交換用日本語図形文字セット、第 1 面 (ISO-IR 228 の更新) (PDF) . ITSCJ/ IPSJ .

[17] Unicode, Inc. (2011年10月14日). 「JIS X 0208 (1990) から Unicode へ」.

[18] van Kesteren, Anne、「インデックス jis0208」、エンコーディング標準、WHATWG

[x1001txt-19] Jungshik Shin (2011年10月14日). 「KSX1001.TXT: KS X 1001 から Unicode への表」. Unicode, Inc.

[25] ^ JIS C 6225-1979（情報交換用日本語図形文字セットの制御文字コード）は、組版の始めと終わりに制御文字を規定した。JIS C 6225は1987年に JIS X 0207と改名され、1997年に廃止された。

[34] IANA文字セットでは、Shift JISはJIS X 0208:1997付録1を参照して定義されています。

[ibm208history-51] 「15. JIS X 0208の歴史」(PDF)、IBM Japanese Graphic Character Set for Extended UNIX Code (EUC)、IBM、p. 371、2017年12月8日のオリジナルからアーカイブ(PDF) 、 2017年12月8日取得

[52] Lunde, Ken. 「付録 Q § 78-vs-83-3」CJKV 情報処理 (補足資料) O'Reilly.ハイフンを省略した区点コードが含まれていることに注意してください。

[53] Lunde, Ken. 「付録 Q § 78-vs-83-2」。CJKV情報処理 (補足資料)。O'Reilly。ハイフンを省略した区点コードが含まれていることに注意してください。

[54] 野村 (1984) によれば、コードポイント間の移動を含めて変更された文字形式の数は 294 である。柴野 (1997a) および第 4 標準のテキストによれば、変更された文字形式の数は 300 である。

[goal-56] 日本語原文: 「JIS X 0208が当初記号化を意図していた現代日本語を記号化するために十分な文字セットを提供することを目的として設計された」

[57] Lunde, Ken. 「付録 Q § TJ2」。CJKV 情報処理 (補足資料)。O'Reilly。ハイフンを省略した区点コードが含まれていることに注意してください。

[58] たとえば、第 4 規格の起草委員会委員長を務めた芝野幸治 (1997a) は、選定方法について次のように述べています。「誤った理解」（原文日本語：「JIS X 0208の文字セット選定の表層的理解に基づくものであり、間違った理解である」） 10000文字を超えています。」 (日本語原文: 「1万字を越える一連の文字セットの検討としては、大きな問題がある」 )

[59] 丸川一志. 「JIS 文字セット - JIS X 0212:1990」. 2005年5月22日時点のオリジナルよりアーカイブ。

[python-eucjis-60] Chang, Hyeshik (2021 年 10 月 31 日). 「CJKCodecs の Readme」. cPython . Python Software Foundation.

[62] JIS X 0213:2000 5.3.2 節、JIS X 0213:2000 附属書 1:2004 3.2.2 節