[#32945] Shift_JIS variants and UTF-16 support — "U.Nakamura" <usa@...>

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

22 messages 2008/01/07
[#32953] Re: Shift_JIS variants and UTF-16 support — Martin Duerst <duerst@...> 2008/01/07

中村さん、こんにちは。

[#32955] Re: Shift_JIS variants and UTF-16 support — Yukihiro Matsumoto <matz@...> 2008/01/07

まつもと ゆきひろです

[#32959] Re: Shift_JIS variants and UTF-16 support — "NARUSE, Yui" <naruse@...> 2008/01/07

成瀬です。

[#32960] Re: Shift_JIS variants and UTF-16 support — Yukihiro Matsumoto <matz@...> 2008/01/07

まつもと ゆきひろです

[#32992] ASCII is alias of US-ASCII; replica of dummy encoding is not a dummy — "NARUSE, Yui" <naruse@...>

成瀬です。

18 messages 2008/01/08
[#32994] Re: ASCII is alias of US-ASCII; replica of dummy encoding is not a dummy — Yukihiro Matsumoto <matz@...> 2008/01/09

まつもと ゆきひろです

[#32995] Re: ASCII is alias of US-ASCII; replica of dummy encoding is not a dummy — Martin Duerst <duerst@...> 2008/01/09

At 18:13 08/01/09, Yukihiro Matsumoto wrote:

[#33011] Re: ASCII is alias of US-ASCII; replica of dummy encoding is not a dummy — "NARUSE, Yui" <naruse@...> 2008/01/11

成瀬です。

[#33012] Re: ASCII is alias of US-ASCII; replica of dummy encoding is not a dummy — Yukihiro Matsumoto <matz@...> 2008/01/11

まつもと ゆきひろです

[#33014] Re: ASCII is alias of US-ASCII; replica of dummy encoding is not a dummy — "NARUSE, Yui" <naruse@...> 2008/01/11

成瀬です。

[#33015] Re: ASCII is alias of US-ASCII; replica of dummy encoding is not a dummy — Yukihiro Matsumoto <matz@...> 2008/01/11

まつもと ゆきひろです

[#33239] Re: [ruby-cvs:22386] Ruby:r15149 (trunk): * string.c (rb_str_each_char): move forward. — Tanaka Akira <akr@...>

In article <200801210259.m0L2x3CW017171@ci.ruby-lang.org>,

11 messages 2008/01/21
[#33240] Re: [ruby-cvs:22386] Ruby:r15149 (trunk): * string.c (rb_str_each_char): move forward. — Nobuyoshi Nakada <nobu@...> 2008/01/21

なかだです。

[#33303] Time#strftimeのエンコーディング — rubikitch@...

るびきちです。

13 messages 2008/01/23
[#33305] Re: Time#strftimeのエンコーディング — Yukihiro Matsumoto <matz@...> 2008/01/23

まつもと ゆきひろです

[#33368] summary of script encoding — "U.Nakamura" <usa@...>

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

22 messages 2008/01/25
[#33375] Re: summary of script encoding — Yukihiro Matsumoto <matz@...> 2008/01/25

まつもと ゆきひろです

[#33376] Re: summary of script encoding — "U.Nakamura" <usa@...> 2008/01/25

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

[#33387] HashからStructを作る — rubikitch@...

るびきちです。

19 messages 2008/01/25
[#33455] Re: HashからStructを作る — Yukihiro Matsumoto <matz@...> 2008/01/28

まつもと ゆきひろです

[#33505] Re: HashからStructを作る — rubikitch@... 2008/01/29

From: Yukihiro Matsumoto <matz@ruby-lang.org>

[#33507] Re: HashからStructを作る — Yukihiro Matsumoto <matz@...> 2008/01/29

まつもと ゆきひろです

[#33508] Re: HashからStructを作る — rubikitch@... 2008/01/29

From: Yukihiro Matsumoto <matz@ruby-lang.org>

[#33433] Win32OLE: set encoding to OLE string — "U.Nakamura" <usa@...>

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

16 messages 2008/01/28

[#33461] Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — MORITA Hideyuki <h-morita@...>

=1B$B?9ED$H?=3D$7$^$9!#=1B(B

19 messages 2008/01/28
[#33473] Re: Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — Nobuyoshi Nakada <nobu@...> 2008/01/28

なかだです。

[#33503] Re: Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — MORITA Hideyuki <h-morita@...> 2008/01/29

森田です。

[#33514] Re: Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — Nobuyoshi Nakada <nobu@...> 2008/01/29

なかだです。

[#33518] Re: Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — MORITA Hideyuki <h-morita@...> 2008/01/30

森田です。

[#33545] Re: Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — Ryutaro Amano <wn9r-amn@...> 2008/01/31

天野竜太郎と申します。

[#33546] Re: Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — MORITA Hideyuki <h-morita@...> 2008/01/31

森田です。

[#33547] Re: Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — Ryutaro Amano <wn9r-amn@...> 2008/01/31

天野です。

[#33551] Re: Failed to make ruby-1.8.6-p111 on MacOSX 10.5(Leopard) — MORITA Hideyuki <h-morita@...> 2008/01/31

森田です。

[#33488] 現在の script encoding の値を得る方法は? — Hidetoshi NAGAI <nagai@...>

永井@知能.九工大です.

20 messages 2008/01/29
[#33491] Re: 現在の script encoding の値を得る方法は? — Yukihiro Matsumoto <matz@...> 2008/01/29

まつもと ゆきひろです

[#33500] Re: 現在の script encoding の値を得る方法は? — Hidetoshi NAGAI <nagai@...> 2008/01/29

永井@知能.九工大です.

[#33501] Re: 現在の script encoding の値を得る方法は? — "NARUSE, Yui" <naruse@...> 2008/01/29

成瀬です。

[#33515] Re: 現在の script encoding の値を得る方法は? — Hidetoshi NAGAI <nagai@...> 2008/01/30

永井@知能.九工大です.

[#33516] Re: 現在の script encoding の値を得る方法は? — "NARUSE, Yui" <naruse@...> 2008/01/30

成瀬です。

[#33519] Re: 現在の script encoding の値を得る方法は? — Hidetoshi NAGAI <nagai@...> 2008/01/30

永井@知能.九工大です.

[#33522] Re: 現在の script encoding の値を得る方法は? — "NARUSE, Yui" <naruse@...> 2008/01/30

成瀬です。

[ruby-dev:33123] Re: Binary String

From: "NARUSE, Yui" <naruse@...>
Date: 2008-01-15 12:09:23 UTC
List: ruby-dev #33123
成瀬です。

Hidetoshi NAGAI wrote:
>> ソースをざっと見ただけなので間違っているかもしれませんが、本当にそうです
>> か。tk_call_without_enc とかの binary 版を作れば解決したりしませんかね。
> 
> ダメだと思います.
> 
> ソースをご覧になったのであればご承知とは思いますが,
> tk_call_without_enc は,ascii のみと分かっているか,
> あるいはすでに UTF-8 (または binary string) に変換済で
> それ以上の変換が必要がない場合に使えるものです.
> 結局はいずれかの段階で,Tk に渡すトークンごとに
> どのように変換するかを決めてやる必要があります.
> binary なのかを判断してやらねばなりません.

あぁ、tk_call_without_enc は変換しないんですね。それでは、バイナリデータ
を要求するメソッドでは tk_call_without_enc を使えば意図しない変換は行わ
れないんじゃないですか?

> Ruby 1.9 で,magic comment がなければ ASCII-8BIT になり
> binary == ASCII-8BIT とするのであるならば,
> これまで動いていた Ruby 1.8 のスクリプトに対しては
> 次のようになると思います.
> 
> (1) これまでと同様に動くようにするため,
>     Ruby 1.8 と同様に binary を明示する情報を付与する.
> 
>     せっかく encoding 情報を持つようになったのに,
>     それを利用しないという方法です.
>     でも,一般ユーザは ASCII-8BIT を binary として
>     使おうとするかもしれません.
>     似て異なる情報を持たせねばならないという
>     気持ちの悪い状況ではあります.

BINARY を定義したのにユーザーが ASCII-8BIT をバイナリとして用いるケース
を想定していらっしゃいますか?

> (2) Ruby 1.8 で動いていた Ruby/Tk のソースは
>     文字化けしてしまうのというのを諦めてもらう.
> 
>     ソースの互換性を捨ててしまうという対応です.
>     動かしたければ,適切な magic comment の付与が必要です.
>     このような互換性は捨ててしまうべきという意見もありそうですが,
>     私は,不可能でない限りは互換性を極力維持したいと
>     考える方ですので,心情としてはかなり辛い選択です.
> 
> 不明時の encoding である ASCII-8BIT と区別できるような 
> binary encoding が存在しさえすれば互換性維持ができると思ってます.
> そのために導入をお願いしてきたわけですが,
> どうしても binary encoding を加えるつもりはないということであれば,
> 非常に残念ですが上記の (2) を選択することにします.

えーっと、まず、1.9 では Kernel#* がいくつか消えていたり、多重代入に変更
が入ったり、、、string[i] が 文字を返すようになったりといった非互換な変
更が大量に入っているので、既存のスクリプトが修正なしに Ruby 1.9 で動くと
いうことはある程度の規模ならばまずあり得ないと思います。よって、1.8 向け
のコードがそのまま動くというのはもとより諦めていただかねばなりません。

magic comment を定義しないことによる問題については定義してくださいの一言
です。magic comment が未定義なことに由来する不都合はユーザー側の責任で
しょう。どうも、magic comment の意義を過小評価していらっしゃるようです
が、magic comment なしで自動推測によってかろうじて動いていたコードは、別
の環境に持って行ったら化けるんですよ?そんなコードが許されるはずがない
じゃないですか。

> というわけで,本当に最後の質問です.
> binary encoding 導入,または ASCII-8BIT と UNKNOWN-8BIT の区別は
> どうしてもダメですか?

え、これで最後なんですか?まだ、永井さんはどこに問題があるのかを把握して
いらっしゃらないように思われます。問題を把握できていない方の修正案ではそ
の問題が本当に解決できるのかわかりませんし、わたしは binary encoding 導
入では問題の解決はできないと考えています。

田中さんも仰られていますが、「具体的な問題の例」言い換えればテストケース
があると理解しやすいように思います。ある種の極限状態——ユーザからもTcl/Tk
自体からもデータを受け取り、そのデータはバイナリデータのこともテキスト
データのこともあるというメソッドが存在し、さらに受け取るテキストデータが
ASCII-8BIT のままである正当な理由があるケース——がもし存在するならば
BINARY が必要な可能性がありますが、わたしはそういうケースは実際には存在
しないと考えています。反証があれば考えを改めさせていただきます。

とりあえず、
* locale 非対応→Ruby が対応すればいいだけ
* magic comment がない→つけてください
なので、これ以外ですかね。

-- 
NARUSE, Yui  <naruse@airemix.com>
DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA

In This Thread