それらを知ることのできる資料やホームページを教えていただけるだけでも大変助かります。
よろしくお願いします。
>最初からマルチバイトコードを意識していれば
当時の遠隔地への通信速度は一秒間に数百bit(現在の1万分の一程度)で、
アルファベットでも1秒間に数文字を送るのがやっとでしたし、
日本でもASCII+カタカナが関の山でした。
その後、マルチバイトに関しては、各国でバラバラに実装が進み、
日本でも漢字を含んだJISコードとしてまとめられ、互換性の問題で、
Shift-JISとして今も多様されています。(日本語の文字コードは、
他にもいくつか存在しますが、本題ではないので、割愛します。)
その後、UNICODEの最初のバージョンが出たのが1991年。
今でもまだUNICODEへの完全移行は成しえていません。
>8bitベースで解釈しているものがshift-jisのものを読み取ろうとした場合
URLエンコード/デコードの必要性はマルチバイトだからという理由ではないです。
(「2バイトコード(漢字)や記号を扱えない」という類の回答はミスリードの、
原因となっています。ひとまず忘れましょう。)
例えば、半角スペースだって置き換えが行われています。この意味は、
RFC1738で「URL文字符号化問題」として下記のような具合で説明されています。
http://www5d.biglobe.ne.jp/~stssk/nro/rfc1738_j.txt
URLとは文字の連続である。即ち文字、数字および特別な文字である。URLは様々な
方法で表される。例えば紙の上のインクか、またはコード化された文字セットによ
る8ビット値の連続によってである。URLの解析は用いられている文字の一致のみに
依存する。
紙に書く事を考えれば「印字可能なもののみ」というのは当然ですね。
「ここで改行」とか「ここでTAB」とか全部紙に書かれてたらウザイです(笑)
少し話はそれますが、HTMLでは先頭の空白は消されて左によったりしますよね?
これは、余計な空白として扱われてしまうからで、どうしてもそこに空白を、
入れたい場合は (&は本当は半角)といった具合に別の手段を用います。
これと同じ事がURLの場合にもあり半角スペースは + という記号に置き換わります。
他にも同様の理由でエンコード/デコードが必要になっています。その説明箇所が、
下記なのですが、確かにちょっと判り辛いかもしれませんね。
文字は幾つかの理由により安全ではなくなる。空白文字が安全でない理由は、ワー
プロソフト類の処理によってURLが翻訳・活字化されることにより、重要なスペー
スが消えたり、重要でない空白が挿入されるからである。
"<"と">"の文字が安全ではないのは、これらが自由なテキストにおいてURLの区切
りとして用いられるからであり、引用符(""")はあるシステムにおいて区切りとし
て用いられているからである。World Wide Webや他のシステムにおいて、"#"文字
はこの後に続くフラグメントやアンカー識別子からURLを区切る為に用いられるの
で安全ではなく、常に符号化するべきである。"%"文字は他の文字を符号化するた
めに用いられるので安全ではない。他の文字はゲートウェイや転送エージェントに
よって時々これらの文字を変更する場合があることが知られているので、安全では
ない。その文字は"{"、"}"、"|"、"\"、"^"、"~"、"["、"]"及び"`"である。
以上のように、そもそもの成り立ちからしてエスケープが必要であり、
そこにさらにマルチバイトの問題が折り重なってきているという構図になっています。
質問はURLエンコード/デコードの歴史的背景という事なので、
日本語の文字化け等については、言及しないでおきますが、マルチバイト問題と、
URLエンコード/デコードとは一旦は切り離して考えないと頭が混乱するという事です。
回答ありがとうございます。
参考にはなったのですが、自分の疑問はまだ晴れません。
うまく自分の疑問を説明できてないのですが...
もうしわけないです。
2バイトコード(漢字)や記号を扱えないからです。
英語圏でシステムが出来上がったので、そういうところに考慮がなかったので、
2バイトコードをエンコードして、無理やり1バイトコードにして
使えるようになったのです。
最近は、http://h.hatena.ne.jp/人力検索
URLも受け付けるようになりましたが、
昔は、人力検索なんて受け付けないので、エンコードして処理されてました。
回答ありがとうございます。
もうちょっと先が知りたいです。
なぜ、2バイトコードを扱えないのでしょうか?
2バイトコードを送ろうとすると、どんな不具合が起きて、なぜその不具合が起こるのでしょうか?
そこが気になります。
URL欄に日本語や記号などを記述するとURLとして判断されず、リンク切れになる場合があります。
検索画面のキーワードやE-mailアドレスなどをプログラムの末尾に掲載する場合、エンコードする事でURLとして判断されます。
例えば
http://・・・/aaa.cgi?key=エンコード って何?
のようなURLでは、keyが途中で切れてしまいます。
また、テキストメール等に掲載してもリンクが途中で切れてしまいます。
回答ありがとうございます。
説明不足で、すいません。
リンク切れが起きてしまう、原因が知りたいです。
サーバーorアプリが、○○という仕組みで動いているためリンク切れが起きます
...っというような答えが知りたいです。
RFC の栄えある 1 番は、なんと1969年4月!! その後1969年10月に
文字を電送する場合はASCIIコードを用いましょうというRFC20勧告が出され、
これが全てのベースとなっている。
通信速度の向上や通信網の整備に伴って、単純な英単語だけでなく、
ワープロのデータなども送るようになり、情報と制御データを区別する必要が、
出てきて、紛らわしいものには%をつけて区別しようという勧告が1994年の
12月にだされた。割りと最近と言えるけど、これでも既に15年も経っている古いもの。
(詳細はRFC1738 に詳しく書かれているが、長くなるのでリンク先を参照されたし。)
現代では、
ネットワーク上を流れる文字データはUTF-8/16などに固まりつつあるけれど、
通信の根幹を成す部分の抜本的改革は起こらず、今もなお8bitベースのまま、
この先いつまで続くかも判らないのが現状であり、URLエンコードはまだまだ、
必須ということになる。(新しい勧告として 2005年1月に RFC3986 が、
出ているがURLエンコードが必要な事に変わりは無い。)
RFCの日本語訳は下記に沢山あります。
回答ありがとうございます。
まずは、歴史的に8bitベースで出来たわけですね。最初からマルチバイトコードを意識していれば、Shift-JISだろうが、UTF-8/16だろうが送れたが、そうはならなかったと。
それは理解できたのですが、8bitベースで解釈しているものがshift-jisのものを読み取ろうとした場合、
どのような不具合が起こるのでしょうか?そして、それは何故起こるのでしょうか?
そういったところが、知りたいです。
「どのような不具合が起こるのでしょうか?そして、それは何故起こるのでしょうか?」
・・・#1の方の上げた資料の一部に次のようにあります。
>D.1.2 デコードする方法
> ・・・
>•改行は「復帰(0x0D) + 行送り(0x0A) 」なのでプラットフォームに従った改行に変換する.
で、2バイト文字(漢字)ならば、第2バイト目が0Dの文字があります。そうすると、
(エスケープしていないと)それは1バイト目のASCII+「復帰」とみなされてしまいます。
このように、「エスケープさせること」で、第2バイトを組にしたデコードを確実にさせます。
おぉ。自分の求めていた、そして何となくイメージしていた答えです!
だいぶ疑問が解けましたー...っと思っていたのですが、
kn1967さんの回答で、また違った様相を呈してきました。
何はともあれ、回答ありがとうございます!
>最初からマルチバイトコードを意識していれば
当時の遠隔地への通信速度は一秒間に数百bit(現在の1万分の一程度)で、
アルファベットでも1秒間に数文字を送るのがやっとでしたし、
日本でもASCII+カタカナが関の山でした。
その後、マルチバイトに関しては、各国でバラバラに実装が進み、
日本でも漢字を含んだJISコードとしてまとめられ、互換性の問題で、
Shift-JISとして今も多様されています。(日本語の文字コードは、
他にもいくつか存在しますが、本題ではないので、割愛します。)
その後、UNICODEの最初のバージョンが出たのが1991年。
今でもまだUNICODEへの完全移行は成しえていません。
>8bitベースで解釈しているものがshift-jisのものを読み取ろうとした場合
URLエンコード/デコードの必要性はマルチバイトだからという理由ではないです。
(「2バイトコード(漢字)や記号を扱えない」という類の回答はミスリードの、
原因となっています。ひとまず忘れましょう。)
例えば、半角スペースだって置き換えが行われています。この意味は、
RFC1738で「URL文字符号化問題」として下記のような具合で説明されています。
http://www5d.biglobe.ne.jp/~stssk/nro/rfc1738_j.txt
URLとは文字の連続である。即ち文字、数字および特別な文字である。URLは様々な
方法で表される。例えば紙の上のインクか、またはコード化された文字セットによ
る8ビット値の連続によってである。URLの解析は用いられている文字の一致のみに
依存する。
紙に書く事を考えれば「印字可能なもののみ」というのは当然ですね。
「ここで改行」とか「ここでTAB」とか全部紙に書かれてたらウザイです(笑)
少し話はそれますが、HTMLでは先頭の空白は消されて左によったりしますよね?
これは、余計な空白として扱われてしまうからで、どうしてもそこに空白を、
入れたい場合は&nbsp;(&は本当は半角)といった具合に別の手段を用います。
これと同じ事がURLの場合にもあり半角スペースは + という記号に置き換わります。
他にも同様の理由でエンコード/デコードが必要になっています。その説明箇所が、
下記なのですが、確かにちょっと判り辛いかもしれませんね。
文字は幾つかの理由により安全ではなくなる。空白文字が安全でない理由は、ワー
プロソフト類の処理によってURLが翻訳・活字化されることにより、重要なスペー
スが消えたり、重要でない空白が挿入されるからである。
"<"と">"の文字が安全ではないのは、これらが自由なテキストにおいてURLの区切
りとして用いられるからであり、引用符(""")はあるシステムにおいて区切りとし
て用いられているからである。World Wide Webや他のシステムにおいて、"#"文字
はこの後に続くフラグメントやアンカー識別子からURLを区切る為に用いられるの
で安全ではなく、常に符号化するべきである。"%"文字は他の文字を符号化するた
めに用いられるので安全ではない。他の文字はゲートウェイや転送エージェントに
よって時々これらの文字を変更する場合があることが知られているので、安全では
ない。その文字は"{"、"}"、"|"、"\"、"^"、"~"、"["、"]"及び"`"である。
以上のように、そもそもの成り立ちからしてエスケープが必要であり、
そこにさらにマルチバイトの問題が折り重なってきているという構図になっています。
質問はURLエンコード/デコードの歴史的背景という事なので、
日本語の文字化け等については、言及しないでおきますが、マルチバイト問題と、
URLエンコード/デコードとは一旦は切り離して考えないと頭が混乱するという事です。
丁寧な回答ありがとうございます!
>(「2バイトコード(漢字)や記号を扱えない」という類の回答はミスリードの、
>原因となっています。ひとまず忘れましょう。)
そうだったのですか!?
完全に予想の斜め上です!
示してくださった説明箇所ですが、自分には難しくて所々分からないのですが、今回、自分が疑問に感じていたことはだいぶクリアになりました。自分なりの言葉でまとめてみると、
URLに使っちゃいけない、unsafeな文字ってのは、いっぱいある。
例えばURLに空白なんかが使われたら、ついつい見逃しちゃったりするし、<, >, ", は区切りとして使われがちだから、そんなんがURLに使われたら、区切りなのかURLそのものなのか紛らわしいし、ついでにゲートウェイや転送エージェントは特定の文字を勝手に変更することがあるし、それらの文字は総じてunsafeであると。
なので、そんなunsafeな文字を使いたかったら(% + 2つの16進数)で表しなさいよ。
ってことになったんですね。
マルチバイト文字を使おうとすると、それらはunsafeなコードも含むので、結果としてURLエンコーディングが必要ということでしょうか。自分は、そう理解しました。
理解が深まりました。ありがとうございます!
丁寧な回答ありがとうございます!
>(「2バイトコード(漢字)や記号を扱えない」という類の回答はミスリードの、
>原因となっています。ひとまず忘れましょう。)
そうだったのですか!?
完全に予想の斜め上です!
示してくださった説明箇所ですが、自分には難しくて所々分からないのですが、今回、自分が疑問に感じていたことはだいぶクリアになりました。自分なりの言葉でまとめてみると、
URLに使っちゃいけない、unsafeな文字ってのは、いっぱいある。
例えばURLに空白なんかが使われたら、ついつい見逃しちゃったりするし、<, >, ", は区切りとして使われがちだから、そんなんがURLに使われたら、区切りなのかURLそのものなのか紛らわしいし、ついでにゲートウェイや転送エージェントは特定の文字を勝手に変更することがあるし、それらの文字は総じてunsafeであると。
なので、そんなunsafeな文字を使いたかったら(% + 2つの16進数)で表しなさいよ。
ってことになったんですね。
マルチバイト文字を使おうとすると、それらはunsafeなコードも含むので、結果としてURLエンコーディングが必要ということでしょうか。自分は、そう理解しました。
理解が深まりました。ありがとうございます!