<html xmlns="http://www.w3.org/1999/xhtml"><head></head><body><section><h1>Appendix A.  Design Alternatives</h1><blockquote><p>This section shortly summarizes major design alternatives and the
reasons for why they were not chosen.</p></blockquote><p>この章では他の設計案とそれを選ばなかった理由を簡単にまとめます。</p><section><h1>Appendix A.1.  New Scheme(s)</h1><blockquote><p>Introducing new schemes (for example, httpi:, ftpi:,...) or a new
metascheme (e.g., i:, leading to URI/IRI prefixes such as i:http:,
i:ftp:,...) was proposed to make IRI-to-URI conversion scheme
dependent or to distinguish between percent-encodings resulting from
IRI-to-URI conversion and percent-encodings from legacy character encodings.</p></blockquote><p>新しい scheme (例えば <samp class="URI">httpi:</samp>, <samp class="URI">ftpi:</samp>)
や新しいメタ scheme (例えば URI・IRI の前に <samp class="URI">i:</samp>
を <samp class="URI">i:http:</samp> や <samp class="URI">i:ftp:</samp> のように付ける。)
を導入して IRI から URI への変換を scheme 依存にしたり IRI
から URI への変換の結果の百分率符号化と遺物文字符号化の百分率符号化を区別できるようにすることが提案されました。</p><blockquote><p>New schemes are not needed to distinguish URIs from true IRIs (i.e.,
IRIs that contain non-ASCII characters).  The benefit of being able
to detect the origin of percent-encodings is marginal, as UTF-8 can
be detected with very high reliability.  Deploying new schemes is
extremely hard, so not requiring new schemes for IRIs makes
deployment of IRIs vastly easier.  Making conversion scheme dependent
is highly inadvisable and would be encouraged by separate schemes for
IRIs.  Using a uniform convention for conversion from IRIs to URIs
makes IRI implementation orthogonal to the introduction of actual new schemes.</p></blockquote><p>真の IRI (非 ASCII 文字を含む IRI) と URI を区別するのに新しい scheme
は不要です。 UTF-8 は非常に高い確率で検出できるので、
百分率符号化の起源を明かせるようにする利点は取るに足りません。
新しい scheme の供用は極めて難しく、 IRI 用の新しい scheme
を必要としないことで IRI の供用は遥かに簡単になります。
変換が scheme 依存になるのは非常に愚かなことであり、 IRI
用の別の scheme を薦めることになります。統一的な IRI から URI
への変換を使うことで IRI の実装が実際の新しい scheme
の導入と直交したものになります。</p></section><section><h1>Appendix A.2.  Character Encodings Other Than UTF-8</h1><blockquote><p>At an early stage, UTF-7 was considered as an alternative to UTF-8
when IRIs are converted to URIs.  UTF-7 would not have needed
percent-encoding and in most cases would have been shorter than
percent-encoded UTF-8.</p></blockquote><p>早い段階の案で IRI を URI に変換する時に UTF-8 の代わりに UTF-8
が検討されました。 UTF-7 は百分率符号化不要であり、
ほとんどの場合百分率符号化した UTF-8 より短くなります。</p><blockquote><p>Using UTF-8 avoids a double layering and overloading of the use of
the &quot;+&quot; character.  UTF-8 is fully compatible with US-ASCII and has
therefore been recommended by the IETF, and is being used widely.</p></blockquote><p>UTF-8 を使うと二層化と文字 <code class="char">+</code> の用法の上書きを避けられます。
UTF-8 は US-ASCII と完全互換であり、従って IETF で推奨されており、
広く使われています。</p><blockquote><p>UTF-7 has never been used much and is now clearly being discouraged.
Requiring implementations to convert from UTF-8 to UTF-7 and back
would be an additional implementation burden.</p></blockquote><p>UTF-7 はそれほど使われることがなく、現在では明らかに非推奨です。
実装に UTF-8 から UTF-7 に変換したり戻したりすることを求めるのは実装の更なる負担となります。</p></section><section><h1>Appendix A.3.  New Encoding Convention</h1><blockquote><p>Instead of using the existing percent-encoding convention of URIs,
which is based on octets, the idea was to create a new encoding
convention; for example, to use &quot;%u&quot; to introduce UCS code points.</p></blockquote><p>URI の既存のオクテットに基づく百分率符号化変換を使う代わりに新しい符号化法を作るという考えでした。
例えば <samp class="URI">%u</samp> を <anchor xmlns="urn:x-suika-fam-cx:markup:suikawiki:0:9:">UCS</anchor> <anchor xmlns="urn:x-suika-fam-cx:markup:suikawiki:0:9:">符号位置</anchor>の前に付けます。</p><blockquote><p>Using the existing octet-based percent-encoding mechanism does not
need an upgrade of the URI syntax and does not need corresponding
server upgrades.</p></blockquote><p>既存のオクテットを基にした百分率符号化法は URI 構文を更新する必要がなく、
それに伴う鯖の更新も不要です。</p></section><section><h1>Appendix A.4.  Indicating Character Encodings in the URI/IRI</h1><blockquote><p>Some proposals suggested indicating the character encodings used in
an URI or IRI with some new syntactic convention in the URI itself,
similar to the &quot;charset&quot; parameter for e-mails and Web pages.  As an
example, the label in square brackets in
&quot;http://www.example.org/ros[iso-8859-1]&amp;#xE9&quot;; indicated that the
following &quot;&amp;#xE9&quot;; had to be interpreted as iso-8859-1.</p></blockquote><p>電子メイルや Web 頁の <code class="MIME"><anchor xmlns="urn:x-suika-fam-cx:markup:suikawiki:0:9:">charset</anchor></code> 引数のように
URI や IRI で使う文字符号化を何らかの新しい構文で URI 自体に記述することが提案されました。
例えば札を四角括弧に入れて <samp class="URI">http://www.example.org/ros[iso-8859-1]&amp;#xE9;</samp>
のようにして、その後の <samp>&amp;#xE9;</samp> を <code class="charset">iso-8859-1</code>
として解釈しなければならないことを示します。</p><blockquote><p>If UTF-8 is used exclusively, an upgrade to the URI syntax is not
needed.  It avoids potentially multiple labels that have to be copied
correctly in all cases, even on the side of a bus or on a napkin,
leading to usability problems (and being prohibitively annoying).
Exclusively using UTF-8 also reduces transcoding errors and confusion.</p></blockquote><p>UTF-8 を排他的に使用すれば URI 構文の更新は不要です。
複数あるかもしれない札がいつ何時でも、たとえバスの側面でもナプキンであっても正しく書き写されなければならず、
可用性の問題を招く (そして極めて困る) というのを避けることができます。
UTF-8 を排他的に使うことで転符号化の誤りと混乱も減ります。</p></section></section><section><h1>License</h1><p><anchor xmlns="urn:x-suika-fam-cx:markup:suikawiki:0:9:">RFCのライセンス</anchor></p></section><section><h1>メモ</h1></section></body></html>