-
Notifications
You must be signed in to change notification settings - Fork 4
/
567.txt
4762 lines (4436 loc) · 158 KB
/
567.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
;; [1] [[Stringprep]] も参照。
'''Preparation of Internationalized Strings ("stringprep")'''
-Network Working Group
-Request for Comments: 3454
-Category: Standards Track
- P. Hoffman
- IMC & VPNC
- M. Blanchet
- Viagenie
- December 2002
*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.
*Copyright Notice
> Copyright (C) The Internet Society (2002). All Rights Reserved.
*Abstract
< This document describes a framework for preparing Unicode text
strings in order to increase the likelihood that string input and
string comparison work in ways that make sense for typical users
throughout the world. The stringprep protocol is useful for protocol
identifier values, company and personal names, internationalized
domain names, and other text strings.
> This document does not specify how protocols should prepare text
strings. Protocols must create profiles of stringprep in order to
fully specify the processing options.
*Table of Contents
1. Introduction....................................................3
1.1 Terminology..................................................4
1.2 Using stringprep in protocols................................4
2. Preparation Overview............................................6
3. Mapping.........................................................7
3.1 Commonly mapped to nothing...................................7
3.2 Case folding.................................................8
4. Normalization...................................................9
5. Prohibited Output..............................................10
5.1 Space characters............................................11
5.2 Control characters..........................................11
5.3 Private use.................................................12
5.4 Non-character code points...................................12
5.5 Surrogate codes.............................................13
5.6 Inappropriate for plain text................................13
5.7 Inappropriate for canonical representation..................13
5.8 Change display properties or deprecated.....................13
5.9 Tagging characters..........................................14
6. Bidirectional Characters.......................................14
7. Unassigned Code Points in Stringprep Profiles..................15
7.1 Categories of code points...................................16
7.2 Reasons for difference between stored strings and queries...17
7.3 Versions of applications and stored strings.................18
8. References.....................................................19
8.1 Normative references........................................19
8.2 Informative references......................................19
9. Security Considerations........................................19
9.1 Stringprep-specific security considerations.................19
9.2 Generic Unicode security considerations.....................20
10. IANA Considerations...........................................21
11. Acknowledgements..............................................22
A. Unicode repertoires............................................23
A.1 Unassigned code points in Unicode 3.2.......................23
B. Mapping Tables.................................................31
B.1 Commonly mapped to nothing..................................31
B.2 Mapping for case-folding used with NFKC.....................32
B.3 Mapping for case-folding used with no normalization.........61
C. Prohibition tables.............................................78
C.1 Space characters............................................78
C.1.1 ASCII space characters..................................78
C.1.2 Non-ASCII space characters..............................79
C.2 Control characters..........................................79
C.2.1 ASCII control characters................................79
C.2.2 Non-ASCII control characters............................79
C.3 Private use.................................................80
C.4 Non-character code points...................................80
C.5 Surrogate codes.............................................80
C.6 Inappropriate for plain text................................80
C.7 Inappropriate for canonical representation..................81
C.8 Change display properties or are deprecated.................81
C.9 Tagging characters..........................................81
D. Bidirectional tables...........................................81
D.1 Characters with bidirectional property "R" or "AL"..........81
D.2 Characters with bidirectional property "L"..................82
Authors' Addresses................................................90
Full Copyright Statement..........................................91
*1. Introduction
Application programs can display text in many different ways.
Similarly, a user can enter text into an application program in a
myriad of fashions. Internationalized text (that is, text that is
not restricted to the narrow set of US-ASCII characters) has many
input and display behaviors that make it difficult to compare text in
a consistent fashion.
This document specifies a framework of processing rules for Unicode
text. Other protocols can create profiles of these rules; these
profiles will allow users to enter internationalized text strings in
applications and have the highest chance of getting the content of
the strings correct. In this case, "correct" means that if two
different people enter what they think is the same string into two
different input mechanisms, the strings should match on a character-
by-character basis.
This framework does not describe how data is transcoded from other
character sets into Unicode. In systems that uses non-Unicode
character sets, the transcoding algorithm is a critical part of
enabling secure and "correct" operation of internationalized text
strings.
In addition to helping string matching, profiles of stringprep can
also exclude characters that should not normally appear in text that
is used in the protocol. The profile can prevent such characters by
changing the characters to be excluded to other characters, by
removing those characters, or by causing an error if the characters
would appear in the output. For example, because the backspace
character can cause unpredictable display results, a profile can
specify that a string containing a backspace character would cause an
error.
A profile of stringprep converts a single string of input characters
to a string of output characters, or returns an error if the output
string would contain a prohibited character. Stringprep profiles
cannot both emit a string and return an error.
Stringprep profiles cannot account for all of the variations that
might occur or that a user might expect. In particular, a profile
will not be able to account for choice of spellings in all languages
for all scripts because the number of alternative spellings of words
and phrases is immense. Users would probably expect all spelling
equivalents to be made equivalent, or none of them to be. Examples
of spelling equivalents include "theater" vs. "theatre", and
"hemoglobin" vs. "h<U+00E6>moglobin" in American vs. British English.
Other examples are simplified Chinese spellings of names (for
example,"<U+7EDF><U+4E00><U+7801>") vs. the equivalent traditional
Chinese spelling (for example, "<U+7D71><U+4E00><U+78BC>").
Language-specific equivalences such as "Aepfel" vs. "<U+00C4>pfel",
which are sometimes considered equivalent in German, may not be
considered equivalent in other languages.
**1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
Note: A glossary of terms used in Unicode and ISO/IEC 10646 can be
found in [Glossary]. Information on the 10646/Unicode character
encoding model can be found in [CharModel].
Character names in this document use the notation for code points and
names from the Unicode Standard [Unicode3.2] and ISO/IEC 10646
[ISO10646]. For example, the letter "a" may be represented as either
"U+0061" or "LATIN SMALL LETTER A". In the lists of mappings and the
prohibited characters, the "U+" is left off to make the lists easier
to read. The comments for character ranges are shown in square
brackets (such as "[CONTROL CHARACTERS]") and do not come from the
standards.
**1.2 Using stringprep in protocols
> The stringprep protocol does not stand on its own; it has to be used
by other protocols at precisely-defined places in those other
protocols. For example, a protocol that has strings that come from
the entire ISO/IEC 10646 [ISO10646] character repertoire might
specify that only strings that have been processed with a particular
profile of stringprep are legal. Another example would be a protocol
that does string comparison as a step in the protocol; that protocol
might specify that such comparison is done only after processing the
strings with a specific profile of stringprep.
Stringprep プロトコルは単独で使うことはできません。
別のプロトコルで使うと定義された場所で使います。例えば、
[[ISO/IEC 10646]] の文字レパートリ全体による文字列を扱うプロトコルでは、
特定の stringprep プロファイルで処理した文字列だけが合法と規定するかもしれません。
あるいは、手順の一つとして文字列比較を行うプロトコルでは、
文字列を特定の stringprep プロファイルで処理した後に比較を行うと規定するかもしれません。
> When two protocols that use different profiles of stringprep
interoperate, there may be conflict about what characters are and are
not allowed in the final string. Thus, protocol developers should
strongly consider re-using existing profiles of stringprep.
2つのプロトコルが違った stringprep プロファイルを使ってやり取りすると、
最終的な文字列でどの文字が認められ、どの文字が認められないかの衝突があるかもしれません。
ですから、プロトコル開発者は既存の stringprep
プロファイルを再利用することをよくよく考えるべきです。
>When developers wish to allow users as wide of a range of characters
as possible in input text strings, they should, where possible, cause
stringprep to convert characters from the input string to a canonical
form instead of prohibiting them.
開発者ができるだけ広範囲の文字を利用者が入力文字列に含められるようにしたいと考える時には、
可能であれば、入力文字列で文字を禁止するのではなく、
変換するようにするべきです。
> Although it would be easy to use the stringprep process to "correct"
perceived mis-features or bugs in the current character standards,
stringprep profiles SHOULD NOT do so.
Stringprep 処理を現行の文字規格の既知の誤った機能や不具合を[Q[正す]]ために使うことも容易ではありますが、
stringprep プロファイルはそういうことを'''するべきではありません'''。
> A profile of stringprep can create tables different from those in the
appendixes of this document, but it will be an exception when they
do. The intention of stringprep is to define the tables and have the
profiles of stringprep select among those defined tables.
Stringprep プロファイルはこの文書の附属書にあるものとは違う表を作ることができますが、
そうするとこれが例外となります。 表を定義し、
stringprep プロファイルに定義された表から選択させることが stringprep
の意図です。
> A profile of stringprep MUST include all of the following:
Stringprep プロファイルは次のすべてを含まなければ'''なりません'''。
>
- The intended applicability of the profile
- The character repertoire that is the input and output to stringprep
(which is Unicode 3.2 for this version of stringprep)
- The mapping tables from this document used (as described in section 3)
- Any additional mapping tables specific to the profile
- The Unicode normalization used, if any (as described in section 4)
- The tables from this document of characters that are prohibited as
output (as described in section 5)
- The bidirectional string testing used, if any (as described in section 6)
- Any additional characters that are prohibited as output specific to the profile
- プロファイルの想定応用可能性
- Stringprep への入出力の文字レパートリ
(この版の stringprep では [[Unicode 3.2]])
- 使用するこの文書の写像表
- 必要なら追加のプロファイル規定の写像表
- 必要なら使用する Unicode 正規化法
- この文書の出力として禁止されている文字の表
- 必要なら使用する双方向的文字列試験
- 必要なら追加のプロファイル規定の禁止文字
> Each profile MUST state the character repertoire on which the profile
will operate. Appendix A lists the Unicode repertoires that can be
selected. No repertoire is ever complete, and it is expected that
characters will be added to the Unicode repertoire for the
foreseeable future. Section 7 of this document describes how to
handle characters that are assigned in later versions of the Unicode
repertories. Subsections of appendix A also list unassigned code
points for each repertoire.
各プロファイルは、プロファイルが対象とする文字レパートリを述べなければ'''なりません'''。
附属書 A は選択できる Unicode レパートリを挙げています。
どのレパートリも完全ではなく、近未来に Unicode
レパートリに文字が追加されると思われます。この文書の7章は後の版の
Unicode レパートリで割当てられる文字をどう扱うかを説明しています。
附属書 A の各節では各レパートリの未割当[[符号位置]]も表にしています。
> This document is for Unicode version 3.2, and should not be
considered to automatically apply to later Unicode versions. The
IETF, through an explicit standards action, may update this document
as appropriate to handle later Unicode versions.
この文書は Unicode 3.2 に対応しており、
自動的に新しい版の Unicode が適用されると考えるべきではありません。
IETF は明示的な[[標準行動]]により、
新しい版の Unicode が扱えるようにこの文書を更新するかもしれません。
> This document lists the unassigned code points in the range 0 to
10FFFF for Unicode 3.2 in appendix A. The list in appendix A MUST be
used by implementations of this specification. If there are any
discrepancies between the list in appendix A and the Unicode 3.2
specification, the list in appendix A always takes precedence.
この文書は附属書 A に Unicode 3.2 で範囲 [CODE(char)[0]]〜[CODE(char)[10FFFF]]
の未割当符号位置の表を掲載しています。この仕様の実装は附属書 A
のこの表を使わなければ'''なりません'''。附属書 A
と Unicode 3.2 仕様書で齟齬があったとしても、附属書 A
の表が常に優先します。
> Each profile of stringprep MUST be registered with IANA. The
registration procedure is described in the IANA Considerations
appendix; basically, the IESG must review each profile of stringprep.
Protocol developers are strongly encouraged to look through the IANA
profile registry when creating new profiles for stringprep, and to
re-use logic from earlier profiles where possible in new profiles.
In some cases, an existing profile can be reused by a different protocol.
Stringprep の各プロファイルは [[IANA]] に登録しなければ'''なりません'''。
登録手続きは IANA に関しての章で説明します。基本的には [[IESG]]
が stringprep の各プロファイルを評論します。
プロトコル開発者は新しい stringprep プロファイルを作る際に [[IANA]]
のプロファイル登録簿を見て、できる限り既存のプロファイルの論理を新しいプロファイルでも再利用することを強く推奨します。
場合によっては既存のプロファイルを別のプロトコルでも再利用できるかもしれません。
*2. Preparation Overview
> The steps for preparing strings are:
文字列を準備する手順は次の通りです。
>
= 1) Map -- For each character in the input, check if it has a mapping
and, if so, replace it with its mapping. This is described in section 3.
= 2) Normalize -- Possibly normalize the result of step 1 using Unicode
normalization. This is described in section 4.
= 3) Prohibit -- Check for any characters that are not allowed in the
output. If any are found, return an error. This is described in section 5.
= 4) Check bidi -- Possibly check for right-to-left characters, and if
any are found, make sure that the whole string satisfies the
requirements for bidirectional strings. If the string does not
satisfy the requirements for bidirectional strings, return an
error. This is described in section 6.
= '''写像''': 入力の文字それぞれについて写像があるか調べ、
あればその写像に基づき置換します。これは3章で説明します。
= '''正規化''': 手順1の結果を Unicode 正規化法を使って正規化しても構いません。
これは4章で説明します。
= '''禁止''': 出力に認められない文字を調べます。
見つかれば[[誤り]]を返します。これは5章で説明します。
='''Bidi 検査''': 右から左の文字を調べ、
見つかれば文字列全体が双方向的文字列の要件を満足するように確認しても構いません。
文字列が双方向的文字列の要件を満たさなければ、
誤りを返します。これは6章で説明します。
> The above steps MUST be performed in the order given to comply with
this specification.
この手順はこの仕様に適合するためにはこの順序で実行しなければ'''なりません'''。
> The mappings described in section 3, and the optional Unicode
normalization described in section 4, can be one-to-none, one-to-one,
one-to-many, many-to-one, or many-to-many. That is, some characters
might be eliminated or replaced by more than one character, and the
output of this step might be shorter or longer than the input.
Because of this, the system using stringprep MUST be prepared to
receive a longer or shorter string than the one input in the
stringprep algorithm.
3章で説明する写像と4章で説明する省略可能な Unicode
正規化は一対零、一対一、一対多、多対一、多対多のどれにもなり得ます。
つまり、文字が削除されたり複数の文字で置換されたり、
出力される文字列が入力よりも短くなったり長くなったりします。
このため、 stringprep を使う文字列は stringprep
法の入力より長さが前後する文字列を受取る準備をしなければ'''なりません'''。
*3. Mapping
> Each character in the input stream MUST be checked against a mapping
table. The mapping table SHOULD come from this document, although
the mapping table MAY be added to or altered by the profile. The
mapping tables are subsections of appendix B.
入力流の各文字は写像表に照らして検査しなければ'''なりません'''。
写像表はこの文書から選ぶ'''べきです'''が、
プロファイルで追加したり変更したりしても'''構いません'''。
写像表は附属書 B の各節にあります。
> The lists in appendix B MUST be used by implementations of this
specification. If there are any discrepancies between the lists in
appendix B and subsections below, the lists in appendix B always
takes precedence.
この仕様の実装は附属書 B の表を使わなければ'''なりません'''。
附属書 B の表と以後の各節で齟齬があれば、附属書 B
の表が常に優先します。
> For any individual character, the mapping table MAY specify that a
character be mapped to nothing, or mapped to one other character, or
mapped to a string of other characters.
文字それぞれについて写像表は何にも写像しないか、
他のある文字に写像するか、他の文字列に写像するかを規定して'''構いません'''。
> Mapped characters are not re-scanned during the mapping step. That
is, if character A at position X is mapped to character B, character
B which is now at position X is not checked against the mapping table.
写像した文字は写像の手順の中で再走査されることはありません。
つまり、位置 [VAR[X]] の文字 [VAR[A]] が文字 [VAR[B]]
に写像されたなら、位置 [VAR[X]] に置かれた文字 [VAR[B]]
を再度写像表で検査することはありません。
**3.1 Commonly mapped to nothing
> The following characters are simply deleted from the input (that is,
they are mapped to nothing) because their presence or absence in
protocol identifiers should not make two strings different. They are
listed in Table B.1.
次の文字は、プロトコル識別子としてはその有無によって文字列が変わってしまうべきではないので、
ただ入力から削除します (何にも写像しません)。これは表 B.1 に載せます。
> Some characters are only useful in line-based text, and are otherwise
invisible and ignored.
幾つかの文字は行指向の文章でのみ有用で、他では不可視で無視されます。
>
00AD; SOFT HYPHEN
1806; MONGOLIAN TODO SOFT HYPHEN
200B; ZERO WIDTH SPACE
2060; WORD JOINER
FEFF; ZERO WIDTH NO-BREAK SPACE
> Some characters affect glyph choice and glyph placement, but do not
bear semantics.
幾つかの文字は[[グリフ]]の選択や位置に影響しますが、
意味は変えません。
>
034F; COMBINING GRAPHEME JOINER
180B; MONGOLIAN FREE VARIATION SELECTOR ONE
180C; MONGOLIAN FREE VARIATION SELECTOR TWO
180D; MONGOLIAN FREE VARIATION SELECTOR THREE
200C; ZERO WIDTH NON-JOINER
200D; ZERO WIDTH JOINER
FE00; VARIATION SELECTOR-1
FE01; VARIATION SELECTOR-2
FE02; VARIATION SELECTOR-3
FE03; VARIATION SELECTOR-4
FE04; VARIATION SELECTOR-5
FE05; VARIATION SELECTOR-6
FE06; VARIATION SELECTOR-7
FE07; VARIATION SELECTOR-8
FE08; VARIATION SELECTOR-9
FE09; VARIATION SELECTOR-10
FE0A; VARIATION SELECTOR-11
FE0B; VARIATION SELECTOR-12
FE0C; VARIATION SELECTOR-13
FE0D; VARIATION SELECTOR-14
FE0E; VARIATION SELECTOR-15
FE0F; VARIATION SELECTOR-16
**3.2 Case folding
> If a profile is going to map characters for case-insensitive
comparison, that profile SHOULD map using either appendix B.2 or
appendix B.3. appendix B.2 is for profiles that also use Unicode
normalization form KC, while appendix B.3 is for profiles that do
not use Unicode normalization. These tables map from uppercase to
lowercase characters. Note that this could have been "change all
lowercase characters into uppercase characters". However, the
upper-to-lower folding was chosen because there is a tradition of
using lowercase in current Internet applications and protocols.
プロファイルが大文字・小文字を区別しない比較のために文字を写像するのであれば、
附属書 B.2 または附属書 B.3 のいずれかを使って写像する'''べきです'''。
附属書 B.2 は Unicode 正規化形 KC をも使うプロファイルのためのもので、
附属書 B.3 は Unicode 正規化を使わないプロファイルのためのものです。
これらの表は大文字から小文字に写像します。
[Q[すべて小文字の文字列を大文字に変更]]することもできたでしょうが、
現在のインターネットの応用とプロトコルでは小文字を使う伝統があるので、
大文字から小文字への統一を選びました。
> If a profile creates its own mapping tables for case folding, they
SHOULD be based on [UTR21], and SHOULD map from uppercase characters
to lowercase. The "CaseFolding.txt" file from the Unicode database
SHOULD be used to prepare the mapping table. The profile SHOULD do
full case mapping (that is, using statuses C, F, and I).
プロファイルが大文字・小文字の変換に関する独自の写像を作る場合は、
UTR #21 に基づく'''べきです'''し、大文字から小文字に写像する'''べきです'''。
Unicode データベースの [CODE(file)[[[CaseFolding.txt]]]]
ファイルを写像表の準備に使う'''べきです'''。
プロファイルは完全な大文字・小文字の写像を行う
(状態 C, F, I を使う) '''べきです'''。
> If the profile is using Unicode normalization form KC (as described
in section 4 of this document), it is important to note that there
are some characters that do not have mappings in [UTR21] but still
need processing. These characters include a few Greek characters and
many symbols that contain Latin characters. The list of characters
to add to the mapping table can determined by the following algorithm:
プロファイルが Unicode 正規化形 KC を使う場合、
UTR #21 では写像を持たないものの処理が必要な文字が存在することに注意するのが重要です。
それには幾つかの[[ギリシャ文字]]と[[ラテン文字]]が含まれる多くの[[記号]]が含まれます。
写像表に追加する文字の表は次の算法により決定できます。
>
b = NormalizeWithKC(Fold(a));
c = NormalizeWithKC(Fold(b));
if c is not the same as b, add a mapping for "a to c".
[VAR[c]] が [VAR[b]] と同じでなければ、
[Q[[VAR[a]] から [VAR[c]]]] の写像を追加
> Because NormalizeWithKC(Fold(c)) always equals c, the table is stable
from that point on.
[CODE[NormalizeWithKC(Fold([VAR[c]]))]] は常に [VAR[c]]
と等しいので、表はその点で安定です。
> Appendix B.3 is derived from the CaseFolding-3.txt file associated
with Unicode 3.2; appendix B.2 is based on appendix B.3 with the
additional characters added from the algorithm above.
附属書 B.3 は Unicode 3.2 附属の [CODE(file)[CaseFolding-3.txt]]
ファイルから作りました。附属書 B.2 は前述の算法によって附属書 B.3
に文字を追加しています。
> Authors of profiles of this document need to consider the effects of
changing the mapping of any currently-assigned character when
updating their profiles. Adding a new mapping for a
currently-assigned character, or changing an existing mapping, could cause a
variance between the behavior of systems that have been updated and
systems that have not been updated.
この文書のプロファイルの著者はプロファイルを更新する時に現在割当てられている文字の写像の変更の影響を考慮する必要があります。
新しい写像を現在割当てられている文字に追加したり、
既存の写像を変更したりすると、
更新したシステムと更新していないシステムの間で差異が生じることになります。
*4. Normalization
> The output of the mapping step is optionally normalized using one of
the Unicode normalization forms, as described in [UAX15]. A profile
can specify one of two options for Unicode normalization:
写像手順の出力は通常 UAX #15 で説明されている Unicode
正規化法のいずれかを使って正規化します。
プロファイルは Unicode 正規化について次の2つの選択肢から
1つ規定できます。
>
- no normalization
- Unicode normalization with form KC
- 正規化なし
- Unicode 正規化形 KC による正規化
> A profile MAY choose to do no normalization. However, such a profile
can easily yield results that will be surprising to typical users,
depending on the input mechanism they use. For example, some input
mechanisms enter compatibility characters that look exactly like the
underlying characters, but have different code points. Another
example of where Unicode normalization helps create predictable
results is with characters that have multiple combining diacritics:
normalization orders those diacritics in a predictable fashion.
プロファイルは正規化しないことにしても'''構いません'''。
しかし、正規化しないプロファイルを使うと入力方法によっては普通の利用者を驚かせる結果になりがちです。
例えば、入力方法によっては同じように見えて違う[[符号位置]]を持つ[[互換性文字]]を入力します。
あるいは、 Unicode 正規化で複数の[[結合]]用[[発音区別符]]を持つ文字の発音区別符が決った順序になるので、
決まった結果を得る助けとなります。
> On the other hand, Unicode normalization requires fairly large tables
and somewhat complicated character reordering logic. The size and
complexity should not be considered daunting except in the most
restricted of environments, and needs to be weighed against the
problems of user surprise from comparing unnormalized strings. Note
that the tables used for normalization are not given in this
document, but instead must be derived from the Unicode database, as
described in [UAX15].
一方で、 Unicode 正規化は非常に大きな表と複雑な文字再順序付け論理が必要です。
しかし大きさと複雑さは本当に制限された環境以外では大きな問題とはいえませんし、
正規化しない文字列の比較で利用者を驚かす問題に比べれば重要でもありません。
なお、正規化に使用する表はこの文書には載せていないので、
Unicode データベースから UAX #15 で説明されている方法で得る必要があります。
> There is a third form of normalization, Unicode normalization with
form C. If a profile is going to use a Unicode normalization, it
MUST use Unicode normalization form KC. Form KC maps many
"compatibility characters" to their equivalents. Some user interface
systems make it possible to enter compatibility characters instead of
the base equivalents. Thus, using form KC instead of form C will
cause more strings that users would expect to match to actually match.
Unicode 正規化形 C という第3の正規化の方法もあります。
プロファイルが Unicode 正規化を使うのであれば、 Unicode
正規化形 KC を使わなければなりません。正規化形 KC は多くの[Q[互換性文字]]
を等価なものに写像します。利用者界面システムによっては基本となる等価な文字ではなく互換性文字を入力することができるかもしれません。
ですから、正規化形 C ではなく正規化形 KC を使い、
利用者が一致すると期待するものにできるだけ一致するようにします。
> A profile that specifies Unicode normalization MUST use the
normalization in [UAX15] that is associated with the version of the
Unicode character set specified for the profile.
Unicode 正規化を規定するプロファイルはプロファイルで規定した版の
Unicode 文字集合の版に対応する UAX #15 の正規化を使わなければ'''なりません'''。
> The composition process described in [UAX15] requires a fixed
composition version of Unicode to ensure that strings normalized
under one version of Unicode remain normalized under all future
versions of Unicode.
UAX #15 で説明されている合成処理は、ある版の Unicode
で正規化された文字列が他のすべての将来の版の Unicode
でも正規化されたものであるために固定の合成の版の Unicode
を要求しています。
> The IETF is relying on Unicode not to change the normalization of
currently-assigned characters in future versions of normalization.
If a future version of the normalization tables changes the
normalized value of an existing character, authors of profiles of
this document have to look at the changes very carefully before they
update their normalization tables. Such a change could cause a
variance between the behavior of systems that have been updated and
systems that have not been updated.
IETF は Unicode が将来の版の正規化で既に割当てられている文字の正規化が変更されないことに依存しています。
将来の版の正規化表が既存の文字の正規化値を変えたなら、
この文書のプロファイルの著者は正規化表を更新する前によくよく十分注意して変更を調べなければなりません。
変更があると更新したシステムと更新していないシステムの動作に違いが出るかもしれません。
*5. Prohibited Output
> Before the text can be emitted, it MUST be checked for prohibited
code points. There are a variety of prohibited code points, as
described in this section. A profile of this document MAY use all or
some of the tables in appendix C.
文字列を出力する前に禁止[[符号位置]]について検査しなければ'''なりません'''。
禁止符号位置にはこの章で説明する通り色々あります。
この文書のプロファイルは附属書 C の表の全部または一部を使用して'''構いません'''。
> The stringprep process never emits both an error and a string. If an
error is detected during the checking for prohibited code points,
only an error is returned.
Stringprep 処理が[[誤り]]と文字列の両方を出すことは決してありません。
禁止符号位置の検査で誤りを検出したら、誤りだけを返します。
> Note that the subsections below describe how the tables in appendix C
were formed. They are here for people who want to understand more,
but they should be ignored by implementors. Implementations that use
tables MUST map based on the tables themselves, not based on the
descriptions in this section of how the tables were created.
以降の節では附属書 C の表をどう作ったかを説明します。
これはより理解したい人のために収録するのであり、
実装者は読み飛ばして構いません。表を使う実装はこの章の表をどう作ったかの説明ではなく、
表自体に基づいて写像する'''べきです'''。
> The lists in appendix C MUST be used by implementations of this
specification. If there are any discrepancies between the lists in
appendix C and subsections below, the lists in appendix C always take
precedence.
この仕様の実装は附属書 C の票を使わなければ'''なりません'''。
附属書 C の表と以後の節で齟齬があれば、附属書 C
の表が常に優先します。
> Some code points listed in one section may also appear in other sections.
1つの節に登場する[[符号位置]]が他の節にも登場することがあります。
> It is important to note that a profile of this document MAY prohibit
additional characters.
なお、重要なことですがこの文書のプロファイルは別の文字を禁止しても'''構いません'''。
> Each subsection of this section has a matching subsection in appendix
C. For example, the characters listed in section 5.1 are listed in
appendix C.1.
この章の各節は附属書 C の節に対応します。例えば、5.1節に挙げた文字は附属書
C.1 に表があります。
**5.1 Space characters
> Space characters can make accurate visual transcription of strings
nearly impossible and could lead to user entry errors in many ways.
Note that the list below is split into two tables in appendix C:
Table C.1.1 contains the ASCII code points, while Table C.1.2
contains the non-ASCII code points. Most profiles of this document
that want to prohibit space characters will want to include both tables.
[[間隔]]文字は見た目から正確に文字列を書き写すのがほとんど不可能になり得、
色々な利用者入力誤りになり兼ねません。次の表は附属書 C
で2つの表に分かれています。表 C.1.1 は [[ASCII]]
の符号位置を含み、表 C.1.2 は非 ASCII の符号位置を含みます。
間隔文字を禁止したいこの文書のプロファイルのほとんどはどちらの表も含めるのがよいでしょう。
>
0020; SPACE
00A0; NO-BREAK SPACE
1680; OGHAM SPACE MARK
2000; EN QUAD
2001; EM QUAD
2002; EN SPACE
2003; EM SPACE
2004; THREE-PER-EM SPACE
2005; FOUR-PER-EM SPACE
2006; SIX-PER-EM SPACE
2007; FIGURE SPACE
2008; PUNCTUATION SPACE
2009; THIN SPACE
200A; HAIR SPACE
200B; ZERO WIDTH SPACE
202F; NARROW NO-BREAK SPACE
205F; MEDIUM MATHEMATICAL SPACE
3000; IDEOGRAPHIC SPACE
**5.2 Control characters
> Control characters (or characters with control function) cannot be
seen and can cause unpredictable results when displayed. Note that
the list below is split into two tables in appendix C: Table C.2.1
contains the ASCII code points, while Table C.2.2 contains the
non-ASCII code points. Most profiles of this document that want to
prohibit control characters will want to include both tables.
[[制御文字]] ([[制御機能]]を持つ[[文字]]) は見ることができず、
表示した時に予期せぬ結果を引き起こしかねません。
次の表は附属書 C では2つの表に分かれます。表 C.2.1
は [[ASCII]] 符号位置を含み、表 C.2.2 は非 ASCII
符号位置を含みます。制御文字を禁止したいこの文書のプロファイルのhトン度はどちらの表も含めるのが良いでしょう。
>
0000-001F; [CONTROL CHARACTERS]
007F; DELETE
0080-009F; [CONTROL CHARACTERS]
06DD; ARABIC END OF AYAH
070F; SYRIAC ABBREVIATION MARK
180E; MONGOLIAN VOWEL SEPARATOR
200C; ZERO WIDTH NON-JOINER
200D; ZERO WIDTH JOINER
2028; LINE SEPARATOR
2029; PARAGRAPH SEPARATOR
2060; WORD JOINER
2061; FUNCTION APPLICATION
2062; INVISIBLE TIMES
2063; INVISIBLE SEPARATOR
206A-206F; [CONTROL CHARACTERS]
FEFF; ZERO WIDTH NO-BREAK SPACE
FFF9-FFFC; [CONTROL CHARACTERS]
1D173-1D17A; [MUSICAL CONTROL CHARACTERS]
**5.3 Private use
> Because private-use characters do not have defined meanings, they are
likely to be prohibited. The private-use characters are:
[[私用文字]]は定義された意味を持ちませんから、
禁止することがよくあります。私用文字は次の通りです。
>
E000-F8FF; [PRIVATE USE, PLANE 0]
F0000-FFFFD; [PRIVATE USE, PLANE 15]
100000-10FFFD; [PRIVATE USE, PLANE 16]
**5.4 Non-character code points
> Non-character code points are code points that have been allocated in
ISO/IEC 10646 but are not characters. Because they are already
assigned, they are guaranteed not to later change into characters.
[[非文字]]符号位置は [[ISO/IEC 10646]] で割当てられているものの文字を持たない符号位置です。
非文字は既に割当てられているので、後で文字に変わることはないと保証されています。
>
FDD0-FDEF; [NONCHARACTER CODE POINTS]
FFFE-FFFF; [NONCHARACTER CODE POINTS]
1FFFE-1FFFF; [NONCHARACTER CODE POINTS]
2FFFE-2FFFF; [NONCHARACTER CODE POINTS]
3FFFE-3FFFF; [NONCHARACTER CODE POINTS]
4FFFE-4FFFF; [NONCHARACTER CODE POINTS]
5FFFE-5FFFF; [NONCHARACTER CODE POINTS]
6FFFE-6FFFF; [NONCHARACTER CODE POINTS]
7FFFE-7FFFF; [NONCHARACTER CODE POINTS]
8FFFE-8FFFF; [NONCHARACTER CODE POINTS]
9FFFE-9FFFF; [NONCHARACTER CODE POINTS]
AFFFE-AFFFF; [NONCHARACTER CODE POINTS]
BFFFE-BFFFF; [NONCHARACTER CODE POINTS]
CFFFE-CFFFF; [NONCHARACTER CODE POINTS]
DFFFE-DFFFF; [NONCHARACTER CODE POINTS]
EFFFE-EFFFF; [NONCHARACTER CODE POINTS]
FFFFE-FFFFF; [NONCHARACTER CODE POINTS]
10FFFE-10FFFF; [NONCHARACTER CODE POINTS]
> The non-character code points are listed in the PropList.txt file
from the Unicode database.
非文字符号位置は Unicode データベースの [CODE(file)[[[PropList.txt]]]]
ファイルに列挙されています。
**5.5 Surrogate codes
> The following code points are permanently reserved for use as
surrogate code values in the UTF-16 encoding, will never be assigned
to characters in the Unicode repertoire, and are therefore prohibited:
次の符号位置は [[UTF-16]] 符号化で代理符号値として使うために恒久的に予約されており、
決して Unicode レパートリの文字が割当てられることはなく、
従って禁止します。
> D800-DFFF; [SURROGATE CODES]
**5.6 Inappropriate for plain text
> The following characters do not appear in regular text.
次の文字は普通の文章には表れません。
>
FFF9; INTERLINEAR ANNOTATION ANCHOR
FFFA; INTERLINEAR ANNOTATION SEPARATOR
FFFB; INTERLINEAR ANNOTATION TERMINATOR
FFFC; OBJECT REPLACEMENT CHARACTER
> Although the replacement character (U+FFFD) might be used when a
string is displayed, it doesn't make sense for it to be part of the
string itself. It is often displayed by renderers to indicate "there
would be some character here, but it cannot be rendered". For
example, on a computer with no Asian fonts, a string with three
ideographs might be rendered with three replacement characters.
置換文字 ([CODE(char)[[[U+FFFD]]]]) は文字列が表示される時に使われるかもしれませんが、
文字列自体の一部としては意味をなしません。置換文字は
[Q[ここには文字がありますが、レンダリングできません]]と示すためによくレンダリング器が表示します。
例えば、アジア系[[フォント]]がない計算機で[[漢字]]3文字の文字列は置換文字
3文字でレンダリングされるかもしれません。
>
FFFD; REPLACEMENT CHARACTER
*5.7 Inappropriate for canonical representation
> The ideographic description characters allow different sequences of
characters to be rendered the same way, which makes them
inappropriate for strings that have to have a single canonical
representation.
[[漢字説明文字]]は異なる文字列が同じようにレンダリングされることがあり、
一つの正準表現を持つ文字列には不適切です。
>
2FF0-2FFB; [IDEOGRAPHIC DESCRIPTION CHARACTERS]
**5.8 Change display properties or are deprecated
> The following characters can cause changes in display or the order in
which characters appear when rendered, or are deprecated in Unicode.
次の文字は表示を変更したり文字がレンダリングされる時の順序を変えたりできたり、
Unicode で非推奨とされていたりします。
>
0340; COMBINING GRAVE TONE MARK
0341; COMBINING ACUTE TONE MARK
200E; LEFT-TO-RIGHT MARK
200F; RIGHT-TO-LEFT MARK
202A; LEFT-TO-RIGHT EMBEDDING
202B; RIGHT-TO-LEFT EMBEDDING
202C; POP DIRECTIONAL FORMATTING
202D; LEFT-TO-RIGHT OVERRIDE
202E; RIGHT-TO-LEFT OVERRIDE
206A; INHIBIT SYMMETRIC SWAPPING
206B; ACTIVATE SYMMETRIC SWAPPING
206C; INHIBIT ARABIC FORM SHAPING
206D; ACTIVATE ARABIC FORM SHAPING
206E; NATIONAL DIGIT SHAPES
206F; NOMINAL DIGIT SHAPES
**5.9 Tagging characters
> The following characters are used for tagging text and are invisible.
次の文字はタグ付き文で使われ、不可視です。
>
E0001; LANGUAGE TAG
E0020-E007F; [TAGGING CHARACTERS]
*6. Bidirectional Characters
> Most characters are displayed from left to right, but some are
displayed from right to left. This feature of Unicode is called
"bidirectional text", or "bidi" for short. The Unicode standard has
an extensive discussion of how to reorder glyphs for display when
dealing with bidirectional text such as Arabic or Hebrew. See [UAX9]
for more information. In particular, all Unicode text is stored in
logical order.
ほとんどの文字は左から右に表示されますが、中には右から左へ表示される文字もあります。
Unicode のこの機能は[Q[双方向的文]]や略して [Q[bidi]]
と呼ばれます。 Unicode 規格は[[アラビア文字]]や[[ヘブライ文字]]の双方向的文表示する時にどうグリフを再順序付けするか多く議論しています。
詳しくは UAX #9 をご覧下さい。特に、すべての Unicode
の文章は[[論理順]]で蓄積します。
> A profile MAY choose to ignore bidirectional text. However, ignoring
bidirectional text can cause display ambiguities. For example, it is
quite easy to create two different strings with the same characters
(but in different order) that are correctly displayed identically.
Therefore, in order to avoid most problems with ambiguous
bidirectional text display, profile creators should strongly consider
including the bidirectional character handling described in this
section in their profile.
プロファイルは双方向的文を無視することにしても'''構いません'''。
しかし、双方向的文を無視すると表示状の曖昧さが残るかもしれません。
例えば、2つの異なる文字列が同じ文字で (異なる順序で)
正しく同じように表示されるようにすることは甚だ容易です。
従って、双方向的文の表示の曖昧性の問題のほとんどを避けるため、
プロファイルの作者はこの節で説明する双方向的文字の扱いをプロファイルに含めることを強く考慮するべきです。
> The stringprep process never emits both an error and a string. If an
error is detected during the checking of bidirectional strings, only
an error is returned.
Stringprep 処理は誤りと文字列の両方を出すことはありません。
双方向的文字列の検査で誤りが検出されれば、
誤りだけが返されます。
> [Unicode3.2] defines several bidirectional categories; each character
has one bidirectional category assigned to it. For the purposes of
the requirements below, an "RandALCat character" is a character that
has Unicode bidirectional categories "R" or "AL"; an "LCat character"
is a character that has Unicode bidirectional category "L". Note
that there are many characters which fall in neither of the above
definitions; Latin digits (<U+0030> through <U+0039>) are examples of
this because they have bidirectional category "EN".
Unicode 3.2 は数個の双方向的分類を定義しています。
各文字はどれか1つの双方向的分類に分類されます。
以降で必要な範囲では、 [Q[R・AL類文字]]は Unicode
双方向的分類が [CODE[R]] または [CODE[AL]]
の文字です。 [Q[L類文字]]は Unicode
双方向的分類が [CODE[L]] の文字です。
なお、多くの文字はこの定義のいずれにも当てはまりません。
ラテン数字 ([CODE(char)[[[U+0030]]]]〜[CODE(char)[[[U+0039]]]])
はその例で、双方向的分類 [CODE[EN]] です。
> In any profile that specifies bidirectional character handling, all
three of the following requirements MUST be met:
双方向的文字処理を規定するプロファイルは、
次の3つの要件すべてを満たさなければ'''なりません'''。
>
- 1) The characters in section 5.8 MUST be prohibited.
- 2) If a string contains any RandALCat character, the string MUST NOT
contain any LCat character.
- 3) If a string contains any RandALCat character, a RandALCat
character MUST be the first character of the string, and a
RandALCat character MUST be the last character of the string.
- 5.8 節の文字を禁止しなければ'''なりません'''。
- 文字列が R・AL 類文字を含むなら、文字列は L
類文字を含んでは'''なりません'''。
- 文字列が R・AL 類文字を含むなら、
R・AL 類文字が文字列の最初の文字でなければ'''なりません'''し、また
R・AL 類文字が文字列の最後の文字でなければ'''なりません'''。
> Note that requirement 3 prohibits strings such as <U+0627><U+0031>
("aleph 1") but allows strings such as <U+0627><U+0031><U+0628>
("aleph 1 beh"). [UAX9] goes into great detail about the display
order of strings that contain particular categories of characters in
particular sequences.
要件3により [SAMP[<[CODE(char)[[[U+0627]]><[CODE(char)[[[U+0031]]]]>]]
([SAMP[alef 1]]) のような文字列は禁止されますが、
[SAMP[<[CODE(char)[[[U+0627]]><[CODE(char)[[[U+0031]]]]><[CODE(char)[[[U+0628]]]]>]]
([SAMP[alef 1 beh]]) のような文字列は認められます。
UAX #9 はある分類の文字を含む文字列がどのように表示されるかについて非常に詳しく説明しています。
> Table D.1 lists the characters that belong to Unicode bidirectional
categories "R" and "AL". Table D.2 lists all the characters that
belong to Unicode bidirectonal category "L". These tables are
derived from [Unicode3.2].
表 D.1 は Unicode 双方向的分類が [CODE[R]] や [CODE[AL]]
の文字を挙げています。表 D.2 は Unicode 双方向的分類 [CODE[L]]
に属する文字をすべて挙げています。これらの表は Unicode 3.2
に基づいています。
*7. Unassigned Code Points in Stringprep Profiles
> This section describes two different types of strings in typical
protocols where internationalized strings are used: "stored strings"
and "queries". Of course, different Internet protocols use strings
very differently, so these terms cannot be used exactly in every
protocol that needs to use stringprep. In general, "stored strings"
are strings that are used in protocol identifiers and named entities,
such as names in digital certificates and DNS domain name parts.
"Queries" are strings that are used to match against strings that are
stored identifiers, such as user-entered names for digital
certificate authorities and DNS lookups.
この章は国際化された文字列が使われる典型的なプロトコルの2つの文字列の種類、
[Q[蓄積文字列]]と[Q[照会]]を説明します。もちろん。
各インターネット・プロトコルは文字列をそれぞれ色々に使っていますから、
この2つの語を stringprep が必要な各プロトコルの通りに使うことはできません。
通常、[Q[蓄積文字列]]はプロトコル識別子や名前付き実体、
例えばデジタル証明書の名前や DNS ドメイン名部分で使われる文字列です。
[Q[照会]]は蓄積文字列である文字列と一致させるのに使う文字列で、
利用者が入力したデジタル証明機関や DNS 探索の名前などです。
> All code points not assigned in the character repertoire named in a
stringprep profile are called "unassigned code points". Stored
strings using the profile MUST NOT contain any unassigned code
points. Queries for matching strings MAY contain unassigned code
points. Note that this is the only part of this document where the
requirements for queries differs from the requirements for stored strings.
Stringprep プロファイルで名前付けされた文字レパートリにおいて割当てられていない符号位置すべてを[Q[未割当符号位置]]と呼びます。
プロファイルを使う蓄積文字列は未割当符号位置を含んでいては'''なりません'''。
一致文字列の照会は未割当符号位置を含んでいても'''構いません'''。
なお、この文書の中でここだけが照会と蓄積文字列で要件の異なる部分です。
> Using two different policies for where unassigned code points can
appear removes the need for versioning in protocols that use
stringprep profiles. This is very useful since it makes the overall
processing simpler and does not impose a "protocol" to handle
versioning. It is expected that the ISO/IEC 10646 and Unicode
repertoires will be updated fairly frequently; at the time that this
document is being written, it has happened approximately once a year.