This informative section provides guidelines for supporting IRIs in the same software components and operations that currently process URIs: Software interfaces that handle URIs, software that allows users to enter URIs, software that creates or generates URIs, software that displays URIs, formats and protocols that transport URIs, and software that interprets URIs. These may all require modification before functioning properly with IRIs. The considerations in this section also apply to URI references and IRI references.
この章 (参考) では、現在 URI を処理しているソフトウェア部品や操作 (URI を扱うソフトウェア界面、利用者が URI を入力できるソフトウェア、 URI を作成・生成するソフトウェア、 URI を表示するソフトウェア、 URI を輸送する書式・プロトコル、 URI を解釈するソフトウェア) において同時に IRI に対応するための指針を示します。これらのソフトウェアはすべて IRI を正しく扱うために修正が必要です。この章での考察は URI 参照から IRI 参照へにも適用できます。
Software interfaces that handle URIs, such as URI-handling APIs and protocols transferring URIs, need interfaces and protocol elements that are designed to carry IRIs.
URI を扱う API や URI を転送するプロトコルのような URI を扱うソフトウェア界面は、 IRI を伝達するよう設計された界面やプロトコル要素が必要です。
In case the current handling in an API or protocol is based on US-ASCII, UTF-8 is recommended as the character encoding for IRIs, as it is compatible with US-ASCII, is in accordance with the recommendations of [RFC2277], and makes converting to URIs easy. In any case, the API or protocol definition must clearly define the character encoding to be used.
API やプロトコルで現在
The transfer from URI-only to IRI-capable components requires no mapping, although the conversion described in section 3.2 above may be performed. It is preferable not to perform this inverse conversion when there is a chance that this cannot be done correctly.
URI だけの部品から IRI が使える部品への変更にはどんな写像も必要ありませんが、 3.2節で説明した変換を行っても構いません。 この逆変換が正しく行えない可能性がある時にはその変換は行わない方が良いです。
Some components allow users to enter URIs into the system by typing or dictation, for example. This software must be updated to allow for IRI entry.
打鍵や書取りなどのシステムにより利用者が URI を入力できるようにしているソフトウェア部品もあります。 このソフトウェアは IRI を入力できるように更新しなければなりません。
A person viewing a visual representation of an IRI (as a sequence of glyphs, in some order, in some visual display) or hearing an IRI will use an entry method for characters in the user's language to input the IRI. Depending on the script and the input method used, this may be a more or less complicated process.
IRI の視覚表現を (
The process of IRI entry must ensure, as much as possible, that the restrictions defined in section 2.2 are met. This may be done by choosing appropriate input methods or variants/settings thereof, by appropriately converting the characters being input, by eliminating characters that cannot be converted, and/or by issuing a warning or error message to the user.
IRI 入力処理は可能な限り2.2節で定義した制限に合致するようにしなければなりません。 これは適切な入力方式・種類・設定を選ぶこと、入力された文字を適切に変換すること、 変換できない文字を除去すること、利用者に警告・ 誤りのメッセージを出すことによって行うことができるでしょう。
As an example of variant settings, input method editors for East Asian Languages usually allow the input of Latin letters and related characters in full-width or half-width versions. For IRI input, the input method editor should be set so that it produces half-width Latin letters and punctuation and full-width Katakana.
設定の例としては、東亜言語の入力方式編集器では通常
An input field primarily or solely used for the input of URIs/IRIs may allow the user to view an IRI as it is mapped to a URI. Places where the input of IRIs is frequent may provide the possibility for viewing an IRI as mapped to a URI. This will help users when some of the software they use does not yet accept IRIs.
URI や IRI の入力が主目的か、それだけに使う入力欄では、 利用者が IRI を URI に写像して見ることができても構いません。 IRI がよく入力される場所では IRI を URI に写像して見る方法を用意しても構いません。 そうすれば IRI をまだ受付けないソフトウェアを使うときに利用者の助けとなるでしょう。
An IRI input component interfacing to components that handle URIs, but not IRIs, must map the IRI to a URI before passing it to these components.
IRI 入力部品と IRI ではなく IRI を扱う部品との界面では、 部品に渡す前に IRI から URI に写像しなければなりません。
For the input of IRIs with right-to-left characters, please see section 4.3.
右から左の文字の IRI の入力については4.2節を見て下さい。
Many applications, particularly mail user agents, try to detect URIs appearing in plain text. For this, they use some heuristics based on URI syntax. They then allow the user to click on such URIs and retrieve the corresponding resource in an appropriate (usually scheme-dependent) application.
多くの応用、特にメイル利用者エージェントは、
平文に現れる URI を検出しようとします。これには URI
構文に基づいた発見的方法が使われます。そして利用者がその URI
を
訳注: 現実の MUA を見る限り、単純に IRI とみなす文字を増やすだけでは誤認識を増やすだけにしかならないと思われます。
Such applications have to be upgraded to use the IRI syntax as a base for heuristics. In particular, a non-ASCII character should not be taken as the indication of the end of an IRI. Such applications also have to make sure that they correctly convert the detected IRI from the character encoding of the document or application where the IRI appears to the character encoding used by the system-wide IRI invocation mechanism, or to a URI (according to section 3.1) if the system-wide invocation mechanism only accepts URIs.
このような応用は発見的方法の基盤を IRI 構文に更新する必要があります。 特に非 ASCII 文字は IRI の終わりを表すものと取るべきではありません。 また、検出した IRI をその文書や応用の文字符号化からシステムの IRI 呼出し機構で使う文字符号化に正しく変換するか、システムの呼出し機構が URI しか受付けないなら正しく URI に変換するかする必要もあります。
The clipboard is another frequently used way to transfer URIs and IRIs from one application to another. On most platforms, the clipboard is able to store and transfer text in many languages and scripts. Correctly used, the clipboard transfers characters, not bytes, which will do the right thing with IRIs.
Systems that offer resources through the Internet, where those resources have logical names, sometimes automatically generate URIs for the resources they offer. For example, some HTTP servers can generate a directory listing for a file directory and then respond to the generated URIs with the files.
インターネットを通じて資源を提供するシステムで、 資源が論理的な名前を持つものは、時々その提供する資源に自動的に URI を生成します。例えば、ある HTTP 鯖はファイル・ディレクトリのディレクトリ一覧を生成して、 生成された URI に対してファイルで応答することができます。
Many legacy character encodings are in use in various file systems. Many currently deployed systems do not transform the local character representation of the underlying system before generating URIs.
多くの遺物文字符号化が色々なファイル・システムで使われています。 多くの現在使用されているシステムは URI を生成する前にシステム側の局所文字表現を変形しません。
For maximum interoperability, systems that generate resource identifiers should make the appropriate transformations. For example, if a file system contains a file named "résumé.html", a server should expose this as "r%C3%A9sum%C3%A9.html" in a URI, which allows use of "résumé.html" in an IRI, even if locally the file name is kept in a character encoding other than UTF-8.
相互運用性を最大化するために資源識別氏を生成するシステムは適切な変形を行うべきです。 例えば、ファイル・システムが résumé.html という名前のファイルを持っているなら、たとえ局所的にファイル名を UTF-8 以外の文字符号化で持っているのだとしても、鯖はこれを r%C3%A9sum%C3%A9.html という URI で見えるようにし、 IRI で résumé.html が使えるようにするべきです。
This recommendation particularly applies to HTTP servers. For FTP servers, similar considerations apply; see [RFC2640].
この推奨は特に HTTP 鯖に適用します。 FTP 鯖にも同様のことが言えます。
In some cases, resource owners and publishers have control over the IRIs used to identify their resources. This control is mostly executed by controlling the resource names, such as file names, directly.
場合によっては資源の所有者と出版社が資源を識別するために使う IRI の統制権を有しています。この統制はほとんどファイル名などの資源名を直接統制することにより行われます。
In these cases, it is recommended to avoid choosing IRIs that are easily confused. For example, for US-ASCII, the lower-case ell ("l") is easily confused with the digit one ("1"), and the upper-case oh ("O") is easily confused with the digit zero ("0"). Publishers should avoid confusing users with "br0ken" or "1ame" identifiers.
その場合、混乱しやすい IRI を避けることを推奨します。例えば、
l) は数字の一
(1) と間違いやすいですし、大文字のオー
(O) は数字の零 (0) と間違いやすいです。
出版社は⊃'フレ夕
、イ力レ夕
識別子で利用者を混乱させないようにするべきです。
Outside the US-ASCII repertoire, there are many more opportunities for confusion; a complete set of guidelines is too lengthy to include here. As long as names are limited to characters from a single script, native writers of a given script or language will know best when ambiguities can appear, and how they can be avoided. What may look ambiguous to a stranger may be completely obvious to the average native user. On the other hand, in some cases, the UCS contains variants for compatibility reasons; for example, for typographic purposes. These should be avoided wherever possible. Although there may be exceptions, newly created resource names should generally be in NFKC [UTR15] (which means that they are also in NFC).
US-ASCII
As an example, the UCS contains the "fi" ligature at U+FB01 for compatibility reasons. Wherever possible, IRIs should use the two letters "f" and "i" rather than the "fi" ligature. An example where the latter may be used is in the query part of an IRI for an explicit search for a word written containing the "fi" ligature.
例として UCS には互換性のために fi fi 合字ではなく f と
i の2文字を使うべきです。合字を使っても良さそうなのは
fi 合字を含んで書かれた語をあえて検索する IRI
の
In certain cases, there is a chance that characters from different scripts look the same. The best known example is the similarity of the Latin "A", the Greek "Alpha", and the Cyrillic "A". To avoid such cases, only IRIs should be created where all the characters in a single component are used together in a given language. This usually means that all of these characters will be from the same script, but there are languages that mix characters from different scripts (such as Japanese). This is similar to the heuristics used to distinguish between letters and numbers in the examples above. Also, for Latin, Greek, and Cyrillic, using lowercase letters results in fewer ambiguities than using uppercase letters would.
場合によっては異なる
In situations where the rendering software is not expected to display non-ASCII parts of the IRI correctly using the available layout and font resources, these parts should be percent-encoded before being displayed.
レンダリング・ソフトウェアが IRI の非 ASCII 部を利用可能な配置・フォント資源を使って正しく表示できそうにない場合には、
その部分は表示の前に
For display of Bidi IRIs, please see section 4.1.
Bidi IRI の表示については4.1節をご覧下さい。
Software that interprets IRIs as the names of local resources should accept IRIs in multiple forms and convert and match them with the appropriate local resource names.
IRI を局所資源の名前と解釈するソフトウェアは IRI を複数の形で受付け、適切な局所氏言明と一致させるべきです。
First, multiple representations include both IRIs in the native character encoding of the protocol and also their URI counterparts.
1番目に、複数の表現にはプロトコルの本来の文字符号化の IRI とそれに対応する URI も両方含みます。
Second, it may include URIs constructed based on character encodings other than UTF-8. These URIs may be produced by user agents that do not conform to this specification and that use legacy character encodings to convert non-ASCII characters to URIs. Whether this is necessary, and what character encodings to cover, depends on a number of factors, such as the legacy character encodings used locally and the distribution of various versions of user agents. For example, software for Japanese may accept URIs in Shift_JIS and/or EUC-JP in addition to UTF-8.
2番目に、 UTF-8 以外の文字符号化に基づき構築された URI
を含んでも構いません。そのような URI はこの仕様書に適合せず非 ASCII 文字の
URI への変換に遺物文字符号化を使う利用者エージェントが生成するかもしれません。
これが必要かどうか、どの文字符号化に対応するかは、
局所的に使われている遺物文字符号化や利用者エージェントの各版の分散などの数々の要因に拠ります。
例えば、日本語のソフトウェアは UTF-8 だけではなく
Third, it may include additional mappings to be more user-friendly and robust against transmission errors. These would be similar to how some servers currently treat URIs as case insensitive or perform additional matching to account for spelling errors. For characters beyond the US-ASCII repertoire, this may, for example, include ignoring the accents on received IRIs or resource names. Please note that such mappings, including case mappings, are language dependent.
3番目に、より利用者に優しく転送誤りに強い写像を更に使って構いません。 これは、いくつかの鯖で既に URI を大文字・小文字を区別しなかったり、 綴りの誤りを考慮して一致を探したりしているのと同様です。 US-ASCII レパートリを超える文字においては、 例えば受信した IRI や資源名のアクセントを無視したりできるでしょう。 このような写像は、大文字・小文字も含め、言語依存であることに注意して下さい。
It can be difficult to identify a resource unambiguously if too many mappings are taken into consideration. However, percent-encoded and not percent-encoded parts of IRIs can always be clearly distinguished. Also, the regularity of UTF-8 (see [Duerst97]) makes the potential for collisions lower than it may seem at first.
あまり多くの写像を考慮すると資源名を曖昧なく識別するのが難しいかもしれません。 しかし、 IRI の百分率符号化部と非百分率符号化部は常に明らかに区別できます。 また、 UTF-8 の規則性により衝突の可能性を見かけより小さくなっています。
Where this recommendation places further constraints on software for which many instances are already deployed, it is important to introduce upgrades carefully and to be aware of the various interdependencies.
この推奨が既に多く採用されているソフトウェアを制約するところでは、 更新を注意深く行い、色々な相互依存性に注意することが重要です。
If IRIs cannot be interpreted correctly, they should not be created, generated, or transported. This suggests that upgrading URI interpreting software to accept IRIs should have highest priority.
IRI を正しく解釈できなければ、作成、生成、輸送するべきではありません。 これは URI 解釈ソフトウェアを IRI を受付けるように更新することが高い優先度を持つべきことを表しています。
On the other hand, a single IRI is interpreted only by a single or very few interpreters that are known in advance, although it may be entered and transported very widely.
他方、一つの IRI は非常に広く入力・輸送されるかもしれませんが、 一つか非常にわずかな解釈器しかこれを解釈しないことが予めわかっています。
Therefore, IRIs benefit most from a broad upgrade of software to be able to enter and transport IRIs. However, before an individual IRI is published, care should be taken to upgrade the corresponding interpreting software in order to cover the forms expected to be received by various versions of entry and transport software.
従って、 IRI の利益はほとんど、ソフトウェアが広く IRI を入力・輸送できるように更新されることから得られます。しかし、 個々の IRI が出版される前に色々な版の入力・輸送ソフトウェアから受信することが想定される各形式に対応するべく対応する解釈ソフトウェアを更新するように注意を払うべきです。
The upgrade of generating software to generate IRIs instead of using a local character encoding should happen only after the service is upgraded to accept IRIs. Similarly, IRIs should only be generated when the service accepts IRIs and the intervening infrastructure and protocol is known to transport them safely.
生成ソフトウェアを局所文字符号化を使わずに IRI を生成するように更新するのはサービスが IRI を受付けるように更新された後ではじめて行うべきです。 同様に、 IRI はサービスが IRI を受付け、 干渉する基盤やプロトコルが安全に IRI を輸送するとわかっている場合にのみ生成するべきです。
Software converting from URIs to IRIs for display should be upgraded only after upgraded entry software has been widely deployed to the population that will see the displayed result.
表示のために URI から IRI に変換するソフトウェアは各ソフトウェアは、 表示結果を見る人達全体に更新された入力ソフトウェアが広く採用されて初めて更新するべきです。
Where there is a free choice of character encodings, it is often possible to reduce the effort and dependencies for upgrading to IRIs by using UTF-8 rather than another encoding. For example, when a new file-based Web server is set up, using UTF-8 as the character encoding for file names will make the transition to IRIs easier. Likewise, when a new Web form is set up using UTF-8 as the character encoding of the form page, the returned query URIs will use UTF-8 as the character encoding (unless the user, for whatever reason, changes the character encoding) and will therefore be compatible with IRIs.
文字符号化の選択が自由に行える場合には、他の符号化ではなく UTF-8 を使うことによって IRI に更新するための注力と依存性を減らすことができるかもしれません。 例えば、新しいファイルを基にしたウェブ鯖を設定する時には、 ファイル名の文字符号化に UTF-8 を使うと IRI への移行が容易になります。同様に、新しいウェブ・フォームを設定するときに UTF-8 をフォーム頁の文字符号化とすれば、返される照会 URI は (利用者が何らかの理由で文字符号化を変えない限り) UTF-8 を文字符号化として使うようになり、従って IRI と互換になります。
These recommendations, when taken together, will allow for the extension from URIs to IRIs in order to handle characters other than US-ASCII while minimizing interoperability problems. For considerations regarding the upgrade of URI scheme definitions, see section 6.4.
これらの推奨に揃って従えば US-ASCII 以外の文字を扱うための URI から IRI への拡張を相互運用性の問題を最小化しつつ行うことができます。 URI scheme 定義の更新に関する考察は6.4節をご覧下さい。