-
Notifications
You must be signed in to change notification settings - Fork 4
/
374.txt
2668 lines (2326 loc) · 131 KB
/
374.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
[FIG(important)[
[1] [[RFC 2070]] は [[RFC 2854]] により廃止されました。
[2147483646] かつて [[RFC 2070]] が規定していた領域は、現在は
[[HTML Standard]] で規定されています。
;; [3] [[HTML 2.[VAR[x]]]] も参照。
]FIG]
'''Internationalization of the Hypertext Markup Language'''
- Network Working Group
- Request for Comments: 2070
- Category: Standards Track
- F. Yergeau
- Alis Technologies
- G. Nicol
- Electronic Book Technologies
- G. Adams
- Spyglass
- M. Duerst
- University of Zurich
- January 1997
* Status of this Memo
> This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
* Abstract
> The Hypertext Markup Language (HTML) is a markup language used to
create hypertext documents that are platform independent. Initially,
the application of HTML on the World Wide Web was seriously
restricted by its reliance on the ISO-8859-1 coded character set,
which is appropriate only for Western European languages. Despite
this restriction, HTML has been widely used with other languages,
using other coded character sets or character encodings, at the
expense of interoperability.
ハイパーテキスト・マーク付け言語 (HTML) は、
ハイパーテキスト文書を作成するのに使用する、
環境独立なマーク付け言語です。はじめ、 World Wide Web
での HTML の応用は、西欧言語にのみ適切な [CODE(charset)[ISO-8859-1]]
符号化文字集合に依存して激しく制限されていました。
この制限にもかかわらず、 HTML
は他の符号化文字集合や文字符号化を使って他の言語で
(相互運用性を犠牲にして) 広く使われています。
> This document is meant to address the issue of the
internationalization (i18n, i followed by 18 letters followed by n)
of HTML by extending the specification of HTML and giving additional
recommendations for proper internationalization support. A foremost
consideration is to make sure that HTML remains a valid application
of SGML, while enabling its use with all languages of the world.
この文書は、 HTML の仕様書を拡張して、
適切な国際化 ([ABBR[i18n]], [CODE[i]] の後に18文字置いて [CODE[n]])
対応のための追加の勧告を行って HTML
の国際化の問題に言及しようとしています。
もっとも重視したことは、 HTML を SGML の妥当な応用としながらも世界のすべての言語を使うことを可能にするという点であります。
* Table of Contents
[PRE[
1. Introduction .................................................. 2
1.1. Scope ...................................................... 2
1.2. Conformance ................................................ 3
2. The document character set ..................................... 4
2.1. Reference processing model ................................. 4
2.2. The document character set ................................. 6
2.3. Undisplayable characters ................................... 8
3. The LANG attribute.............................................. 8
4. Additional entities, attributes and elements ................... 9
4.1. Full Latin-1 entity set .................................... 9
4.2. Markup for language-dependent presentation ................ 10
5. Forms ..........................................................16
5.1. DTD additions ..............................................16
5.2. Form submission ............................................17
6. External character encoding issues .............................18
7. HTML public text ...............................................20
7.1. HTML DTD ...................................................20
7.2. SGML declaration for HTML ..................................35
7.3. ISO Latin 1 character entity set ...........................37
8. Security Considerations.........................................40
Bibliography ......................................................40
Authors' Addresses ................................................43
]PRE]
* 1. Introduction
> The Hypertext Markup Language (HTML) is a markup language used to
create hypertext documents that are platform independent. Initially,
the application of HTML on the World Wide Web was seriously
restricted by its reliance on the ISO-8859-1 coded character set,
which is appropriate only for Western European languages. Despite
this restriction, HTML has been widely used with other languages,
using other coded character sets or character encodings, through
various ad hoc extensions to the language [TAKADA].
ハイパーテキスト・マーク付け言語 (HTML) は、
ハイパーテキスト文書を作成するのに使用する、
環境独立なマーク付け言語です。はじめ、 World Wide Web
での HTML の応用は、西欧言語にのみ適切な [CODE(charset)[ISO-8859-1]]
符号化文字集合に依存して激しく制限されていました。
この制限にもかかわらず、 HTML
は色々な特別な拡張によって他の符号化文字集合や文字符号化を使って他の言語で
(相互運用性を犠牲にして) 広く使われています。
> This document is meant to address the issue of the
internationalization of HTML by extending the specification of HTML
and giving additional recommendations for proper internationalization
support. It is in good part based on a paper by one of the authors
on multilingualism on the WWW [NICOL]. A foremost consideration is
to make sure that HTML remains a valid application of SGML, while
enabling its use with all languages of the world.
この文書は、 HTML の仕様書を拡張して、
適切な国際化 ([ABBR[i18n]], [CODE[i]] の後に18文字置いて [CODE[n]])
対応のための追加の勧告を行って HTML
の国際化の問題に言及しようとしています。
それは著者の一人の WWW の多言語主義に関する論文に基づいた良い点です。
もっとも重視したことは、 HTML を SGML の妥当な応用としながらも世界のすべての言語を使うことを可能にするという点であります。
> The specific issues addressed are the SGML document character set to
be used for HTML, the proper treatment of the charset parameter
associated with the "text/html" content type and the specification of
some additional elements and entities.
特に言及している問題は、 HTML で使用する SGML
文書文字集合、 [CODE(MIME)[[[text/html]]]] 内容型に関連付けられた
[CODE(MIME)[[[charset]]]] 引数の適切な取扱い、
それに幾つか追加の要素と実体の規定です。
** 1.1 Scope
> HTML has been in use by the World-Wide Web (WWW) global information
initiative since 1990. This specification extends the capabilities
of HTML 2.0 (RFC 1866), primarily by removing the restriction to the
ISO-8859-1 coded character set [ISO-8859].
HTML は1990年から World Wide Web (WWW) 活動で使われてきました。
この仕様書は [[HTML 2.0]] ([[RFC 1866]]) の能力を、
主として [CODE(charset)[[[ISO-8859-1]]]] への制限を取除くことによって拡張します。
> HTML is an application of ISO Standard 8879:1986, Information
Processing Text and Office Systems -- Standard Generalized Markup
Language (SGML) [ISO-8879]. The HTML Document Type Definition (DTD)
is a formal definition of the HTML syntax in terms of SGML. This
specification amends the DTD of HTML 2.0 in order to make it
applicable to documents encompassing a character repertoire much
larger than that of ISO-8859-1, while still remaining SGML
conformant.
HTML は ISO 規格 8859:1986 情報処理文章及び事務システム —
標準一般化マーク付け言語 ([[SGML]]) の[[応用]]です。
HTML 文書型定義 ([[DTD]]) は HTML 構文の SGML の言葉による正式な定義です。
この仕様書は HTML 2.0 の DTD を改訂して、 SGML
に適合したままながらも [CODE(charset)[ISO-8859-1]]
よりもずっと大きな文字レパートリの文書に適用可能にします。
> Both formal and actual development of HTML are advancing very fast.
The features described in this document are designed so that they can
(and should) be added to other forms of HTML besides that described
in RFC 1866. Where indicated, attributes introduced here should be
extended to the appropriate elements.
HTML の正式な開発も実際の開発も非常に速く進みます。
この文書で記述する機能は RFC 1986 で記述されたものとは別の形の
HTML にも追加できる (しするべきである) ように設計されています。
示されたところでは、ここで導入した属性は適切な要素に拡張するべきです。
** 1.2 Conformance
> This specification changes slightly the conformance requirements of
HTML documents and HTML user agents.
この仕様書は HTML 文書および HTML 利用者エージェントの適合性要件を甚だ変更致します。
*** 1.2.1 Documents
> All HTML 2.0 conforming documents remain conforming with this
specification. However, the extensions introduced here make valid
certain documents that would not be HTML 2.0 conforming, in
particular those containing characters or character references
outside of the repertoire of ISO 8859-1, and those containing markup
introduced herein.
すべての HTML 2.0 適合文書は、この仕様書にも適合します。
しかし、ここで導入する拡張は HTML 2.0 に適合しないある種の文書、
特に ISO 8859-1 のレパートリ外の文字や文字参照を含む文書やここで導入するマークを含む文書を妥当にします。
*** 1.2.2. User agents
> In addition to the requirements of RFC 1866, the following
requirements are placed on HTML user agents.
RFC 1866 の要件に加えて、次の要件を HTML
利用者エージェントに課します。
> To ensure interoperability and proper support for at least
ISO-8859-1 in an environment where character encoding schemes other
than ISO-8859-1 are present, user agents MUST correctly interpret
the charset parameter accompanying an HTML document received from
the network.
[CODE(charset)[ISO-8859-1]] 以外の文字符号化方式の環境で最低
[CODE(charset)[ISO-8859-1]] の相互運用性と適当な対応を確保するために、
利用者エージェントはネットワークから受信した HTML
文書に添えられた [CODE(MIME)[charset]] 引数を正しく解釈しなければ'''なりません'''。
> Furthermore, conforming user-agents MUST at least parse correctly
all numeric character references within the range of ISO 10646-1
[ISO-10646].
更に、適合利用者エージェントは、最低 ISO 10646-1
の範囲内のすべての数値文字参照を正しく解析しなければ'''なりません'''。
[INS[
訳注: ISO/IEC 10646-1 の範囲だと ISO/IEC 10646
のすべての文字が含まれてしまいますが・・・。
([[BMP]] すべてとでも言いたかったのでしょう。)
]INS]
> Conforming user-agents are required to apply the BIDI presentation
algorithm if they display right-to-left characters. If there is
no displayable right-to-left character in a document, there is no
need to apply BIDI processing.
適合利用者エージェントは、右から左への文字を表示する時に [ABBR[BIDI]]
表現算法を適用する必要があります。文書に表示可能な左から右への文字がなければ、
[ABBR[BIDI]] 処理を適用する必要はありません。
* 2. The document character set
** 2.1. Reference processing model
> This overview explains a reference processing model used for HTML,
and in particular the SGML concept of a document character set. An
actual implementation may widely differ in its internal workings from
the model given below, but should behave as described to an outside
observer.
この概観は、 HTML で使用する参照処理模型と、
特に SGML の文書文字集合の概念を説明します。
実際の実装は内部の作業が以降で説明する模型と大きく異なっていても構いませんが、
外から観たらここで説明するように振る舞っているべきです。
> Because there are various widely differing encodings of text, SGML
does not directly address how the sequence of characters that
constitutes an SGML document in the abstract sense are encoded by
means of a sequence of octets (or occasionally bit groups of another
length than 8) in a concrete realization of the document such as a
computer file. This encoding is called the external character
encoding of the concrete SGML document, and it should be carefully
distinguished from the document character set of the abstract HTML
document. SGML views the characters as a single set (called a
"character repertoire"), and a "code set" that assigns an integer
number (known as "character number") to each character in the
repertoire. The document character set declaration defines what each
of the character numbers represents [GOLD90, p. 451]. In most cases,
an SGML DTD and all documents that refer to it have a single document
character set, and all markup and data characters are part of this
set.
文章の符号化には多種多様なものがありますから、 SGML
は抽象的な意味で SGML
文書を構成する文字列が計算機ファイルなどの文書の具体的な存在でどうオクテット列
(あるいは場合によっては8以外の数のビットの組)
として符号化されているのかに直接言及していません。この符号化は具象 SGML
文書の外部文字符号化と呼び、抽象 HTML
文書の文書文字集合とは注意して区別するべきです。 SGML
は文字を一つの集合 ([Q[文字レパートリ]]と呼びます。) と整数
([Q[文字番号]]といわれます。) をレパートリ中のそれぞれの文字に割当てた[Q[符号集合]]としてみます。
文書文字集合宣言は各文字番号が何を表現するかを定義します。
ほとんどの場合、 SGML DTD とそれを参照するすべての文書は一つの文書文字集合を持ち、
すべてのマークとデータはその集合の一部です。
> HTML, as an application of SGML, does not directly address the
question of the external character encoding. This is deferred to
mechanisms external to HTML, such as MIME as used by the HTTP
protocol or by electronic mail.
HTML は、 SGML 応用として、直接外部文字符号化の問題には言及していません。
これは HTML の外の仕組み、例えば HTTP プロトコルや電子メイルによって使われる
MIME の範疇です。
> For the HTTP protocol [RFC2068], the external character encoding is
indicated by the "charset" parameter of the "Content-Type" field of
the header of an HTTP response. For example, to indicate that the
transmitted document is encoded in the "JUNET" encoding of Japanese
[RFC1468], the header will contain the following line:
HTTP プロトコルでは、外部文字符号化は HTTP 応答の頭部の
[CODE(HTTP)[[[Content-Type]]]] 欄の [CODE(MIME)[[[charset]]]]
引数によって示します。例えば、転送される文書が日本の [Q[JUNET]]
符号化で符号化されていることを示すには、
頭部が次の行を含むことになります。
>
[PRE(HTTP)[
Content-Type: text/html; charset=ISO-2022-JP
]PRE]
> The term "charset" in MIME is used to designate a character encoding,
rather than merely a coded character set as the term may suggest. A
character encoding is a mapping (possibly many-to-one) of sequences
of octets to sequences of characters taken from one or more character
repertoires.
MIME の用語 [Q[charset]] は、語感の通りの単なる符号化文字集合ではなく、
文字符号化を示すために使用されます。文字符号化はオクテットの列から一つ以上の文字レパートリから取った文字の列への
(多対一のこともある) 写像です。
> The HTTP protocol also defines a mechanism for the client to specify
the character encodings it can accept. Clients and servers are
strongly requested to use these mechanisms to assure correct
transmission and interpretation of any document. Provisions that can
be taken to help correct interpretation, even in cases where a server
or client do not yet use these mechanisms, are described in section 6.
HTTP プロトコルはクライアントが受入れることのできる文字符号化を指定する仕組みも定義しています。
クライアントと鯖には、すべての文書の正しい転送と解釈を保証するために、
こうした仕組みを使うことを強く要求します。
鯖やクライアントがこのような仕組みを使っていなかったとしても正しい解釈を助けることができる準備については6章で説明します。
> Similarly, if HTML documents are transferred by electronic mail, the
external character encoding is defined by the "charset" parameter of
the "Content-Type" MIME header field [RFC2045], and defaults to
US-ASCII in its absence.
同様に、 HTML 文書が電子メイルで転送される場合も、
外部文字符号化は [CODE(MIME)[[[Content-Type]]]] MIME 頭欄の
[CODE(MIME)[[[charset]]]] 引数で定義し、
存在しない場合には [CODE(charset)[[[US-ASCII]]]] が既定値となります。
> No mechanisms are currently standardized for indicating the external
character encoding of HTML documents transferred by FTP or accessed
in distributed file systems.
FTP で転送されたり分散ファイル・システムで access
する HTML 文書の外部文字符号化を示す仕組みは現在のところ標準化されていません。
> In the case any other way of transferring and storing HTML documents
are defined or become popular, it is advised that similar provisions
be made to clearly identify the character encoding used and/or to use
a single/default encoding capable of representing the widest range of
characters used in an international context.
他の HTML 文書を転送したり蓄積したりする方法が定義されたり好評を博したりする場合には、
同様な仕組みで使用する文字符号化を明確に識別するようにするか、
あるいは国際的な文脈で使われる広範囲の文字を表現する能力のある符号化だけを使ったり既定のものとしたりするか、
その両方とするよう助言致します。
> Whatever the external character encoding may be, the reference
processing model translates it to the document character set
specified in Section 2.2 before processing specific to SGML/HTML.
The reference processing model can be depicted as follows:
外部文字符号化が何であれ、参照処理模型はこれを SGML・HTML
固有の処理の前に2.2節で規定する文書文字集合に翻訳します。
参照処理模型は次の通り表すことができます。
>
[PRE[
[resource]->[decoder]->[entity ]->[ SGML ]->[application]->[display]
[manager] [parser]
^ |
| |
+----------+
]PRE]
[PRE[
[ 資源 ]->[復号器 ]->[実体 ]->[ SGML ]->[ 応用 ]->[ 表示 ]
[ 管理器] [解析器]
^ |
| |
+----------+
]PRE]
> The decoder is responsible for decoding the external representation
of the resource to the document character set. The entity manager,
the parser, and the application deal only with characters of the
document character set. A display-oriented part of the application
or the display machinery itself may again convert characters
represented in the document character set to some other
representation more suitable for their purpose. In any case, the
entity manager, the parser, and the application, as far as character
semantics are concerned, are using the HTML document character set
only.
復号器は資源の外部表現を文書文字集合に復号することに責任を持ちます。
実体管理器、解析器、応用は文書文字集合の文字のみを処理します。
応用の表示指向部分や表示機械自体は再び文書文字集合で表現した文字を他のより目的に沿った表現に変換して構いません。
どの場合でも、実体管理器、解析器、応用は文字の意味に関する限り、
HTML 文書文字集合のみを使います。
> An actual implementation may choose, or not, to translate the
document into some encoding of the document character set as
described above; the behaviour described by this reference processing
model can be achieved otherwise. This subject is well out of the
scope of this specification, however, and the reader is invited to
consult the SGML standard [ISO-8879] or an SGML handbook [BRYAN88]
[GOLD90] [VANH90] [SQ91] for further information.
実際の実装は文書を前述の文書文字集合の符号化に翻訳するかしないかを選ぶことができます。
この参照処理模型で記述した振舞いは他の方法でも達成できます。
しかし、この主題はこの仕様書の適用範囲を明確にすることでありまして、
読者は詳しくは SGML 規格または SGML 手引きをご覧頂きたく存じます。
> The most important consequence of this reference processing model is
that numeric character references are always resolved with respect to
the fixed document character set, and thus to the same characters,
whatever the external encoding actually used. For an example, see
Section 2.2.
この参照処理模型のもっとも重要な結果は、
数値文字参照が常に固定の文書文字集合に関して、
すなわち実際に使われている外部符号化に関わらず同じ文字に解決されることであります。
** 2.2. The document character set
> The document character set, in the SGML sense, is the Universal
Character Set (UCS) of ISO 10646:1993 [ISO-10646], as amended.
Currently, this is code-by-code identical with the Unicode standard,
version 1.1 [UNICODE].
SGML の意味での文書文字集合は、 ISO 10646:1993
および改正による国際符号化文字集合 ([[UCS]])
です。現在、 UCS は符号ごとに Unicode 規格 1.1 版と同一です。
> NOTE -- implementers should be aware that ISO 10646 is amended
from time to time; 4 amendments have been adopted since the
initial 1993 publication, none of which significantly affects this
specification. A fifth amendment, now under consideration, will
introduce incompatible changes to the standard: 6556 Korean Hangul
syllables allocated between code positions 3400 and 4DFF
(hexadecimal) will be moved to new positions (and 4516 new
syllables added), thus making references to the old positions
invalid. Since the Unicode consortium has already adopted a
corresponding amendment for inclusion in the forthcoming Unicode
2.0, adoption of DAM 5 is considered likely and implementers
should probably consider the old code positions as already
invalid. Despite this one-time change, the relevant standard
bodies have committed themselves not to change any allocated code
position in the future. To encode Korean Hangul irrespective of
these changes, the conjoining Hangul Jamo in the range 1110-11F9 can be used.
備考: 実装者は、 ISO 10646 が時々刻々と改正されていることに注意するべきです。
1993年の最初の出版から4つの追補が採用されましたが、
いずれもこの仕様書的には重大ではありません。現在検討中の5つ目の追補は、
規格に非互換な変更を行う予定です。6556個の韓国のハングル音節が符号位置
[CODE(char)[3400]]〜[CODE(char)[4DFF]] に割当てられていますが、
これが新しい位置に移動し、 (4516 個新しい音節が追加され、)
古い位置への参照が無効となります。 Unicode consortium
は既に相当する改正を近日発行の Unicode 2.0 に取込んでいますから、
[ABBR[DAM] [追補案]] 5 も同様に採用されるでしょうし、
実装者はおそらく既に古い符号位置は不当と考えるべきでしょう。
関係する標準化団体は、今回の一度だけの変更は別として、
将来は割当て済みの符号位置を変更しないことに合意しています。
韓国のハングルを変更に影響なく符号化するためには、
範囲 [CODE(char)[1110]]〜[CODE(char)[11F9]] の組合せハングル字母を使うことができます。
[INS[
訳注: 後日、元のハングル音節にはまったく別の漢字が割当てられ、
古い文書はひどく文字化けするようになりました。
また、今後割当てを変更しないという約束も反古にされました。
ちなみに、代わりに使えば良いと書いてある組合せ用ハングル字母は、
現在でも UCS での実装は数えるほどしかなく、
RFC 2070 の当時は誰が使うのかと思われていたような代物です。
]INS]
> The adoption of this document character set implies a change in the
SGML declaration specified in the HTML 2.0 specification (section 9.5
of [RFC1866]). The change amounts to removing the first BASESET
specification and its accompanying DESCSET declaration, replacing
them with the following declaration:
この文書文字集合の採用は、 HTML 2.0 仕様書で規定された
SGML 宣言を変更することを意味しています。
変更は最初の [CODE(SGML)[[[BASESET]]]] 指定と付随する
[CODE(SGML)[[[DESCSET]]]] 宣言を削除し、
次の宣言に置換えます。
[PRE(SGML)[
BASESET "ISO Registration Number 177//CHARSET
ISO/IEC 10646-1:1993 UCS-4 with implementation level 3
//ESC 2/5 2/15 4/6"
DESCSET 0 9 UNUSED
9 2 9
11 2 UNUSED
13 1 13
14 18 UNUSED
32 95 32
127 1 UNUSED
128 32 UNUSED
160 2147483486 160
]PRE]
[INS[
訳注: 実はこの改訂版 SGML 宣言は[[規格参照量集合]]の制限を超えていて
SGML 不適合であることが後に分かっています。 SGML
宣言で8桁を超える数を記述することはできません。
]INS]
> Making the UCS the document character set does not create non-conformance of any expression, construct or document that is
conforming to HTML 2.0. It does make conforming certain constructs
that are not admissible in HTML 2.0. One consequence is that data
characters outside the repertoire of ISO-8859-1, but within that of
UCS-4 become valid SGML characters. Another is that the upper limit
of the range of numeric character references is extended from 255 to
2147483645; thus, И is a valid reference to a "CYRILLIC CAPITAL
LETTER I". [ERCS] is a good source of information on Unicode and
SGML, although its scope and technical content differ greatly from
this specification.
UCS を文書文字集合としましても、 HTML 2.0 に適合する表現や構造や文書が不適合となることはありません。
HTML 2.0 で認められなかったある種の項像が適合するようにはなります。
一つの結果として、 [CODE(charset)[ISO-8859-1]] のレパートリ外であって
[[UCS-4]] のレパートリ内である文字が妥当な SGML 文字となります。
他に、数値文字参照の上限が [CODE(char)[255]] から
[CODE(char)[2147483645]] に引き上げられます。
従って、 [SAMP(HTML)[И]] は
[CODE(char)[CYRILLIC CAPITAL LETTER I]] への妥当な参照です。
[ABBR[ERCS]] はこの仕様書とは適用範囲と技術的内容が大きく異なりますが、
Unicode と SGML に関する良い情報源です。
> NOTE -- the above SGML declaration, like that of HTML 2.0,
specifies the character numbers 128 to 159 (80 to 9F hex) as
UNUSED. This means that numeric character references within that
range (e.g. ’) are illegal in HTML. Neither ISO 8859-1 nor
ISO 10646 contain characters in that range, which is reserved for
control characters.
備考: 前述の SGML 宣言は、 HTML 2.0 のものと同じく、
文字番号 [CODE(char)[128]]〜[CODE(char)[159]]
(16進数で [CODE(char)[80]]〜[CODE(char)[9F]])
を [CODE(SGML)[[[UNUSED]]]] としています。これは、
この範囲の数値文字参照 (例えば [SAMP(HTML)[’:]]) が HTML
では違法であることを意味します。 ISO 8859-1
も ISO 10646 もこの範囲には文字を含んでおらず、
[[制御文字]]に予約されています。
> Another change was made from the HTML 2.0 SGML declaration, in the
belief that the latter did not express its authors' true intent. The
syntax character set declaration was changed from ISO 646.IRV:1983 to
the newer ISO 646.IRV:1991, the latter, but not the former, being
identical with US-ASCII. In principle, this introduces an
incompatibility with HTML 2.0, but in practice it should increase
interoperability by i) having the SGML declaration say what everyone
thinks and ii) making the syntax character set a proper subset of the
document character set. The characters that differ between the two
versions of ISO 646.IRV are not actually used to express HTML syntax.
HTML 2.0 SGML 宣言に他にも変更が行われました。
これは著者の本来の意図を正しく表現していなかったことによるものです。
構文文字集合宣言は ISO 646.IRV:1983 から新しい ISO 646.IRV:1991
に変更しました。後者は US-ASCII と等しいですが、前者はそうではありません。
基本的にこれは HTML 2.0 と非互換になりますが、
実際上は i) SGML 宣言を誰もが考えていることを表すようにし、
ii) 構文文字集合を文書文字集合の適切な部分集合とすることから、
相互運用性を増すはずです。 ISO 646.IRV の2つの版の違う部分は実際には
HTML 構文を表現するために使っていません。
> ISO 10646-1:1993 is the most encompassing character set currently
existing, and there is no other character set that could take its
place as the document character set for HTML. If nevertheless for a
specific application there is a need to use characters outside this
standard, this should be done by avoiding any conflicts with present
or future versions of ISO 10646, i.e. by assigning these characters
to a private zone of the UCS-4 coding space [ISO-10646 section 11].
Also, it should be borne in mind that such a use will be highly
unportable; in many cases, it may be better to use inline bitmaps.
ISO 10646-1:1993 は現在存在するもっとも大きな文字集合で、
HTML の文書文字集合とすることのできる文字集合は他にありません。
それでもこの規格の外の文字を使う必要がある特定分野では、
現在と将来の版の ISO 10646 との衝突を避けることで、
つまり UCS-4 符号領域の私用域にその文字を割当てることで行うべきです。
また、そうして使用することは非常に非過般であることを念頭に置くようにするべきです。
多くの場合には、行内ビット写像を使用する方がましかもしれません。
[INS[
訳注: その UCS の私用面・私用群は数年後に削除されてしまいました。
使っていた人達には随分な仕打ちです。やはり行内画像の方がましでありました。
]INS]
** 2.3. Undisplayable characters
> With the document character set being the full ISO 10646, the
possibility that a character cannot be displayed due to lack of
appropriate resources (fonts) cannot be avoided. Because there are
many different things that can be done in such a case, this document
does not prescribe any specific behaviour. Depending on the
implementation, this may also be handled by the underlaying display
system and not the application itself. The following considerations,
however, may be of help:
完全な ISO 10646 が文書文字集合でありますから、
適当な資源 (フォント) が無いために文字を表示できない可能性というものは避けることができません。
そうした場合に行うことのできることは色々ありますから、
この文書は特定の振舞いを規定することはしません。
実装によって使用している表示システムも処理して鷹揚自体は処理しないかもしれません。
しかし、次の考慮が補助となるかもしれません。
>
- A clearly visible, but unobtrusive behaviour should be preferred.
Some documents may contain many characters that cannot be
rendered, and so showing an alert for each of them is not the
right thing to do.
- In case a numeric representation of the missing character is
given, its hexadecimal (not decimal) form is to be preferred,
because this form is used in character set standards [ERCS].
- 明らかに可視ながらもうざくない振舞いを優先するべきです。
文書によってはレンダリングできない文字を沢山含んでいるかもしれませんから、
そのそれぞれに警告を出すのはするべきこととはいえません。
- 欠けたる文字の数値表現を与える場合には、 (10進ではなく)
16進数を優先するべきです。16進数表現が文字集合規格では使われています。
* 3. The LANG attribute
> Language tags can be used to control rendering of a marked up
document in various ways: glyph disambiguation, in cases where the
character encoding is not sufficient to resolve to a specific glyph;
quotation marks; hyphenation; ligatures; spacing; voice synthesis;
etc. Independently of rendering issues, language markup is useful as
content markup for purposes such as classification and searching.
言語札は種々の方法でマーク付けされた文書のレンダリングを制御するために使うことができます。
グリフの決定を文字符号化が特定のグリフに解決するのに十分でない場合に行ったり、
引用符を決定したり、ハイフン付けを行ったり、
合字化したり、間隔付けしたり、音声合成に使ったり、その他色々な用途があります。
レンダリングの問題は別にしても、言語マークは分類や検索のような目的のための内容マークとしても有用です。
> Since any text can logically be assigned a language, almost all HTML
elements admit the LANG attribute. The DTD reflects this; the only
elements in this version of HTML without the LANG attribute are BR,
HR, BASE, NEXTID, and META. It is also intended that any new element
introduced in later versions of HTML will admit the LANG attribute,
unless there is a good reason not to do so.
論理的にはすべての文章に言語を割振ることができますから、
ほとんどすべての HTML 要素が [CODE(HTMLa)[lang]]
属性を使えます。 DTD はこれを反映しています。
この版の HTML で [CODE(HTMLa)[lang]] 属性がないのは、
[CODE(HTMLe)[[[br]]]], [CODE(HTMLe)[[[hr]]]], [CODE(HTMLe)[[[base]]]],
[CODE(HTMLe)[[[nextid]]]],
[CODE(HTMLe)[[[meta]]]] だけです。
今後の版の HTML で新たに導入する要素は、
[CODE(HTMLa)[lang]] 属性が要らないという理由が特になければ、
[CODE(HTMLa)[lang]] 属性を認めるつもりです。
> The language attribute, LANG, takes as its value a language tag that
identifies a natural language spoken, written, or otherwise conveyed
by human beings for communication of information to other human
beings. Computer languages are explicitly excluded.
言語属性 [CODE(HTMLa)[lang]] は、その値として人間が他の人間と意思疎通するために話したり書いたりその他伝達される自然言語を識別する言語札を値として取ります。
計算機言語は陽に除外します。
> The syntax and registry of HTML language tags is the same as that
defined by RFC 1766 [RFC1766]. In summary, a language tag is composed
of one or more parts: A primary language tag and a possibly empty
series of subtags:
HTML 言語札の構文と登録簿は [[RFC 1766]]
で定義されたものと同じとします。要約すると、言語札は一つ以上の部分
(第一言語札と零個以上の亜札の系列) から構成します。
>
- language-tag = primary-tag *( "-" subtag )
- primary-tag = 1*8ALPHA
- subtag = 1*8ALPHA
> Whitespace is not allowed within the tag and all tags are case-insensitive. The namespace of language tags is administered by the
IANA. Example tags include:
札の内側に空白は認めず、すべての札は大文字・小文字を区別しません。
言語札の名前空間は IANA が管理します。
例:
>
[PRE[
en, en-US, en-cockney, i-cherokee, x-pig-latin
]PRE]
> In the context of HTML, a language tag is not to be interpreted as a
single token, as per RFC 1766, but as a hierarchy. For example, a
user agent that adjusts rendering according to language should
consider that it has a match when a language tag in a style sheet
entry matches the initial portion of the language tag of an element.
An exact match should be preferred. This interpretation allows an
element marked up as, for instance, "en-US" to trigger styles
corresponding to, in order of preference, US-English ("en-US") or
'plain' or 'international' English ("en").
HTML の文脈では、言語札は RFC 1766 の通り1つの字句として解釈するのではなく、
階層的に解釈します。例えば、言語に従ってレンダリングする利用者エージェントは、
スタイル・シート中の言語札項目が要素の言語札の最初の部分に一致した時には言語札が一致したと考えるべきです。
全体の一致は優先するべきです。この解釈によって、
要素を例えば [SAMP(lang)[en-US]] とマーク付けして、
優先度によって米語 ([SAMP(lang)[en-US]]) と[Q[普通の]]あるいは
[SAMP[国際的な]]英語 ([SAMP(lang)[en]]) とスタイルを切替ることができ
ます。
> NOTE -- using the language tag as a hierarchy does not imply that
all languages with a common prefix will be understood by those
fluent in one or more of those languages; it simply allows the
user to request this commonality when it is true for that user.
備考: 言語札を階層的に使っても、
同じ接尾辞のすべての言語がそのうちの一つ以上に堪能な人が理解できるとは限りません。
そのような共通性がその利用者にとって真である時にこの共通性を利用者に要求することが認められるというただそれだけです。
> The rendering of elements may be affected by the LANG attribute. For
any element, the value of the LANG attribute overrides the value
specified by the LANG attribute of any enclosing element and the
value (if any) of the HTTP Content-Language header. If none of these
are set, a suitable default, perhaps controlled by user preferences,
by automatic context analysis or by the user's locale, should be used
to control rendering.
要素のレンダリングに [CODE(HTMLa)[lang]] 属性が影響しても構いません。
どの要素でも、 [CODE(HTMLa)[lang]] 属性の値はその要素を囲む要素の
[CODE(HTMLa)[lang]] 属性で指定された値と
(あれば) HTTP [CODE(HTTP)[[[Content-Language]]]] 頭で指定された値を上書きします。
いずれも設定されていなければ、適当な既定値、
おそらくは利用者が設定したものか自動文脈調査によるものか、
利用者のロケールによるものをレンダリングの制御に使うべきです。
* 4. Additional entities, attributes and elements
** 4.1. Full Latin-1 entity set
> According to the suggestion of section 14 of [RFC1866], the set of
Latin-1 entities is extended to cover the whole right part of
ISO-8859-1 (all code positions with the high-order bit set), including
the already commonly used , © and ®. The names of the
entities are taken from the appendices of SGML [ISO-8879]. A list is
provided in section 7.3 of this specification.
RFC 1866 の14章の提案の通り、 Latin-1 実体を拡張して、
既に広く用いられている [SAMP(HTML)[ ]], [SAMP(HTML)[©]],
[SAMP(HTML)[®]] を含めて ISO-8859-1 の右半分全体
(高次ビット集合のすべての符号位置) を覆うようにします。
実体の名前は SGML の附属書から取りました。
一覧はこの仕様書の7.3節にあります。
** 4.2. Markup for language-dependent presentation
*** 4.2.1. Overview
> For the correct presentation of text in certain languages
(irrespective of formatting issues), some support in the form of
additional entities and elements is needed.
ある言語の文章の正しい表示のため
(書式付けの問題とは関係なく)、追加の実体と要素の形で幾分の対応が必要です。
> In particular, the following features are dealt with:
特に、次の機能を処理します。
>
- Markup of bidirectional text, i.e. text where left-to-right and
right-to-left scripts are mixed.
- Control of cursive joining behaviour in contexts where the
default behaviour is not appropriate.
- Language-dependent rendering of short (in-line) quotations.
- Better justification control for languages where this is
important.
- Superscripts and subscripts for languages where they appear as
part of general text.
- 双方向文章 (左から右への用字と右から左への用字が混ざった文章) のマーク。
- 既定の振舞いが不適切な文脈での連綿連結の制御。
- 短い (行内) 引用の言語依存のレンダリング。
- 文字揃えが重要な言語でのより良い揃え制御。
- 普通の文章の一部として上付き・下付きが出現する言語のための上付き・下付き。
> Some of the above features need very little additional support;
others need more. The additional features are introduced below with
brief comments only. Explanations on cursive joining behaviour and
bidirectional text follow later. For cursive joining behaviour and
bidirectional text, this document follows [UNICODE] in that: i)
character semantics, where applicable, are identical to [UNICODE],
and ii) where functionality is moved to HTML as a higher level
protocol, this is done in a way that allows straightforward
conversion to the lower-level mechanisms defined in [UNICODE].
前記の機能の幾つかは非常にわずかな追加の支援だけが必要で、
他のものはもっと必要です。追加の機能は次に短い注釈と共に紹介します。
連綿連結動作と双方向文の説明は後に続けます。
連綿連結動作と双方向文については、この文書は Unicode
規格に従い、 i) 文字の意味は適用可能であれば Unicode
と同じであり、 ii) 機能が HTML に高水準プロトコルとして移動したところでは、
Unicode で定義された低水準機構に直接変換して行うことができます。
*** 4.2.2. List of entities, elements, and attributes
> First, a generic container is needed to carry the LANG and DIR (see
below) attributes in cases where no other element is appropriate; the
SPAN element is introduced for that purpose.
最初に、他の要素が適切でない場合に [CODE(HTMLa)[[[lang]]]]
属性と [CODE(HTMLa)[[[dir]]]] 属性を伝達する一般包含子が必要です。
[CODE(HTMLe)[[[span]]]] 要素をこの目的で導入します。
> A set of named character entities is added for use with bidirectional
rendering and cursive joining control:
双方向レンダリングと連綿連結制御に使用するために名前付き文字実体の集合を追加します。
[PRE(SGML)[
<!ENTITY zwnj CDATA "‌"--=zero width non-joiner-->
<!ENTITY zwj CDATA "‍"--=zero width joiner-->
<!ENTITY lrm CDATA "‎"--=left-to-right mark-->
<!ENTITY rlm CDATA "‏"--=right-to-left mark-->
]PRE]
> These entities can be used in place of the corresponding formatting
characters whenever convenient, for example to ease keyboard entry or
when a formatting character is not available in the character
encoding of the document.
これらの実体は対応する書式付け文字の場所で、
有用な時、例えば鍵盤の入力を簡単にするためや書式付け文字が文書の文字符号化で利用可能でない時にはいつでも使うことができます。
> Next, an attribute called DIR is introduced, restricted to the values
LTR (left-to-right) and RTL (right-to-left), for the indication of
directionality in the context of bidirectional text (see 4.2.4 below
for details). Since any text and many other elements (e.g. tables)
can logically be assigned a directionality, all elements except BR,
HR, BASE, NEXTID, and META admit this attribute. The DTD reflects
this. It is also intended that any new element introduced in later
versions of HTML will admit the DIR attribute, unless there is a good
reason not to do so.
次に、 [CODE(HTMLa)[dir]] という属性を導入します。
値は [CODE(HTML)[ltr]] (左から右) と
[CODE(HTML)[rtl]] (右から左) で、双方向文の文脈で方向を指示します。
論理的に任意の文章や多くの他の要素 (例えば表)
が方向性を割当てることができますから、
[CODE(HTMLe)[[[br]]]], [CODE(HTMLe)[[[hr]]]],
[CODE(HTMLe)[[[base]]]], [CODE(HTMLe)[[[nextid]]]], [CODE(HTMLe)[[[meta]]]]
を除くすべての要素がこの属性を認めます。 DTD
はこれを反映しています。今後の版の HTML で新しい要素が導入される時には
[CODE(HTMLa)[dir]] 属性を特にそうしない理由がない限り認めるつもりです。
> A new phrase-level element called BDO (BIDI Override) is introduced,
which requires the DIR attribute to specify whether the override is
left-to-right or right-to-left. This element is required for
bidirectional text control; for detailed explanations, see section
4.2.4.
新しい [CODE(HTMLe)[bdo]] (BIDI 上書き) という語句水準要素を導入します。
この要素は上書きが左から右か右から左かを指定する [CODE(HTMLa)[dir]]
属性を必須とします。この要素は双方向文制御のため必要です。
詳細な説明は4.2.4節を見て下さい。
> The phrase-level element Q is introduced to allow language-dependent
rendering of short quotations depending on language and platform
capability. As the following examples show (rather poorly, because of
the character set restriction of Internet specifications), the
quotation marks surrounding the quotation are particularly affected:
"a quotation in English", `another, slightly better one', ,,a
quotation in German”, << a quotation in French >>. The contents of
the Q element does not include quotation marks, which have to be
added by the rendering process.
語句水準要素 [CODE(HTMLe)[q]] を言語依存な短い引用を言語と環境の能力によってレンダリングできるように導入します。
次の例が示す (のはインターネット仕様書の文字集合の制限で貧しい表現ではありますが。)
ように、引用を囲む引用符は特に影響があります。例えば
"a quotation in English", `another, slightly better one', ,,a
quotation in German”, << フランス語の引用 >> のようにです。
[CODE(HTMLe)[q]] 要素の内容は引用符を含まず、
引用符はレンダリング処理で追加しなければなりません。
> NOTE -- Q elements can be nested. Many languages use different
quotation styles for outer and inner quotations, and this should
be respected by user-agents implementing this element.
備考: [CODE(HTMLe)[q]] 要素は入れ子にできます。
多くの言語は外側と内側の引用で異なる引用様式を用いますから、
この要素を実装する利用者エージェントもこれを尊重するべきです。
> NOTE -- minimal support for the Q element is to surround the
contents with some kind of quotes, like the plain ASCII double
quotes. As this is rather easy to implement, and as the lack of
any visible quotes may affect the perceived meaning of the text,
user-agent implementors are strongly requested to provide at least
this minimal level of support.
備考: [CODE(HTMLe)[q]] 要素の最低限の対応は内容を普通の ASCII
の二重引用符など何らかの引用符で囲むというものです。
これは簡単に実装できますし、可視引用符がないと文章の意味の理解に影響するかもしれませんから、
利用者エージェントの実装社には最低でもこの程度の対応を行うよう強く要求します。
> Many languages require superscript text for proper rendering: as an
example, the French "Mlle Dupont" should have "lle" in superscript.
The SUP element, and its sibling SUB for subscript text, are
introduced to allow proper markup of such text. SUP and SUB contents
are restricted to PCDATA to avoid nesting problems.
多くの言語は適切なレンダリングのために上付き文を必要としています。
例えば、フランス語の [Q[M[SUP[lle]] Dupont]] は [Q[lle]]
が上付きになっているべきです。 [CODE(HTMLe)[sup]] 要素と兄弟で下付きの
[CODE(HTMLe)[sub]] 要素は、このような文章を適切にマークすることができるように導入します。
[CODE(HTMLe)[sup]] と [CODE(HTMLe)[sub]] の内容は入れ子の問題を避けるために
[CODE(SGML)[[[PCDATA]]]] に制限します。
> Finally, in many languages text justification is much more important
than it is in Western languages, and justifies markup. The ALIGN
attribute, admitting values of LEFT, RIGHT, CENTER and JUSTIFY, is
added to a selection of elements where it makes sense (the block-like
P, HR, H1 to H6, OL, UL, DIR, MENU, LI, BLOCKQUOTE and ADDRESS). If
a user-agent chooses to have LEFT as a default for blocks of left-to-right directionality, it should use RIGHT for blocks of right-to-left directionality.
最後に、多くの言語では西洋言語より文字揃えがずっと重要であり、
マークを揃えます。 [CODE(HTMLa)[align]] 属性を、
値として [CODE(HTML)[left]], [CODE(HTML)[right]], [CODE(HTML)[center]],
[CODE(HTML)[justify]] を認めて、これが意味を持つ要素
(ブロック状の [CODE(HTMLe)[[[p]]]], [CODE(HTMLe)[[[hr]]]],
[CODE(HTMLe)[[[h1]]]]〜[CODE(HTMLe)[[[h6]]]], [CODE(HTMLe)[[[ol]]]],
[CODE(HTMLe)[[[ul]]]], [CODE(HTMLe)[[[dir]]]], [CODE(HTMLe)[[[menu]]]],
[CODE(HTMLe)[[[li]]]], [CODE(HTMLe)[[[blockquote]]]],
[CODE(HTMLe)[[[address]]]]) を選んで追加します。
利用者エージェントが左から右の方向のブロックに [CODE(HTML)[left]]
を既定値として選ぶなら、右から左の方向のブロックには [CODE(HTML)[right]]
を既定値として使うべきです。
> NOTE -- RFC 1866 section 4.2.2 specifies that an HTML user agent
should treat an end of line as a word space, except in
preformatted text. This should be interpreted in the context of
the script being processed, as the way words are separated in
writing is script-dependent. For some scripts (e.g. Latin), a
word space is just a space, but in other scripts (e.g. Thai) it is
a zero-width word separator, whereas in yet other scripts (e.g.
Japanese) it is nothing at all, i.e. totally ignored.
備考: RFC 1866 4.2.2 節は HTML 利用者エージェントが行末を整形済み文以外では語間隔として扱うように既定しています。
これは、筆記時に語を分離する方法は用字系依存ですから、
処理している用字系の文脈で解釈するべきです。幾つかの用字系 (例えば Latin)
では語間隔は単なる間隔ですが、他の用字系 (例えばタイ文字)
では零幅語分離子ですし、また他の用字系 (例えば日本語文字)
では何もなし、つまり完全に無視です。
> NOTE -- the SOFT HYPHEN character (U+00AD) needs special attention
from user-agent implementers. It is present in many character
sets (including the whole ISO 8859 series and, of course, ISO
10646), and can always be included by means of the reference
­. Its semantics are different from the plain HYPHEN: it
indicates a point in a word where a line break is allowed. If the
line is indeed broken there, a hyphen must be displayed at the end
of the first line. If not, the character is not dispalyed at all.
In operations like searching and sorting, it must always be
ignored.
備考: [CODE(char)[SOFT HYPHEN]] 文字 ([CODE(char)[U+00AD]])
はり容赦エージェント実装者の特別な注意を必要とします。
この文字は多くの文字集合 (すべての ISO 8859 系列と、もちろん
ISO 10646 を含みます。) に存在しますし、常に参照 [CODE(HTML)[­]]
として含めることができます。この意味は単なる [CODE(char)[HYPHEN]]
とは異なります。 [CODE(char)[SOFT HYPHEN]] は語の中で改行が認められる位置を示します。
行がそこで割られる時には、最初の行の終わりにハイフンを表示しなければなりません。
そうでない時には、この文字はまったく表示されません。
検索や並替えのような処理では、常に無視しなければなりません。
> In the DTD, the LANG and DIR attributes are grouped together in a
parameter entity called attrs. To parallel RFC 1942 [RFC1942], the
ID and CLASS attributes are also included in attrs. The ID and CLASS
attributes are required for use with style sheets, and RFC 1942
defines them as follows: