[#31928] securerandom.rb for 1.8 — Tanaka Akira <akr@...>

securerandom.rb を 1.8 に追加し、cgi/session.rb に使わせたい

18 messages 2007/10/03
[#31990] Re: securerandom.rb for 1.8 — "Akinori MUSHA" <knu@...> 2007/10/09

At Wed, 3 Oct 2007 12:49:20 +0900,

[#31992] Re: securerandom.rb for 1.8 — Tanaka Akira <akr@...> 2007/10/09

In article <86k5pwinco.knu@iDaemons.org>,

[#31993] Re: securerandom.rb for 1.8 — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/10/09

-----BEGIN PGP SIGNED MESSAGE-----

[#31936] Rake添付 — Yukihiro Matsumoto <matz@...>

まつもと ゆきひろです

21 messages 2007/10/04
[#31937] Re: Rake添付 — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/10/04

-----BEGIN PGP SIGNED MESSAGE-----

[#31938] Re: Rake添付 — Yukihiro Matsumoto <matz@...> 2007/10/04

まつもと ゆきひろです

[#31941] Re: [ruby-list:44071] Re: Ruby 1.8.6-p111 / 1.8.5-p114 released (Security Fix) — Shugo Maeda <shugo@...>

前田です。

20 messages 2007/10/04
[#31943] Re: [ruby-list:44071] Re: Ruby 1.8.6-p111 / 1.8.5-p114 released (Security Fix) — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/10/05

-----BEGIN PGP SIGNED MESSAGE-----

[#31945] Re: [ruby-list:44071] Re: Ruby 1.8.6-p111 / 1.8.5-p114 released (Security Fix) — Shugo Maeda <shugo@...> 2007/10/05

前田です。

[#31948] Re: [ruby-list:44071] Re: Ruby 1.8.6-p111 / 1.8.5-p114 released (Security Fix) — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/10/05

-----BEGIN PGP SIGNED MESSAGE-----

[#31952] Re: [ruby-list:44071] Re: Ruby 1.8.6-p111 / 1.8.5-p114 released (Security Fix) — Shugo Maeda <shugo@...> 2007/10/05

前田です。

[#31956] Re: [ruby-list:44071] Re: Ruby 1.8.6-p111 / 1.8.5-p114 released (Security Fix) — GOTOU Yuuzou <gotoyuzo@...> 2007/10/06

In message <47063403.3070402@ruby-lang.org>,

[#31960] Re: [ruby-list:44071] Re: Ruby 1.8.6-p111 / 1.8.5-p114 released (Security Fix) — GOTOU Yuuzou <gotoyuzo@...> 2007/10/07

In message <20071006.101915.596518898.gotoyuzo@sawara.priv.tokyo.netlab.jp>,

[#31980] multibyte string/regex literal with escape sequence — "U.Nakamura" <usa@...>

こんにちは、なかむら(う)です。

24 messages 2007/10/09
[#31981] Re: multibyte string/regex literal with escape sequence — Yukihiro Matsumoto <matz@...> 2007/10/09

まつもと ゆきひろです

[#31983] Re: multibyte string/regex literal with escape sequence — "U.Nakamura" <usa@...> 2007/10/09

こんにちは、なかむら(う)です。

[#31984] Re: multibyte string/regex literal with escape sequence — Yukihiro Matsumoto <matz@...> 2007/10/09

まつもと ゆきひろです

[#31986] Re: multibyte string/regex literal with escape sequence — "U.Nakamura" <usa@...> 2007/10/09

こんにちは、なかむら(う)です。

[#31987] Re: multibyte string/regex literal with escape sequence — Yukihiro Matsumoto <matz@...> 2007/10/09

まつもと ゆきひろです

[#32003] Re: multibyte string/regex literal with escape sequence — "U.Nakamura" <usa@...> 2007/10/10

こんにちは、なかむら(う)です。

[#32133] undefined method `now' for DateTime:Class (NoMethodError) — "NAKAMURA, Hiroshi" <nakahiro@...>

-----BEGIN PGP SIGNED MESSAGE-----

12 messages 2007/10/23
[#32135] Re: undefined method `now' for DateTime:Class (NoMethodError) — tadf@... 2007/10/23

どういう状況かよくわかってないのですが、いっそ必ず date 丸ごと読むようにするか、

[#32136] Re: undefined method `now' for DateTime:Class (NoMethodError) — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/10/23

-----BEGIN PGP SIGNED MESSAGE-----

[ruby-dev:32056] Re: multibyte string/regex literal with escape sequence

From: "U.Nakamura" <usa@...>
Date: 2007-10-14 17:13:15 UTC
List: ruby-dev #32056
こんにちは、なかむら(う)です。

In message "[ruby-dev:32042] Re: multibyte string/regex literal with escape sequence"
    on Oct.13,2007 01:54:44, <akr@fsij.org> wrote:
| > 「わかる」ことはそれ自体嬉しいことだと思うのですが、それじゃ
| > 弱いということですかね。
| 
| しばらく考えていたのですが、「わかる」ということは「意識しな
| ければならない」ということでもあります。
| 
| たとえば G というものを考えると、LATIN CAPITAL LETTER G とい
| う文字を表現したいのか 0x47 というバイトを表現したいのか常に
| 意識する必要があります。
| 
| それを意識すべきだ、という主張なのだとは思うのですが、あんま
| り意識しない慣習があるのもたしかだと思います。

なんか既に成瀬さんから意見が出て話が進んでるようですが、私が
「バイナリ」という言葉で意図していたのは、今のASCII-8BITとい
う名前で示されているものでした。
つまり、何が「わかる」と嬉しかったのかというと、
  * ある文字列に8bit目が立っているデータが含まれていること
  * しかしそれは現在デフォルトとなっているエンコーディングの
    文字列というわけではないということ
が「わかる」と嬉しい、という意味でした。

あの話を出した前後では、
  * US-ASCIIというエンコーディング名の文字列が8bitデータを含
    むことがあり、
  * US-ASCIIを名乗る文字列が相互に連結できないことがあるがエ
    ンコーディング名からはそれを事前に知る方法がなく、
  * さらに話の流れによっては8bitデータを含む文字列はデフォル
    トのエンコーディング(例えばEUC-JPとか)として扱われる方向
    になるかもしれなかった
という状況でした。

まだいろいろどうなるかわかってないんですが、とりあえず私が懸
念していた点に関しては、ASCII-8BITというエンコーディング名が
導入されたことと、今後US-ASCIIが別の形で定義されそうだという
ことから、今はあんまり不安視はしていません。


| ASCII とバイナリを完全に分離するということは、このような表現
| をプログラム上で行うときにはその表現が ASCII を前提としたも
| のであることを陽に記述しなければならないことを意味します。
| 
| たとえば、/\AGIF/ =~ image とかは動かないわけです。
| image がバイナリとすれば、内部に LATIN CAPITAL LETTER G とい
| う文字は存在し得ないわけですから。
| 
| それでもそれが正しいという主張はたしかにあり得ると思いますし、
| 非 ASCII 環境 (EBCDIC とか) に対してもポータブルになる利点は
| 考えられるとは思うのですが、それって ASCII を前提にした表現
| の慣習を捨てるほど嬉しいものなんですかね?

まさにその田中さんと同じ懸念から、ASCII-8BITとは別のBINARYと
いうエンコーディングを導入する必要はないのではないかと思いま
す。
# どうも自分の主張に筋が通ってない気もする


それでは。
-- 
U.Nakamura <usa@garbagecollect.jp>



In This Thread