Days on the Moon

Perl の URI モジュールには ASCII 外の文字の扱いに関して欠陥がある。ここでは Perl における URI の扱いについて述べ、URI モジュールの修正方針を提案する。

用語の定義

URI

RFC 3986 (日本語訳) で定義される識別子。

URI.pm

Perl の URI モジュール。ここでは、ファイルとしての URI.pm だけでなく、URI パッケージ下に含まれるコード全般を指す。断りがない限りバージョン 1.58 に基づく。

文字列

UTF-8 文字列と Latin-1 文字列のいずれか。

UTF-8 文字列

Perl の文字列値で、UTF8 フラグが立っているもの。

Latin-1 文字列

Perl の文字列値で、UTF8 フラグが立っておらず、文字の並びとして扱われることを期待されているもの。

オクテット列

Perl の文字列値で、UTF8 フラグが立っておらず、バイトの並びとして扱われることを期待されているもの。Latin-1 文字列とオクテット列の機械的な判別は不可能。

発端となった問題

URI.pm のメソッドに UTF-8 文字列とオクテット列を同時に渡した場合、期待した出力が得られないことがある。特に Perl 5.10 以下では、use utf8 環境下で bareword に UTF8 フラグが立つため、この問題が発生しやすい。

#!/usr/bin/perl5.8.8
use strict;
use warnings;
use utf8;
use URI;
use Encode qw/encode_utf8/;

my $uri = URI->new('http://example.org/');
$uri->query_form( foo => encode_utf8('字') );
print $uri->query, "\n";
# actual:   "foo=%C3%A5%C2%AD%C2%97"
# expected: "foo=%E5%AD%97"

• Bug #53681 for URI: A bad utf8-related trap on query_form()
• use utf8 環境下で => オペレータの左辺が UTF8 flag on になってしまう - daily dayflower

Perl において URI はどう扱われるべきか

URI は US-ASCII の範囲内の文字で構成されるが、特定の文字符号化方式を仮定しない。URI には任意の文字符号化方式で符号化されたオクテットの並びが (パーセントエンコードされて) 含まれうる。たとえば、二つの URI http://ja.wikipedia.org/wiki/%E3%81%AF%E3%81%A6%E3%81%AA と http://d.hatena.ne.jp/keyword/%A4%CF%A4%C6%A4%CA において、パーセントエンコードされた部分はいずれも「はてな」という文字の並びを表すが、前者は UTF-8、後者は EUC-JP で符号化され、パーセントエンコードされたものである。

それゆえ、Perl において URI はオクテット列として扱われるべきである。そのオクテット列がどの文字符号化方式を用いて解釈されるかは、URI とは別の層の問題である。

URI.pm をどう修正すべきか

現在、URI.pm では入力を文字列として扱うものとオクテット列として扱うものが混在している。たとえば、host メソッドの引数に渡した値は UTF-8 文字列または Latin-1 文字列として解釈され、query メソッドの引数に渡した値はオクテット列であるかのように扱われる。

ここでは、前節の主張に従い、URI.pm に関する入出力はすべてオクテット列として扱うことを提案する。IRI に関するものを除き、URI.pm の各メソッドに渡された引数はすべてオクテット列とみなされ、返り値はオクテット列となるべきである。

引数に UTF-8 文字列が渡された場合は、それを UTF-8 で符号化されたオクテット列として扱うのがよいと考える。HTTP::Message の content メソッドのように UTF-8 文字列を渡されたらエラーとするのもひとつの手ではあるが、現在の URI.pm との互換性を大きく損ねないためにはエラーにしないほうがよいと判断する。

国際化ドメイン名の扱い

URI.pm の入出力をオクテット列とみなすとき、問題となるのは国際化ドメイン名の扱いである。本来なら ASCII 外の文字を含めるのに URI::IRI のような専用のモジュールを使うべきだろうが、現在の URI.pm との互換性を損ねないためには、URI->new(...) や $uri->host(...) で ASCII 外の文字を指定できるのが好ましい。

あくまで入力はオクテット列とみなすという方針を貫きつつ国際化ドメイン名を受け付けるため、URI のホスト部に関してはオクテット列を UTF-8 で符号化されたものとみなし、UTF-8 でデコードした文字列を Punycode 符号化して出力のホスト部とする。

URI.pm の互換性の確保

ここで提案する修正により、URI.pm は後方互換性を失う。特にホスト部に関しては、これまで Latin-1 文字列として扱われてきたものが、UTF-8 で符号化されたオクテット列として扱われ、まったく違った出力を得ることになる。

そこで、過去の挙動に戻せるよう、$URI::COERCE_OCTETS 変数を設ける。この変数のデフォルト値は真であるが、値が偽なら以前と同様に入力をオクテット列とみなさず処理を行う。

修正の段取り

以上の提案を実装すべく、現在 github の nanto/uri レポジトリの coerce_octets ブランチで作業中である。さしあたってどのような出力を期待しているのか明らかにするため、ASCII 外の文字を含む入出力に関するテストを書いた。実装が一段落したら URI.pm に対するパッチとして提出するつもりである。