-
Notifications
You must be signed in to change notification settings - Fork 4
/
424.txt
1240 lines (936 loc) · 62.9 KB
/
424.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
[22] [DFN[ISO-2022-JP]] は、かつて[[日本]]で用いられた[[文字コード]]の1つでした。
[23] [[電子メール]]や[[ネットニュース]]では[[日本]]の[[標準]]の[[文字コード]]とされていました。
* 代替
[25] [[電子メール]]では、世界的な流れにやや遅れて[[日本語]]の[[メール]]でもなし崩し的に
[[UTF-8]] に移行が完了しつつあります。
[24] [[Web]] でも一時使われましたが、主流にはなりませんでした。
当時は[[シフトJIS]]や[[日本語EUC]]がよく使われました。
現在は [[UTF-8]] が使われています。
[26] [[ネットニュース]]は衰退しました。
* 符号化方式
[21]
,ISO-IR# ,[[符号化文字集合]] ,[[指示]]
,6 ,[[ASCII]] ,ESC 02/08 [(] 04/02 [B]
,14 ,[[JISX0201]] Roman set ,ESC 02/08 [(] 04/09 [J]
,42 ,[[JISX0208]]-1978 ,ESC 02/04 [$] 04/00 [@]
,87 ,JIS X 0208-1983 ,ESC 02/04 [$] 04/02 [B]
- 最初は
-- ASCII で始まらなければなりません (MUST [BIS1468])
-- ISO/IEC 646 IRV (ASCII) ではじまります [JISX0208:1997]
- 終端は
-- ASCII または JIS X 0201 roman で終わらなければなりません [JUNET], [PRACTICE] (MUST [BIS1468])
-- ASCII で終わらなければなりません (must [RFC1468], shall [JISX0208:1997])
- 行末は ASCII または JIS X 0201 roman に
-- であるのが望ましいです [JUNET]
-- でなければなりません (must [RFC1468], MUST [BIS1468], shall [JISX0208:1997])
-- [[指示]]がなくても [[ISO/IEC646]] [[IRV]] (ASCII) にして構いません [JISX0208:1997]
- [58] ESC 02/08 [(] 04/08 [H] は
-- 使ってはいけません [JUNET]
-- 使わないのが望ましいです (should not) [RFC1468]
-- [SEE[ [[指示シーケンス]] ]]
- 制御文字を使う時は ASCII または JIS X 0201 Roman の状態
-- であることが望ましいです [JUNET]
-- でなければなりません ([[BNF]] [RFC1468], [BIS1468]; 定義 [JISX0208:1997])
- JIS X 0208‐1978 と ‐1983, ASCII と JIS X 0201 Roman はそれぞれ
-- 同一視して表示する処理系があります [RFC1468]
-- 全ての処理系が区別するわけではありません [BIS1468]
-- 1978 も 1983 も使わずに 1997 ですが、
1978 と 1983 で入れ替わっている符号位置は、入れ替わってて構いません。
1978 にない符号位置は実装しなくても構いません。 [JISX0208:1997]
-- が、配送途中で変更するのはいけません (must not [RFC1468], SHOULD NOT [BIS1468])
-- ASCII と JIS X 0208‐1983 を推奨します。 [BIS1468], [PRACTICE]
- [59] JIS X 0208‐1990 を使う時は [[IRR]] を
-- 使わないことにしましょう。 (suggest) [RFC1468]
-- 使ってはいけません。 [JISX0208:1997]
-- [SEE[ [[IRR]] ]]
- JIS X 0208 で規定されていない符号位置は
-- 使ってはいけません [JUNET] (MUST [BIS1468])
-- 情報交換の当事者間の合意で使用できますが、 Internet では使用しません [JISX0208:1997]
※[PRACTICE] は、実際の習慣
[95]
[[文字集合]]については
[[ISO/IEC 646 IRV]],
[[JIS X 0201]],
[[JIS X 0208]]
も参照。
[57]
[[DEC]] は [[ISO-2022-JP]] の [[JIS X 0208]] を
[[JIS X 0208-1990]]
としていました。
[SEE[ [[DECの文字コード]] ]]
[152]
非常に古い[[インターネットメール]]や[[ネットニュース]]の[[メッセージ]]
([[昭和時代]]後期、[[JUNET]] 初期のもの)
には
[CODE(charname)@en[ESC]] [N[2/8]] [N[4/8]]
を使ったものがあります。
[[インターネットメッセージ]]を扱う実装は
[[ISO-2022-JP]] ([[JUNETコード]])
の[[復号]]時にこれにも対応しておく必要があります。
** 冗長なエスケープシーケンス
[148]
現在の [[Webブラウザー]]の [[iso-2022-jp]] ([CITE[Encoding Standard]]
が規定するもの)
では、冗長な[[エスケープシーケンス]] (例えば [[ASCII]]
に切り替えた直後に [[JIS X 0208]] 切り替えるもの)
は誤りとみなして、
[CODE[U+FFFD]]
が挿入されることになっています。
[149]
これはセキュリティー上の理由とされています。
[150]
古い [[ISO-2022-JP]] の文書 ([[メール]]など) には、
こうしたものが含まれることがあります。
[[日本語入力]]の関係か、編集の関係でそういうこともあったのでしょうか。
[[平成時代]]初期のものにはこれは頻出します。
[151]
従って [[Web]] 以外の [[ISO-2022-JP]] の[[復号]]は、
[CITE[Encoding Standard]] の [[iso-2022-jp]] ではなく、
既存のファイルに対応可能な[[復号器]]を使う必要があります。
* 拡張
[113]
[[ISO-2022-JP]] に独自要素を付け足した実装は無数にあります。拡張により
[[ISO-2022-JP]] でなくなっているにも関わらず [[ISO-2022-JP]]
と称していることもあります。
[67]
[[JIS X 0208]] の[[空き領域]]の[[外字]]については、
[[JIS X 0208]] 参照。
[70]
[[符号化文字集合]]を増やした拡張:
[[ISO-2022-JP-1]], [[ISO-2022-JP-2]], [[ISO-2022-INT]], [[ISO-2022-JPext]]
[71]
[[絵文字]]を追加した拡張:
[CODE[x-iso-2022-jp-kddi]],
[CODE[x-iso-2022-jp-airh]]
[72]
足し引きしたもの:
[[ISO-2022-JP-3]],
[[ISO-2022-JP-2004]]
** 片仮名用拡張
[60]
昔から「JIS」「JISコード」「ISO-2022-JP」と称して[[半角カナ]]
([[JIS X 0201]] [[片仮名用図形文字集合]])
の読み書きの一方または両方に対応している実装が多いです。
対応方法は何通りかあります。
- [61] [[JIS X 0201]] [[片仮名用図形文字集合]]を [[G0]] に[[指示]]して使うもの
- [62] [CODE(charname)@en[SO]] ... [CODE(charname)@en[SI]] で使うもの
- [63] [[GR]] で使うもの
[73]
[DFN[CP50220]]:
[[Windows]] 版 [[JIS X 0208]] (外字つき),
[[Unicode]] → [[CP50220]] 変換時に[[半角カナ]]は[[全角カタカナ]]に置換される
- [74] [CITE[cp50220 - PukiWiki]], [TIME[2022-05-07T13:59:26.000Z]], [TIME[2006-06-19T16:59:28.251Z]] <https://web.archive.org/web/20060619165834/http://legacy-encoding.sourceforge.jp/wiki/index.php?cp50220>
- [76] [TIME[2021-07-18T23:39:49.000Z]], [TIME[2022-05-07T14:02:08.270Z]] <http://www.iana.org/assignments/charset-reg/CP50220>
- [75] [CITE@ja-jp[Microsoft Windows Codepage : 50220 ‐ 通信用語の基礎知識]], [TIME[2022-05-07T14:00:54.000Z]] <https://www.wdic.org/w/WDIC/Microsoft%20Windows%20Codepage%20%3A%2050220>
[78]
[DFN[CP50221]]:
[[Windows]] 版 [[JIS X 0208]] ([[外字]]つき)、
[[半角カナ]] ESC ( J あり、
[[EUDC]] は第1バイト 0x7F - 0x92 (入出力ともに可能)
([[IBM拡張文字]]は[[NEC選定IBM拡張文字]]に変換される)
- [88]
[CITE[cp50221 - PukiWiki]], [TIME[2022-05-07T14:32:48.000Z]], [TIME[2006-06-19T17:28:22.816Z]] <https://web.archive.org/web/20060619165444/http://legacy-encoding.sourceforge.jp/wiki/index.php?cp50221>
- [77]
[CITE@ja-jp[Microsoft Windows Codepage : 50221 ‐ 通信用語の基礎知識]], [TIME[2022-05-07T14:04:36.000Z]] <https://www.wdic.org/w/WDIC/Microsoft%20Windows%20Codepage%20%3A%2050221>
[79]
[DFN[CP50222]]:
[[Windows]] 版 [[JIS X 0208]] ([[外字]]つき)、
[[半角カナ]] SI/SO、
[[EUDC]] は第1バイト 0x7F - 0x92 (入出力ともに可能)
([[IBM拡張文字]]は[[NEC選定IBM拡張文字]]に変換される)
- [80] [CITE@ja-jp[Microsoft Windows Codepage : 50222 ‐ 通信用語の基礎知識]], [TIME[2022-05-07T14:08:42.000Z]] <https://www.wdic.org/w/WDIC/Microsoft%20Windows%20Codepage%20%3A%2050222>
- [87] [CITE[cp50222 - PukiWiki]], [TIME[2022-05-07T14:32:04.000Z]], [TIME[2006-06-19T17:31:41.032Z]] <https://web.archive.org/web/20060619165847/http://legacy-encoding.sourceforge.jp/wiki/index.php?cp50222>
[114]
[[IRC]] は[[プロトコル]]レベルで[[文字コード]]を記述することがほぼ出来ないので、
当事者間で[[文字コード]]を取り決めて使っていました。
[[UTF-8]] が主流になる前は[[日本]]では [[ISO-2022-JP]] が主流でしたが、
[[半角カナ]]の扱いに流儀がいくつかありました。
;; [124] 現在では [[IRC]] で [[ISO-2022-JP]] が使われることは、
少なくても公開サーバーではほぼなくなりましたが (公開サーバー自体が絶滅寸前)、
過去に生成された[[チャットログ]]は受け取った[[バイト列]]をそのまま保存していることも多いでしょうから、
それを読み込む需要は今後も皆無ではありません。
[123]
[[LimeChat]] は[[日本]]で人気の [[IRC]] [[クライアント]]の1つです。
「[[ISO-2022-JP]]」
を含むいくつかの[[文字コード]]に対応しています。
[[LimeChat]] は次の4つの[[符号化]]のオプションを提供していました。
おそらくこれでかつて[[日本]]の [[IRC]]
コミュニティーで行われた[[文字コード]]をほぼカバーできていると思われます。
- [115] [[全角カナ]]に変換
- [116] JIS X0201 Roman 8bit [ ESC ( J ]
-- [119] [[半角カナ]]は [[GR]]。直前に ESC ( J。直後に次の文字に応じた指示。
- [117] JIS X0201 Roman 7bit [ ESC ( J + SO/SI ]
-- [120] [[半角カナ]]は [[GL]]。直前に ESC ( J [[SO]]。直後に次の文字に応じた指示。
- [118] JIS X0201 Kana [ ESC ( I ]
-- [121] [[半角カナ]]は [[GL]]。直前に ESC ( I。直後に次の文字に応じた指示。
[122]
[[ISO/IEC 2022]] 的に見れば >>116, >>117 で
[[JIS X 0201]] [[ラテン文字用図形文字集合]]を
[[G0]] に[[指示]]する ESC ( J
は何の意味も持ちません。
(直後に[[半角英数字]]が来ると間に ESC ( B が挿入されるので、
本当に何の意味も持ちません。)
この方式を考案した人にとっては、「[[JIS X 0201]] モードに入る」
というつもりだったのでしょうか。
[125]
>>117 は [[SO]] を前に挿入しますが、 (説明にも反して) 後ろに [[SI]]
を挿入しません。つまり [[GL]] を [[G1]] に[[呼び出し]]するところまでは良いとして、
[[半角カナ]]が終わっても [[GL]] を [[G0]] に戻さないので、
以後すべてが[[半角カナ]]扱いになってしまいます。
この方式を考案した人にとっては、[[エスケープシーケンス]]で
[[SI]]/[[SO]] の状態遷移はリセットされるというつもりだったのでしょうか。
** シフトJIS関連の拡張
[86] [[eucJP-ms]] を [[ISO-2022-JP]] 変換したもの
- [85] [CITE[7bit-eucJP-ms(?) - PukiWiki]], [TIME[2022-05-07T14:31:11.000Z]], [TIME[2006-06-19T17:26:28.982Z]] <https://web.archive.org/web/20060619165430/http://legacy-encoding.sourceforge.jp/wiki/index.php?7bit-eucJP-ms%28%3F%29>
[68]
[DFN[ISO-2022-JP-MS]] と称する拡張があります。
[[EUDC]] に[[私用終端バイト]]が使われています。
[SEE[ [[私用終端バイト]] ]]
[83] -ms とありますが、提案者は [[MS]] ではなく、 [[MS]] の利用例があるかも不明。
[REFS[
- [82] [CITE@ja[libiconv-1.11-ja-1.patch.gz]] ([TIME[2007-10-27 07:56:21 +09:00]] 版) <http://www2d.biglobe.ne.jp/~msyk/software/libiconv-1.11-ja-patch.html>
- [84] [CITE[ISO-2022-JP-MS - PukiWiki]], [TIME[2022-05-07T14:28:53.000Z]], [TIME[2006-06-19T17:31:09.265Z]] <https://web.archive.org/web/20060619170130/http://legacy-encoding.sourceforge.jp/wiki/index.php?ISO-2022-JP-MS>
- [81] [CITE@ja-jp[ISO-2022-JP-MS ‐ 通信用語の基礎知識]], [TIME[2022-05-07T14:09:29.000Z]] <https://www.wdic.org/w/WDIC/ISO-2022-JP-MS>
]REFS]
[69]
[[シフトJIS]]の [N[0xF040]] 以降の領域 ([[94[SUP[2]]集合]]の外側の95区とそれ以降)
を表すために
[[GL]]
を機械的に延長して [N[0x7F]], [N[0x80]], ... と続ける方式もあるようです。
>>78 >>79
[REFS[
- [10] [CITE[高瀬橋対岸2]] ([TIME[2010-05-25 11:19:41 +09:00]] 版) <http://drshinwebsite.fc2web.com/sanennanshin/takasebashitaigan2.html>
]REFS]
[11] >>10 は [[ISO-2022-JP]] ですが、たまに[[シフトJIS]]が混入しています。
[[WinIE]] は意図通りに表示しますが、[[Firefox]] / [[Chrome]] ([[Windows]])
では[[シフトJIS]]部分が文字化け ([CODE(char)[[[U+FFFD]]]] 化) します。
[TIME[2012-05-25T12:51:37.600Z]]
[89]
>>10 ページ途中に出てくる 0xA5 0xA5 は[[半角カナ]]2文字。
ページ末尾にサーバーが挿入したと思われる広告は[[シフトJIS]]。
前者はIE11で正しく表示されるが (Firefox では U+FFFD)、
後者はIE11でも文字化けする (U+FFFD + 第2バイト)。
(10年前のIEがこの動作だったかは不明)
[TIME[2022-05-07T14:43:23.0Z]]
* 文脈
[64]
[[日本]]の [[Unix]] 系プラットフォームは伝統的に
[[ISO/IEC 2022]] の[[指示シーケンス]]と [[G0]] = [[GL]]
と
[[JISコード]]を組み合わせる方式を[[情報交換]]用に使っていました。
従ってその方面で発展した[[アプリケーション]]ではいわゆる
「7ビットJIS」
コードが使われてきました。
[65]
次のような場面で [[JUNETコード]]、 [[RFC 1468]] [[ISO-2022-JP]]、
あるいはそれらに近いものが使われていました。
- [[インターネットメール]]
- [[インターネットニュース]]
- [[MIMEメッセージ]]
- [[IRC]]
- [[Web]] ([[HTML]])
- [[XML]]
;; [66] 現在ではいずれもほぼ [[UTF-8]] に置き換わっています。
** メールにおける利用
[153]
[[日本語]]の[[インターネットメール]]は ([[IP]] [[インターネット]]になる前の [[JUNET]]
時代から) [[ISO-2022-JP]] が標準の[[文字符号化]]として用いていました。
[154]
[[平成時代]]後期になって [[Gmail]] や [[Webサービス]]からの通知メールなどが
[[UTF-8]] を使うようになりました。[[Web]] 系企業を中心とした移行でしたが、
その当時 [[Webページ]]では既に [[UTF-8]] が主流になっていて、
[[メール]]専用の[[文字コード変換]]をやめたいという思惑もありました。
;; [155] 特に[[標準化]]手続きなどはなく、なし崩し的に [[UTF-8]] への移行が進められました。
[156]
一方で[[令和時代]]に入っても未だに [[ISO-2022-JP]] は使われ続けています。
令和5年に入って受信したメールをさらっと調べてみましたが、
- [157] [[eコマース]]系[[SaaS]]の通知メール (複数のプラットフォーム)
- [158] [[eコマース]]系[[SaaS]]の[[メールマガジン]] (複数のプラットフォーム)
- [159] 企業のメールアドレスを収集して一斉配信していると思われる営業[[DM]]
(おそらく一斉配信用[[SaaS]]経由、プラットフォーム不明ながらも複数社)
- [167] その他メール一斉配信系[[SaaS]]を使ったメールマガジン
(複数のプラットフォーム)
- [160] 某ゲーム会社の[[Webサービス]]の通知メール
- [161] 某ドメイン販売業者の告知メール
- [162] 某[[ふるさと納税]]仲介事業者の通知メール
- [163] [CITE[mixi]] の通知メール
- [164] 某大手CD通販サイトのメールマガジン
- [165] 某美容系ポータルサイトの通知メール
- [166] [[リクルート]]社のメールマガジン
といった [[ISO-2022-JP]] 利用事例が見つかりました。
[[平文]]が多いですが、 [[HTMLメール]]もありました。
** Web における利用
[132]
[[日本]]の[[ウェブ]]の草創期 ([[平成時代]]前半頃)
には、[[大学]]等 [[Unix]] 文化の流れを引く[[ウェブサイト]]を中心に
[[ISO-2022-JP]] (や [[ISO-2022-JP-2]] など)
が使われていました。
[133]
現在でも[[Webブラウザー]]は [[ISO-2022-JP]] に対応しています。
[[ISO-2022-JP]] に対応しない [[Webブラウザー]]は
[[Web互換]]ではありません。
[134]
[[ISO-2022-JP]] (など) は初期からいろいろな [[Webブラウザー]]に実装されていました。
- [139] 各種 [[Mosaic]]
-- [131] [[Mosaic-L10N]]
- [138] [[Lynx]]
- [135] [[w3m]] とその派生
-- [136] [[w3m-m17n]]
-- [137] [[w3mmee]]
- [140] [[Netscape Navigator]]
- [141] [[Internet Explorer]]
- [142] その後のほぼすべての [[Webブラウザー]]
[143]
[[CGI]] 開発の一部界隈などでは、[[8ビット]]符号で区別が自明ではない[[シフトJIS]]
や[[日本語EUC]] は避けて、[[エスケープシーケンス]]によって確実に[[漢字]]を判別できる
[[ISO-2022-JP]] が好まれました。
[144]
初期の初期には [CODE[x-]] のない [[charset]] 名がまともに使えるのは [[ISO-2022-JP]]
だけだったので、[[シフトJIS]]や[[日本語EUC]]よりも [[ISO-2022-JP]]
を使うのが正統という考えの人もいました。
*** 実利用例
[168] [CITE@ja[Masayasu ISHIKAWA's Welcome Page]], [TIME[2007-03-31T16:22:28.000Z]], [TIME[2023-10-10T16:14:12.178Z]] <https://www.w3.org/People/mimasa/>
* 性能
[145]
[[エスケープシーケンス]]の分、
[[シフトJIS]]や[[日本語EUC]]よりバイト長は微妙に大きくなる傾向があります。
[146]
[[かな]]、[[漢字]]が3バイトになる [[UTF-8]] よりはバイト長が短い傾向がありますが、
(文章ではなく) [[Webアプリケーション]]の [[HTML]] のように
[[ASCII文字]]が多く[[かな]]、[[漢字]]がまばらだと [[UTF-8]] の方が短いこともあります。
[147]
[[gzip]] 圧縮するとこの傾向が逆転して、
[[シフトJIS]]や[[日本語EUC]]や [[UTF-8]] よりも [[ISO-2022-JP]]
が短くなることがあります。
[[エスケープシーケンス]]の繰り返しはあまり問題にならなくなりますし、
[[7ビット]]の[[符号構造]]がかえって圧縮効率を高めていそうです。
* 歴史
もともと [[JUNET]] での通信用符号として決められました。
そもそもは漢字コードには [[JIS]] のものを使う, という緩い取り決め
しかなかったようです。
最初は JIS の不具合で、 JIS X 0201 Roman 集合の指示に
ESC 02/08 <(> 04/07 (H) を使っていましたが、正しい
ESC 02/08 <(> 04/09 (J) に改めました。その時により細かい点が
合意されて、現在の ISO-2022-JP とほぼ同じ[[文字コード]]
が出来上がりました。 [[JUNETの手引きの漢字コードの説明]]が
それをまとめたものです。 (この[[文字コード]]は JUNET コード
と呼ばれるようになりました。) (1987年頃)
1993年頃、 [[ietf-822ext]] では [[MIME]]
の制定が進められていました。その時に JUNET コードを
MIME で使えるように登録することになりました。
その名前は当初はそのまま "junet-code" とする案でしたが、
結局 ISO-2022-JP になりました。この文書が RFC 1468
<urn:ietf:rfc:1468> です。 RFC 1468 は JUNET コードを
より厳密に定義しなおしました。
1993年、 RFC 1468 に日本語以外の文字集合を追加した多言語拡張,
[[ISO-2022-JP-2]] や [[ISO-2022-INT-1]] が定義されました。
(1997年には RFC 2237 で、 RFC 1468 + [[JISX0201]]
の [[ISO-2022-JP-1]] が定義されました。)
1997年には [[JISX0208]] が改正され、附属書2 RFC 1468
符号化表現 (規定) として [[JIS]] で標準化されました。
これは RFC 1468 で定義された符号を JIS のほかの規格・規定
と整合するようにしたものです。かなり無理がたたって、
結局 RFC 1468 とは別物になってしまったという説まであります。
1998年頃、 RFC 1468 の改訂 [[Internet-Draft]]
draft-yamamoto-charset-iso-2022-jp がかかれました。
<urn:ietf:id:draft-yamamoto-charset-iso-2022-jp-02>
RFC 1468 には幾つか不具合が見つかっていましたし、
その後の JIS の改訂や [[ietf-822]] の [[RFC822]]
改訂案 (後の [[RFC2822]]) に比べると RFC 1468
は時代遅れになってました。
bis1468 は厳密な規定・解釈が求められるようになってきた
時代背景を反映して、一層規定が厳密になりました。
しかし [[IETF]] [[RFC]] になることなく expire されました。
2000年には [[JISX0213]]:2000 が制定され、
附属書2 ISO-2022-JP-3 符号化表現では ISO-2022-JP
と似た構造を持つ [[ISO-2022-JP-3]] が定義されました。
ただし、 ISO-2022-JP-3 は ISO-2022-JP や JUNET コードとは
互換性が全くありません。
** ISO/IEC 2022 への適合性
[52]
[[ISO-2022-JP]] が [[ISO/IEC2022]] に適合するかについて
いろいろ言われてきました。
[BIS1468] と [JISX0208:1997] は、 ISO/IEC 2022
には適合しないと明言しています。
このことについて、 『RFC1468とISO 2022のカンケイ』
<http://www.xinada.ne.jp/~handa/tech/Scribbles/RFC1468-and-ISO2022>
という文章がとてもよくまとめています。だけどここではあえて
その内容を繰り返します。
ISO-2022-JP が ISO/IEC 2022 に適合するかどうかの問題点
は次のものが挙げられています。
= 漢字 (JIS X 0208-1978, -1983) が[[指示]]されている状態で制御文字や [[SPACE]] などが使用できない
= 改行 ([[CRLF]]) で(指示がなくても) ASCII に戻しても良い
= 更新番号 ([[IRR]]) がなくても JIS X 0208-1990 が使える
[[JISX0208]]:1997 の解説は、 RFC 1468 符号化表現の問題点を
3つ挙げる。
= [[指示]]シーケンスによる文字集合の選択が曖昧である
= 改行後の文字集合の扱いの実装にばらつきがある
= ISO/IEC 2022 の subset であるかの誤解を与える
= (一々文字集合を指示するのは古くさい)
残念なことに、解説は問題点を挙げる以上の説明をしていない。
*** 漢字列中での制御文字などの使用
この問題はそもそも [[JUNET]] コードよりまだ昔に起因します。
当時広く流布していた[[漢字イン・漢字アウト]]説によると、
漢字インした状態では制御文字が使えません。この神話に基づく
実装では実際その通りになったので、 JUNET 初期は (あまり深い意図無しに)
漢字列中で制御文字などを使用しないことにしていたみたいです。
[[JUNETの手引き]]にある JUNET コードが成立した頃には、
この説は否定されました。そして制御文字などを漢字列中で
使っても良いことにし、その方向に進めようという姿勢が
手引きにはあります。 (なお、改行だけは、行指向のソフトウェア
が簡単に実装できるように、従来通り ASCII 状態とすることに
なりました。)
ところがこの企みはそううまくいかなかったのか、 RFC 1468
では一転して禁止されてしまいました。以後の仕様や実装は
それに従っています。
さて本題の ISO/IEC 2022 適合性ですが、この規定は
生の ISO/IEC 2022 より制限するものではありますが、
対立するものではないですから、適合性には影響しない
という解釈が大勢だと思われます。 (特に JUNET コードの場合は
推奨なので、まったく違反しないでしょう。)
*** 改行で指示がなくても ASCII に戻してよい
[92]
この規定は JIS X 0208:1997 附属書2 にのみあります。
この動作はエラー処理かもしれません。 RFC 1468 も当の JIS X 0208:1997
附属書2 も、改行 [[CRLF]] は漢字列中には現れません。
だけど現れたら・・ってこと。 (だけど、他の考え得るエラー処理
のことは規定されていないしなあ。)
行指向ソフトウェアでは前の行で JIS X 0201 Roman か ASCII
のどちらで終わったか調べ{れ|たく}ないので、 ASCII だと
仮定したいのですが、そういう場面での話かもしれません。
([BIS1468] に似たような話があります。)
いずれにせよ実装の話であってそのような符号列の出力を
認めているわけではありませんから、
([[受信装置]]の適合性は疑わしい可能性がありますが)
データの適合性には影響しないでしょう。
JIS X 0213:2000 附属書2 の [[ISO-2022-JP-3]]
にも同様の話がありますが、 ISO/IEC 2022 に適合しないとは
書かれていません。 (逆にするとも書かれていませんが。)
ですから、 JIS としてはこの点は ISO/IEC 2022 への適合性に
関して問題ないと判断しているのではないでしょうか。
JIS X 0208:1997 の解説にもこの問題が取り上げられていますが、
解説の解説が欲しいような曖昧な指摘です。
たぶん、実装が行頭で勝手に漢字から ASCII に戻したり、
JIS X 0201 roman から ASCII に替えたりするのは問題だ、
といいたいんじゃないかな。
[91]
[[改行]]による [[ASCII]] 復帰 (をする実装があるが、
すべての実装がそうだということでもない。) は他の解釈もあり得ます。
[[メール本体]]や[[行指向]]の[[テキストファイル]]が特定の[[符号化文字集合]]で記述された1つの[[文字列]]とは必ずしも断言できません。
「改行」という[[プロトコル要素]]によって「行」という[[プロトコル要素]]が連結されていて、
各「行」は何らかの[[符号化文字集合]]によって符号化されている、
という建付けなら、
[[改行]]によって行頭 [[ASCII]] になったとしても、
どの[[符号化文字集合]]規格にも違反しません。
;;
[93]
実際 [[RFC 822]] は[[メール本体]]を [CODE[text]] (1行)
を[[改行]]区切りで連接したものとする [[ABNF]] 構文を定めていました。
[94]
ところで、[[改行]]で [[ASCII]] に復帰する実装を想定するなら、
他の [[C0制御文字]]や [CODE(charname)@en[SP]]
(や [CODE(charname)@en[DEL]] も?) をもって
[[ASCII]] に復帰する実装も想定するべきでは、
という疑問もあります。
[102]
[[改行]]が [N[0x0D]] [N[0x0A]] だけしか想定されていないのもおかしな点。
確かに[[インターネットメール]]では[[改行]]は [N[0x0D]] [N[0x0A]]
と定められていますが、 [[Unix]] 系ツールなら [N[0x0A]]
のみでも[[改行]]とみなすものがほとんどのはず。
当時まだ現役だった [[Mac OS]] の [N[0x0D]]
のみの[[改行]]に対応していたソフトウェアも多かったはず。
そうした実装は対象と考えていなかったのだろうか。
*** 更新番号なしで JIS X 0208-1990 が使える
JIS X 0208-1990 を指示するには更新列 ESC 02/06 04/00
が指示列の直前に必要ですが、 RFC 1468 は使わないことを提案 (suggest)
し、 [BIS1468] ははっきりなくても追加文字を使ってよいこととし、
JIS X 0208:1997 附属書2 も (JIS としての都合上) そうしています。
このことが ISO/IEC 2022 への不適合の疑いがあるわけです。
ただし、 [[IRR]] が定義されていなかったふるい ISO/IEC 2022
との絡みなどの理由から、不適合には当たらないのではという
説もあります。 (だけど規格に問題ないって書いてあるわけじゃないし、
ちょっと弱い気がする。)
*** 文字集合の区別がいい加減
あまり問題視されませんが、 ASCII & JIS X 0201 Roman,
JIS X 0208-1978 & -1983 の code point unify
のほうが問題のような気もします。 ISO/IEC 2022 と [[ISOREG]]
で規定された[[終端バイト]]と[[符号化文字集合]]の対応関係を
適当に無視することを認めているからです。
まあ、この装置では JIS X 0201 を使えないから ASCII
の似たのにエラー処理で変換しただけだ、みたいな
言い訳は思いつきますけど。 (その言い訳が通る (どこを?)
かどうかは知りませんが。)
JIS X 0208:1997 附属書2 は深刻です。 -1978 と -1983
で入れ替えられた文字は (文書に明示するだけで自由に)
逆にして構いませんし、 -1978 になかった文字は実装しなくて
構いません。堂々と規定してあるのでエラー処理だなんて
言い訳は出来ません。そりゃあ ISO/IEC 2022 には適合しない、
って参考に書きたくもなりますわ。 (そのくせ ASCII と
JIS X 0201 の差異2文字は入れ替えてもいい、みたいな
規定はないなんて、片手落ちな。さすがにそれしたら
ISO/IEC 646 や JIS X 0201 に適合しなくなるから? (なにをいまさら))
(文字を実装しなくて良い、はデータの適合性には影響しないでしょうが、
受信装置の適合性で問題がある可能性があります。
でもまあ参照されてる側の規格がいいと言ってるからいいのかな?
(でも ISO-IR で参照されてるのは -1978 とか -1983 だったりする。
ISO-IR には最新版適用規則はないはず。))
この項と前の項が、 JIS X 0208:1997 解説の言うところの
文字集合選択が曖昧である、の指すところだと思います。
*** ISO-2022-JP という名前は ISO/IEC 2022 の subset のような印象を与える
(上の様な非適合性問題がなければ) 確かにそのとおりであって、
別に問題はないんですが・・・。
元々 ISO-2022-JP という名前は、 [[MIME]] で (Internet
の[[電子メイル]]で) 使う ISO/IEC 2022 に基づく表現の、
日本で使われてるやつ、くらいの意味でつけたんであって、
[[JUNETコード]]の正式名称にしようなんて意気込んでつけた
わけじゃないでしょう。
そもそも当の [[JUNET]] では JIS の符号を使う、という方針で
動いていたわけですから、 ISO/IEC 2022 に不適合とわかれば
頑張って修正したんじゃないでしょうか。 ESC ( H みたいにね。
(もちろん、今じゃもう無理でしょう。 ([[JUNET]] もないし。))
ISO-2022-JP ってのは数奇な運命を辿った
[[符号化文字集合]]だなあと思います。
*** その他
- 2002-09-30 (Mon) 17:11:36 ''[[名無しさん]]'' : JIS X 0208:1997 の解説は、 JIS 本体の解説は豊富だけど、新たに (しかも制定間際にとってつけたように) 加えられた RFC 1468 符号化表現については (シフト符号化表現についてもですが) 説明が少なすぎると感じます
- 2002-09-30 (Mon) 17:13:07 ''[[名無しさん]]'' : JIS X 0208:1997 の制定の頃話題になった ISO/IEC 2022 への適合性はもちろんのこと、 JIS に取り入れられるまでの歴史とかを入れて然るべきじゃないでしょうか。
[53] <http://pc5.2ch.net/test/read.cgi/linux/1003159137/667->
>674 名前:672[sage] 投稿日:04/12/03(金) 03:59:08 ID:9rXlF8ug
>解答例:
改訂番号の識別機能を使うとき、それがエスケープシーケンスとしてCCデータ要素
に埋め込まれている必要はない。
したがって、改訂番号識別シーケンスを使わないことをもってただちに不適合である
とは結論できない。
** 参考文献
:[JUNET]:『JUNET 利用の手引き第1版』 (See [[JUNETの手引きの漢字コードの説明]])
:[RFC1468]:“Japanese Character Encoding for Internet Message”, [[IETF]] [[RFC]] 1468, <urn:ietf:rfc:1468>
:[RFC1554]:“[[ISO-2022-JP-2]]: Multilingual Extension to ISO-2022-JP”, [[IETF]] [[RFC]] 1554, <urn:ietf:rfc:1554>
:[RFC2237]:“Japanese Character Encoding for Internet Message”, [[IETF]] [[RFC]] 2237, <urn:ietf:rfc:2237> (See [[ISO-2022-JP-1]])
:[BIS1468]:“Japanese Character Encoding for Internet Message”, [[IETF]] [[Internet-Draft]], <urn:ietf:id:draft-yamamoto-charset-iso-2022-jp-02>
:[JISX0208]:『7ビット及び8ビットの2バイト情報交換用符号化漢字集合』, [[JISX0208]]:1997
** RFC 1468 の [CODE[ISO-2022-JP]]
[39] [DFN[[[RFC 1468]]]] は、[[日本語]]用の[[文字コード]]である [[ISO-2022-JP]] を規定しています。
[[ISO-2022-JP]] の定義は複数存在しますが、「[[ISO-2022-JP]]」という名を翳した最初の正式な文書である
[[RFC 1468]] が原典であると考えられています。
[REFS[
- [54] [CITE@en[[[RFC 1468]] - Japanese Character Encoding for Internet Messages]], [TIME[2021-01-31T08:38:25.000Z]], [TIME[2021-03-13T11:49:28.666Z]] <https://tools.ietf.org/html/rfc1468>
]REFS]
[40] [[RFC 1468]]は単なる[[文字コード]]ではなく、
従来[[JUNET]]で[[822]][[メッセージ]]の[[本文]]で使われてきた[[文字コード]]を[[MIME]]で使うために説明 & [[IANA]]登録するという形を採っているので、
[CSECTION@en[Formal Syntax]]には[CODE(ABNF)@en[headers]]も含まれた[CODE(ABNF)@en[message]]の構文として説明されている。
;; 古い案では[CODE(ABNF)@en[[[message]]]]と[CODE(ABNF)@en[[[headers]]]]はなく、[CODE(ABNF)@en[[[line]]]]があったのに、わざわざいまの形に変更されている。
[CITE[iso-2022-jp doc]]
<http://www.imc.org/ietf-822/old-archive1/msg02541.html>
にも関わらず、後から[[ietf-822]]で指摘されて[CSECTION@en[MIME Considerations]]に[CODE(ABNF)@en[[[encoded-word]]]]でも使えると追記しており、
構文はそのままなので、どう使うのかが説明できていない。
;; しかも一時は別文書にするつもりだったらしい。
[CITE@en[Re: JUNET Kanji code document review]]
<news:BytJt0.Jto@poel.juice.or.jp>
[41] 末尾では[[ASCII]]状態でなければならないとされている。
これは[[SMTP]]/[[822]]が[[ASCII]]で終わることとの整合性のためらしい。
;; [CITE[re: new version of ISO-2022-JP document]]
<http://www.imc.org/ietf-822/old-archive1/msg02528.html>
[[JUNET利用の手引き]] (6.3)
では[[JIS X 0201]]で終えてもよいこととされており、
現実にもそうされていたのと矛盾している。
;;
1つの[[メッセージ]]中で[[ASCII]]と[[JIS X 0201]]の[[指示シーケンス]]を併用するのは稀で、
1992年当時は[[JIS X 0201]]の方がよくつかわれていた。
[CITE@en[ESC$? ESC(?]]
<news:144@isdn1.smsc.sony.com>,
[CITE@en[ESC$? ESC(?]]
<news:1993Jan3.064853.27094@sm.sony.co.jp>
[42]
当初の案では隣接する[[指示シーケンス]]は異なるものであるべき
([Q@en[should]]) とし、推奨されない例 ([Q@en[not recommended]])
[CODE(example)@en[[CODE(charname)@en[[[ESC]]]] $ B [VAR[....]] [CODE(charname)@en[[[ESC]]]] $ B [VAR[....]]]]
を示していた。
この部分は不要ということで削除された。
;; [CITE[Re: iso-2022-jp]]
<http://www.imc.org/ietf-822/old-archive1/msg02480.html>
[43]
[CSECTION@en[Description]]には[[JIS X 0208]]‐''1983''と明記されているが、
[CSECTION@en[Background Information]]には[[更新番号]]なしで'''1990''''版の追加2文字を使ってもいいことにしようと提案している
([Q@en[suggested here]])。
[[著者]]のエリックはそれを書き足すに先だって同じことを提案しているが、
それに関する議論はなかったのか、あるいは残っていない。
[[反論がなければ合意]]なのか? [[合意]]がないから曖昧なのか?
;; [CITE@en[Re: JUNET Kanji code document review]]
<news:Bu7Av0.2I4@poel.juice.or.jp>
;; そもそも[[RFC 1468]]に向けた作業をしていたらしい[[メイリング・リスト]]の記事が残っていない・・・。
[44]
[Q@en[Formal Syntax]] には、[[指示シーケンス]]なしの[[行]]が認められない不具合がある。
[45]
[Q@en[Formal Syntax]] によれば、[[行]]最後の
[CODE(char)@en[[CODE(charname)@en[[[ESC]]]] ( B]] or [CODE(char)@en[[CODE(charname)@en[[[ESC]]]] ( J]]
''以外''の[[指示シーケンス]]の後には1文字以上必要。
もとの[[JUNET利用の手引き]] (6.3) にはこの制限は書かれていない。
;; もっとも現実には[[RFC 1468]]の制限があっても問題はないだろう。
[46]
[Q@en[Formal Syntax]] によれば、[CODE(charname)@en[[[CR]]]]と[CODE(charname)@en[[[LF]]]]は単独では使用できず、
必ず[CODE(ABNF)@en[[[CRLF]]]]でなければならない。
この制限は[[822]]/[[SMTP]]由来で、[[RFC 1468]]の性質 (>>1)
によるものと考えられる。
もとの[[JUNET利用の手引き]]には書いてないが、
暗黙の仮定 (というより別の層の問題) としていたと考えてよいだろう。
;;
では[[MIME]][[本体]]以外で[[RFC 1468]]の[[文字コード]]が使われる場合にこの制限はどうなるのか。
;;
[[JUNET]]の時代も、ネットワーク転送中は[CODE(ABNF)@en[[[CRLF]]]]になるとしても
(なるの?)、
[[UNIX]]内部では[CODE(charname)@en[[[LF]]]]にしていたのでは。
[47]
[CSECTION@en[Formal Syntax]] によれば、[[JIS X 0208]]
状態では[[制御文字]]や[CODE(charname)@en[[[SPACE]]]]が使えない。
[[JUNET利用の手引き]] (6.3) では、
[[改行]]前に[[ASCII]]または[[JIS X 0201]]状態にするのが望ましいことと[[JIS X 0208]]状態で[[制御文字]]や[CODE(charname)@en[[[SPACE]]]]を使ってもよいことが書かれているから、
それと整合していない。
ただし、92年時点で[[JIS X 0208]]状態で[[制御文字]]や[CODE(charname)@en[[[SPACE]]]]に対応できない実装があったようだし、
ほとんど (ほとんど。) の[[メッセージ]]は[[RFC 1468]]の構文通りになっていたようだ。
[48]
[CSECTION@en[Background Information]] に古い [CODE(char)@en[[CODE(charname)@en[[[ESC]]]] ( H]]
は使うべきではない ([Q@en[should not]]) と書いてある。
>>42 の [Q@en[should]] やそれへの指摘
;; [CITE[Re: iso-2022-jp]]
<http://www.imc.org/ietf-822/old-archive1/msg02479.html>
も踏まえて、推奨なのか禁止なのか。推奨なら [CSECTION@en[Description]]
や [CSECTION@en[Description]] や[[JUNET利用の手引き]] (禁止)
や当時の実情 (絶滅) と矛盾する。
** JIS X 0208:1997 の RFC 1468 符号化表現
[1034]
[DFN[RFC 1468符号化表現]]は、[[JIS X 0208]]:1997で規定されている[[符号化文字集合]]です。
その参考によれば[Q[通常、[Q[ISO-2022-JP]]と呼ばれており、[[インターネット]]で使用されている]]らしいですが、
[[RFC 1468]]で説明されている[CODE(MIME)@en[[[ISO-2022-JP]]]]とは相違点も多く、
かといって[[IETF]]の[[RFC 1468]]を改訂することを意図したものや[[IANA]]における[CODE(MIME)@en[[[ISO-2022-JP]]]]の登録の更新を意図したものでは''ない''ようであり、
何を考えて制定したものなのかがよくわからないところです。
[1036] [Q[RFC 1468符号化表現]]という怪しい名前にも関わらず、
規格中に[[RFC 1468]]との関係について説明がまったくありません。
[1035]
> ソースは?
> ▼インターネットで見た
[101] 仕様書:
- [[JIS X 0208]]:1997
-- [CSECTION[附属書2 (規定) RFC 1468 符号化表現]]
*** 符号化文字集合
- [103] [CODE[0x00]]〜[CODE[0x1F]]: [[制御文字]]:
[[JIS X 0211]] (最新版)
[[C0集合]]
[SRC[JIS97 附属書2 4.1 a)]]
-- [104] [[情報交換]]の先頭では、使用できる状態。
[SRC[JIS97 附属書2 4.2 a)]]
-- [105] [CODE[0x0E]]: [[使用しない]]。
[SRC[JIS97 附属書2 4.1 a)]]
-- [106] [CODE[0x0F]]: [[使用しない]]。
[SRC[JIS97 附属書2 4.1 a)]]
-- [107] [CODE[0x1B]]: 領域の切換え。
[SRC[JIS97 附属書2 4.1 a), f)]]
--- [108] [CODE[0x1B 0x28 0x42]]: [[制御文字]]の領域を使用する。
[[図形文字]]の領域は[[ISO/IEC 646]] (最新版) [[IRV]]
--- [109] [CODE[0x1B 0x28 0x4A]]: [[制御文字]]の領域を使用する。
[[図形文字]]の領域は[[JIS X 0201]] (最新版)
[[ラテン文字用図形文字集合]]
--- [1010] [CODE[0x1B 0x24 0x40]]: [[制御文字]]の領域を使用''しない''
([CODE[0x1B]] を除く)。
[[図形文字]]の領域は[[JIS X 0208]]:1997本体6.5.1の[[漢字集合]]で、
[[JIS X 0208]]:1997 附属書2表1の[[図形文字]]の組を入れ替えたもの。
[CODE(charname)@en[[[SPACE]]]]を使用しない。
[CODE(charname)@en[[[DELETE]]]]を使用しない。
--- [1011] [CODE[0x1B 0x24 0x42]]: [[制御文字]]の領域を使用''しない''
([CODE[0x1B]] を除く)。
[[図形文字]]の領域は[[JIS X 0208]]:1997本体6.5.1の[[漢字集合]]。
[CODE(charname)@en[[[SPACE]]]]を使用しない。
[CODE(charname)@en[[[DELETE]]]]を使用しない。
--- [1012] これ以外で [CODE[0x1B]] は[[使用しない]]。
- [1013] [CODE[0x20]]: [CODE(charname)@en[[[SPACE]]]]
- [1014] [CODE[0x21]]〜[CODE[0x7E]]: [[図形文字]]
-- [1015] [[情報交換]]の先頭では、[[ISO/IEC 646]] (最新版) [[IRV]]。
[SRC[JIS97 附属書2 4.2 a)]]
- [1016] [CODE[0x7F]]: [CODE(charname)@en[[[DELETE]]]]
- [1017] [CODE[0x80]]〜[CODE[0xFF]]: [[使用しない]]。
- [1018] [[情報交換]]の末尾では、[[ISO/IEC 646]] (最新版) [[IRV]]
の状態でなければなりません。 [SRC[JIS97 4.3 a)]]
;;
[1030]
元の[[RFC 1468]]は明らかに[[7ビット符号]]を規定しているのに、
[[RFC 1468符号化表現]]はなぜか[[8ビット符号]]のようです。
[1032]
[[JIS]]は他[[規格]]の最新版を参照していますが、
元の[[RFC 1468]]はすべて年号付きで引用しています。
たまたま[[JIS X 0211]], [[ISO/IEC 646]] [[IRV]],
[[JIS X 0201]]とも1997年の時点で[[RFC 1468]]の参照する規格と内容が一致している
(ようにみえる) のですが、将来もそうである保障はありません。
(実際[[ISO/IEC 646]] [[IRV]]は1991年に非互換変更されていますから。)
将来[[RFC 1468符号化表現]]が勝手に違うものになってしまう危険性があります。
[1033] >>1010 は[[JIS X 0208]]‐1983で行われた[[漢字]]の入れ替えを元に戻すことを求めていますが、
なぜか[[JIS X 0208]]‐1983および[[JIS X 0208]]‐1990での追加分には触れていません。
(>>1029 は[[装置]]の適合性に関する規定のようです。)
[1037]
>>1010-1011 の2つの[[指示シーケンス]]の後は[[制御文字]]が使えないことになっていて
(附属書2 4.1 f))、[CODE(charname)@en[[[ESC]]]]も例外とされて''いません''。附属書2図3〜5もそうなっています。
附属書2 4.2 b) で [Q[4.1 f) の[[バイト列]]が現れた場合は、 4.1 f) に示す利用状態の遷移が起こる]]とありますが、
4.1 f) の規定に従えば一旦[[JIS X 0208]]状態に遷移すると4.1 f)
の[[バイト列]]は出現できないので・・・。
[1038]
>>1037 と >>1018 により、[[RFC 1468符号化表現]]で[[JIS X 0208]]を使うことは無理としか考えられない。
[PRE(aa)[
[AA(fw)[ ]]ナ ゝ[AA(fw)[ ]]ナ ゝ[AA(fw)[ ]]/[AA(fw)[ ]] 十[AA(fw)[_]]"[AA(fw)[ ]] ー;=‐[AA(fw)[ ]]|! |!
[AA(fw)[ ]]cト[AA(fw)[ ]]cト[AA(fw)[ ]]/[AA(fw)[^]][AA(hw)[、]]_ﾉ[AA(fw)[ ]] | [AA(hw)[、]].__[AA(fw)[ ]]つ[AA(fw)[ ]] [AA(fw)[(]].__ [AA(fw)[ ]] [AA(fw)[‾‾‾‾]] [AA(fw)[ ]] ・ ・
]PRE]
*** 適合性
[1019]
'''情報交換の適合性''':
[[情報交換]]の[[適合性]]は、[[JIS X 0208]]:1997
本体 3.2 ([SEE[ [[JIS X 0208]] ]]) によります。
ただし、[[符号化文字集合]]については[[JIS X 0208]]:1997
附属書2 4. (>>102) によります。
[SRC[JIS97 附属書2 2.1]]
[1020] 本体3.2の規定により、[[適合性]]を主張する情報交換は採用した[[符号化文字集合]]を[Q[[[文書]]に明示]]しなければなりません。
この規定は附属書2では上書きされておらず、有効と思われます。
[1021] '''装置の適合性'''
[[装置]]の[[適合性]]は、[[JIS X 0208]]:1997 附属書2.2の規定によります。
[SRC[JIS97 附属書2 2.1]]
;;
[90]
規格本体にも規定がありますが、そちらではなく、
個別の規定が適用されるようです。参考として
[Q[[[インターネット]]の[[情報交換]]においては、[INS[〜]][[空き領域]]の[[利用]]は行われない]]とあり、
そのために本体や[[シフト符号化表現]]とは別の[[適合]]の要件が規定されているのだと思われます。
- [1022] 本体3.1 ([SEE[ [[JIS X 0208]] ]]) [SRC[JIS97 附属書2 2.2]]
- [1023] 本体3.3.1 ([SEE[ [[JIS X 0208]] ]]) [SRC[JIS97 附属書2 2.2]]
- [1024] 本体3.3.2 ([SEE[ [[JIS X 0208]] ]]) と附属書2 2.2.2 (>>1026) の一方又は両方
[SRC[JIS97 附属書2 2.2, 2.2.1]]
- [1027] [[適合性]]を主張する場合、附属書2の[[符号化文字集合]]を採用したことを[Q[[[文書]]に明示]]しなければなりません。
[SRC[JIS97 附属書2 2.2]]
- [1028] 指定された[[図形文字]]の組を入れ替えても構いません。
その場合、入れ替えの一覧を[Q[[[文書]]に明示]]しなければなりません。
[SRC[JIS97 附属書2 2.2]]
- [1029] 指定された[[図形文字]]を実装しなくても構いません。
その場合、実装しないものの一覧を[Q[[[文書]]に明示]]しなければなりません。
[SRC[JIS97 附属書2 2.2]]
;;
[1025] >>1028 は[[JIS X 0208]]‐1983や[[JIS X 0208]]‐1990で入れ替え等があった[[漢字]]。
>>1029 は[[JIS X 0208]]‐1983や[[JIS X 0208]]‐1990で追加された[[図形文字]]。
[1026] '''受信装置の要件''':
本体3.3.3 ([SEE[ [[JIS X 0208]] ]]) によります。
ただし、[CODE[0x0D 0x0A]]を[[受信]]した場合、
[[図形文字]]の領域を[[ISO/IEC 646]] (最新版) [[IRV]]
に遷移しても構いません。その場合、
[Q[[[文書]]に明示]]しなければなりません。
[SRC[JIS97 附属書2 2.2.2]]
;;
[1031]
>>1010 や >>1011 で[[制御文字]]の領域を[[使用しない]]時に[CODE[0x0D 0x0A]]を[[受信]]すると、
[[制御文字]]の領域がそのまま[[使用しない]]のままになってしまいますが・・・。
[1039]
[[JUNET利用の手引き]]にも[[RFC 1468]]にもない
>>1026 の規定はどこからでてきたのでしょう?
;; そのような実装があった (いまもある?) ことは事実ですが・・・。
[1040]
[[JIS X 0208]]:1997の解説には、
- [[改行]]の後の状態が異なる実装があること、
- [[指示シーケンス]]の解釈が曖昧だと[[RFC 1468]]自身が認めていること、
- [[ISO/IEC 2022]]のサブセットであるかのような誤解を抱かせること
が問題として認められるので、[[ISO-2022-JP]]の実装が[[JIS X 0208]]への[[適合]]を主張できるように附属書にしたという旨の説明があります。
わかるようなわからないような説明である上に、
本当に挙げられた問題を解決できているのか甚だ疑問であります。
[96]
[[JIS C 6226-1978]] と [[JIS C 6226-1983]] の2つの[[指示シーケンス]]を、
後者は [[JIS X 0208:1997]] の漢字集合、
前者は [[JIS X 0208:1997]] の漢字集合の一部 ([[83JIS]] 入れ替え相当) を入れ替えたもの、
という意味と定めています。
「古いJIS」と参照するわけにもいかず苦肉の策なのでしょうが、
入れ替えだけ戻して文字の追加や字形の変更は反映していないので、
本来 [[78JIS]] であったものが 「[[78JIS]] のような変な何か」
になっているのは気持ち悪いですね。
[97]
しかも実装は
[[78JIS]], [[83JIS]], [[90JIS]] の適当なミックスでも適合するっぽいのですが、
本当にそんなのでいいのでしょうか。
[[相互運用性]]はハナから放棄していたのでしょうかね。
[SEE[ [[JIS X 0208]] ]]
実装については2つの[[指示シーケンス]]を区別しろとは書かれていません。
入れ替えについてはしてもしなくても適合しそうですが、
その他の変更についてはどうですかね?
[98]
ちなみに [[ASCII]] と [[JIS X 0201]] [[ラテン文字用図形文字集合]]は区別しなくてもいいとは書かれていないので、
区別しなければ適合しないはずです。
実際には区別しない実装もたくさんあった (今もある) はずで、
そういう実装を適合させる意図はなかったのでしょうか。
;; [99] [[JIS X 0208:1997]] 全体的に言えることですが、
おかしな実装も含めて歴史的ないろいろを無理に適合させようとしている点と、
いろいろあるはずなのに救済措置が何もない点が混じっていて、
どこで線引したのかさっぱりわかりません。
[100]
[[シフト符号化表現]]には[[外字]]を認めるような規定がありますが、
[[RFC 1468符号化表現]]にはありません。
(これも現実と乖離しています。)
[110]
本体の [[ISO/IEC 2022]] 系の[[符号化文字集合]]や[[シフト符号化表現]]では[[全角英数字]]を禁止し、
または[[代替名称]]を用いることにしていますが、
[[RFC 1468符号化表現]]には相当の規定がありません。
従って[[全角英数字]]を使用しない[[漢字集合]]とみなすことも、