正己の異論・反論

ついっぷるでツイートするためのブックマークレット

正己 — Fri, 02 Mar 2012 22:51:47 +0900

　私のブログにもあるが、最近では多くのサイトにそのサイトについてTwitterでツイートするためのリンクが用意されている。しかし、リンクが用意されてないサイトもあり、そのために【共有ブックマークレット】が用意されている。この「Share on Twitter」というリンクをFirefoxならブックマークツールバーに、Internet Explorer(IE)なら「お気に入りバー」に設置し、例えば私のブログを見ている状態でクリックすると、「リンクをあなたのフォロワーに共有する」と書いてある下の入力欄に「正己の異論・反論：So-net blog http://self.blog.so-net.ne.jp/」と入力されたウィンドウが開く。前半が見ているサイトのtitleで、後半が見ているサイトのURLである。ここで、そのままか文章を追加してから「ツイート」ボタンをクリックするとTwitterに投稿できる。
　「共有ブックマークレット」は便利だと思うが、私は自動的に入力されている文字列が「title URL」だけであることが不満で、「→【title】 URL」となるように、自分でブックマークレットを作った。それは最終的には次のリンクになった。

ツイート（Firefox 10.0.2用）

（追記：2012/3/5：２ちゃんねるのページに対してはエラーになりましたので修正しました。）

Twitterでつぶやく（IE8用）

　上のブックマークレットは私の環境では問題なく動作しているようだが、他の人の環境で動作するか分からないし、私の環境でも今後は分からない。そもそも「→【title】 URL」という形の自動入力は私の好みだから、他の人は【共有ブックマークレット】の方を使った方が良いだろう。

　実は、上のブックマークレットを作ったのは今日で、以前は別のJavascriptだった。Twitterを使ってツイートする場合は古いブックマークレットでも問題なかったのだが、ついっぷるでツイートするためのブックマークレットで問題が生じたので、それに合わせてTwitterでツイートするブックマークレットの方も修正した。

　【共有ブックマークレット】を使って【内閣 (日本) - Wikipedia】のページを試してほしい。入力欄に次のように入力されているだろう。

内閣 (日本) - Wikipedia http://ja.wikipedia.org/wiki/%E5%86%85%E9%96%A3_(%E6%97%A5%E6%9C%AC)

　この状態で「ツイート」ボタンをクリックすればURLは自動的に短縮URL「t.co」に変換される（参照）。その短縮URLで【内閣 (日本) - Wikipedia】にジャンプする。
　しかし、ついっぷるの入力欄に上記のように入力されていて「URL短縮」がチェックされた状態でツイートすると例えば次のようにbit.lyで短縮される（参照）。

http://bit.ly/zNHIlj(%E6%97%A5%E6%9C%AC)

　"("から後ろをURLの一部とみなさずに短縮したようである。この現象は2010年7月18日に気づいて（参照）2010年9月19日に報告して（参照）2010年10月4日に要望を出した（参照）のだが修正される気配がない。仕方ないのでユーザーが対処するしかない。
　例えば、【内閣 (日本) - Wikipedia】については入力欄に次のように入力されていれば良い。

内閣 (日本) - Wikipedia http://ja.wikipedia.org/wiki/%E5%86%85%E9%96%A3_%28%E6%97%A5%E6%9C%AC%29

　"("が"%28"に、")"が"%29"にエンコードされている。Firefoxではアドレスバーからコピーすればエンコードされて張り付けられるようになるが、できればブックマークレットをクリックして自動的に入力されるようにしたい。しかし、【共有ブックマークレット】を使った結果と同様に、通常は"("や")"はエンコードされない。JavascriptではencodeURIComponent()を使ってエンコードする方法が一般的だが、それでは"("や")"はエンコードされない。Googleで検索して次のような情報を見つけた。

If one wishes to be more stringent in adhering to RFC 3986 (which reserves !, ', (, ), and *), even though these characters have no formalized URI delimiting uses, the following can be safely used:

function fixedEncodeURIComponent (str) {
return encodeURIComponent(str).replace(/!/g, '%21').replace(/'/g, '%27').replace(/$/g, '%28').
replace(/$/g, '%29').replace(/\*/g, '%2A');
}

（encodeURIComponent - MDN）

　要するに、encodeURIComponent()でエンコードした後に"("や")"などを"%28"や"%29"などに置換すれば良いらしい。

　まずは、JSActionsのスクリプトで試した。しかし、"("や")"は"("や")"のままで"%28"や"%29"と表示されない。試行錯誤の末に「"("や")"はreplaceで"%28"や"%29"に置換されてはいるがアドレバーに表示された時にデコードされて"("や")"に戻ってしまう」ということに気づいた。そこで、JSActionsのスクリプトでは"("や")"をreplaceで"%2528"や"%2529"に置換して、ようやくついっぷるの入力欄に例えば次のように自動的に入力されるスクリプトを作ることができた。

→【内閣 (日本) - Wikipedia】 http://ja.wikipedia.org/wiki/%E5%86%85%E9%96%A3_%28%E6%97%A5%E6%9C%AC%29

　JSActionsのスクリプトを利用してブックマークレットも簡単に作れるかと思ったのだが、"("や")"を"%2528"や"%2529"に置換するだけではダメで、"%252528"や"%252529"に置換しなければいけないらしい。そんな試行錯誤の結果、ようやく、ついっぷるでツイートするためのブックマークレットを作ることができた。

ツイート（Firefox 10.0.2用）

（追記：2012/3/5：２ちゃんねるのページに対しては文字化けしたので修正しました。）

ついっぷるでつぶやく（IE8用）

　私が利用するのはFirefoxだが、ブログに書くのでIE8用も作ってみた。全角文字の扱い方がFirefoxとIE8とで異なるので戸惑ったが、とりあえず作ってみた。バグがあったら修正する予定である。

　Firefoxの方は最初は次のようなソースだった。

javascript:(function(){
if(document.getSelection()!=""){var%20str0="→「"+document.getSelection()+"」";}
else{var%20str0="→";};
var%20str1="【"+document.title+"】";
var%20str=str0+str1;
var%20url=document.location.href;
url=encodeURIComponent(url).replace(/!/g,"%252521").replace(/'/g,"%252527").replace(/$/g,"%252528").replace(/$/g,"%252529").replace(/\*/g,"%25252A");
window.open("http://twipple.jp/?text="+encodeURIComponent(str)+"%20"+url);
})();
（ブックマークレットにするときは改行コードを削除）

　しかし、ブックマークレットのURL欄にコピーしたら全角文字が自動的にエンコードされて次のようになった。

javascript:(function(){
if(document.getSelection()!=""){var%20str0="%E2%86%92%E3%80%8C"+document.getSelection()+"%E3%80%8D";}
else{var%20str0="%E2%86%92";};
var%20str1="%E3%80%90"+document.title+"%E3%80%91";
var%20str=str0+str1;
var%20url=document.location.href;
url=encodeURIComponent(url).replace(/!/g,"%252521").replace(/'/g,"%252527").replace(/$/g,"%252528").replace(/$/g,"%252529").replace(/\*/g,"%25252A");
window.open("http://twipple.jp/?text="+encodeURIComponent(str)+"%20"+url);
})();
（ブックマークレットにするときは改行コードを削除）

　エンコードした文字をさらにencodeURIComponent(str)とエンコードするのは気持ちが良くないので、最終的にencodeURIComponent()ではdocument.titleだけをエンコードする次のスクリプトになった。（追記：2012/3/5：document.titleだけをエンコードする次のスクリプトでは一部のサイトで文字化けが生じたので、encodeURIComponent(str)の方のスクリプトの方が良いかもしれません。上のついっぷる用のブックマークレット（Firefox用）は修正しました。）

javascript:(function(){
if(document.getSelection()!=""){var%20str0="%E2%86%92%E3%80%8C"+document.getSelection()+"%E3%80%8D";}
else{var%20str0="%E2%86%92";};
var%20str1="%E3%80%90"+encodeURIComponent(document.title)+"%E3%80%91";
var%20str=str0+str1;
var%20url=document.location.href;
url=encodeURIComponent(url).replace(/!/g,"%252521").replace(/'/g,"%252527").replace(/$/g,"%252528").replace(/$/g,"%252529").replace(/\*/g,"%25252A");
window.open("http://twipple.jp/?text="+str+"%20"+url);
})();
（ブックマークレットにするときは改行コードを削除）

　document.titleが既にエンコードされているのならencodeURIComponent()でさらにエンコードするのは気持ちが良くないので、エンコードしない次のスクリプトの方が良いかもしれない。今のところ、Firefoxでは、どれも問題がないようだが…。

javascript:(function(){
if(document.getSelection()!=""){var%20str0="%E2%86%92%E3%80%8C"+document.getSelection()+"%E3%80%8D";}
else{var%20str0="%E2%86%92";};
var%20str1="%E3%80%90"+document.title+"%E3%80%91";
var%20str=str0+str1;
var%20url=document.location.href;
url=encodeURIComponent(url).replace(/!/g,"%252521").replace(/'/g,"%252527").replace(/$/g,"%252528").replace(/$/g,"%252529").replace(/\*/g,"%25252A");
window.open("http://twipple.jp/?text="+str+"%20"+url);
})();
（ブックマークレットにするときは改行コードを削除）

　IE8用はよく分からなかった。
　まず、document.getSelection()は使えなかったのでdocument.selection.createRange().textに変えた。
　次に、window.open()を使ったらポップアップブロックに邪魔されたのでlocation.href=""に変えた。
　一番分からなかったのは、全角文字の扱いで、Firefox用の上のスクリプトのwindow.open()やdocument.getSelection()を変えただけでは文字化けが生じた。
　そこで、最終的に次のスクリプトになった。

javascript:(function(){
if(document.selection.createRange().text!=""){var%20str0="→「"+document.selection.createRange().text+"」";}
else{var%20str0="→";};
var%20str1="【"+document.title+"】";
var%20str=str0+str1;
var%20url=document.location.href;
url=encodeURIComponent(url).replace(/!/g,"%252521").replace(/'/g,"%252527").replace(/$/g,"%252528").replace(/$/g,"%252529").replace(/\*/g,"%25252A");
location.href="http://twipple.jp/?text="+encodeURIComponent(str)+"%20"+url;
})();
（ブックマークレットにするときは改行コードを削除）

　encodeURIComponent(str)で全角文字とdocument.titleをエンコードすることは必要らしく、document.titleだけをencodeURIComponent()でエンコードしたり、全角文字を最初からエンコードして記述してdocument.titleだけをencodeURIComponent()でエンコードしても文字化けが起こった。全角文字を最初からエンコードして記述してdocument.titleをencodeURIComponent()でエンコードしない状態でも文字化けが起こった。結局、全角文字の所は最初からエンコードして記述するのではなくencodeURIComponent()でエンコードする必要があるのかもしれない。全角文字をencodeURIComponent()でエンコードしてdocument.titleはエンコードしないスクリプトは試してない。上記のスクリプトを改変する際に面倒だからである。Firefoxのように全角文字を最初からエンコードして記述してはダメな理由がよく分からないが…。

　今回は"("や")"をブックマークレットで"%28"や"%29"にエンコードする方法を見つけるのに苦労した。Googleで検索しても答が見つからなかったので、私と同じようにGoogle検索で答を見つけようとする人がいたら、その人の役に立てればとブログに記録を残した。参考になれば幸いである。

　ちなみに、このブログに用意したブックマークレット（リンク）では「replace(/'/g,"%252527")」を「replace(/%27/g,"%252527")」にしてある。「a href=''」の中に「'」があると問題が生じるし、「a href=''」ではなく「a href=""」にすると、その中に「"」が存在するので問題が生じる。結局は、「a href=''」にしても「a href=""」にしても、その中に「'」と「"」の両方が存在して問題が生じるので、「'」を「%27」に置き換えて記述することにした。

A4やB5の紙の長辺を３等分する方法の確認の補足

正己 — Sat, 22 Oct 2011 14:43:00 +0900

　【A4やB5の紙の長辺を３等分する方法の確認】で私は次のように書いた。

重要なのはＥの位置である。頂点Ｄを対辺ＢＣの中点Ｑに合わせるように折り曲げたら、折れ線と長辺ＡＤの接点Ｅが偶然ＡＤの1/4の位置になったかのようである。これは「長辺で半分に折り曲げた後の短辺と長辺の比が折り曲げる前の短辺と長辺の比に等しい」という紙の寸法の規格（参照）により生じたものらしい。
（A4やB5の紙の長辺を３等分する方法の確認）

　「Ｅの位置」とは次の図のＥの位置である。

図１

　このＥの位置がＡＤの1/4の位置になることは証明できる。ただし、引用文のように「長辺で半分に折り曲げた後の短辺と長辺の比が折り曲げる前の短辺と長辺の比に等しい」すなわち「長辺が短辺の倍である」という条件の下である。
　下の図のように座標を用いることで容易に証明できる。

（クリックで拡大）
図２

　長辺が短辺の1/aの紙（短辺が長辺のa倍の紙）を長方形ＡＢＣＤとし、各頂点の座標をＡ(0,1)、Ｂ(a,1)、Ｃ(a,0)、Ｄ(0,0)とする。線分ＡＤの中点はＰ(0,1/2)、線分ＢＣの中点はＱ(a,1/2)である。ＤとＱを重ねるように折り曲げた時の折れ線は線分ＥＦで、Ｅのｙ座標をbとする。a=の時に b=3/4 になることを証明すれば良い。
　直線ＥＦの方程式②は直線ＤＱ（方程式は①）と直角に交わることから傾きが分かり、線分ＤＱの中点Ｓ(a/2,1/4)を通ることで求められるので、bは次のようになることがすぐに分かる。

　aにを代入すれば、b=3/4 になる。逆に b=3/4 になるのは a=、すなわち長辺が短辺の倍の場合だけである。

　次にＤをＱに重ねることでＰが移ったＲのｙ座標が2/3になるためのaの値を確認する。
　線分ＥＤが移った線分ＥＱを通る直線の方程式③はＥ(0,b)、Ｑ(a,1/2)を通ることから求められる。直線ＰＲの方程式④は直線ＤＱと傾きが同じでＰ(0,1/2)を通ることから求められる。Ｒの座標は直線ＥＱと直線ＰＲの交点だから「③=④」から求められ、次のようになる。

　aにを代入すればＲのｙ座標が2/3になることが分かり、逆にＲのｙ座標が2/3になるのは a=、すなわち長辺が短辺の倍の場合だけであることが分かる。ＮＨＫＥテレの「すイエんサー」という番組で４月に「定規もな～んにも使わずに、手紙をピッタリ3等分にしたい」というタイトルで紹介された芳賀の定理を応用してＡ４やＢ５の紙を三つ折りにする方法は、Ａ４やＢ５の紙が「長辺が短辺の倍である」という条件を満たしていたから使えたもので、その条件を満たしていなければ使えないことが証明できた。

　【A4やB5の紙の長辺を３等分する方法の確認】ではＲの場所を求める別の方法も紹介した。

図３

　こちらも座標を用いることでＲのｙ座標が2/3であることを容易に証明できる。

（クリックで拡大）
図４

　線分ＤＱで折り曲げてＣが移った位置Ｒの座標を求める。
　直線ＣＲの方程式②は直線ＤＱ（方程式は①）と直角に交わることから傾きが分かり、Ｃ(a,0)を通ることから方程式が求められる。ちなみに、a=での直線ＣＲのｙ切片bは１になり、Ａと重なる。
　直線ＣＲと直線ＤＱの交点Ｓの座標は「①=②」から求められ、次のようになる。

　Ｒの座標はＳが線分ＲＣの中点であることを利用して求められ、次のようになる。

　芳賀の定理を応用する方法と同じ結果である。
　a=、すなわち長辺が短辺の倍ならば、Ｒのｙ座標は2/3になり、三つ折りの目安にできる。

A4やB5の紙の長辺を３等分する方法の確認

正己 — Sun, 16 Oct 2011 18:03:12 +0900

　ＮＨＫＥテレの「すイエんサー」という番組で４月に「定規もな～んにも使わずに、手紙をピッタリ3等分にしたい」というタイトルで、Ａ４やＢ５など日本で使われる一般的な規格の紙の長辺を三つ折りにするテクニックが紹介されていた（参照）。定型郵便の封筒に手紙を入れる時に困っていたので助かった。紹介された方法は公式のサイトにはないが、ブログに記録してくれている人がいる。例えば、『すイエんサーの「定規を使わずに手紙をピッタリ3等分に折る方法」 - お気に入り』。四つ折りにした紙の一つを無視して３等分のための定規を作る方法は何等分にする場合にも応用できて頻繁に使いそうである。理屈は簡単で、三角形の底辺に平行に高さを３等分する線を引けば、その線は斜辺も３等分するので、三つ折りしたい紙の長辺を斜辺にすれば３等分する場所が分かる仕組みである。私は番組を見た後、一番最後に紹介された長辺を３重に丸めて端と端を合わせて印を付ける方法を利用していた。しかし、本当は芳賀の定理を使う方法を利用したかった。利用しなかったのは覚えられなかったからである。説明されても、何故３等分されるか分からなかった。考えずに横着していたからだが、先日、Ａ４の紙が入った封筒が届き、捨てる前に、ふと３等分したくなった。インターネットで調べたら芳賀の定理を使う方法が載っていて、試したら、確かに３等分される。今度は横着せずに、何故３等分されるのか考えてみた。

　すイエんサーで紹介されていたのは次の図のような方法である。

図１

　長方形ＡＢＣＤの頂点Ｄを対辺ＢＣの中点Ｑに合わせるように折り曲げて、反対の辺ＡＤの中点Ｐが移動した場所Ｒの所で折り曲げれば、あるいは底辺ＤＣがＲの所に来るように折り曲げれば、綺麗に長辺ＡＤ、ＢＣを３等分できる。上の図でＲＨが長辺ＡＤ、ＢＣの1/3になる。
　この方法で３等分できる理由を一所懸命考えた結果、芳賀の定理との関連は分からないが、次のようなことだろうと理解した。

図２

　計算した結果は後で書くが、頂点Ｄを対辺ＢＣの中点Ｑに合わせた場合の折れ線ＥＦのＥ（長辺ＡＤ側）はＡＰの中点、すなわち、ＡＥは長辺ＡＤの1/4になるらしい。するとＥＰはＥＤの1/3になる。３等分するための定規が作られ、ＤとＱを合わせたことで、ＥＤを移したＥＱにより、短辺ＡＢを３等分する場所が分かるようになる。また、この定規はＥＱを対角線とする長方形の短辺ＥＰを３等分する場所も分かる。上の図のＧＲはＰＱの1/3であり、ＥＧはＥＰの1/3である。ＥＰが紙の長辺ＡＤの1/4だから、ＥＧは1/12となる。これに、長辺ＡＤの1/4であるＡＥを足して、ＡＧは1/3になる。
　この方法は、1/3と1/4の差1/12を作るために編み出された方法だろうか。一言で言えば、４等分から３等分を作る方法である。重要なのはＥの位置である。頂点Ｄを対辺ＢＣの中点Ｑに合わせるように折り曲げたら、折れ線と長辺ＡＤの接点Ｅが偶然ＡＤの1/4の位置になったかのようである。これは「長辺で半分に折り曲げた後の短辺と長辺の比が折り曲げる前の短辺と長辺の比に等しい」という紙の寸法の規格（参照）により生じたものらしい。だから、どんな寸法の紙でも可能なわけではないので注意が必要である。

　次の図は計算結果をまとめたものである。

（クリックで拡大）
図３

　ＤＳの長さは計算できるので、直角三角形ＤＳＥが直角三角形ＤＰＱと相似であることを利用して直角三角形ＤＳＥの斜辺ＤＥの長さを求めた。ＤＥが3/4となり、ＡＥが1/4であることを確認できた。次にＥＲがＥＰを移したものであるため長さが分かるので、直角三角形ＥＧＲが直角三角形ＥＰＱと相似であることを利用してＥＧの長さを求め、1/12であることを確認した。これで上記のように、ＡＧ、すなわちＡＤの中点Ｐが移ったＲの位置の短辺ＡＢからの距離ＲＨが1/3であることを確認した。

　実は、上のように解く前に、別の方法でも解いていた。次の図のような解き方である。

（クリックで拡大）
図４

　まずはＥの位置の確認である。これは上記と同じように直角三角形ＤＳＥが直角三角形ＤＰＱと相似であることを利用した。次に直角三角形ＧＲＰが直角三角形ＰＱＤと相似であることを利用してＰＧの長さを求めた。直角三角形ＧＲＰの斜辺ＰＲを求めるために二等辺三角形ＥＰＲが二等辺三角形ＥＤＱと相似で辺が1/3であることを利用した。ＰＧが1/6と分かったので、1/2であるＤＰと足してＤＧは2/3、すなわちＡＤの中点Ｐが移ったＲの位置の短辺ＤＣからの距離が2/3で、短辺ＡＢからの距離ＲＨが1/3であることを確認した。

　上記のように、すイエんサーで紹介されていた方法でＡ４の紙の長辺をぴったり３等分できることを確認した後に、もっと簡単に折り目の目安となるＲの位置を見つける方法はないものかと、紙をいろいろと折っているうちに、別の方法を見つけた。すイエんサーの補足で紹介されたような気もするが、次の図のような方法である。

図５

　長方形ＡＢＣＤの頂点Ｄと対辺ＢＣの中点Ｑを結ぶ線で折り曲げた時に、頂点Ｃの移動した点Ｒが、長辺を３等分するための目印となることが分かった。この方法はすイエんサーで紹介されていた方法と比べて、ＤＱの所に折り目が付きやすく、折り目が付かないように慎重に曲げるとＲの位置が少しずれる欠点があるが、覚えやすく簡単なので、今後は利用するかもしれない。
　この方法で正しいことは、次の図のように確認した。

（クリックで拡大）
図６

　直角三角形ＣＤＱと直角三角形ＳＣＱと直角三角形ＦＣＲが相似であることを利用して、Ｒの短辺ＤＣからの距離ＣＦを求めて、Ｒの短辺ＡＢからの距離ＢＦが1/3であることを確認した。

　以上が、ＮＨＫＥテレの「すイエんサー」という番組で紹介された「手紙を超ピッタリ三つ折りにする方法」について、正しいかどうか計算して確認した結果である。もっと簡単に証明できないか探している間に、丸一日が過ぎてしまった。私の能力の劣化を感じたが、楽しませてもらった。図を作成している最中に、どの三角形を使ったら良いか試行錯誤して何度も修正したので、修正し忘れて誤りがあるかもしれない。見つけた方は教えていただきたい。ところで、芳賀の定理との関連については、疲れたので考察しないことにする。

追記（2011/10/16）：
　「芳賀の定理」へのリンクを忘れていたので追記。

得票数の推移を見ながらの二者択一ギャンブル－２

正己 — Thu, 06 Oct 2011 19:36:41 +0900

　以前に【得票数の推移を見ながらの二者択一ギャンブル】を書いた。そこでは「１枚100円の投票券が1000枚ある」と投票権の数が限られていた。それを1000人が好きな票数だけ投票できる設定に変えたらどうなるか、気になったのでシミュレーションしてみた。同じ人が何度投票してもかまわないが、延べ人数が1000人に達した時に終了する。得票数は、各自の投票数の合計になるが、一度に一票以上なので確実に1000票以上になる。
　今回も、次の投票者がそれまでの得票状況を見て同調することを考慮する。ただし、同調率を決める式は【得票数の推移を見ながらの二者択一ギャンブル】と同じにはできない。その同調率の決め方で悩み、結局は妥当な決め方を思いつかなかった。しかし、せっかく時間をかけて考察したので、ここに記録を残しておくことにする。

賛成か反対かの二者択一で勝敗が決定するまでの推移

　ゲームのルールは次のようなものである。

ある意見に対する賛否を投票する。
一人何票でも何回でも投票できる。
投票される度に賛成票と反対票の得票数が公開される。
プレーヤーは公開された得票数を見てから投票できる。
投票者の延べ人数が1000人に達したらゲームは終わる。
ゲーム終了時に自分の投票した側の得票数の方が多ければ勝ちで少なければ負けである。
「最終的な得票数の差－投票時の得票数の差」が投票者の得点となる。
例えば、自分が投票した直後の得票数の差が-50（50票負けている状態）で最終的には+600票の差を付けて勝った場合の得点は(600-(-50))=+650点となる。
自分が投票した直後の得票数の差が+100（100票勝っている状態）で最終的には勝っても+10票の差にしかならなかった場合の得点は(10-(+100))=-90点となる。
負けた場合は、例えば、自分が投票した直後の得票数の差が+100（100票勝っている状態）で最終的な得票数の差が-200（200票負けている状態）の場合の得点は(-200-(+100))=-300点となる。
自分が投票した直後の得票数の差が-50（50票負けている状態）で最終的な得票数の差が-5（5票負けている状態）の場合の得点は(-5-(-50))=+45点となる。
すなわち、投票時に勝っていた場合は、票差が広がって終わればプラスの得点だが最終的に負けたり票差が縮まるとマイナスになる。逆に、投票時に負けていた場合は、最終的に勝ったり票差が縮まればプラスの得点になる。票差が広がればマイナスである。

　このゲームでも、鍵を握るのは例えば100票を投票するような大口プレーヤーである。誰もが多数派に投票したいので公開されている得票数で多い方に投票する傾向がある。大口プレーヤーの投票が多数派を形成すれば、大口プレーヤーに同調して投票するだろう。問題は大口プレーヤの投票でも逆転できずに小数派のままだった場合である。例えば、大口プレーヤーの投票に多数のプレーヤーが同調して得票差がさらに広がった後に別の大口プレーヤーが先の大口プレーヤーと同数の逆の投票をしても、票差を縮めることはできるが逆転はできないことがある。しかし、票差は縮まったし、大口プレーヤーに同調する別の大口プレーヤーが現れて逆転できるかもしれない。大口プレーヤーが何らかの裏情報を基に投票していたとしたら、後から投票した方は先に投票した大口プレーヤーの知らなかった情報を手にして逆に投票したのかもしれない。そうすると、その後に別の大口プレーヤーも続く可能性があリ、逆転する可能性がある。そう考えると、勝っている大口プレーヤーと負けている大口プレーヤーのどちらに同調するべきか。それが難しい問題である。

　とりあえず、このシミュレーションでは同調率を次のように決めた。

得票数の差＝賛成票－反対票
変動１＝投票後の得票数の差－投票前の得票数の差
変動２＝投票前の変動１
変動３＝投票前の変動２
変動４＝投票前の変動３
変動５＝投票前の変動４
賛成が同調される確率
＝0.5＋得票数の差×重みw_diff＋変動１×重みw_m1
＋変動２×重みw_m2＋変動３×重みw_m3＋変動４×重みw_m4＋変動５×重みw_m5
反対が同調される確率
＝0.5－得票数の差×重みw_diff－変動１×重みw_m1
－変動２×重みw_m2－変動３×重みw_m3－変動４×重みw_m4－変動５×重みw_m5
賛成が同調される確率＋反対が同調される確率＝１
（注：計算式が０以下になる場合は０に、１以上になる場合は１とする。）

　変動１～変動５まで用意したのは、大口プレーヤーの投票を見て同調するのは次のプレーヤーだけではないからである。本当は、ずっと後のプレーヤーの投票にも影響を与えたかったが、大きく変化した票差（得票数の差）を考慮することで同時に大口プレーヤーの投票も考慮しているとみなして、用意したのは変動５までにした。
　大口プレーヤーの投票の直後に別の大口プレーヤーが同数の逆の投票をした場合、大口プレーヤーの投票は無かったとみなせるのだが、残念ながら、その様子をシミュレーションに反映されることはできなかった。先の大口プレーヤーの投票直後は通常はプレーヤーの同調率が高くなるのに逆に投票した別の大口プレーヤーによって同調されず、後から投票した大口プレーヤーの投票直後は普通のプレーヤーの同調率が高くなる仕組みになってしまった。この点は改善する必要がある。
　同調率の結果を次の投票に反映させる方法は、単純に同調率の高い方を選択するのではなくて、ルーレットを回して針が賛成票と反対票のどちらに止まるかで判断する仕組みである。同調率の高い方が針の止まる場所が広くて選択されやすくなる。

　シミュレーション結果は、大口プレーヤーがいない状態では例えば次のようになる。

（クリックで拡大）
（クリックで拡大）

　縦軸（賛否票差）のプラス側（上側）が賛成票の多い状態でマイナス側（下側）が反対票の多い状態である。
　この例は接戦で賛成が勝ったようであるが、大口プレーヤーがいなければ接戦になるかというと、そうとも限らない。次のように一方的になることもある。証明はできないが接線になることの方が少ないかもしれない。

（クリックで拡大）
（クリックで拡大）

　では、大口プレーヤーが参加する例として、11番目に100票を賛成に入れてみよう。例えば次のようになる。

（クリックで拡大）
（クリックで拡大）

　得票数も同調率も賛成派の方が一方的に伸びて、最終的には賛成派の勝ちである。
　これに対抗して400番目に反対に100票を入れてみよう。

（クリックで拡大）
（クリックで拡大）

　残念ながら反対派は逆転できなかったようである。差が開きすぎていて、多数派になることができず、同調率で逆転することができなかった。賛成に同調する確率の方が高くて賛成に投票されやすく、その結果として賛成に同調する確率がさらに高くなり、差がさらに広がったのである。シミュレーションは票を入れ直すたびに再計算するので、400番目までのデータは上と異なるが、反対派が勝ちにくいことは同じである。

　このように、人が多数派に同調する傾向があると、有力者がゲームを支配することになり、有力者が勝ちやすくなる。例えば、上の例では有力者（大口プレーヤー）は100票しか入れてないのに最終的には800票も差が付いた。この800票が有力者と逆に投票していれば、有力者は負けていた。あるいは、誰も同調しなければ、100票の差なら逆転したかもしれない。対立する全ての事に言えるのだが、勝敗の鍵を握るのは有力者だが、有力者に鍵を握られるのは多くの人が多数派に同調する傾向があるからである。
　また、ゲームを支配するのなら、先に多数派を形成した方が有利である。有力者がゲームを支配したければ、早めに行動して多数派を形成する必要がある。圧倒的な多数派に対しては、多数派を形成した有力者と同程度の力を持った有力者の行動では逆転できない。多数派を形成した有力者よりも遥かに強い力を持った有力者に頼るか、多数の有力者が協力して対抗しなければ逆転できない。多数派を形成したのが有力者ではないとしても、圧倒的な多数派に対しては一部の普通の有力者の力では逆転できない。

　このシミュレーションは未完成である。例えば、最近の金融市場の動きを表現し切れていない。金融市場が一方的になりやすいのは多くの人がトレンドに同調するからである。しかし、トレンドには終わりがあり、逆に動き始める時がある。トレンドが逆になったら多くの人はそのトレンドに同調するのだが、このシミュレーションでは「逆に動き始める時」を表現し切れていない。グラフを見るとトレンドが逆転することがあるのだが、それは乱数の結果の偶然に頼っているだけで、大口プレーヤーの影響を考慮し切れていない。上記のグラフのように、このシュミレーションでは、圧倒的な多数派が形成された後に一部の大口プレーヤーの力ではトレンドを変えることはできない。しかし、金融市場は圧倒的な多数派が形成された後でも一部の大口プレーヤーの動きでトレンドが変わる。多くのプレーヤーが同調傾向を変える。それが表現し切れていない。
　どうやら今の金融市場はアルゴリズム取引に支配されているらしい。そのプログラムは複雑で、売買方法がどのように組まれているか分からない。プログラムがどのように判断して売買しているか分からない。アルゴリズム取引は金融市場が一方的になりやすい原因の一つだろう。例えば、皆が同じプログラムで売買したら一方的になるのは当然である。実際は、たくさんのプログラムが存在して、相互作用で市場が理解不能な複雑な動きになるらしい。その動きをシミュレーションできる人がいたらすごいと思う。ただ、アルゴリズム取引の特性を読んで「見せ玉」と呼ばれる手法で相場操縦した人もいるらしい（参照）。「見せ玉」という素人を相手にする一般的な相場操縦方法に自動売買のプログラムが引っかかったということだろう。これはアルゴリズム取引のプログラムが多くの人の売買方法を模倣して組まれているからかもしれない。そうならば、アルゴリズム取引であろうとも、売買方法に傾向があり、簡単に市場の動きをシミュレーションできるのかもしれない。
　私のシミュレーションは人が多数派に同調することでトレンドが形成されてしまう怖さを示すために作ったものだが、接戦状態から大量の票数で意図的にトレンドを作るだけでなく、タイミングが良ければ同じ票数で意図的にトレンドを変えられる同調率の決め方を思いついたら、改良したい。今はトレンドが形成されても票差が小さければ意図的にトレンドを変えることは可能だが、票差が大きくても可能になる同調率の決め方を思いついたら、改良したい。人は多数派に同調するだけでなく、今は小数派でも後で多数派になりそうな方に同調する。それを組み込んだシミュレーションができたら嬉しい。

統計トリック「病院に行くと死ぬ」

正己 — Thu, 29 Sep 2011 19:56:26 +0900

　これは、ネット上のある統計データとその解釈を読んで「その解釈は何か変だ」と思ったから書いている。その統計データや解釈へのリンクは張らない。以下は人口１万人の架空の国を想定して書いたものである。ジャーナリストの言ったこともフィクションであり、実在の人物が似たことを言った事実が無い言葉も含まれている。

　国の調査によると、昨年の死亡者数200人の内、150人は死亡前１年以内に病院で治療を受けていたが、50人は病院に行かず、治療を受けていなかったようだ。そのデータを見たジャーナリストは「病院で治療しても無駄だ。治療した人は治療してない人の３倍も死んでいる。治療したことが死亡の原因になっている可能性がある。治療しない方が良い。病院に行かない方が良い。病院に行くと死ぬ」と解説した。その年、人口１万人の内、病院に行って治療を受けたのは1000人で、残りの9000人は病院に行かず、治療を受けていなかった。その調査結果も「病院に行くと死ぬ」という意見を補強することになった。そのジャーナリストは言った。「病院に行った1000人の内150人も死んでいる。15％である。それに対して、病院に行かなかった9000人の内、死んだのは50人だけ。0.6％よりも少ない。やはり病院に行くのは危険である。病院に行くと死ぬ」と。
　実は、国は死に至る病の「早期発見・早期治療」の政策を続けていた。ある年、死に至る病で150人が死んだ。その多くが病院で治療を受けてなかった。そこで国は「早期発見・早期治療」の政策を掲げ、死に至る病になった人に治療を受けてもらうことにした。しかし、一昨年も死に至る病で150人が死んだ。その年は500人が死に至る病になったと推計された。死んだ150人の内、病院に行って治療を受けたのは50人で、残りの100人は病院に行かず、治療を受けていなかった。そして昨年、死に至る病で200人が死んだ。病院に行って治療を受けていたのは150人。病院に行かず治療を受けていなかったのは50人だった。病院に行って治療を受けている人は増えている。しかし、死んだ人も増えた。この結果を見た先のジャーナリストは国を批判した。「早期発見・早期治療でも死者は減らない。むしろ病院に行った人が増えたことで死者が増えた。早期発見・早期治療は間違いだ。病院に行くと死ぬ」と。ところで、その年、死に至る病になった人は1000人と推計された。

　さて、上記ジャーナリストの「病院に行くと死ぬ」は正しいのだろうか。上に書いてあるデータを図で表した。一番下に、死に至る病になった人の半数しか病院に行って治療を受けなかった場合の図も加えた。図を見れば一目瞭然である。上記のジャーナリスト主張は誤りである。

（クリックで拡大）

　一番上の図を見ると、治療なしで死亡する確率は低く、治療を受けた方が死亡する確率が高いように見える。しかし、治療を受ける必要の無い人は治療を受けない。治療を受ける必要のない人が増えれば増えるほど、この図では治療なしで死亡する確率は低くなる。この図からは「治療を受ける必要があると言われている人も治療しない方が良い」とは言えない。
　二段目の図は昨年の死亡者数200人を治療の有無で分けたものであるが、これだけを見て「治療を受けると治療を受けないよりも死ぬ」と解釈してはいけない。三段目の図と合わせて考える必要がある。
　三段目の図は「死に至る病になった人」の中での分布を表したものである。治療を受けなかった人の半数が死んでいるのに対して、治療を受けた人の６人に５人は助かっていることが分かる。死亡する確率は治療を受けなかった場合の方が高い。治療を受けた場合の死亡する確率が低くても、確率がゼロでない限り、治療を受ける人が増えれば増えるほど死亡する人が増える。二段目の図で治療を受けた人の方が治療を受けない人よりも死んだ人が多いのは、治療を受けた人が治療を受けない人の９倍だからである。この三段目の図から、「死に至る病になった人は、治療を受けないよりも受けた方が良い」と分かる。
　五段目に、死に至る病になった1000人の半数しか病院に行って治療を受けなかった場合に、死亡する人の数がどの程度になるか図示してみた。治療を受けた人の６人に１人は死に、治療を受けなかった人の半数が死ぬのだから、治療ありで死亡するのは83人。治療なしで死亡するのは250人である。治療を受けた方が良いことが明らかである。三段目の図では治療を受けた人が多かったので治療ありで死亡した人の方が治療なしで死亡した人よりも多かった。しかし、治療を受ける人と受けない人の人数が同じならば、治療なしで死亡する人の方が治療ありで死亡する人よりも多くなる。
　四段目の図は一昨年の状態である。上記のジャーナリストは「早期発見・早期治療」の政策を批判し、「早期発見・早期治療でも死者は減らない」と言っている。確かに昨年は一昨年よりも治療を受けた人の割合が大きいのに死亡した人の数が増えている。早期発見・早期治療だけでは数が減らない。しかし、死亡した人の数が増えたのは死に至る病になった人が倍になったからである。昨年、もしも一昨年のように死に至る病になって治療を受けた人が５人に３人、60％だったら、死亡した人の数は300人になっただろう。昨年は、死に至る病になった90％の人が治療を受けたので死亡した人の数を200人に減らせた。早期発見・早期治療は効果があったのである。また、昨年、もしも一昨年のように死に至る病になった人が500人だったら、死亡した人の数は100人まで減らせたであろう。この結果は「早期発見・早期治療は間違いだ」ではなく「死に至る病になる人も減らさなければいけない」と見た方が良い。

　ここでは人口１万人の架空の国を想定して考察した。興味のある人は日本の人口で確認すると良い。「死に至る病」の所は五大疾病の一つでも当てはめて、それぞれの数値には実際のデータを入れて確認すると良いだろう。統計データを基に「病院に行くべきではない」「治療を受けるべきではない」などと主張する人がいたら、その主張が正しいか否かを、この記事の様にデータを分析して判断したら良い。私はデータを見つけられなかったので書かないが、私がデータを探した参考になるかもしれないサイトへのリンクを張っておく。

POP3の設定をしても旧Infoseekメールのメールを新Infoseekメールに移せない

正己 — Tue, 13 Sep 2011 13:19:58 +0900

注意：この記事に解決策や対処方法は書いてありません。期待はずれでごめんなさい。m(_ _)m

　長年使ってきたInfoseekメールが事実上廃止されてマイクロソフトが提供するHotmailになった。

今回の合意に基づきInfoseek メールは、2011年9月よりマイクロソフトの運営する個人向けクラウドサービス「Windows Live (R)」を採用した新しいWebメールサービスに移行する予定です。これにより、Infoseekメールのユーザーは、「＠infoseek.jp」のメールアドレスのままで、Windows Liveの提供するWindows Live HotmailやWindows Live Messenger、Windows Live SkyDrive（オンラインストレージ）といった各種サービスを利用できるようになります。
（「楽天とマイクロソフト、「Infoseek メール」を「Windows Live (R)」のプラットフォームで提供することに合意」2011年7月21日 - 【楽天株式会社】ニュースリリース）

　楽天の上記ニュースに気付いたのは最近で7/21の時点ではインフォシークからのメールで知った。そこにはWindows Liveと提携することは書いてあったがHotmailを利用することは書いてなかった。似た内容がインフォシークのブログにも載っている。

■ リニューアル内容マイクロソフト社が提供する「Windows Live」とタッグを組み、下記を実現します。
[ 機能アップ ]
・メールボックスの容量が無制限
・セキュリティ対策がさらに強力に
[ 新機能 ]
・Officeドキュメントをブラウザ上で編集できる
・Messengerによる音声通話やビデオ通話もできる
・オンライン上のハードディスクに写真やファイルを保存できる
　しかも「25GB」の大容量
（「2011年9月1日に Infoseek メールが新しくなります」2011.07.21 - インフォシーク　ユーザサポートからのお知らせ）

　Hotmailになるとは書いてなかったが、「Windows Live」と書いてあったので嫌な予感がしていた。案の定、新Infoseekメールの実体はHotmailだった。私は弟と妹にInfoseekメールを勧めたので申し訳なく思っている。まさかHotmailにされるとは思っていなかった。私は一時期、スパムが多いのでHotmailからのメールを着信拒否したことがある。印象の悪いサービスである。また、7/27にHotmailのアドレスを作って使ってみたが、不安定で使いにくかった（参照）。各種設定の変更がしにくいことも気に入らなかった。設定メニューのツリー構造が分かりにくい。そして、一番の問題は、Hotmailは一定期間使われてなかったメールアドレスを他人が利用できることである。Hotmailはもう使いたくないが自分の使っていたメールアドレスを他人に使われたくないという人から相談されて知った。ネットで調べたら次のように書いてある2009/7/20の記事を見つけた。

CrollはHotmailに場所を移してパスワードを盗みだす努力を続けた。彼はGmailのユーザー名から、この社員がhotmailで使っていたであろうユーザー名を推測することができた。調べてみると、なんとGmailに第2のメールアドレスとして登録されているはずのhotmailのアカウントはすでに無効になっていた。Hotmailでは一定期間利用されていない休眠アカウントを削除し、リサイクルすることにしている。Crollはその hotmailにそのユーザー名で新規登録し、Gmailに戻って再度パスワード・リセットを要求した。こうしてCrollは難なくTwitter社員の Gmailアカウントへのアクセスを確保した。最初のドミノの駒が倒れた。
（Twitterのハッカーとのコンタクトに成功―攻撃手口の詳細が判明した）

　公式の情報は見つけられなかったが、2011年9月の現在でも、他人が使っていたメールアドレスの再利用が可能なことは変わってないだろう。

　さて、旧Infoseekメールが新Infoseekメールに変わるのに伴い、旧Infoseekメールに保存してあったメールを移さないといけない。パソコンに移す方法もあるが、ウェブメールとしてしか使っていない人のために旧InfoseekメールのPOP3を有効にすることで新Infoseekメールに全てのメールを転送できる仕組みが用意された。

手順には２ステップあります。
【かならず、両方のステップを完了させてください】
ステップ1.　旧 Infoseek メールのPOP3を有効にする
ステップ2.　新 Infoseek メール ( Windows Live ) にPOP3の設定をし、旧 Infoseek メールのメールを受信する
==== 【ご注意ください】 ====
※ POP3で受信できるメールは、旧 Infoseek メールの「受信フォルダ」内のメールのみです
※ 新 Infoseek メール ( Windows Live ) に取り込みたいメールは、あらかじめ受信フォルダに移動してください
（POP3の設定で旧 Infoseek メールのメールを取り込むには？ - 【インフォシーク】ヘルプ）

　転送できるメールは「受信フォルダ」内のメールだけなので注意が必要である。旧Infoseekメールのフォルダにあるメールを「受信フォルダ」に移さないと転送してくれない。フォルダの数やメール数が多い場合は大変である。私は新Infoseekメールには無いが旧Infoseekメールには昔から用意されている「一括ダウンロード」の機能を使ってeml形式のファイルをフォルダごとにダウンロードした。最終的にはパソコンに保存しようとしていたので良い機会だった。もしもPOP3の設定でフォルダごとに新Infoseekメールに移したければ、一つのフォルダ内のメールを受信フォルダに移して転送されたことを確認して新Infoseekメールに用意した同じ名前のフォルダに移動させ、その後に別のフォルダ内のメールを受信フォルダに移して転送させることを繰り返さなければいけない。しかし、Hotmailで他のアカウントのメールを受信するのは３０分ごとらしい（参照）。すると、一つのフォルダのメールを転送した後、次のフォルダのメールを転送するまで３０分も待たないといけない。フォルダの数が多いと時間がかかる。仕方ないので、複数のフォルダのメールを一度に受信フォルダに移しておくしかない。

　弟に新Infoseekメールへ移行できないと相談されて、行ってみると、Windows Live用のパスワードの作成を要求されるのだが、旧Infoseekメールのパスワードを入力しても拒否され続けた。仕方なく別パスワードを用意して入力し、新Infoseekメールが使えるようになったのだが、ついでに、旧Infoseekメールのメールを新Infoseekメールに移す作業も手伝った。
　上記の【インフォシーク】ヘルプに従って設定したのだが、一向にメールが転送されない。何度か設定し直したが無駄だった。
　インターネットで検索すると同じように移せない人がたくさんいるようだった。
　やがて、インフォシークが次のようなヘルプを用意した。

POP3設定をしても「旧 Infoseek メールのメールが取り込めない」、または「一部のメールしか取り込めていない」という場合は旧 Infoseek メールの「受信フォルダ」に取り込みたいメールがなかったことが考えられます。
POP3で取り込むことができるメールは、旧 Infoseek メールの「受信フォルダ」内のメールのみとなります。
（POP3の設定をしても旧Infoseek メールの全てのメールが取り込めない - 【インフォシーク】ヘルプ）

　「受信フォルダ」内のメールも新Infoseekメールで取り込めないから問題なのであって、『旧 Infoseek メールの「受信フォルダ」に取り込みたいメールがなかった』ということはない。

===【対処】===
・　POP3設定を一度リセット
・　旧 Infoseek メールの取り込みたいメールを「受信フォルダ」に移動、未読状態にする
・　POP3を再設定する
※※※　ご注意ください　※※※
POP3の再設定をしても、すぐにメールが受信されない場合がございます。
下記手順の対処をしていただいた後、しばらくお待ちいただき、様子をみていただきたく存じます。
（POP3の設定をしても旧Infoseek メールの全てのメールが取り込めない - 【インフォシーク】ヘルプ）

　この対処法でも旧Infoseekメールのメールを新Infoseekメールで取り込むことはできなかった。「しばらくお待ちいただき、様子をみていただきたく」とあるが、４日過ぎても、取り込めてないことを確認している。このままでは今後も取り込めないだろう。

3.　旧 Infoseek メールにログインし、移動させたいメールを「受信フォルダ」にうつし「未読」にしてください
（POP3の設定をしても旧Infoseek メールの全てのメールが取り込めない - 【インフォシーク】ヘルプ）

　旧Infoseekメールのメールを「未読」にすることは、新しく加えられた情報である。未読じゃなかったから取り込めなかったと考えているのだろうか。残念ながら原因は他にある。「未読」にしても、４日過ぎても、旧Infoseekメールのメールを新Infoseekメールで取り込めない。

　この問題についてインフォシークに問い合わせて回答メールの届いた人がいるらしい。その回答には次のように書いてあったそうだ。

旧Infoseek メールのメールデータ移行をする際に
・POP3設定をしても新メールボックスに取り込めない
・POP3設定時にエラーになり設定できない
という状況になっている場合は、マイクロソフト社が提供している
「Windows Live メール」を使ったInfoseek メールの管理、および
データ移行を提案いたします。
なお、弊社では「Windows Live メール」のソフトウェアに関する
サポートを行っておりません。
（893 ：名無しさん＠お腹いっぱい。：2011/09/09(金) 23:44:20.55 - infoseek×windows live）

　POP3を使った転送を諦めろということだろう。トラブルの原因はインフォシーク側にあると考えられるのだが、インフォシーク側はPOP3の設定をしても旧Infoseekメールのメールを新Infoseekメールに移せない問題を解決する気が無いということだろう。

　私はこの問題について弟のメールアドレスで確認していたのだが、弟は諦めて旧Infoseekメールのメールを全て削除してしまったそうだ。インフォシークがこの問題を解決したかどうか、私の環境では確認できなくなった。この問題に対するインフォシークの今後の対応が気になるが残念である。

　インフォシークのサポートの姿勢には好感が持てないが、Infoseekメールは今後も使い続けるしかなそうである。Infoseekのメールアドレスで様々な業者のサービスに登録してある。これらの登録メールアドレスを全て変更するのは手間がかかる。メールアドレス自体がIDになっているサービスもある。では、アカウントを削除して必要な業者のサービスだけ別のメールアドレスを再登録するのが良いだろうか。これも危険である。上記のように新InfoseekメールはHotmailを利用していて、Hotmailは一定期間使われてなかったメールアドレスを他人が利用できる。もしも他人が私のメールアドレスを利用したら、その人の所に私がメールアドレスを登録した業者からのメールが届く。業者からのメールには「○○様」などと本名が記載されているものや、リンクをクリックするだけでサービスにログインできるURLが記載されているものもある。すなわち、他人が私の本名を知ったり、私が登録した様々な情報を知ることができる。また、上記の【Twitterのハッカーとのコンタクトに成功―攻撃手口の詳細が判明した】に書いてあるハッカーの手口は、アカウントを利用してないのに他のサービスにHotmailのアドレスを登録したままだった人がいたために可能になった。だからHotmailになったInfoseekのメールアドレスは使い続けなければいけない。
　幸い、私のパソコンの性能で今の新Infoseekメールは大きなストレス無く使える。たぶん、このまま使い続けるだろう。

既定のブラウザがIEのままThunderbirdからFirefoxを開く方法

正己 — Sun, 04 Sep 2011 12:19:42 +0900

　Infoseek RSSリーダーが使えなくなって（参照）、Thunderbird 3.1をRSSリーダとして利用することにした。Thunderbirdでは取得したフィードの中に含まれている記事の要約ではなく、Webページを読み込むことができる。アカウントの設定で「標準では Web ページを読み込まずに記事の要約を表示する」のチェックを外せば良い（参照）。
　さて、Thunderbirdに表示されたWebページのリンクをクリックすると、Windowsの既定のブラウザで開くのだが、メッセージ内のリンクをFirefoxで開くには、Firefoxが既定のブラウザに設定されている必要がある（参照）。Infoseek RSSリーダーを使っていた時はFirefoxで見ていたのでリンクをクリックしてもFirefoxで開いていた。しかし、ThunderbirdをRSSリーダーとして利用するようになったので、既定のブラウザがInternet Explorer（IE）のままでは、リンクをクリックした時にIEで開いてしまう。URLをコピーしてFirefoxを起動してアドレス欄に入力して開かないとFirefoxで見ることができない。【強制改行されたリンク異常URLにアクセスするバッチファイル】で紹介したbatファイルを使えば少しは楽になるが、もっと楽に既定のブラウザ以外で開けるようにしたい。ずっと不可能だと思っていたのだが、ブログをThunderbirdで見るようになってリンクをクリックする機会が増えたことで、改めて方法を探してみた。そして、見つけた。Launchyというアドオンを使う方法である。
　ThunderbirdにLaunchyというアドオンを入れたら、すぐにFirefoxでリンクを開くことができると思ったのだが、残念ながら、少し難しい作業が必要だった。作者のサイトによると、自動的にFirefoxが認識されるらしいが、残念ながら認識されず、Thunderbirdのプロファイルが入っているフォルダの中に「chrome」というフォルダを作って、その中に次のように記載された「launchy.xml」ファイルを作って入れておかなければならなかった。テキストファイルを保存する時はUTF-8形式にする必要があるので注意が必要である。私はShift-JISで保存して一度失敗した。

http://launchy.mozdev.org/configurations">

    Firefox
    1
    C:\Program Files\Mozilla Firefox\firefox.exe

　これでリンク上の右クリックだけで、ThunderbirdからFirefoxを開くことが可能になった。

（クリックで拡大）

　このアドオンを使えば、ブログのソースをテキストエディタで開いたり、画像を自分のパソコン内にあるソフトで開くこともできる。Thunderbirdをメールソフトとして使い始めた時に知りたかったアドオンである。

RSSにするか、Atomにするか

正己 — Sun, 04 Sep 2011 10:17:36 +0900

　2011年8月31日に長年利用させてもらったInfoseek RSSリーダーがサービスを終了した。

いつもインフォシークをご利用いただき、ありがとうございます。
先日、お知らせをさせていただきましたが、2011年8月31日（水）をもって、下記のサービスを終了させていただきました。

■終了したサービス
RSSリーダー

■サービス終了日
2011年8月31日（水）

長年にわたるご利用に感謝いたしますとともに、サイトの終了に際し、
皆さまにはご迷惑をおかけいたしますことをお詫び申し上げます。

（サービス提供終了のお知らせ - インフォシーク　ユーザサポートからのお知らせ）

　一ヶ月前に終了することを知って、次にどのRSSリーダーを使うか悩んだ末にThunderbirdを使うことにした。Infoseek RSSリーダーからOPML形式でRSSデータをエクスポートできるようになっていたことを知らずに、全部で８３のブログのフィードURLを一つ一つ調べてThunderbirdに登録した。とても面倒だった。その際に、フィードURLの選択で迷った。多くのブログが複数のフィードURLを提供している。大きく分けて、RSS1.0、RSS2.0、Atomのようだ。Infoseek RSSリーダーではブログのURLを登録すると自動的にフィードURLを選択していたようで、意識することが無かった。しかし、Thunderbird 3.1ではフィードURLを登録する必要があるので自分で決めなければいけない。RSS1.0にするか、RSS2.0にするか、Atomにするか、迷った。
　RSS1.0、RSS2.0、Atomは、それぞれが独特の仕様を持ち、RSS2.0がRSS1.0の後継規格というわけでもなさそうだ（参照）。AtomもRSS2.0の後に生まれたのだがRSS2.0の後継規格というわけではない。
　一番新しい規格が一番良いのではないかと考えて、最初はAtomのフィードURLを最優先にすることにした。Atomが提供されてなければRSS2.0にしようと思って、全部で８３のブログのフィードURLをThunderbirdに一つ一つ登録していった。登録が終わった後に確認のためにブログを読んだ。ThunderbirdにはフィードURLに記載された情報ではなく、ブログそのものを表示する機能がある。Infoseek RSSリーダーには無かった魅力的な機能である。フィードURLに記載されている情報はブログの記事のタイトルとURLと作成日だけで良くて他の情報は無駄だなとも思った。フィードURLの選択でさらに迷う原因にもなった。
　Atomを最優先にしてThunderbirdに登録したブログを読んでいる時に、一部のブログで違和感があった。Thunderbirdに表示された記事のリストを上から順に古い順に読んでいるつもりだったが、古い記事が後になっているブログがある。各ブログ記事には前の記事や次の記事へのリンクもあるので、それで確認するとThunderbirdに表示されている順番と異なる。最初は何が起こっているのか分からなかった。どうやら、Atomでは最初の投稿日時だけでなく更新日時のデータも記載されていて、Thunderbirdでは更新日時のデータを「送信日時」欄に表示しているらしい。だから送信日時で並べ替えると最初の投稿日時の順番にならない。ブログの方は最初の投稿日時の順番なのでブログで見る順番とThunderbirdで見る順番が異なってしまう。
　私のブログでも確認してみた。

（クリックで拡大）

　取得した２０記事の全ての送信日時が「2011/06/12 15:12」になっている。新しい記事が下になるように並べているのに、一番新しい記事【Thunderbirdが勝手にUTF-8に変えて送信するのに警告を出さない】が一番古い記事のようになっている。この記事の投稿日時は「2011.02.06 16:02」で追記があるわけではない。ブログ全体に対する何らかの操作を「2011/06/12 15:12」に行った結果、更新日時として記録されたのだろう。
　Firefoxでもフィードを表示できるので確認してみた。

（クリックで拡大）

　こちらは表示された記事の全ての日時が「2011年8月18日 10:22」になっている。こちらは最新記事が一番上に表示されていて記事の順番は入れ替わってなさそうである。日時がThunderbirdと異なるのは、Thunderbirdでフィードを取得した後にブログ全体に対する何らかの操作を8月18日に行ったからだろう。

　このように、RSSリーダーに登録するフィードURLをRSSではなくてAtomフォーマットの方にすると、RSSリーダーは最初の投稿日時ではなくて更新日時の方を利用して表示してしまうらしい。追記などで更新があった場合、更新されるたびにフィードを送ってくれれば、新しくなった部分を見逃さないメリットはあるだろう。しかし、更新されるたびに配信されているのだろうか？最初に投稿した時に配信するだけで、その後は更新しても配信してないような気がしないでもない。そうならば、更新日時が常に取得できるわけではなく、RSS配信されている間に改めてフィードを取得した場合に取得できるだけである。Thunderbirdのように一度取得したフィードは二度と取得しない仕様では役に立たない。実際、私のブログは8月18日に更新されていることになっているのに、Thunderbirdは改めて取得することなく、更新日時は「2011/06/12 15:12」のままである。また、私のように未読が大量に溜まってから読む癖があると、更新日時で並べ替えられてしまうと、古い記事から順番に読むことができなくなる。例えば、フィードの取得が一日に一回のようなペースだと、一日にたくさんの記事が投稿されるブログを読むときに支障を来す。（追記：9/4に二つの記事を投稿した後のThunderbirdでフィード取得された結果の図。順番が乱れている。→20110904_6.png）
　私が使うことにしたThunderbirdで「送信日時」の欄に更新日時ではなく最初の投稿日時を表示してくれればフィードURLの選択はAtomでも良いのだが、私のPCのスペックが低いため、Thunderbirdのメジャーアップデートはできそうにない。すなわち、バージョン 3.1のままThunderbirdを使い続けるしかなく、「送信日時」の欄はブログの更新日時が表示されるままである。このことから、私は登録するフィードURLの選択からAtomを除外することにした。Atomしか配信されてないブログではAtomを選択するが、それ以外ではRSS2.0を選択することにした。

　「一番新しい規格が一番良いとは限らない」を実感した出来事だった。

Thunderbirdが勝手にUTF-8に変えて送信するのに警告を出さない

正己 — Sun, 06 Feb 2011 16:02:49 +0900

　先日、Yahoo!グループでメールの送受信をしているときに、送信メールの文字エンコーディングが UTF-8 になった。私が使っているThunderbird 3.1.7 は UTF-8 の受信メールに返信すれば自動的に UTF-8 になるようだが、ISO-2022-JP のメールに返信したのに UTF-8 になった。自分が送信した UTF-8 のメールを受信して読んでみて文字化けが生じているわけではなく問題がなさそうだったので気にしないでいようと思ったのだが、念のためにYahoo!グループにアクセスして確認したら、酷く文字化けしていた。そして、数時間後に同じＭＬの人からメールが届かなくなったという連絡があった。私が送信した UTF-8 のメールの後のメールが全く届かなくなったらしい。実際に私のメールが原因か否かは分からないが、状況証拠から私のメールが怪しい。
　Yahoo!グループのウェブページで文字化けしていることに気付いてから、ふと、以前は UTF-8 に変更して送信する前は警告メッセージが出ていたことを思い出した。警告メッセージが出たら機種依存文字など ISO-2022-JP でエンコードできない文字を探して削除して送信していた。今回は自動的に UTF-8 で送信されてしまった。インターネットで調べたら次のような情報を見つけた。

・メッセージに挿入された文字が初期設定のエンコードで表示できない場合、UTF-8 への変換がプロンプトなしで自動的に行われるようになりました。
（Thunderbird 3 for users - MDC Doc Center）

　警告メッセージを出さない仕様に変更されたらしい。
　ＭＬのメンバーからメールが届かないとの連絡を受けた後、一夜明けて調べたら、次のような情報を見つけた。

http://kb.mozillazine.org/Thunderbird_3.0_-_New_Features_and_Changes#Encoding-Related_Changes
これですね。どこかで見た覚えがあって探してました。
「混乱の元になるからダイアログなしで UTF-8 にフォールバック！」ってことみたいです。
mailnews.disable_fallback_to_utf8.ISO-2022-JP を true にすれば UTF-8 にフォールバックすることなく ISO-2022-JP のまま送信できますが、これだとダイアログなしで無条件 ISO-2022-JP です。
帯に短し襷に長し……
（件名: Re: Thunderbird 3.0 beta4ではエンコード指定の変更ダイアログが表示されない投稿時間: 2009年10月09日(金) 14:30）

　その下を読むと仕様変更には議論があったらしい。改悪のような気がする。私の環境では問題なく受信できるが、受信できないソフトを利用している人もいるだろうし、UTF-8 のメールを受信できるソフトでも、ISO-2022-JP を強制的に UTF-8 に変えてしまうことで思わぬトラブルも生じる。私のメールに生じた今回のトラブルが一つの例である。

　上に引用した情報を見ると、機種依存文字など正しく表示できない文字が含まれていても初期設定どおり ISO-2022-JP で送信する設定にできるようである。警告メッセージは出ないようだが…。とりあえず、私はThunderbirdのオプションの詳細から「設定エディタ」（about:config）を開いて mailnews.disable_fallback_to_utf8.ISO-2022-JP を「true」に変更した。これで UTF-8 で送信されることは無いだろう。

　ところで、今回の私のメールの問題はSubjectと本文に「�」が含まれていることで生じた。受信したメールのSubjectの後ろに付いていたのだが、見た目は空白で気付かなかったので、そのまま返信メールを作成した。本文にも受信メールのSubjectをコピーした。「�」が何を意味しているのかは分からない。ただ、通常の機種依存文字よりも悪質な振る舞いをしそうである。知っている方は教えて欲しい。
　この「�」をSubjectと本文に含めたメールを作成することでYahoo!グループのウェブページでの文字化けを再現することができた（参照）。Firefox 3.6.13で見ると、fontタグや改行(br)タグを侵食していることが分かる。

（クリックで拡大）

　送信メールのSubjectは「特殊文字?」で「?」の部分が「�」である。本文は次のように書いて送信した。やはり「?」の部分が「�」である。

本文にも↓
特殊文字?
件名にも特殊文字がある。
特殊文字?←ここにある。
特殊文字のUTF-8でのコードは�
表示されなかったときのために全角で＆＃６５５３３；
Yahoo!メール（ベータ版）から送信

　実験はYahoo!メール（ベータ版）を使った。旧バージョンでは ISO-2022-JP で送信されたが、新バージョンでは UTF-8 で送信された。Yahoo!メール（ベータ版）も通常は ISO-2022-JP で送信するようなので、今回の実験メールでは UTF-8 に変えて送信したのだろう。強制的に UTF-8 に変えて送信するのはThunderbirdだけではなかった。これからのメールはほとんどが強制的に UTF-8 に変えて送信するのかもしれない。今回のようなトラブルが生じる状況で、それが正しいことだとは思えない。強制的に UTF-8 に変えて送信するソフトを提供しているYahoo!のサービスであるYahoo!グループで文字化けを生じさせてしまうような状態である。しばらくはエンコーディングを変える前に警告メッセージを出して、変えるか否かを選択させるくらいの配慮が必要だろう。

ソネブロのシェアボタンの仕様を少し変えて欲しい。

正己 — Tue, 25 Jan 2011 14:35:50 +0900

　ソネブロが「シェアボタン」と呼ぶリンク機能を追加したらしい。

　サービスが提供されてから１０日以上も過ぎて私のブログにも設置した。私はツイッターのボタンしか動作を確認できないが、クリックしてみて少し残念な仕様に気付いた。
　例えば、【シェアボタン機能追加とキャンペーンのお知らせ：What's new?：So-netブログ】のページを開いて「Tweet」ボタンをクリックして表示されたウィンドウのテキストエリアには次のように入力されている。

シェアボタン機能追加とキャンペーンのお知らせ：What's new?：So-netブログ http://t.co/QhBv4oH

「記事のタイトル：ブログ名：So-netブログ記事のURL」となっていて、「記事のタイトル：ブログ名：So-netブログ」までは記事のHTMLソースのを使っているらしい。 　その結果、トップページの<a href="http://blog-wn.blog.so-net.ne.jp/" target="_blank" title="What's new?：So-netブログ">【What's new?：So-netブログ】</a>で「シェアボタン機能追加とキャンペーンのお知らせ」の記事にある「Tweet」ボタンをクリックすると、表示されたウィンドウのテキストエリアには次のように入力されている。 <blockquote> What's new?：So-netブログ http://t.co/QhBv4oH </blockquote> 　記事のURLは「シェアボタン機能追加とキャンペーンのお知らせ」のものだが、その前は「ブログ名：So-netブログ」となっていて記事のタイトルが入力されない。表示されているページのソースの<title>には記事のタイトルが無いからである。 　記事のページを開かなくてもトップページなどの「Tweet」ボタンをクリックして記事のタイトルがテキストエリアに入力されるようにすることは可能である。ただし、ソネブロの開発者に<a href="https://blog.so-net.ne.jp/_js/bookmark.js" target="_blank" title="シェアボタン用Javascript">bookmark.js</a>を改良してもらわなければらない。私はブログ以外の自分のサイトを持っているので、そちらにアップロードしたJavascriptファイルを利用することで対処できた。 　書き換えるのは次の部分である。 <blockquote style="font-size:75%;"> case 'twitter': document.write('<li><a href="http://twitter.com/share" class="twitter-share-button" data-url="' + seesaa_article_page_url + '" data-count="none">Tweet</a><script type="text/javascript" src="http://platform.twitter.com/widgets.js"></script></li>'); break; </blockquote> 　これを次のように書き換える。 <blockquote style="font-size:75%;"> case 'twitter': document.write('<li><a href="http://twitter.com/share" class="twitter-share-button" data-url="' + seesaa_article_page_url + '" data-text="' + seesaa_article_subject + '" data-count="none">Tweet</a><script type="text/javascript" src="http://platform.twitter.com/widgets.js"></script></li>'); break; </blockquote> 　違いは、「 + '" data-text="' + seesaa_article_subject」が追加されているだけである。「data-text」については、<a href="http://twitter.com/about/resources/tweetbutton" target="_blank" title="Twitter / ツイートボタン">ツイートボタン</a>のサイトに解説へのリンク（<a href="http://dev.twitter.com/pages/tweet_button" target="_blank" title="Tweet Button | dev.twitter.com">参照</a>）がある。デフォルトで入力するテキストを指定するようで、指定してない場合は表示されているページの<title>タグの内容を入力するらしい。 　さて、上記のように<a href="https://blog.so-net.ne.jp/_js/bookmark.js" target="_blank" title="シェアボタン用Javascript">bookmark.js</a>を書き換えることで、「Tweet」ボタンをクリックして表示されるウィンドウのテキストエリアに記事のタイトルが自動的に入力されるようになる。しかし、これだけではブログ名が入力されない。上記の例だと次のようになるだろう。 <blockquote> シェアボタン機能追加とキャンペーンのお知らせ http://t.co/QhBv4oH </blockquote> 　これは記事のページを開いてからクリックしても複数の記事が表示されているトップページなどから記事の下にある「Tweet」ボタンをクリックしても同じである。 　これでも良いのかもしれないが、次のようにブログ名を含めて入力されていた方が良いかもしれない。 <blockquote> シェアボタン機能追加とキャンペーンのお知らせ：What's new? http://t.co/QhBv4oH </blockquote> 　これは次のようにすれば可能になる。ただし、ソネブロの開発者に<a href="https://blog.so-net.ne.jp/_js/bookmark.js" target="_blank" title="シェアボタン用Javascript">bookmark.js</a>を上記のように書き換えてもらった後での話である。 　ソネブロの「管理ページ」の「デザイン」から「レイアウト」をクリックして、表示されている多数のブロックの内、「記事」のブロックをクリックして「コンテンツHTML編集」をクリックする（<a href="http://blog-help.blog.so-net.ne.jp/design3" target="_blank" title="コンテンツのHTML編集：使い方マニュアル：So-netブログ">参照</a>）と、シェアボタンの設置に該当する次のような記述がある。 <blockquote style="font-size:75%;"> <% if:blog.bookmark_service %> <script type="text/javascript" language="javascript" charset="utf-8"> //<![CDATA[ seesaa_bookmark_services = "<% blog.bookmark_service %>"; seesaa_article_page_url = "<% article.page_url %>"; seesaa_article_subject = "<% article.subject | jsescape | tag_strip %>"; seesaa_blog_url = "<% site_info.blog_url %>"; //]]></script> <script type="text/javascript" language="JavaScript" charset="utf-8" src="<% site_info.blog_url %>/_js/bookmark.js"></script> <% /if %> </blockquote> 　これを次のように変書き換えれば良い。 <blockquote style="font-size:75%;"> <% if:blog.bookmark_service %> <script type="text/javascript" language="javascript" charset="utf-8"> //<![CDATA[ seesaa_bookmark_services = "<% blog.bookmark_service %>"; seesaa_article_page_url = "<% article.page_url %>"; seesaa_article_subject = "<% article.subject | jsescape | tag_strip %>：<% blog.title %>"; seesaa_blog_url = "<% site_info.blog_url %>"; //]]></script> <script type="text/javascript" language="JavaScript" charset="utf-8" src="<% site_info.blog_url %>/_js/bookmark.js"></script> <% /if %> </blockquote> 　<a href="https://blog.so-net.ne.jp/_js/bookmark.js" target="_blank" title="シェアボタン用Javascript">bookmark.js</a>で使う「seesaa_article_subject」に「：<% blog.title %>」を追加しただけである。私のブログでは「 - <% blog.title %>」を追加した。 ソネブロ（Seesaaブログ）における「article.subject」と「blog.title」の意味は、<a href="http://self.blog.so-net.ne.jp/2008-05-10" target="_blank" title="カスタマイズ方法はSeesaaにあり - 正己の異論・反論：So-net blog">【カスタマイズ方法はSeesaaにあり】</a>で紹介した<a href="http://www.blogcustomize.com/customize_html_reference.html" target="_blank" title="HTML関数リファレンス - ブログカスタマイズ">【SeesaaブログHTML関数リファレンス】</a>や<a href="http://vitoro.up.seesaa.net/image/seesaatag.txt" target="_blank" title="テキストファイル「seesaatag.txt」">【Seesaa独自タグメモ】</a>を見ると「記事タイトル」と「ブログ名」らしい。すなわち、記事のタイトルしか入力されていなかった「seesaa_article_subject」にブログ名を追加する。さらに「：So-netブログ」も追加すれば、次のように自動的に入力されるようにすることもできる。 <blockquote> シェアボタン機能追加とキャンペーンのお知らせ：What's new?：So-netブログ http://t.co/QhBv4oH </blockquote> 　私の場合は私が改良したJavascriptファイルを利用することで、「Tweet」ボタンをクリックした時に開くウィンドウのテキストボックスに「記事のタイトル - 正己の異論・反論記事のURL」の形で自動的に入力されているようにすることができるし、もっと好みのテキストが入力されているようにすることもできる。シェアボタンの仕様が今のまま変わらないのなら、ソネブロの開発者に<a href="https://blog.so-net.ne.jp/_js/bookmark.js" target="_blank" title="シェアボタン用Javascript">bookmark.js</a>を変更してもらう必要は無い。しかし、頻繁に仕様が変わって<a href="https://blog.so-net.ne.jp/_js/bookmark.js" target="_blank" title="シェアボタン用Javascript">bookmark.js</a>も変わるようなら、私が改良したJavascriptファイルも変える必要があって面倒なので、できれば、私もソネブロで提供されている<a href="https://blog.so-net.ne.jp/_js/bookmark.js" target="_blank" title="シェアボタン用Javascript">bookmark.js</a>を使いたい。なぜ、トップページなどで「Tweet」ボタンをクリックした時に開くウィンドウのテキストボックスに記事のタイトルが入力されない仕様にしたのか分からないが、URLは記事のURLが自動的に入力されるのだから、テキスト部分も記事のタイトルが入力されるように変更して欲しい。 　実は「シェアボタン」機能はソネブロに提供されなくても、自分でブログのカスタマイズができる人なら自分で設置することができる。自分で設置すれば自分好みにすることもできる。私の場合は、以前から記事についてツイッターでツイートするためのボタンを記事の右上に設置していた。<a href="http://twitter.com/about/resources/tweetbutton" target="_blank" title="Twitter / ツイートボタン">ツイートボタン</a>の存在を知ってから改良したが、私が私のブログ記事についてツイートする場合は、そちらを使うだろう。これまでに私のブログ記事について私以外にツイートしてくれた人がいないようなので、「Twitter」の他に「mixi」「はてなブックマーク」「Facebook」のボタンが含まれる「シェアボタン」を設置しても意味が無いかもしれない。それでも、せっかく提供してくれたのだから設置してみた。「Tweet」ボタンをクリックした際の動作を変更したのも私以外の人が使うことを前提にしている。この改良に意味があったか無かったか…。でも自己満足にはなった。 <a name="more"></a> 追記（2011/3/8）： 　ソネブロさんが希望通りに変更してくれたらしい。 <blockquote> ■2月15日追記：一部機能修正 ブログのトップページから「Tweet」ボタンを押した場合にも、ツイート内容に各記事のタイトルが引用されるよう改修を行いました。（ご指摘をお寄せいただいたお客様へお礼申し上げます） <cite><a href="http://blog-wn.blog.so-net.ne.jp/2011-01-13" target="_blank">（シェアボタン機能追加とキャンペーンのお知らせ：What's new?：So-netブログ）</a></cite> </blockquote> 　ありがとうございました。m(_ _)m 追記（2011/3/8）： 　今回のbookmark.jpの変更は document.title から article.subject＋”：” を引いた doctitle をarticle.subjectに足して、「article.subject：doctitle」としている。個別エントリーのdocument.titleが「記事名：ブログ名：So-net blog」であることを前提にして、「記事名：」を削除した「ブログ名：So-net blog」を「記事名」の後に「：」と「ブログ名：So-net blog」を追加している。 <blockquote style="font-size:75%;"> var doctitle = document.title; var twitter_seesaa_article_subject = seesaa_article_subject + '：'; var doctitle = doctitle.replace(twitter_seesaa_article_subject,''); document.write('<li><a href="http://twitter.com/share" class="twitter-share-button" data-url="' + seesaa_article_page_url + '" data-text="' + seesaa_article_subject + '：' + doctitle + '" data-count="none">Tweet</a><script type="text/javascript" src="http://platform.twitter.com/widgets.js"></script></li>'); </blockquote> 　だから、私のブログのようにdocument.titleが「記事名 - ブログ名：So-net blog」の場合は「記事名：」が無いので「記事名」は削除されず、「記事名：記事名 - ブログ名：So-net blog」となってしまう。 　トップページは「ブログ名：So-net blog」だから、「記事名：」を追加しても「記事名：ブログ名：So-net blog」となる。 　しばらくは、その異常な状態にしておく。ご容赦願いたい。 追記（2011/3/8）： 　たぶん、次のように修正すれば問題は解決する。（3/29にこれではトップページから「Tweet」ボタンを押した場合に問題が生じることを確認した。） <blockquote style="font-size:75%;"> <del> var doctitle = document.title; var doctitle = doctitle.replace(seesaa_article_subject,''); document.write('<li><a href="http://twitter.com/share" class="twitter-share-button" data-url="' + seesaa_article_page_url + '" data-text="' + seesaa_article_subject + doctitle + '" data-count="none">Tweet</a><script type="text/javascript" src="http://platform.twitter.com/widgets.js"></script></li>'); </del> </blockquote> 追記（2011/3/29）： 　ソネブロさんの方針を最大限に尊重した方法での改善策が見つからなかったので、とりあえず、自分のサイトにアップロードしたJavascriptを利用することにした。 </article> <article> <h1>PDFファイルの中を検索できないしテキストをコピーできない</h1> 正己 — Wed, 29 Dec 2010 23:42:17 +0900 　Windowsで<a href="http://match.seesaa.jp/afr.pl?hid=25&sid=self:000214442277&k=PostScript&ic=utf8" class="affiliate-link" target="_blank">PostScript</a>ファイルをビットマップ画像に変換せずに見られるようになり、MacintoshのOS9.2.2でプリント時にPostScriptファイルとして保存できることを知ったので、Macのドローソフトで作った画像をWindowsで利用できるようにEPS形式で保存することにした。Macで一般的なPICT形式でもQuickTimeに付属するPictureViewerを使えばWindowsでもベクターイメージのままで拡大したり縮小したりしても綺麗に見ることができるが、Windows内に無いフォントは表示できないし機種依存文字の違いがあるので同じフォントをWindowsにインストールしても表示できない文字がある。EPS形式ならMacで見ていたように表示してくれる。ドローソフトで見ていたように拡大しても縮小しても綺麗である。だから、EPS形式で移すことに決めた。 　しかし、EPS形式でWindowsに移してGSview 4.9でPDF形式に変換してAdobe Reader 9.4.1で見て、テキスト部分を選択してクリップボードにコピーしてテキストエディタ貼り付けたとき、日本語が全くコピーできず、英数字や記号の羅列が貼り付けられた。後に、Adobe Reader内で日本語の検索ができないことも分かった。 　この不具合を無くそうとかなりの時間を費やしたのだが、残念ながら対処法は見つからなかった。 　諦めたわけではないが、この問題はいったん終わりにしようと思い、頭を整理する目的、興味のある人への情報提供の目的、ブログを見た人が対処法を教えてくれるかもしれないという期待から、日本語テキストを検索できないしコピーもできないPDFファイルと、そのPDFファイルの元になったPostScriptファイルを、作成時の設定と共にアップロードしておく。 <ol> <li> <div><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101229/20101229_Mac_1111.eps" target="_blank" title="「フォント代用なし、EPS内容確認なし、PostScript：レベル２と３、フォントの保持：すべて、優先フォーマット：True Type」で作成したEPSファイル">20101229_Mac_1111.eps</a></div> <div><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101229/20101229_Mac_1111.pdf" target="_blank" title="「フォント代用なし、EPS内容確認なし、PostScript：レベル２と３、フォントの保持：すべて、優先フォーマット：True Type、pdfwrite」で作成したPDFファイル">20101229_Mac_1111.pdf</a></div> <div style="font-size:75%;"> 設定：Macでは、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_1_1.png" target="_blank" title="20101229_1_1.png">フォント代用なし</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_2_1.png" target="_blank" title="20101229_2_1.png">EPS内容確認なし、PostScript：レベル２と３、フォントの保持：すべて</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_3_1.png" target="_blank" title="20101229_3_1.png">優先フォーマット：True Type</a>でEPSを作成。Windowsの <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_4_1.png" target="_blank" title="20101229_4_1.png">GSview 4.9のpdfwrite</a>でPDFに変換。 </div> <div> <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_1_1.png" target="_blank" title="20101229_1_1.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_2_1.png" target="_blank" title="20101229_2_1.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_3_1.png" target="_blank" title="20101229_3_1.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_4_1.png" target="_blank" title="20101229_4_1.png"> </a> </div> </li> <li> <div><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101229/20101229_Mac_1211.eps" target="_blank" title="「フォント代用なし、EPS Mac拡張内容確認、PostScript：レベル２と３、フォントの保持：すべて、優先フォーマット：True Type」で作成したEPSファイル">20101229_Mac_1211.eps</a></div> <div><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101229/20101229_Mac_1211.pdf" target="_blank" title="「フォント代用なし、EPS Mac拡張内容確認、PostScript：レベル２と３、フォントの保持：すべて、優先フォーマット：True Type、pdfwrite」で作成したPDFファイル">20101229_Mac_1211.pdf</a></div> <div style="font-size:75%;"> 設定：Macでは、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_1_1.png" target="_blank" title="20101229_1_1.png">フォント代用なし</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_2_2.png" target="_blank" title="20101229_2_2.png">EPS Mac拡張内容確認、PostScript：レベル２と３、フォントの保持：すべて</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_3_1.png" target="_blank" title="20101229_3_1.png">優先フォーマット：True Type</a>でEPSを作成。Windowsの <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_4_1.png" target="_blank" title="20101229_4_1.png">GSview 4.9のpdfwrite</a>でPDFに変換。 </div> <div> <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_1_1.png" target="_blank" title="20101229_1_1.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_2_2.png" target="_blank" title="20101229_2_2.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_3_1.png" target="_blank" title="20101229_3_1.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_4_1.png" target="_blank" title="20101229_4_1.png"> </a> </div> </li> <li> <div><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101229/20101229_Mac_1311.eps" target="_blank" title="「フォント代用なし、EPS Mac標準内容確認、PostScript：レベル２と３、フォントの保持：すべて、優先フォーマット：True Type」で作成したEPSファイル">20101229_Mac_1311.eps</a></div> <div><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101229/20101229_Mac_1311.pdf" target="_blank" title="「フォント代用なし、EPS Mac標準内容確認、PostScript：レベル２と３、フォントの保持：すべて、優先フォーマット：True Type、pdfwrite」で作成したPDFファイル">20101229_Mac_1311.pdf</a></div> <div style="font-size:75%;"> 設定：Macでは、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_1_1.png" target="_blank" title="20101229_1_1.png">フォント代用なし</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_2_3.png" target="_blank" title="20101229_2_3.png">EPS Mac標準内容確認認、PostScript：レベル２と３、フォントの保持：すべて</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_3_1.png" target="_blank" title="20101229_3_1.png">優先フォーマット：True Type</a>でEPSを作成。Windowsの <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_4_1.png" target="_blank" title="20101229_4_1.png">GSview 4.9のpdfwrite</a>でPDFに変換。 </div> <div> <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_1_1.png" target="_blank" title="20101229_1_1.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_2_3.png" target="_blank" title="20101229_2_3.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_3_1.png" target="_blank" title="20101229_3_1.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_4_1.png" target="_blank" title="20101229_4_1.png"> </a> </div> </li> <li> <div><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101229/20101229_Mac_1411.ps" target="_blank" title="「フォント代用なし、PostScript作業、PostScript：レベル２と３、フォントの保持：すべて、優先フォーマット：True Type」で作成したEPSファイル">20101229_Mac_1411.ps</a></div> <div><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101229/20101229_Mac_1411.pdf" target="_blank" title="「フォント代用なし、PostScript作業、PostScript：レベル２と３、フォントの保持：すべて、優先フォーマット：True Type、pdfwrite」で作成したPDFファイル">20101229_Mac_1411.pdf</a></div> <div style="font-size:75%;"> 設定：Macでは、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_1_1.png" target="_blank" title="20101229_1_1.png">フォント代用なし</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_2_4.png" target="_blank" title="20101229_2_4.png">PostScript作業、PostScript：レベル２と３、フォントの保持：すべて</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_3_1.png" target="_blank" title="20101229_3_1.png">優先フォーマット：True Type</a>でEPSを作成。Windowsの <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_4_1.png" target="_blank" title="20101229_4_1.png">GSview 4.9のpdfwrite</a>でPDFに変換。 </div> <div> <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_1_1.png" target="_blank" title="20101229_1_1.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_2_4.png" target="_blank" title="20101229_2_4.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_3_1.png" target="_blank" title="20101229_3_1.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_4_1.png" target="_blank" title="20101229_4_1.png"> </a> </div> </li> <li> <div><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101229/20101229_Mac_1511.eps" target="_blank" title="「フォント代用なし、EPS内容確認なし、PostScript：レベル２と３、フォントの保持：なし、優先フォーマット：True Type」で作成したEPSファイル">20101229_Mac_1511.eps</a></div> <div>20101229_Mac_1511.pdf（作成できなかった）</div> <div style="font-size:75%;"> 設定：Macでは、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_1_1.png" target="_blank" title="20101229_1_1.png">フォント代用なし</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_2_5.png" target="_blank" title="20101229_2_5.png">EPS内容確認なし、PostScript：レベル２と３、フォントの保持：なし</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_3_1.png" target="_blank" title="20101229_3_1.png">優先フォーマット：True Type</a>でEPSを作成。Windowsの <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_4_1.png" target="_blank" title="20101229_4_1.png">GSview 4.9のpdfwrite</a>でPDFに変換。 </div> <div> <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_1_1.png" target="_blank" title="20101229_1_1.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_2_5.png" target="_blank" title="20101229_2_5.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_3_1.png" target="_blank" title="20101229_3_1.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_4_1.png" target="_blank" title="20101229_4_1.png"> </a> </div> </li> <li> <div><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101229/20101229_Mac_1121.eps" target="_blank" title="「フォント代用なし、EPS内容確認なし、PostScript：レベル２と３、フォントの保持：すべて、優先フォーマット：Type 1」で作成したEPSファイル">20101229_Mac_1121.eps</a></div> <div><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101229/20101229_Mac_1121.pdf" target="_blank" title="「フォント代用なし、EPS内容確認なし、PostScript：レベル２と３、フォントの保持：すべて、優先フォーマット：Type 1、pdfwrite」で作成したPDFファイル">20101229_Mac_1121.pdf</a></div> <div style="font-size:75%;"> 設定：Macでは、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_1_1.png" target="_blank" title="20101229_1_1.png">フォント代用なし</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_2_1.png" target="_blank" title="20101229_2_1.png">EPS内容確認なし、PostScript：レベル２と３、フォントの保持：すべて</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_3_2.png" target="_blank" title="20101229_3_2.png">優先フォーマット：Type 1</a>でEPSを作成。Windowsの <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_4_1.png" target="_blank" title="20101229_4_1.png">GSview 4.9のpdfwrite</a>でPDFに変換。 </div> <div> <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_1_1.png" target="_blank" title="20101229_1_1.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_2_1.png" target="_blank" title="20101229_2_1.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_3_2.png" target="_blank" title="20101229_3_2.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_4_1.png" target="_blank" title="20101229_4_1.png"> </a> </div> </li> <li> <div><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101229/20101229_Mac_2131.eps" target="_blank" title="「フォント代用あり、EPS内容確認なし、PostScript：レベル２と３、フォントの保持：すべて、優先フォーマット：Type 1（Type42フォーマットを作成しない）」で作成したEPSファイル">20101229_Mac_2131.eps</a></div> <div><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101229/20101229_Mac_2131.pdf" target="_blank" title="「フォント代用あり、EPS内容確認なし、PostScript：レベル２と３、フォントの保持：すべて、優先フォーマット：Type 1（Type42フォーマットを作成しない）、pdfwrite」で作成したPDFファイル">20101229_Mac_2131.pdf</a></div> <div style="font-size:75%;"> 設定：Macでは、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_1_2.png" target="_blank" title="20101229_1_2.png">フォント代用あり</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_2_1.png" target="_blank" title="20101229_2_1.png">EPS内容確認なし、PostScript：レベル２と３、フォントの保持：すべて</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_3_3.png" target="_blank" title="20101229_3_3.png">優先フォーマット：Type 1（Type42フォーマットを作成しない）</a>でEPSを作成。Windowsの <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_4_1.png" target="_blank" title="20101229_4_1.png">GSview 4.9のpdfwrite</a>でPDFに変換。 </div> <div> <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_1_2.png" target="_blank" title="20101229_1_2.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_2_1.png" target="_blank" title="20101229_2_1.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_3_3.png" target="_blank" title="20101229_3_3.png"> </a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_4_1.png" target="_blank" title="20101229_4_1.png"> </a> </div> </li> </ol> 　Macintosh OS9.2.2側では、用紙設定の「PostScript オプション」で「フォント代用」は半角の英数字に関してだけらしいのでチェックを入れても入れなくても変わらないと思うが、チェックを入れないほうが安心である。 　プリントの「ファイルとして保存」の所ではフォーマットが４種類ある。「PostScript作業」を選べば一度に全ページをPostScriptに変換できるようだがEPS形式ではなく、プレビュー画像が必要なら「EPS Mac標準内容確認」などの方が良いらしい。「EPS Mac標準内容確認」は72dpiのビットマップデータを含むらしい。「EPS Mac拡張内容確認」はQuickDrawイメージを含むらしくプレビューなどはPICT画像で変形しても歪まないらしい。しかし、WindowsではPICTのベクターイメージを扱えるソフトがほとんど無いのではないだろうか。「EPS内容確認なし」はMacでは一般的に使われるだろう「EPS Mac拡張内容確認」からPICTイメージを取り除いたものなのだろう。これを選ぶなら「PostScript作業」を選んだ方が良いような気がするが、詳細は分からない。「PostScriptレベル」については「レベル３」が良いらしい。「レベル２と３」で「レベル３」だけを選択できないことによる問題はよく分からない。「フォントの保持」も「なし」「すべて」「標準１３フォント以外」「PPDファイルに無いフォントのみ」の４種類あって、上の例のように「なし」を選ぶとWindowsで見ることができなくなるようである。PostScriptプリンタに内蔵されてないフォントをファイル内に保存するか否かの選択らしい。フォントの種類が異なるWindowsで見るためには「すべて」を選んでおくのが無難だろう。 　プリントの「フォント設定」パネルの「フォント・ダウンロード」の「優先フォーマット」は「フォントをダウンロードする必要があるときに、Type 1 または TrueType フォーマットのどちらかをドライバに選択させる」らしい（<a href="http://developer.apple.com/jp/technotes/tn1165.html" target="_blank" title="Introducing the LaserWriter 8 Driver version 8.6.5">参照</a>）。ファイルで保存するときに関係あるとは思えないが「TrueType」を選んでおく方が無難な気がする。なぜならば、Type1フォントだと元のTrueTypeフォントと外観が異なったり、PDFファイル内で検索できないのかもしれないからである（<a href="http://kb2.adobe.com/jp/cps/219/219039.html" target="_blank" title="Acrobat Distiller/PDFWriter：Acrobat Distiller と Acrobat PDFWriter でのフォントの扱い">参照</a>）。「Type42フォーマットを作成しない」の選択があるが、この「Type42」とは「TrueTypeフォントをPostScriptプリンタで処理するための形式」らしい（<a href="http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A9%E3%83%B3%E3%83%88#.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E5.BD.A2.E5.BC.8F.EF.BC.88.E3.81.BE.E3.81.9F.E3.81.AF.E5.88.A9.E7.94.A8.E3.81.A7.E3.81.8D.E3.82.8B.E3.82.B7.E3.82.B9.E3.83.86.E3.83.A0.EF.BC.89.E3.81.AB.E3.82.88.E3.82.8B.E5.88.86.E9.A1.9E" target="_blank" title="フォント - Wikipedia">参照</a>）。また、「True Type フォントを Type 42 フォント（ネイティブともいう）で送信すると、TrueType フォントの外観が保持され、Type 1 フォントで置き換えられないようにする」らしく、テキストを検索できるようにするには「Type42」を使うのが最適らしい（<a href="http://kb2.adobe.com/jp/cps/219/219039.html" target="_blank" title="Acrobat Distiller/PDFWriter：Acrobat Distiller と Acrobat PDFWriter でのフォントの扱い">参照</a>）。ただ、「他の要素が影響することにより、検索できないテキストに変換されてしまう場合があります」（<a href="http://kb2.adobe.com/jp/cps/230/230452.html" target="_blank" title="Acrobat Distiller におけるフォントの扱いについて（Acrobat 8）">参照</a>）ということらしく、上の例では色が変わっている「私のブログ：」などはPDFファイルでテキスト部分を選択できなくなっているので関係あるかもしれない。とにかく、「Type42フォーマットを作成しない」はチェックしない方が良さそうである。むしろ、「常にType42フォーマットを作成する」があれば、その方が良さそうである。 　ところで、これを書いている間に、上の「20101229_Mac_1111.pdf」を開いてプロパティのフォントタブを見たら次のようになっていた。 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_Mac_1111.png" target="_blank" title="20101229_Mac_1111.pdfのプロパティのフォントタブ ">（クリックで拡大）</a> 　種類の所に「Type 1」とある。検索できないのはこれが原因だろうか。 　さて、EPSファイルをPDFに変換する仕組みに問題があるのなら、Windowsで作成したEPSファイルでも日本語テキストの検索やコピーができないはずである。 　と、ここまで書いてからWindowsで同様のEPSファイルを作成してPDFファイルに変換してみた。日本語テキストの検索もコピーもできなかった。以前はできたのだが、それはTeraPadで作成したテキストファイルをプリント時にEPSファイルで出力してPDFに変換したのだった。その時は検索もコピーもできた。今回はFirefox 3.6.13で閲覧している私のサイトを印刷時にファイルへ出力して実験した。Windowsでも問題が生じたり生じなかったりするようである。 　ファイルは次の通り。 <ol> <li> <div><a href="http://groups.yahoo.co.jp/group/self7777/files/20101229/20101229_Win_1.eps" target="_blank" title="Windows XPで、プリンタ名は「Acrobat Distiller J」、PostScript出力オプション「EPS」、TrueTypeフォントダウンロードオプション「Native TrueType」で作成したEPSファイル">20101229_Win_1.eps</a></div> <div><a href="http://groups.yahoo.co.jp/group/self7777/files/20101229/20101229_Win_1.pdf" target="_blank" title="20101229_Win_1.epsをPDFに変換">20101229_Win_1.pdf</a></div> <div style="font-size:75%;"> 設定の画像： <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_Win_1_1.png" target="_blank" title="20101229_Win_1_1.png">20101229_Win_1_1.png</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_Win_1_2.png" target="_blank" title="20101229_Win_1_2.png">20101229_Win_1_2.png</a> </div> <div style="font-size:75%;"> EPF作成時の警告メッセージ： <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_Win_1_3.png" target="_blank" title="20101229_Win_1_3.png">20101229_Win_1_3.png</a>、 </div> <div style="font-size:75%;"> 「文書のプロパティ」の「フォント」タブ： <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_Win_1_4.png" target="_blank" title="20101229_Win_1_4.png">20101229_Win_1_4.png</a>、 </div> </li> <li> <div><a href="http://groups.yahoo.co.jp/group/self7777/files/20101229/20101229_Win_2.eps" target="_blank" title="Windows XPで、プリンタ名は「Acrobat Distiller J」、PostScript出力オプション「印刷処理が速くなるよう最適化」、TrueTypeフォントダウンロードオプション「Native TrueType」で作成したEPSファイル">20101229_Win_2.eps</a></div> <div><a href="http://groups.yahoo.co.jp/group/self7777/files/20101229/20101229_Win_2.pdf" target="_blank" title="20101229_Win_2.epsをPDFに変換">20101229_Win_2.pdf</a></div> <div style="font-size:75%;"> 設定の画像： <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_Win_1_1.png" target="_blank" title="20101229_Win_1_1.png">20101229_Win_1_1.png</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_Win_2_2.png" target="_blank" title="20101229_Win_2_2.png">20101229_Win_2_2.png</a> </div> <div style="font-size:75%;"> EPF作成時の警告メッセージは無く、「文書のプロパティ」の「フォント」タブの画像は 20101229_Win_1.pdf と同じ。 </div> </li> <li> <div><a href="http://groups.yahoo.co.jp/group/self7777/files/20101229/20101229_Win_3.eps" target="_blank" title="Windows XPで、プリンタ名は「Acrobat Distiller J」、PostScript出力オプション「印刷処理が速くなるよう最適化」、TrueTypeフォントダウンロードオプション「自動」で作成したEPSファイル">20101229_Win_3.eps</a></div> <div><a href="http://groups.yahoo.co.jp/group/self7777/files/20101229/20101229_Win_3.pdf" target="_blank" title="20101229_Win_1.epsをPDFに変換">20101229_Win_3.pdf</a></div> <div style="font-size:75%;"> 設定の画像： <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_Win_1_1.png" target="_blank" title="20101229_Win_1_1.png">20101229_Win_1_1.png</a>、 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101229_Win_3_2.png" target="_blank" title="20101229_Win_3_2.png">20101229_Win_3_2.png</a> </div> <div style="font-size:75%;"> EPF作成時の警告メッセージは無く、「文書のプロパティ」の「フォント」タブの画像は 20101229_Win_1.pdf と同じ。 </div> </li> </ol> 　20101229_Win_1.eps を作成するときだけ警告メッセージが生じたが、ファイルの異常には気付かなかった。 　今回、Windowsで作成したEPSをGSview 4.9のpdfwriteでPDFに変換した場合も日本語テキストが検索できなかったりコピーできなかったりすることが分かったので、MacOS9.2.2だけの問題ではないと分かった。これでこの問題についての検討は終了する予定だったが、継続しなければならないようである。 <a name="more"></a> </article> <article> <h1>FirefoxのアドオンAdblockでWebメールが真っ白に</h1> 正己 — Mon, 27 Dec 2010 17:30:06 +0900 　先日、So-netのWebメールでSo-netから届いたメールに記載されたリンクをクリックした時にメールの本文が消えた。クリックしたURLは http://mailcenter.so-net.ne.jp/ で始まっていた。クリックしたら他のURLをクリックした場合と同様に新しいウィンドウが開いた。私の場合は新しいタブで開くように設定してあるが、その新しいタブの内容は次のようなものだった。 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101227.png" target="_blank" title="オブジェクトは移動しました"></a> 　別のページにジャンプさせる仕組みだと思って最初は気にしてなかった。待ってもジャンプしなかったがFirefoxのアドオンBlockSiteかAdblockでブロックされているからだろうと気にしなかった。しかし、Webメールに戻るとメールの本文が消えていて、再表示させようとしても方法が見つからず、リンクをクリックしたメール以外のメールまでも本文が表示されなくなってしまって焦った。 　原因が分からず、とりあえずWebメールのページを再読み込みして、Adblockを無効にしてからクリックしてみたら問題は生じなかった。Adblockが有効なままでも、Ctrlキーを押しながら左クリックしたり、マウスのホイールをクリックしてリンク先を開いた場合は問題なかった。Adblockを有効にして単独の左クリックで開く「オブジェクトは移動しました」と表示されているページのソースは、Ctrl+左クリックの時に表示されるサイトのものだった。 　いろいろと考えた後に、ふと「オブジェクトは移動しました」の下の「このオブジェクトはここ」の「ここ」をクリックしてみた。Ctrl+左クリックの時と同じ新しいページにジャンプした。メール本文は復活しなかったが、「ここ」のURLが気になって確認してみた。http://ad.scadnet.com/ で始まっていた。「ad.」が付いているサイトの画像などはAdblockでブロックしているはずである。フィルタを確認したら「http://ad.$~object-subrequest,~other」があった。この設定を無効にしたらAdblockが有効なままでも問題が生じなかった。 　翌日にYahoo!メール（ベータ版）で実験したら同じトラブルが生じた。こちらはページ全体が真っ白になってしまった。Yahoo!メールの旧バージョンなら生じない。本文表示のためにJavascriptを使っているWebメールで生じるトラブルではないかと思ったので、同じようにJavascriptを使っていそうな「Infoseek メール Beta」でも試してみた。メール本文が消えたりWebメールのページ全体が消えたりはしなかった。それならば、So-netのWebメールもYahoo!メール（ベータ版）も問題が生じないように改良できるはずである。 　<a href="https://addons.mozilla.org/ja/firefox/addon/1865/" target="_blank" title="Adblock Plus :: Add-ons for Firefox">Adblock</a>はページ内に広告などを表示させないアドオンであり、サイトへのアクセスを妨害する仕様ではないだろう。それならば、リンク先をWebメールと同じウィンドウの同じフレーム内に表示する仕様に問題があるのではないかと考えた。しかし、リンクしたURLの部分のソースを見たら「target="_blank"」が記載されている。同じウィンドウに表示するのではなく新しいウィンドウを開いて表示するはずで、そもそも「オブジェクトは移動しました」のページは新しいウィンドウに表示されている。Webメールの仕様に問題があるのかAdblockに問題があるのか分からなくなった。 　この不具合は「Firefox 3.6.13」と「Adblock <a href="http://match.seesaa.jp/afr.pl?hid=25&sid=self:000214442277&k=Plus&ic=utf8" class="affiliate-link" target="_blank">Plus</a> 1.3.3」と「So-netのWebメール」あるいは「Yahoo!メール（ベータ版）」を同時に使っているときに生じた。Javascriptを使ったWebメールの構造は複雑だろうから、それらのWebメールを使わない再現実験は難しいだろうと思った。しかし、再現できるソースは簡単に作れた。Javascriptは使っていない。インラインフレーム（iframe）を使っているだけである。インラインフレームを使ったソースで実験する前に普通のフレームを使ったソースを作って実験した。アップロードしたので「Firefox 3.6.13」と「Adblock Plus 1.3.3」を同時に使っている人は次のサイトにアクセスすればフレームやページ全体が消える不具合を体験できる。試して欲しい。 <ul> <li><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101225/index1.html" target="_blank" title="So-netのWebメールで起こる本文消失の再現実験">インラインフレームの一部が消えるケース （So-netのWebメール風）</a></li> <li><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101225/index2.html" target="_blank" title="Yahoo!メール（ベータ版）で起こるページ全体が消失する不具合の再現実験">ページ全体が消えるケース （Yahoo!メール（ベータ版）風）</a></li> <li><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101225/index.html" target="_blank" title="リンクをクリックすることでフレームの境界線が端に移動することを確認する実験">普通のフレームを使ったケース （消失したフレームは境界線のドラッグで現れる）</a></li> <li><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101225/index0.html" target="_blank" title="リンクをクリックすることでフレームの境界線が端に移動することを確認する実験（noresizeを設定）">普通のフレームを使ったケース （noresizeを設定して境界線のドラッグを不可能にした）</a></li> </ul> 　それぞれのサイトには「target="_blank"」を使ったリンクと使わないリンクを用意してあるが、Adblockで「http://ad.$~object-subrequest,~other」というフィルタを有効にしている場合、どちらもフレームが消える。Adblockが「target="_blank"」を無視しているのだろうか。 　ところで、Adblockのフィルタの記述に関してはAdblock Plusのサイトの<a href="https://adblockplus.org/en/filters" target="_blank" title="Writing Adblock Plus filters">【Writing Adblock Plus filters】</a>に書いてある。 　私の乏しい英語能力で解釈したところ、「http://ad.$~object-subrequest,~other」の「$」は各フィルタのオプションを記述する前に付けるようである。「~」はフィルタを適用しない例外の前に付けるようである。「object-subrequest」は「requests started plugins like Flash」とあり、フラッシュのようなプラグインの開始に関係していそうである。「other」は「types of requests not covered in the list above」とあり、各オプションのどれにも当てはまらない場合に適用するようである。要するに、「http://ad.$~object-subrequest,~other」はフラッシュ以外のほとんどのケースで「ad.」で始まるドメインに存在する画像などのファイルを無視するようである。嬉しいフィルタである。しかし、「http://ad.」で始まるURLへのリンクをクリックした時にリンクが存在するページまで消してしまう仕様は変である。「target="_blank"」で新しいウィンドウを開くようになっている場合は新しいウィンドウ内に表示しなければ良いはずである。私が確認したのはバージョン「1.3.3」である。アップデートされて改善されるか注目したい。アップデートされる度に、上の実験サイトで確認したい。 <a name="more"></a> </article> <article> <h1>PhotoFiltre 6.5.1の自動トリミングにバグ？</h1> 正己 — Sun, 12 Dec 2010 08:43:18 +0900 　気まぐれで確認したら私が愛用している画像ソフト<a href="http://photofiltre.free.fr/" target="_blank" title="PhotoFiltre">PhotoFiltre</a>がVersion 6.5.1に更新されていた（<a href="http://photofiltre.free.fr/frames_en.htm" target="_blank" title="Graphisme et utilitaires">参照</a>）。<a href="http://self.blog.so-net.ne.jp/2009-11-20" target="_blank" title="PhotoFiltreでは２色のGIF画像を再保存できない？ - 正己の異論・反論">【PhotoFiltreでは２色のGIF画像を再保存できない？】</a>で確認した問題が改善されているかもしれないと期待して、早速インストールした。古いVersion 6.3.2は削除した。しかし、このアップデートは失敗だった。 　<a href="http://self.blog.so-net.ne.jp/2009-11-20" target="_blank" title="PhotoFiltreでは２色のGIF画像を再保存できない？ - 正己の異論・反論">【PhotoFiltreでは２色のGIF画像を再保存できない？】</a>と同様に青地に赤字で「正己」と書いた画像を作成しようとした。新規作成で大きな青色の下地を用意してから下地よりも小さな「正己」を書き、上下左右の余分な下地を削除するために「イメージ」メニューにある「自動トリミング」を選択した。しかし、下と右の下地は削除されるのに上と左の下地が削除されない。Version 6.3.2では上下左右の全ての余分な下地が削除されていた。しかし、Version 6.5.1では仕様変更なのかバグなのか分からないが、下と右の下地しか削除されない。単純な図形で確認すると次の図のような感じである。 <table border="1" summary="PhotoFiltre 6.5.1の「自動トリミング」" style="margin-bottom:12px;"><tbody> <tr> <td valign="top" align="left"></td> <td valign="top" align="left"></td> </tr> <tr> <td>自動トリミング前</td> <td>自動トリミング後</td> </tr> </tbody></table> 　このバグ（仕様変更？）はショックだった。私は「自動トリミング」で上下左右の余白を削除してから上下左右に同じ幅の余白を足すことで画像を中央に配置するテクニックを頻繁に使っていたからである。「白地に赤」の画像では上下左右の余白は削除された。「青地に赤」では「青地」を必要な画像の一部と認識したのかと思ったが、それでは下と右の余白が削除されるのは変である。 　では、<a href="http://self.blog.so-net.ne.jp/2009-11-20" target="_blank" title="PhotoFiltreでは２色のGIF画像を再保存できない？ - 正己の異論・反論">【PhotoFiltreでは２色のGIF画像を再保存できない？】</a>の問題はVersion 6.5.1で改善されたのだろうか。 　Version 6.3.2ではGIF画像は「インデックスカラー」のモードで開く。しかし、Version 6.5.1では「RGBカラー」のモードで開くようである。だから、再び「インデックスカラー」に変換してから出ないと再保存できない。その結果、『PhotoFiltreで「青地に赤」のGIF画像を作って保存した後に、再びPhotoFiltreで開いて、すぐに「名前を付けて保存」したら真っ青な画像になってしまった』という現象は無くなった。Version 6.3.2でも、「インデックスカラー」のモードで開いた画像を「RGBカラー」のモードに変換してから再び「インデックスカラー」変換すれば問題が生じなかったので、その一手間を省いた形である。しかし、面倒になった。「インデックスカラー」のモードのままで問題が生じない方が良い。再保存時に元のデータが消えてしまう最悪の事態は避けられるようになったが…。 　では、透過GIFではどうだろうか。<a href="http://self.blog.so-net.ne.jp/2009-11-10" target="_blank" title="GIMPとPhotoFiltreの透過GIFで頭が混乱 - 正己の異論・反論">【GIMPとPhotoFiltreの透過GIFで頭が混乱】</a>で書いたようなトラブルは生じないのだろうか。確認してみた。 　Version 6.3.2では透過GIF画像は透過GIFのまま「インデックスカラー」のモードで開く。それはVersion 6.5.1でも変わらなかった。そして再保存してみたら、<a href="http://self.blog.so-net.ne.jp/2009-11-10" target="_blank" title="GIMPとPhotoFiltreの透過GIFで頭が混乱 - 正己の異論・反論">【GIMPとPhotoFiltreの透過GIFで頭が混乱】</a>で書いたトラブルはそのまま残っていた。 　結局、Version 6.5.1になってもGIF画像に対するVersion 6.3.2の問題は残ったままで、「自動トリミング」の問題が追加されたので、Version 6.5.1にアップデートする必要性は無くなったし、むしろアップデートしない方が良い。しかし、私はアップデートしてしまった。<a href="http://photofiltre.free.fr/" target="_blank" title="PhotoFiltre">PhotoFiltreのサイト</a>に古いバージョンは置いてない。焦ったが、Googleで検索して<a href="http://photofiltre-6-3-1.jp.brothersoft.com/" target="_blank" title="PhotoFiltre 6.3.2 日本語ダウンロード - Brothersoft.jp">【PhotoFiltre 6.3.2 日本語ダウンロード - Brothersoft.jp】</a>というサイトを見つけた。このサイトからダウンロードすることが安全かどうか分からない。正式なサイトではないのでウィルスが混ざっていたらどうしようかと心配になる。しかし、Version 6.5.1を使い続けたくなかったのでここからVersion 6.3.2をダウンロードしてインストールした。通常のインストールとは違った不思議な動作だったが、とりあえずVersion 6.3.2は使えるようになった。 　ここで書いたことを確認したい人は、<a href="http://photofiltre.free.fr/" target="_blank" title="PhotoFiltre">PhotoFiltreのサイト</a>のインストーラーの無い「zip format」の方をダウンロードして解凍してフォルダの中のアイコンをクリックして起動すると良い。確認が終わったらフォルダごと削除すればアンインストールしたことになるようである。インストーラーを使ってインストールしてフォルダ名が同じVersion 6.3.2に上書きしてしまうトラブルを避けられる。 　GIF画像の問題は解決しなくても良いから、「自動トリミング」の問題が早く改善されてVersion 6.5.2になることを願っている。今度は問題が無いことを確認する前にVersion 6.3.2を削除しないように気を付けたいと思う。 <a name="more"></a> 追記（2010/12/12）： 　Version 6.3.2ではGIF画像を開いた後に「RGBカラー」のモードに変えても、同じ名前で拡張子が「.gif」のまま保存すれば、GIF画像として保存されるようである。再び開くと「インデックスカラー」のモードになっている。Version 6.5.1でも、再保存時に「インデックスカラー」のモードにしなくても拡張子が「.gif」のままならGIF画像として保存されるかもしれない。それならば、「RGBカラー」のモードに変える手間を省いた分、GIF画像の再保存時にデータが消失する不具合は解決されたと言える。 追記（2012/1/11）： 　2011/2/3にアップデートされた6.5.2では自動トリミングのバグは残っていたが、2012/1/6にアップデートされた6.5.3では自動トリミングのバグは無くなっていた。 </article> <article> <h1>Yahoo!グループを使う際にはSubjectの取り扱いに注意してください</h1> 正己 — Sun, 21 Nov 2010 11:37:37 +0900 　<a href="http://self.blog.so-net.ne.jp/2010-11-18" target="_blank" title="Yahoo!グループでSubjectが文字化けする原因">【Yahoo!グループでSubjectが文字化けする原因】</a>ではYahoo!グループのメーリングリストを使っていて送信時には問題が無いのに受信するとSubjectの一部が文字化けする現象（追記：<a href="http://groups.yahoo.co.jp/group/selfmirror7777/messages" target="_blank" title="Yahoo!グループ: 正己の倉庫掲示板">サンプル</a>）について書いた。その後もYahoo!グループで確認のための実験を続けたら文字化け以外にも異常な症状があることに気付いた。ここでは、その実験結果をメモしておく。 　Yahoo!グループではSubjectに<a href="http://help.yahoo.co.jp/help/jp/groups/settings/settings-16.html" target="_blank" title="Yahoo!グループヘルプ - 件名の見出しとは">【件名の見出し】</a>と<a href="http://help.yahoo.co.jp/help/jp/groups/settings/settings-39.html" target="_blank" title="Yahoo!グループヘルプ - 件名の見出しにメッセージ番号を追加するには">【メッセージ番号】</a>を追加することができる。この「メッセージ番号」を追加する設定にしておくとここで書くような異常が生じるようである。「メッセージ番号」を追加する設定にしてないユーザーは異常には気付かないだろう。Yahoo!グループのスタッフもYahoo!グループを使ってなかったり使っていても「メッセージ番号」を追加する設定にしてなければ気付かず、改善しようとする気にならないだろう。 　まずは、Subjectに「件名の見出し」として[groupname]を追加し、「メッセージ番号」は追加しない場合には次のようになる。 <ul> <li>送信時： あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOyQ9GyhC?= =?ISO-2022-JP?B?GyRCJD8kQSREJEYkSCRyJDUkOyRrSn1LIRsoQg==?= </li> <li>受信時（No.64）： [groupname] あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> [groupname] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOyQ9GyhC?= =?ISO-2022-JP?B?GyRCJD8kQSREJEYkSCRyJDUkOyRrSn1LIRsoQg==?= </li> </ul> 　このメール（No.64）に返信すると次のようになる。 <ul> <li>送信時： Re: [groupname] あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Re: [groupname] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxGyhC?= =?ISO-2022-JP?B?GyRCJDMkNSQ3JDkkOyQ9JD8kQSREJEYkSCRyJDUkOyRrSn1LIRsoQg==?= </li> <li>受信時（No.65）： Re: [groupname] あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Re: [groupname] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxGyhC?= =?ISO-2022-JP?B?GyRCJDMkNSQ3JDkkOyQ9JD8kQSREJEYkSCRyJDUkOyRrSn1LIRsoQg==?= </li> </ul> 　文字化けなど異常は見られない。 　メール（No.64）に返信する際に[groupname]の位置を変えると次のようになる。 <ul> <li>送信時： Re: あ[groupname]いうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Re: =?ISO-2022-JP?B?GyRCJCIbKEJbZ3JvdXBuYW1lXRskQiQkJCYkKCQqGyhC?= =?ISO-2022-JP?B?GyRCJCskLSQvJDEkMyQ1JDckOSQ7JD0kPyRBJEQkRiRIJHIkNSQ7GyhC?= =?ISO-2022-JP?B?GyRCJGtKfUshGyhC?= </li> <li>受信時（No.66）： Re: あ[groupname]いうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Re: =?ISO-2022-JP?B?GyRCJCIbKEJbZ3JvdXBuYW1lXRskQiQkJCYkKCQqGyhC?= =?ISO-2022-JP?B?GyRCJCskLSQvJDEkMyQ1JDckOSQ7JD0kPyRBJEQkRiRIJHIkNSQ7GyhC?= =?ISO-2022-JP?B?GyRCJGtKfUshGyhC?= </li> </ul> 　[groupname]はSubject冒頭にも「Re: 」の後ろにも付かず、送信時に移動した「あ」と「い」の間に残ったままである。このことから、Subject内に[groupname]が在るかどうか検索して在った場合は放っておくプログラムだと思われる。検索のために一度デコードしているだろう。メール（No.65）がデコードせずに[groupname]の存在を確認できるのとは異なる。 　次に、Subjectに「件名の見出し」として[groupname]を追加し、「メッセージ番号」も追加する設定で実験した。 <ul> <li>送信時： あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOyQ9GyhC?= =?ISO-2022-JP?B?GyRCJD8kQSREJEYkSCRyJDUkOyRrSn1LIRsoQg==?= </li> <li>受信時（No.67）： [groupname][00067] あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> [groupname][00067] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOyQ9GyhC?= =?ISO-2022-JP?B?GyRCJD8kQSREJEYkSCRyJDUkOyRrSn1LIRsoQg==?= </li> </ul> 　このメール（No.67）に返信すると次のようになる。 <ul> <li>送信時： Re: [groupname][00067] あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Re: [groupname][00067] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0bKEI=?= =?ISO-2022-JP?B?GyRCJC8kMSQzJDUkNyQ5JDskPSQ/JEEkRCRGJEgkciQ1JDska0p9GyhC?= =?ISO-2022-JP?B?GyRCSyEbKEI=?= </li> <li>受信時（No.68）： Re: [groupname][00068] あいうえおかきくけこさしすせそたちつてとをさ;$kJ}?法 </li> <li style="font-size:75%;"> Re: [groupname][00068] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0bKEIbJEIkLyQxJDMkNSQ3JDkkOyQ9JD8kQSREJEYkSCRyJDUk?= =?ISO-2022-JP?B?OyRrSn0bKEIbJEJLIRsoQg==?= </li> </ul> 　「させる方法」が「さ;$kJ}?法」に文字化けしている。「メッセージ番号」の部分を変更するためにデコードする必要が無く、エンコードされて送信されたメールのSubjectをそのまま使えば良いのに、そうしてないのだろう。 　メール（No.67）を同じメーリングリスト宛に転送すると次のようになる。 <ul> <li>送信時： Fwd: [groupname][00067] あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Fwd: [groupname][00067] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrGyhC?= =?ISO-2022-JP?B?GyRCJC0kLyQxJDMkNSQ3JDkkOyQ9JD8kQSREJEYkSCRyJDUkOyRrGyhC?= =?ISO-2022-JP?B?GyRCSn1LIRsoQg==?= </li> <li>受信時（No.69）： Fwd: [groupname][00069] あいうえおかきくけこさしすせそたちつてとをさ;$k?方法 </li> <li style="font-size:75%;"> Fwd: [groupname][00069] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrGyhCGyRCJC0kLyQxJDMkNSQ3JDkkOyQ9JD8kQSREJEYkSCRyJDUk?= =?ISO-2022-JP?B?OyRrGyhCGyRCSn1LIRsoQg==?= </li> </ul> 　やはり「させる方法」の所が文字化けしているが、メール（No.68）と異なり「さ;$k?方法」と化けている。これは返信時に付く「Re:」と転送時に付く「Fwd:」とでは文字数が異なるためだと思われる。No.68とNo.69とではThunderbirdを使った送信時からエンコードされた結果が異なっている。 　メール（No.66）のようにメール（No.67）に返信する際に[groupname][00067]の位置を変えると次のようになる。 <ul> <li>送信時： Re: あ[groupname][00067]いうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Re: =?ISO-2022-JP?B?GyRCJCIbKEJbZ3JvdXBuYW1lXVswMDA2N10bJEIkJBsoQg==?= =?ISO-2022-JP?B?GyRCJCYkKCQqJCskLSQvJDEkMyQ1JDckOSQ7JD0kPyRBJEQkRiRIGyhC?= =?ISO-2022-JP?B?GyRCJHIkNSQ7JGtKfUshGyhC?= </li> <li>受信時（No.70）： Re: あ[groupname][00070]いうえおかきくけこさしすせそたちつてとr$5$;$kJ}K!? </li> <li style="font-size:75%;"> Re: =?ISO-2022-JP?B?GyRCJCIbKEI=?=[groupname][00070]=?ISO-2022-JP?B?GyRCJCQbKEIbJEIkJiQoJCokKyQtJC8kMSQzJDUkNyQ5JDskPSQ/JEEkRCRGJEgbKEIbJEIk?= =?ISO-2022-JP?B?ciQ1JDska0p9SyEbKEI=?= </li> </ul> 　送信時に[groupname][00067]を含めてエンコードしているのにYahoo!グループは全角文字の所だけをエンコードしているようである。そして、「てとをさせる方法」が「てとr$5$;$kJ}K!?」に文字化けしている。また、メール（No.66）と同様に、[groupname][00070]は「あ」と「い」の間に残っている。 　返信時に「件名の見出し」と「メッセージ番号」の位置を変える必要が無いではないかと思われるかもしれないが、私は次のようにSubjectを変更し、Subjectの末尾に返信元のSubjectを付加することがあるので、「件名の見出し」と「メッセージ番号」の位置が変わった状態になる。 <ul> <li>送信時： 返信時に件名を変える (Re: [groupname][00067] あいうえおかきくけこさしすせそたちつてとをさせる方法) </li> <li style="font-size:75%;"> =?ISO-2022-JP?B?GyRCSlY/Ljt+JEs3b0w+JHJKUSQoJGsbKEIgKFJlOiBbZ3Jv?= =?ISO-2022-JP?B?dXBuYW1lXVswMDA2N10gGyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNRsoQg==?= =?ISO-2022-JP?B?GyRCJDckOSQ7JD0kPyRBJEQkRiRIJHIkNSQ7JGtKfUshGyhCKQ==?= </li> <li>受信時（No.71）： 返信時に件名を変える (Re: [groupname][00071] あいうえおかきくけこさしすせそたちつてとをさ;$kJ}K!?) </li> <li style="font-size:75%;"> =?ISO-2022-JP?B?GyRCSlY/Ljt+JEs3b0w+JHJKUSQoJGsbKEI=?= (Re: [groupname][00071] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNRsoQhskQiQ3JDkkOyQ9JD8kQSREJEYkSCRyJDUk?= =?ISO-2022-JP?B?OyRrSn1LIRsoQg==?=) </li> </ul> 　返信元の「メッセージ番号」が変わってしまった。これは以前に見たことがある。当時は変だと思ったのだが深く分析することなく流していた。この実験で「こういうことだったのか」とようやく分かった。また、当然のように文字化けが生じていて「させる方法」が「さ;$kJ}K!?」になっている。 　さて、メール（No.70）では[groupname][00067]の位置を変えて返信したのだが、[groupname]と[00067]を分離して位置を変えると次のようになる。 <ul> <li>送信時： Re: あ[groupname]いうえお[00067]かきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Re: =?ISO-2022-JP?B?GyRCJCIbKEJbZ3JvdXBuYW1lXRskQiQkJCYkKCQqGyhC?= =?ISO-2022-JP?B?WzAwMDY3XRskQiQrJC0kLyQxJDMkNSQ3JDkkOyQ9JD8kQSREJEYkSBsoQg==?= =?ISO-2022-JP?B?GyRCJHIkNSQ7JGtKfUshGyhC?= </li> <li>受信時（No.72）： Re: あ[groupname][00072]かきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Re: =?ISO-2022-JP?B?GyRCJCIbKEI=?=[groupname][00072]=?ISO-2022-JP?B?GyRCJCskLSQvJDEkMyQ1JDckOSQ7JD0kPyRBJEQkRiRIGyhCGyRCJHIkNSQ7JGtKfUshGyhC?= </li> </ul> 　文字化けしてないし、メッセージ番号[00072]が件名の見出し[groupname]の直後に移動していて、一見良さそうだが、文字化けしてないのは連続した全角文字数が少なくなったからであり、致命的なトラブルも生じている。送信時に[groupname]と[00067]の間にあった「いうえお」が消えている。「メッセージ番号」を「件名の見出し」の直後に置くアルゴリズムだからだろうが、Subjectの一部を消してしまうのは明らかに異常な仕様である。 　メール（No.72）の現象を極端に再現したのが次のメールである。 <ul> <li>送信時： Re: [groupname] あいうえおかきくけこさしすせそたちつてとをさせる方法[00067] </li> <li style="font-size:75%;"> Re: [groupname] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxGyhC?= =?ISO-2022-JP?B?GyRCJDMkNSQ3JDkkOyQ9JD8kQSREJEYkSCRyJDUkOyRrSn1LIRsoQlsw?= =?ISO-2022-JP?B?MDA2N10=?= </li> <li>受信時（No.73）： Re: [groupname][00073] </li> <li style="font-size:75%;"> Re: [groupname][00073] </li> </ul> 　Subjectの全角文字が全て消えてしまった。 　次に、「件名の見出し」をSubjectに追加せず、「メッセージ番号」だけ追加する設定も実験しておいた。 <ul> <li>送信時： あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOyQ9GyhC?= =?ISO-2022-JP?B?GyRCJD8kQSREJEYkSCRyJDUkOyRrSn1LIRsoQg==?= </li> <li>受信時（No.74）： [00074] あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> [00074] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOyQ9GyhC?= =?ISO-2022-JP?B?GyRCJD8kQSREJEYkSCRyJDUkOyRrSn1LIRsoQg==?= </li> </ul> 　このメール（No.74）に返信すると次のようになる。 <ul> <li>送信時： Re: [00074] あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Re: [00074] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNRsoQg==?= =?ISO-2022-JP?B?GyRCJDckOSQ7JD0kPyRBJEQkRiRIJHIkNSQ7JGtKfUshGyhC?= </li> <li>受信時（No.75）： Re: [00075] あいうえおかきくけこさしすせそたちつてとをさ;$kJ}K!? </li> <li style="font-size:75%;"> Re: [00075] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNRsoQhskQiQ3JDkkOyQ9JD8kQSREJEYkSCRyJDUk?= =?ISO-2022-JP?B?OyRrSn1LIRsoQg==?= </li> </ul> 　「させる方法」が「さ;$kJ}K!?」に文字化けしている。「件名の見出し」だけを追加した場合の返信（No.65）では文字化けしてなかったことから、文字化けの原因は「メッセージ番号」を追加（変更時）するプログラムにあるのだろう。 　では、メール（No.73）のように「メッセージ番号」をSubjectの末尾に置いたらどうなるか。 <ul> <li>送信時： Re: あいうえおかきくけこさしすせそたちつてとをさせる方法 [00074] </li> <li style="font-size:75%;"> Re: =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOxsoQg==?= =?ISO-2022-JP?B?GyRCJD0kPyRBJEQkRiRIJHIkNSQ7JGtKfUshGyhCIFswMDA3NF0=?= </li> <li>受信時（No.76）： Re: あいうえおかきくけこさしすせそたちつてとをさ;$kJ}K!? [00076] </li> <li style="font-size:75%;"> Re: =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOxsoQhskQiQ9JD8kQSREJEYkSCRyJDUk?= =?ISO-2022-JP?B?OyRrSn1LIRsoQg==?= [00076] </li> </ul> 　文字化け（「させる方法」→「さ;$kJ}K!?」）するのは相変わらずだが、さすがにメール（No.73）のようにSubjectの全部（No.72では一部）が消されてしまう現象は生じない。「件名の見出し」が存在しないお陰である。 　さて、Yahoo!グループヘルプの<a href="http://help.yahoo.co.jp/help/jp/groups/settings/settings-16.html" target="_blank" title="Yahoo!グループヘルプ - 件名の見出しとは">【件名の見出しとは】</a>に<a href="http://help.yahoo.co.jp/help/jp/groups/groups-68.html" target="_blank" title="Yahoo!グループヘルプ - 確認されている不具合について">【確認されている不具合について】</a>へのリンクがあり、見ると、「件名に日本語が含まれていると、見出しが文字化けしたり、重複して表示されてしまう場合があります。」と書いてある。「見出し」とは「件名の見出し」のことだろう。アルファベットで構成されている[groupname]では文字化けしそうにないので、「件名の見出し」を日本語が含まれている[正己]に変えて実験してみた。「件名の見出し」を[]などで囲まず「正己」などと日本語だけにすると「件名の見出し」以外の部分と区別しにくくなるので注意が必要である。好みの問題かもしれないが…。 <ul> <li>送信時： あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOyQ9GyhC?= =?ISO-2022-JP?B?GyRCJD8kQSREJEYkSCRyJDUkOyRrSn1LIRsoQg==?= </li> <li>受信時（No.78）： [正己] あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> [=?ISO-2022-JP?B?GyRCQDU4ShsoQg==?=] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOyQ9GyhC?= =?ISO-2022-JP?B?GyRCJD8kQSREJEYkSCRyJDUkOyRrSn1LIRsoQg==?= </li> </ul> 　このメール（No.78）に返信すると次のようになる。 <ul> <li>送信時： Re: [正己] あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Re: =?ISO-2022-JP?B?WxskQkA1OEobKEJdIBskQiQiJCQkJiQoJCokKyQtGyhC?= =?ISO-2022-JP?B?GyRCJC8kMSQzJDUkNyQ5JDskPSQ/JEEkRCRGJEgkciQ1JDska0p9GyhC?= =?ISO-2022-JP?B?GyRCSyEbKEI=?= </li> <li>受信時（No.79）： Re: [正己] あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Re: =?ISO-2022-JP?B?WxskQkA1OEobKEJdIBskQiQiJCQkJiQoJCokKyQtGyhC?= =?ISO-2022-JP?B?GyRCJC8kMSQzJDUkNyQ5JDskPSQ/JEEkRCRGJEgkciQ1JDska0p9GyhC?= =?ISO-2022-JP?B?GyRCSyEbKEI=?= </li> </ul> 　文字化けなど異常は見られなかった。 　「件名の見出し」とSubjectの例が悪いのかもしれないので、Yahoo!グループヘルプの<a href="http://help.yahoo.co.jp/help/jp/groups/settings/settings-16.html" target="_blank" title="Yahoo!グループヘルプ - 件名の見出しとは">【件名の見出しとは】</a>にあるサンプルで実験してみた。 <ul> <li>送信時： 思い出も新生活もグループで共有！告知号 </li> <li style="font-size:75%;"> =?ISO-2022-JP?B?GyRCO1ckJD1QJGI/N0A4M2gkYiUwJWshPCVXJEc2Jk0tGyhC?= =?ISO-2022-JP?B?GyRCISo5cENOOWYbKEI=?= </li> <li>受信時（No.80）： [Yahoo!グループ] 思い出も新生活もグループで共有！告知号 </li> <li style="font-size:75%;"> [Yahoo!=?ISO-2022-JP?B?GyRCJTAlayE8JVcbKEI=?=] =?ISO-2022-JP?B?GyRCO1ckJD1QJGI/N0A4M2gkYiUwJWshPCVXJEc2Jk0tGyhC?= =?ISO-2022-JP?B?GyRCISo5cENOOWYbKEI=?= </li> </ul> 　このメール（No.80）に返信すると次のようになる。 <ul> <li>送信時： Re: [Yahoo!グループ] 思い出も新生活もグループで共有！告知号 </li> <li style="font-size:75%;"> Re: =?ISO-2022-JP?B?W1lhaG9vIRskQiUwJWshPCVXGyhCXSAbJEI7VyQkGyhC?= =?ISO-2022-JP?B?GyRCPVAkYj83QDgzaCRiJTAlayE8JVckRzYmTS0hKjlwQ045ZhsoQg==?= </li> <li>受信時（No.81）： Re: [Yahoo!グループ] 思い出も新生活もグループで共有！告知号 </li> <li style="font-size:75%;"> Re: =?ISO-2022-JP?B?W1lhaG9vIRskQiUwJWshPCVXGyhCXSAbJEI7VyQkGyhC?= =?ISO-2022-JP?B?GyRCPVAkYj83QDgzaCRiJTAlayE8JVckRzYmTS0hKjlwQ045ZhsoQg==?= </li> </ul> 　文字化けなど異常は見られなかった。「件名の見出し」だけをSubjectに追加する設定では、「件名の見出し」に日本語が含まれていても文字化けは生じないのかもしれない。 　Yahoo!グループヘルプの<a href="http://help.yahoo.co.jp/help/jp/groups/settings/settings-16.html" target="_blank" title="Yahoo!グループヘルプ - 件名の見出しとは">【件名の見出しとは】</a>にあるサンプルに「メッセージ番号」も追加する設定で実験してみた。 <ul> <li>送信時： 思い出も新生活もグループで共有！告知号 </li> <li style="font-size:75%;"> =?ISO-2022-JP?B?GyRCO1ckJD1QJGI/N0A4M2gkYiUwJWshPCVXJEc2Jk0tGyhC?= =?ISO-2022-JP?B?GyRCISo5cENOOWYbKEI=?= </li> <li>受信時（No.82）： [Yahoo!グループ][00082] 思い出も新生活もグループで共有！告知号 </li> <li style="font-size:75%;"> [Yahoo!=?ISO-2022-JP?B?GyRCJTAlayE8JVcbKEI=?=][00082] =?ISO-2022-JP?B?GyRCO1ckJD1QJGI/N0A4M2gkYiUwJWshPCVXJEc2Jk0tGyhC?= =?ISO-2022-JP?B?GyRCISo5cENOOWYbKEI=?= </li> </ul> 　このメール（No.82）に返信すると次のようになる。 <ul> <li>送信時： Re: [Yahoo!グループ][00082] 思い出も新生活もグループで共有！告知号 </li> <li style="font-size:75%;"> Re: =?ISO-2022-JP?B?W1lhaG9vIRskQiUwJWshPCVXGyhCXVswMDA4Ml0gGyRCO1cbKEI=?= =?ISO-2022-JP?B?GyRCJCQ9UCRiPzdAODNoJGIlMCVrITwlVyRHNiZNLSEqOXBDTjlmGyhC?= </li> <li>受信時（No.83）： Re: [Yahoo!グループ][00083] 思い出も新生活もグループで共有！告知号 </li> <li style="font-size:75%;"> Re: [Yahoo!=?ISO-2022-JP?B?GyRCJTAlayE8JVcbKEI=?=][00083] =?ISO-2022-JP?B?GyRCO1cbKEIbJEIkJD1QJGI/N0A4M2gkYiUwJWshPCVXJEc2Jk0tISo5cENOOWYbKEI=?= </li> </ul> 　この例では返信時に文字化けが生じない。それはSubject内の「連続した全角文字」の数が少ないからだろう。私が実験してきた No.68 などでは２６文字であるのに対して、No.83 では１９文字しかない。 　このメール（No.82）のSubjectに一文字追加して返信してみた。 <ul> <li>送信時： Re: [Yahoo!グループ][00082] 思い出も新生活もグループで共有！告知号よ </li> <li style="font-size:75%;"> Re: =?ISO-2022-JP?B?W1lhaG9vIRskQiUwJWshPCVXGyhCXVswMDA4Ml0gGyRCO1cbKEI=?= =?ISO-2022-JP?B?GyRCJCQ9UCRiPzdAODNoJGIlMCVrITwlVyRHNiZNLSEqOXBDTjlmGyhC?= =?ISO-2022-JP?B?GyRCJGgbKEI=?= </li> <li>受信時（No.90）： Re: [Yahoo!グループ][00090] 思い出も新生活もグループで共有！告知号h? </li> <li style="font-size:75%;"> Re: [Yahoo!=?ISO-2022-JP?B?GyRCJTAlayE8JVcbKEI=?=][00090] =?ISO-2022-JP?B?GyRCO1cbKEIbJEIkJD1QJGI/N0A4M2gkYiUwJWshPCVXJEc2Jk0tISo5cENOOWYbKEIbJEIk?= =?ISO-2022-JP?B?aBsoQg==?= </li> </ul> 　「告知号よ」が「告知号h?」に文字化けしている。Subject内の「連続した全角文字」の数を１９文字から２０文字に増やしただけで文字化けした。文字化けを避けるためには１９文字以内に収める必要があるかもしれないが、１９文字以内に収めたからといって文字化けしない保証はないし、２０文字以上でも運良く文字化けしないケースもあるかもしれない。 　また、文字化けするのは、上記のように「メッセージ番号」を変更するプログラムに原因があると思われるので、次のようにメール（No.90）では文字化けした文字数のメールで「件名の見出し」に日本語が含まれていても、「メッセージ番号」が付いていない状態なら、返信後に「件名の見出し」と「メッセージ番号」が追加されても文字化けは生じないだろう。 <ul> <li>送信時： 思い出も新生活もグループで共有！告知号よ </li> <li style="font-size:75%;"> =?ISO-2022-JP?B?GyRCO1ckJD1QJGI/N0A4M2gkYiUwJWshPCVXJEc2Jk0tGyhC?= =?ISO-2022-JP?B?GyRCISo5cENOOWYkaBsoQg==?= </li> <li>受信時（No.91）： [Yahoo!グループ][00091] 思い出も新生活もグループで共有！告知号よ </li> <li style="font-size:75%;"> [Yahoo!=?ISO-2022-JP?B?GyRCJTAlayE8JVcbKEI=?=][00091] =?ISO-2022-JP?B?GyRCO1ckJD1QJGI/N0A4M2gkYiUwJWshPCVXJEc2Jk0tGyhC?= =?ISO-2022-JP?B?GyRCISo5cENOOWYkaBsoQg==?= </li> </ul> 　文字化けなど異常は見られない。 　同様に、送信時に「件名の見出し」が付いた返信メールでも「メッセージ番号」が付いていない状態なら、「メッセージ番号」が追加されても文字化けは生じないだろう。 <ul> <li>送信時： Re: [Yahoo!グループ] 思い出も新生活もグループで共有！告知号よ </li> <li style="font-size:75%;"> Re: =?ISO-2022-JP?B?W1lhaG9vIRskQiUwJWshPCVXGyhCXSAbJEI7VyQkGyhC?= =?ISO-2022-JP?B?GyRCPVAkYj83QDgzaCRiJTAlayE8JVckRzYmTS0hKjlwQ045ZiRoGyhC?= </li> <li>受信時（No.92）： Re: [Yahoo!グループ][00092] 思い出も新生活もグループで共有！告知号よ </li> <li style="font-size:75%;"> Re: [Yahoo!=?ISO-2022-JP?B?GyRCJTAlayE8JVcbKEI=?=][00092] =?ISO-2022-JP?B?GyRCO1ckJBsoQhskQj1QJGI/N0A4M2gkYiUwJWshPCVXJEc2Jk0tISo5cENOOWYkaBsoQg==?= </li> </ul> 　文字化けなど異常は見られない。 　ちなみに、メール（No.67）に返信する際に[groupname]を削除して送信すると次のようになる。 <ul> <li>送信時： Re: [00067] あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Re: [00067] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNRsoQg==?= =?ISO-2022-JP?B?GyRCJDckOSQ7JD0kPyRBJEQkRiRIJHIkNSQ7JGtKfUshGyhC?= </li> <li>受信時（No.96）： [groupname][00096] Re: [00067] あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> [groupname][00096] Re: [00067] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNRsoQg==?= =?ISO-2022-JP?B?GyRCJDckOSQ7JD0kPyRBJEQkRiRIJHIkNSQ7JGtKfUshGyhC?= </li> </ul> 　[00067]は「メッセージ番号」と認識されなかったようである。「メッセージ番号」を変更するのではなく追加するだけだから文字化けも生じてない。 　メール（No.67）に返信する際に[00067]を[00001]に変えて送信する次のようなる。 <ul> <li>送信時： Re: [groupname][00001] あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Re: [groupname][00001] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0bKEI=?= =?ISO-2022-JP?B?GyRCJC8kMSQzJDUkNyQ5JDskPSQ/JEEkRCRGJEgkciQ1JDska0p9GyhC?= =?ISO-2022-JP?B?GyRCSyEbKEI=?= </li> <li>受信時（No.98）： Re: [groupname][00098] あいうえおかきくけこさしすせそたちつてとをさ;$kJ}?法 </li> <li style="font-size:75%;"> Re: [groupname][00098] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0bKEIbJEIkLyQxJDMkNSQ3JDkkOyQ9JD8kQSREJEYkSCRyJDUk?= =?ISO-2022-JP?B?OyRrSn0bKEIbJEJLIRsoQg==?= </li> </ul> 　[00001]が「メッセージ番号」と認識されて、[00098]に更新されたので文字化け（「させる方法」→「さ;$kJ}?法」）が生じている。 　メール（No.67）に返信する際に[00067]を[00001]に変えるだけでなく位置も変えて送信する次のようなる。 <ul> <li>送信時： Re: [groupname] あ[00001]いうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Re: [groupname] =?ISO-2022-JP?B?GyRCJCIbKEJbMDAwMDFdGyRCJCQkJhsoQg==?= =?ISO-2022-JP?B?GyRCJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOyQ9JD8kQSREJEYkSCRyGyhC?= =?ISO-2022-JP?B?GyRCJDUkOyRrSn1LIRsoQg==?= </li> <li>受信時（No.99）： Re: [groupname][00099]いうえおかきくけこさしすせそたちつてとをB$5$;$kJ}K!? </li> <li style="font-size:75%;"> Re: [groupname][00099]=?ISO-2022-JP?B?GyRCJCQkJhsoQhskQiQoJCokKyQtJC8kMSQzJDUkNyQ5JDskPSQ/JEEkRCRGJEgkchsoQhsk?= =?ISO-2022-JP?B?QiQ1JDska0p9SyEbKEI=?= </li> </ul> 　[00001]は「メッセージ番号」と認識されて[00099]に更新され、「件名の見出し」と「メッセージ番号」の間にある文字が削除される現象も現れて「あ」が消えている。また、「メッセージ番号」が変更されたので「てとをさせる方法」が「てとをB$5$;$kJ}K!?」に文字化けしている。 返信メールで文字化けが生じないようにする工夫 　最後に、返信時にYahoo!グループのメーリングリストで文字化けするようにエンコードされない工夫を書いておく。ただし、継続して確認したわけではないので「絶対に文字化けしない」と保証することはできない。 　返信メールを作成する際にSubjectから「件名の見出し」と「メッセージ番号」を削除して送信する。 　メール（No.67）に返信する際に「[groupname][00067] 」を削除して送信すると次のようになる。 <ul> <li>送信時： Re: あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Re: =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOxsoQg==?= =?ISO-2022-JP?B?GyRCJD0kPyRBJEQkRiRIJHIkNSQ7JGtKfUshGyhC?= </li> <li>受信時（No.100）： [groupname][00100] Re: あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> [groupname][00100] Re: =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOxsoQg==?= =?ISO-2022-JP?B?GyRCJD0kPyRBJEQkRiRIJHIkNSQ7JGtKfUshGyhC?= </li> </ul> 　ちなみに、上記メール（No.92）の例があるので、返信メールを作成する際ににSubjectから「メッセージ番号」を削除するだけでも大丈夫かと思ったが、大丈夫ではなかった。 　メール（No.67）に返信する際に[00067]を削除して送信すると次のようになる。 <ul> <li>送信時： Re: [groupname] あいうえおかきくけこさしすせそたちつてとをさせる方法 </li> <li style="font-size:75%;"> Re: [groupname] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxGyhC?= =?ISO-2022-JP?B?GyRCJDMkNSQ3JDkkOyQ9JD8kQSREJEYkSCRyJDUkOyRrSn1LIRsoQg==?= </li> <li>受信時（No.101）： Re: [groupname][00101] あいうえおかきくけこさしすせそたちつてとをさ;$kJ}K!? </li> <li style="font-size:75%;"> Re: [groupname][00101] =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxGyhCGyRCJDMkNSQ3JDkkOyQ9JD8kQSREJEYkSCRyJDUk?= =?ISO-2022-JP?B?OyRrSn1LIRsoQg==?= </li> </ul> 　「させる方法」が「さ;$kJ}K!?」に文字化けしている。 　以上、Yahoo!グループのメーリングリストにおけるSubjectの異常な振る舞いについて実験結果を述べてきた。このブログ記事がYahoo!グループ利用者の参考になれば幸いである。また、異常に気付いていないと思われるYahoo!グループの担当者がYahoo!グループの異常に気付いて改善してくれたのなら、書いて良かったと喜べるだろう。期待はできないので、私は上記メール（No.100）のような工夫で文字化けが生じないように注意しながらYahoo!グループを使いたいと思う。 <a name="more"></a> </article> <article> <h1>Yahoo!グループでSubjectが文字化けする原因</h1> 正己 — Thu, 18 Nov 2010 22:59:31 +0900 　先日<a href="http://groups.yahoo.co.jp/" target="_blank" title="Yahoo!グループ - 無料でメーリングリストを作成">Yahoo!グループ</a>内のメーリングリストでSubjectに文字化けのあるメールが届いた。送信者は私である。私が送信して文字化けしていないメールに返信したら文字化けして届いた。（追記：<a href="http://groups.yahoo.co.jp/group/selfmirror7777/messages" target="_blank" title="Yahoo!グループ: 正己の倉庫掲示板">サンプル</a>） 　一般的にYahoo!グループ内のメーリングリストで文字化けした場合、次の原因が考えられるらしい。 <blockquote> 投稿に関するお知らせが文字化けして配信される 一般的な文字化けの原因には以下のようなものがあります。 <ul> <li>Content-Transfer-Encoding: 8bitでの送信</li> <li>HTML形式でのメッセージ投稿</li> <li>本文中に「半角カタカナ」「機種依存文字」など電子メッセージ上で使用すべきではない文字が含まれている場合</li> </ul> これらの場合は、文字化けが生じることがあります。あらかじめご了承ください。 <cite><a href="http://help.yahoo.co.jp/help/jp/groups/messages/messages-17.html" target="_blank">（Yahoo!グループヘルプ - 投稿に関するお知らせが文字化けして配信される）</a></cite> </blockquote> 　どれも心当たりが無かった。問い合わせたが上記の回答が返ってくるだけで原因は分からなかった。 　と、ここまで書いた後にYahoo!グループヘルプに次のように書いてあるページを見つけた。 <blockquote> 確認されている不具合について Yahoo!グループでは、以下の不具合が確認されています。ご了承ください。 <ul><li> 投稿に関するお知らせの件名の見出しが正しく表示されない 投稿に関するお知らせの件名に日本語が含まれていると、見出しが文字化けしたり、重複して表示されてしまう場合があります。 英字の件名に変えたり、文字数を減らすことで解決する場合もあります。 </li></ul> <cite><a href="http://help.yahoo.co.jp/help/jp/groups/groups-68.html" target="_blank">（Yahoo!グループヘルプ - 確認されている不具合について）</a></cite> </blockquote> 　<del>既知の不具合だったことを</del>今になって知ったのだが（追記：ここで述べている不具合とは関係ない。「件名の見出し」は「件名」のことではなく（<a href="http://help.yahoo.co.jp/help/jp/groups/settings/settings-16.html" target="_blank" title="Yahoo!グループヘルプ - 件名の見出しとは">参照</a>）「件名の見出し」がアルファベットでも生じる）、問い合わせても原因が分からないのなら自分で考えるしかないと思って夕方から夜中までを費やして考えた（<a href="http://twilog.org/self7777/date-101117/asc" target="_blank" title="正己(@self7777)/2010年11月17日 - Twilog">参照</a>）ので、その結論をここに記録しておく。 　早い段階で諦めかけたのだがドラザキッド（@dorathekid999）さんに<a href="http://encodemaniax.com/" target="_blank" title="エンコードマニアックス - 各種エンコードやハッシュを一発作成">【エンコードマニアックス】</a>を教わって（<a href="http://twitter.com/dorathekid999/status/4826823011602432" target="_blank" title="Twitter / ドラザキッド: @self7777 表示→メッセージのソースを開いて ...">参照</a>）から大きく進展した。感謝している。 　さて、ここでは文字化けを再現したメールで報告するが、元になった送信メールのSubjectの日本語部分とソースは次の通りである。 <ul> <li>あいうえおかきくけこさしすせそたちつてとをさせる方法</li> <li style="font-size:75%;"> =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOyQ9GyhC?= =?ISO-2022-JP?B?GyRCJD8kQSREJEYkSCRyJDUkOyRrSn1LIRsoQg==?= </li> </ul> 　Yahoo!グループを経由して届いたときの文字コードは次の通りである。 <ul> <li>あいうえおかきくけこさしすせそたちつてとをさせる方法</li> <li style="font-size:75%;"> =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0kLyQxJDMkNSQ3JDkkOyQ9GyhC?= =?ISO-2022-JP?B?GyRCJD8kQSREJEYkSCRyJDUkOyRrSn1LIRsoQg==?= </li> </ul> 　変わってない。 　このメールに返信した時の送信済みトレイに残ったメールのSubjectの日本語部分は次のようになっている。 <ul> <li>あいうえおかきくけこさしすせそたちつてとをさせる方法</li> <li style="font-size:75%;"> =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0bKEI=?= =?ISO-2022-JP?B?GyRCJC8kMSQzJDUkNyQ5JDskPSQ/JEEkRCRGJEgkciQ1JDska0p9GyhC?= =?ISO-2022-JP?B?GyRCSyEbKEI=?= </li> </ul> 　ところが、Yahoo!グループを経由すると次のように変わる。 <ul> <li>あいうえおかきくけこさしすせそたちつてとをさ;$kJ}?法</li> <li style="font-size:75%;"> =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrJC0bKEIbJEIkLyQxJDMkNSQ3JDkkOyQ9JD8kQSREJEYkSCRyJDUk?= =?ISO-2022-JP?B?OyRrSn0bKEIbJEJLIRsoQg==?= </li> </ul> 　「させる方法」の所が「さ;$kJ}?法」と文字化けしている。 　返信ではなく転送でも文字化けする。送信済みトレイに残ったメールのSubjectの日本語部分は次のようになっている。 <ul> <li>あいうえおかきくけこさしすせそたちつてとをさせる方法</li> <li style="font-size:75%;"> =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrGyhC?= =?ISO-2022-JP?B?GyRCJC0kLyQxJDMkNSQ3JDkkOyQ9JD8kQSREJEYkSCRyJDUkOyRrGyhC?= =?ISO-2022-JP?B?GyRCSn1LIRsoQg==?= </li> </ul> 　返信時と少し違うことが分かる。これは返信時には「Re:」が付くのに対して転送時は「Fwd:」が付くためだろう。最初の文字からの文字数が半角で１文字異なるので、「ISO-2022-JP」の分割位置が変わり異なる結果になる。しかし、<a href="http://encodemaniax.com/" target="_blank" title="エンコードマニアックス - 各種エンコードやハッシュを一発作成">【エンコードマニアックス】</a>を使えば、同じ「あいうえおかきくけこさしすせそたちつてとをさせる方法」であることを確認できる。 　これがYahoo!グループを経由すると次のように変わる。 <ul> <li>あいうえおかきくけこさしすせそたちつてとをさ;$k方法</li> <li style="font-size:75%;"> =?ISO-2022-JP?B?GyRCJCIkJCQmJCgkKiQrGyhCGyRCJC0kLyQxJDMkNSQ3JDkkOyQ9JD8kQSREJEYkSCRyJDUk?= =?ISO-2022-JP?B?OyRrGyhCGyRCSn1LIRsoQg==?= </li> </ul> 　「させる方法」の所が「さ;$k方法」と文字化けしている。 　実は、最初に文字化けに気付いたメールはこちらの転送の方と同じである。Yahoo!グループではSubjectの冒頭に件名の見出し（例えば[selfmirror7777]）とメッセージ番号（例えば[00001]）を付けることができる。この長さが文字化けの仕方に影響している。 　さて、プログラマーでもなくbase64も理解できてない私にはSubjectのコードは意味不明な暗号である。テキストエディタにコピーしてじっくりと観察して次のことが分かった。 <ol> <li>「GyRC」と「GyhC」が繰り返して見られる。→４文字ずつ区切られているのか？</li> <li>終わり「?=」と始まり「 =?ISO-2022-JP?B?」を削除したら文字化けが解消された。→文字コードには誤りが無く分割の問題か？</li> <li>「=?ISO-2022-JP?B?OyRrGyhCGyRCSn1LIRsoQg==?=」は「;$k方法」になる。</li> <li>「=?ISO-2022-JP?B?GyRCJDUkOyRrGyhCGyRCSn1LIRsoQg==?=」は「させる方法」になる。</li> <li>「=?ISO-2022-JP?B?GyRCJDUkOyRrSn1LIRsoQg==?=」も「させる方法」になる。→「GyhCGyRC」は不要？</li> <li>「=?ISO-2022-JP?B?GyRCJDUk?= =?ISO-2022-JP?B?OyRrGyhCGyRCSn1LIRsoQg==?=」は「さ;$k方法」になる。→やはり「?= =?ISO-2022-JP?B?」による分割が問題？</li> <li>「=?ISO-2022-JP?B?GyRCJDUkOyRr?= =?ISO-2022-JP?B?GyhCGyRCSn1LIRsoQg==?=」は「させる方法」になる。→「OyRr」を前のブロックに移動しただけで文字化けが無くなったのだから、やはり分割位置の問題？</li> <li>「=?ISO-2022-JP?B?GyRCJDUkOyRr?= =?ISO-2022-JP?B?GyRCSn1LIRsoQg==?=」も「させる方法」になる。→「GyhC」は不要？</li> </ol> 　ここで、「GyRC」と「GyhC」が文字を表しているのではなく、文字列の最初と最後に付けるものではないかと想像して、<a href="http://www.google.co.jp/search?hl=ja&source=hp&biw=1280&bih=826&q=GyRC+GyhC&aq=f&aqi=&aql=&oq=&gs_rfai=" target="_blank" title="GyRC GyhC - Google 検索">「GyRC GyhC」</a>でググったら、<a href="http://homepage2.nifty.com/c_lang/sdk3/sdk_235.htm" target="_blank" title="猫でもわかるプログラミング　Windows SDK編第３部　第２３５章">【第２３５章 base64の基礎】</a>というサイトを見つけた。 　<a href="http://homepage2.nifty.com/c_lang/sdk3/sdk_235.htm" target="_blank" title="猫でもわかるプログラミング　Windows SDK編第３部　第２３５章">【第２３５章 base64の基礎】</a>を見て、base64で日本語をエンコードする手順が分かった。 　「GyRC」は「２バイト文字の始まりの合図」を表しているらしく、「GyhC」は「２バイト文字からASCII文字に変わる時」に現れるらしい。しかし、「GyRC」は現れるが「GyhC」が無いこともある。「GyhC」にエンコードする前のJISコード「0x1b, 0x28, 0x42」がSubjectを含む全ての文字列を２進法で表した後の「先頭から６ビットずつ切り直す」作業で一部が前の文字に組み込まれてしまうために残りの文字で別の文字列になるらしい。 　<a href="http://homepage2.nifty.com/c_lang/sdk3/sdk_235.htm" target="_blank" title="猫でもわかるプログラミング　Windows SDK編第３部　第２３５章">【第２３５章 base64の基礎】</a>を見て、「させる方法」を手動でエンコードしたくなった。その作業を経験することで、文字化けの原因が分かると思ったからである。 　結論は『「OyRr」の前で区切るということは「せ」の文字を分割していることになる。』である。また『JISコードの後ろのブロックで２バイト文字の始まりの合図「GyRC」(0x1b, 0x24, 0x42) が抜けている。』という問題もある。まとめると、『Yahoo!グループでは送信されたメールのSubjectで分割されているJISコードを一度合成してから処理して再度分割するのかもしれないが、再分割の際に「GyRC」や「GyhC」を無視するなどして、分割してはいけない所で分割してしまい文字化けを発生させている。（追記：あるいは再分割せずにメールサーバに送り、７６文字を超えていることでメールサーバーが機械的に分割することで不適切な所で分割されてしまって文字化けを発生させている。<a href="http://ameblo.jp/mingw/entry-10381427224.html" target="_blank" title="日本語メール送信｜そろそろホンキ出す">【参照】</a>）』ということだろう。（追記：ただし、この文字化けはSubjectの冒頭に件名の見出し（例えば[selfmirror7777]）とメッセージ番号（例えば[00001]）を付ける設定の時にしか起こらないかもしれないので、その見出しを付けたりメッセージ番号を付けたりするプログラムに問題があるのかもしれない。この不具合は返信時に「件名の見出し」と「メッセージ番号」を削除してから送信することで避けられるかもしれない。どちらか一方でも残して返信すると文字化けが生じることは確認した。） 　さて、手動で確認した「させる方法」のエンコードを以下に記録しておく。 <a name="more"></a><div style="font-size:75%;"> <ol> <li>「させる方法」のそれぞれのJISコードは「2435, 243B, 246B, 4A7D, 4B21」である。</li> <li>１バイトずつ横１列に表示すると「24, 35, 24, 3B, 24, 6B, 4A, 7D, 4B, 21」になる。</li> <li>２進法で表すと「00100100, 00110101, 00100100, 00111011, 00100100, 01101011, 01001010, 01111101, 01001011, 00100001」</li> <li>２バイト文字の始まりの合図「1b,24,42」（＝「00011011, 00100100, 01000010」）を前に付けて、２バイト文字からASCII文字に変わる合図「1b,28,42」（＝「00011011, 00101000, 01000010」）を後ろに付ける。</li> <li>「00011011, 00100100, 01000010, 00100100, 00110101, 00100100, 00111011, 00100100, 01101011, 01001010, 01111101, 01001011, 00100001, 00011011, 00101000, 01000010」</li> <li>先頭から６ビットずつ切り直す。最後が「10」で足りないので「0000」を加えて「100000」にする。</li> <li>「000110, 110010, 010001, 000010, 001001, 000011.010100, 100100, 001110, 110010, 010001, 101011, 010010, 100111, 110101, 001011, 001000, 010001, 101100, 101000, 010000, 100000」</li> <li>各組を１６進に戻すと「6, 32, 11, 2, 9, 3, 14, 24, E, 32, 11, 2B, 12, 27, 35, B, 8, 11, 2C, 28, 10, 20」</li> <li>１６進表現からは<a href="http://homepage2.nifty.com/c_lang/sdk3/sdk_235.htm" target="_blank" title="猫でもわかるプログラミング　Windows SDK編第３部　第２３５章">【第２３５章 base64の基礎】</a>の記号表を使って、その上の２進表現からは<a href="http://ja.wikipedia.org/wiki/Base64" target="_blank" title="Base64 - Wikipedia">Wikipedia</a>にある変換表を使って記号に置き換える。</li> <li>「G, y, R, C, J, D, U, k, O, y, R, r, S, n, 1, L, I, R, s, o, Q, g」</li> <li>４つずつ並べて「GyRC JDUk OyRr Sn1L IRso Qg==」</li> <li>「=?ISO-2022-JP?B?」と「?=」で挟んで「=?ISO-2022-JP?B?GyRCJDUkOyRrSn1LIRsoQg==?=」</li> <li>これを、<a href="http://encodemaniax.com/" target="_blank" title="エンコードマニアックス - 各種エンコードやハッシュを一発作成">【エンコードマニアックス】</a>で確認すると「させる方法」になる。</li> </ol> </div> </article> <article> <h1>改行の無いテキストファイルの文章をブラウザの右端で折り返す方法</h1> 正己 — Wed, 17 Nov 2010 12:05:28 +0900 　私は<a href="http://groups.yahoo.co.jp/" target="_blank" title="Yahoo!グループ - 無料でメーリングリストを作成">Yahoo!グループ</a>を使ってファイルを共有しつつ情報交換をしているのだが、そのファイル共有のための<a href="http://groups.yahoo.co.jp/local/info/guide/main/briefcase.html" target="_blank" title="Yahoo!グループ　チュートリアル - ファイルを共有しよう">「ブリーフケース」</a>を使っていて以前から面倒だと思っていたことがあった。それは共有されたテキストファイルの閲覧である。ブリーフケースではファイルをアップロードしなくてもテキストファイルを作成して共有できるし、アップロードし直さなくてもテキストファイルなら文章を変更できる。それは便利な機能だが読むときに不便なのである。 　<a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/20101116_1.txt" target="_blank" title="20101116_1.txt">【サンプル】</a>をFirefox 3.6.12やIE8で見てもらえば分かるとおり、文字列がウィンドウの右端で折り返されない。一段落が長い文章だったら、横スクロールバーを使って読み進めて、一段落を読み終わったら、一番左まで戻して読まなければいけない。面倒である。以前からこれを何とかしたいと思っていた。今回、ようやく解決策が見つかった。 　Firefox 3 を使っている場合、<a href="https://addons.mozilla.org/ja/firefox/addon/2351/" target="_blank" title="Toggle Word Wrap :: Add-ons for Firefox">【Toggle Word Wrap】</a>というアドオンが便利である。 　インストールした後にウィンドウの右端で折り返したいページを開いたら、メニューバーの「表示」から「<a href="http://match.seesaa.jp/afr.pl?hid=25&sid=self:000214442277&k=Word&ic=utf8" class="affiliate-link" target="_blank">Word</a> Wrap within <PRE>」を選択すれば良い。 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101117_1.png" target="_blank" title="Toggle Word Wrap for Firefoxの使い方">（クリックで拡大）</a> 　この「Toggle Word Wrap」というアドオンには<a href="https://addons.mozilla.org/ja/thunderbird/addon/2351/" target="_blank" title="Toggle Word Wrap :: Add-ons for Thunderbird">Thunderbird用</a>もある。私はURLが特定の文字数で勝手に改行されて気持ち悪かったので導入した（<a href="http://twitter.com/self7777/status/19406289491" target="_blank" title="Twitter / 正己: 一時的にWord Wrapをオフにするのにこのアドオンが使えそうだ。ウィンドウサイズで折り返してくれるので横スクロールも避けられる。→【Toggle Word Wrap :: Add-ons for Thunderbird】 http://bit.ly/c45ki6">参照</a>）。表示されている時は改行されていても送信されたメールでは改行コードが入らないはずだが…。メニューバーの「オプション」にある「Enable Word Wrap」のチェックを外すことでウィンドウの右端で改行されてウィンドウの途中の特定の文字数で勝手に改行されなくなる。もちろん、文章の部分は一行が長くならないように手動で改行しなければならない。 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/20101117_2.png" target="_blank" title="Toggle Word Wrap for Thunderbirdの使い方">（クリックで拡大）</a> 　さて、ファイルを共有しているメンバーの中にはFirefoxではなくIE8を使っている人もいる。IE8で<a href="https://addons.mozilla.org/ja/firefox/addon/2351/" target="_blank" title="Toggle Word Wrap :: Add-ons for Firefox">【Toggle Word Wrap】</a>のようなアドオンがないか探してみたが見つからなかった。他の解決策はないか探したみたら、ユーザースタイルシートを使う方法を見つけた（<a href="http://www.microsoft.com/japan/enable/training/ie8/webstyle.mspx" target="_blank" title="カスタムスタイルシートを使って Web ページの書式を設定する - マイクロソフトアクセシビリティ">参照</a>）。 　指定するスタイルシートに「pre {word-wrap: break-word;}」と記述すれば良い。これでウィンドウの右端で折り返される。文字の大きさや表示する幅など他のスタイルも指定できる。 　このユーザースタイルシートを使うか否かをメニューバーから切り替えられれば良いのだが、その方法は見つからなかった。ユーザースタイルシートを使いたくない場合に「インターネットオプション」のウィンドウをいちいち開いて解除していたら面倒である。あるいは、複数のユーザースタイルシートを見るサイトに応じて、あるいはメニューバーから切り替えられれば良いのだが、そのようなアドオンも見つけることができなかった。残念である。御存知の方は教えていただきたい。 <a name="more"></a> 　IE8では「表示」メニューから「ソース」を選択して、ソース画面の「書式」メニューで「右端で折り返す」をチェックする方法が良さそうである。 　しかし、ブックマークレットを使ってボタンをクリックするだけで切り替えることができれば、メニューバーのプルダウンメニューを操作するよりも楽かもしれない。そこで、ブックマークレットを作った。 　Javascriptの方針はFirefoxのアドオン【Toggle Word Wrap】を参考にした。このアドオンで改行した後にソースを見たら、ヘッダにpreタグのスタイルシートを追加しているだけだった。同じことをJavascriptで実現すれば良い。 　まずはFirefox用を作った。次のリンクをブックマークツールバーに追加すれば使える。 <a href="javascript:(function(){var%20str1='pre{white-space:pre-wrap!important;}';var%20str2='pre{white-space:pre!important;}';var%20header=document.getElementsByTagName('head').item(0);var%20ck=header.childNodes;var%20style=document.createElement('style');style.type='text/css';style.id='masamiprewrap';if(header.innerHTML.indexOf('masamiprewrap',0)!=-1){var%20i=-1;while(++i<ck.length){if(ck[i].nodeType!=1)continue;if(ck[i].id=='masamiprewrap'){header.removeChild(ck[i]);}}}else%20if(header.innerHTML.indexOf('pre-wrap',0)!=-1){style.innerHTML=str2;header.appendChild(style);}else{style.innerHTML=str1;header.appendChild(style);};})();" title="改行">改行（Firefox用）</a> 　上のブックマークレットはIE8では使えなかったので、Javascriptを少し変えて次のIE8用のブックマークレットも作った。お気に入りバーに追加すれば使える。 <a href="javascript:(function(){var%20str1='pre{word-wrap:break-word!important;}';var%20str2='pre{word-wrap:normal!important;}';var%20header=document.getElementsByTagName('head').item(0);var%20ck=header.childNodes;var%20style=document.createElement('style');style.type='text/css';style.id='masamiprewrap';if(header.innerHTML.indexOf('masamiprewrap',0)!=-1){var%20i=-1;while(++i<ck.length){if(ck[i].nodeType!=1)continue;if(ck[i].id=='masamiprewrap'){header.removeChild(ck[i]);}}}else%20if(header.innerHTML.indexOf('break-word',0)!=-1){style.styleSheet.cssText=str2;header.appendChild(style);}else{style.styleSheet.cssText=str1;header.appendChild(style);};})();" title="改行">改行（IE8用）</a> 　テキストファイル以外のページでクリックしてしまった場合にどのようなトラブルが生じるか調べてないので、不具合が起こってもご容赦願いたい。通常はクリックし直すことで元に戻るはずである。 追記（2011/8/18）： 　上記のブックマークレットがあれば不要かもしれないが、私が使っているFirefox3ではJSActionsのスクリプトとしても用意してある。ブックマークレットは、そこから改行を削除して半角スペースを%20にしたものである。そのスクリプトは次の通りである。 <div style="margin:14px 42px;font-size:75%;"> (function(){ var str1 = "pre { white-space: pre-wrap !important; word-wrap: break-word !important; }"; var str2 = "pre { white-space: pre !important; }"; var header = document.getElementsByTagName("head").item(0); var ck=header.childNodes; var style = document.createElement("style"); style.type = "text/css"; style.id = "masamiprewrap"; if (header.innerHTML.indexOf("masamiprewrap",0) !=-1){ var i=-1; while (++i < ck.length) { if (ck[i].nodeType!=1) continue; if (ck[i].id=="masamiprewrap"){ header.removeChild(ck[i]); } } } else if (header.innerHTML.indexOf("pre-wrap",0) !=-1){ style.innerHTML = str2; header.appendChild(style); } else { style.innerHTML = str1; header.appendChild(style); }; })(); </div> </article> <article> <h1>Thunderbirdでは引用部分の改行を元に戻せない</h1> 正己 — Fri, 29 Oct 2010 20:25:04 +0900 　先日、私の所に１行の長いメール（１段落を全く改行してないメール）が届いた。私は<a href="http://mozilla.jp/thunderbird/3.1.6/releasenotes/" target="_blank" title="Mozilla Thunderbird 3.1.6 リリースノート">Thunderbird</a>というメールソフトを使っているのだが、その<a href="http://match.seesaa.jp/afr.pl?hid=25&sid=self:000214442277&k=Thunderbird&ic=utf8" class="affiliate-link" target="_blank">Thunderbird</a>を使って返信する時に改行の扱いで困ったことが起こった。 　Thunderbirdでは送信メールを作成すると適当な所で自動的に改行して送信してくれる。例えば、次のような文字列を入力すると36文字目（や）と37文字目（ゆ）の間で自動的に改行してくれる。それはメールを作成している時だけでなく、送信されたメールも改行されている。 <blockquote> <div style="font-weight:bold;">入力文字列：</div> <div style="font-size:12px;"> あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほまみむめもやゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> <div style="font-weight:bold;">送信された文字列：</div> <div style="font-size:12px;"> あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほまみむめもや ゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> </blockquote> 　しかし、返信メールを作成する時の引用部分は自動的に改行されない。 <blockquote> <div style="font-weight:bold;">届いたメールの文字列が２行に分かれている場合の引用部分：</div> <div style="font-size:12px;"> > あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほまみむめもや > ゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> <div style="font-weight:bold;">届いたメールの１行の文字列が長い場合の引用部分：</div> <div style="font-size:12px;"> > あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほまみむめもやゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> </blockquote> 　36文字目（や）と37文字目（ゆ）の間で改行されたメールに返信する時は先頭の文字（あ）の前だけでなく37文字目（ゆ）の前に引用符「>」が付くが、改行されてなくて１行の文字列が長い場合は先頭の文字（あ）の前にしか引用符「>」が付かない。Thunderbirdでは編集中に横スクロールが表示される。編集中だけでなく、送信されたメールも自動的に改行されないので、手動で改行しないと１行の長いメールを送信してしまうことになる。 　そこで、１行の長いメールに返信する場合は引用部分を手動で改行する必要があるのだが、Thunderbirdでは、その編集が難しい。 　まず、「返信」ボタンを押した直後に作られたメールの引用部分は次の通り。 <blockquote> <div style="font-size:12px;"> > あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほまみむめもやゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> </blockquote> 　「こ」と「さ」の間にカーソルを移して「Enter」キーを１度だけ押すと次のようになる。 <blockquote> <div style="font-size:12px;"> > あいうえおかきくけこ さしすせそたちつてとなにぬねのはひふへほまみむめもやゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> </blockquote> 　なぜか、「こ」と「さ」の間に空白行が生じる。 　そこで、「さ」の前にカーソルを移して「Backspace」キーを１度だけ押すと次のようになる。 <blockquote> <div style="font-size:12px;"> > あいうえおかきくけこ さしすせそたちつてとなにぬねのはひふへほまみむめもやゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> </blockquote> 　「さ」の前の空白行が削除された。 　次に「こ」と「さ」の間の改行コードを削除するために、再び「さ」の前にカーソルを移して「Backspace」キーを１度だけ押す。すると見た目は次のようになる。 <blockquote> <div style="font-size:12px;"> > あいうえおかきくけこ さしすせそたちつてとなにぬねのはひふへほまみむめもやゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> </blockquote> 　最初に「さ」の前にカーソルを移して「Backspace」キーを１度だけ押して改行した時と変わってない。 　そこで、再び「さ」の前にカーソルを移して「Backspace」キーを１度だけ押す。すると次のように「こ」が削除されてしまう。 <blockquote> <div style="font-size:12px;"> > あいうえおかきくけ さしすせそたちつてとなにぬねのはひふへほまみむめもやゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> </blockquote> 　改行されてなかった最初の状態に戻せない。 　もう一度、届いたメールを選択して「返信」ボタンを押して最初から返信メールを作成する。最初の状態は次の通りである。 <blockquote> <div style="font-size:12px;"> > あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほまみむめもやゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> </blockquote> 　「こ」と「さ」の間にカーソルを移して「Enter」キーを１度だけ押すと次のようになる。 <blockquote> <div style="font-size:12px;"> > あいうえおかきくけこ さしすせそたちつてとなにぬねのはひふへほまみむめもやゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> </blockquote> 　「こ」と「さ」の間に空白行が生じたので、今度は空白行にカーソルを移して「Backspace」キーを１度だけ押す。すると次のようになる。 <blockquote> <div style="font-size:12px;"> > あいうえおかきくけこ さしすせそたちつてとなにぬねのはひふへほまみむめもやゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> </blockquote> 　やはり「さ」の前の空白行が削除された。 　次に「こ」と「さ」の間の改行コードを削除するために、今度も「さ」の前にカーソルを移して「Backspace」キーを１度だけ押す。すると見た目は次のようになり、やはり変わらない。 <blockquote> <div style="font-size:12px;"> > あいうえおかきくけこ さしすせそたちつてとなにぬねのはひふへほまみむめもやゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> </blockquote> 　そこで、再び「さ」の前にカーソルを移して「Backspace」キーを１度だけ押す。すると次のように「こ」が削除されてしまう。 <blockquote> <div style="font-size:12px;"> > あいうえおかきくけ さしすせそたちつてとなにぬねのはひふへほまみむめもやゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> </blockquote> 　改行されてなかった最初の状態に戻せない。 　実は、２度目の「Backspace」キーの後は見た目が変わってなくても「こ」と「さ」の間に改行コードは存在しない。見た目は改行されているが、見た目の２行目が長すぎて見た目の１行目の後ろに付けると見た目の１行目が長くなりすぎてしまうので見た目だけ改行されたままの状態にしているのである。テキストエディタなどにコピーすると次のように改行されていないことが分かる。 <blockquote> <div style="font-size:12px;"> > あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほまみむめもやゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> </blockquote> 　では、改行コードが削除されて見た目だけ改行された状態で送信すれば引用部分が長い１行として送信されるのであろうか。 　見た目が次のようになっているメールを自分宛に送信してみた。 <blockquote> <div style="font-size:12px;"> > あいうえおかきくけこ さしすせそたちつてとなにぬねのはひふへほまみむめもやゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> </blockquote> 　結果は次の通りである。 <blockquote> <div style="font-size:12px;"> > あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほまみむめもやゆよわをんがぎぐげご ざじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> </blockquote> 　「さ」から36文字目の「ご」の後で改行されている。 　改行などの編集作業をしなければ、次のように引用部分は１行のまま届く。 <blockquote> <div style="font-size:12px;"> > あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほまみむめもやゆよわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ </div> </blockquote> 　すなわち、返信メールの引用部分を一度でも改行してしまうと、「Backspace」キーでは元に戻せないのである。改行した直後ならば「編集」メニューの「元に戻す（Ctrl+Z）」で元に戻すことができるが、改行後に文章を書き加えるなど別の部分を編集した後では、「元に戻す（Ctrl+Z）」では書き加えた文章まで削除しなければいけないなど、改行後の作業をすべて取り消さなければいけなくなる。これは非常に不便である。 　私は返信用の長い文章を書いた後に引用部分の改行位置を変更しようとして上記のようなトラブルに遭った。例えば、上記の例では、最初は「ほ」と「ま」の間で改行したのだが、改行位置を「と」と「な」の間に変更したくなった。しかし、「ほ」と「ま」の間の改行が消えない。無理に消そうとすると「ほ」が削除されてしまう。興味のある方は実験してみてほしい。そのようなトラブルに遭い、何度も同じ文章を入力しなければいけないことになった。 　このようなトラブルに遭ったのは私だけだろうか。Googleで検索しても改善策を見つけることができなかった。Thunderbirdの開発者たちは気付いているのだろうか。それとも、気付いているが、当然の仕様とみなして気にしていないのだろうか。できれば「Backspace」キーで元に戻せるよう改良してもらいたい。無理なのだろうか。 <a name="more"></a> 追記（2010/10/30）： 　この問題は<a href="http://kengo.preston-net.com/archives/002157.shtml" target="_blank" title="Going My Way: Thunderbird利用時に任意のエディターでメールを編集できるエクステンション External Editor">【ここ】</a>で紹介されているExternal Editorというアドオンを使って外部エディタで編集することで対処することにした。 　引用部分で改行コードが削除されているのに見た目だけ改行されている状態は外部エディタで見ると改行されてないことが分かり、外部エディタを閉じるとThunderbirdのメール作成画面で見た目も改行されなくなる。すなわち、元に戻すことも可能になる。外部エディタで編集するので元に戻す必要もなくなるが。 </article> <article> <h1>モンティ・ホール問題：プレーヤーが選択する前</h1> 正己 — Sat, 04 Sep 2010 14:01:38 +0900 　ここでは、モンティ・ホール問題のシミュレーションとして紹介されている<a href="http://gascon.cocolog-nifty.com/blog/2007/09/flash_c2ac.html" target="_blank" title="Flash：モンティ･ホール問題: ガスコン研究所">【Flash：モンティ･ホール問題: ガスコン研究所】</a>と<a href="http://nameniku.blog71.fc2.com/blog-entry-358.html" target="_blank" title="ニートが頑張るブログ　モンティ・ホール問題フラッシュ">【ニートが頑張るブログ　モンティ・ホール問題フラッシュ】</a>のフラッシュの結果について考察する。 　モンティ・ホール問題については何度も書いてきたが（<a href="http://self.blog.so-net.ne.jp/tag/articles/%E3%83%A2%E3%83%B3%E3%83%86%E3%82%A3%E3%83%BB%E3%83%9B%E3%83%BC%E3%83%AB%E5%95%8F%E9%A1%8C" target="_blank" title="タグ：モンティ・ホール問題 - 正己の異論・反論">参照</a>）、<a href="http://self.blog.so-net.ne.jp/2006-09-16" target="_blank" title="モンティ・ホール問題の解法 - 正己の異論・反論">【モンティ・ホール問題の解法】</a>のようにベイズの定理を使って解く方法が中心だった。それは３囚人問題や変形３囚人問題（<a href="http://self.blog.so-net.ne.jp/2006-09-06" target="_blank" title="三囚人問題と変形三囚人問題 - 正己の異論・反論">参照</a>）と同型だと判断したからである。しかし<a href="http://self.blog.so-net.ne.jp/2006-09-20" target="_blank" title="モンティ・ホール問題：補足 - 正己の異論・反論">【モンティ・ホール問題：補足】</a>の頃に本当にベイズの定理を使って解いて良いのか、ベイズ解が正解なのかという疑問が生じた。 　<a href="http://self.blog.so-net.ne.jp/2006-09-20" target="_blank" title="モンティ・ホール問題：補足 - 正己の異論・反論">【モンティ・ホール問題：補足】</a>では、プレーヤーがＡのドアを選んだ後に司会者がＢまたはＣのドアを開ける前の状態では、Ｂが開いた場合とＣが開いた場合の両方を加重平均せねばならず、その結果、「選択を変えずに当たる確率」はプレーヤーがドアを選ぶ前から決まっていた「Ａのドアが当たりの確率（P(A)）」と同じになり、「選択を変えて当たる確率」は「Ａ以外のドアが当たりの確率（P(B)+P(C)）」と同じになることを示した。 　また<a href="http://self.blog.so-net.ne.jp/2008-08-10" target="_blank" title="モンティ・ホール問題：補足３ - 正己の異論・反論">【モンティ・ホール問題：補足３】</a>では、プレーヤーがＡのドアを選んだ後に司会者がＢまたはＣのドアを開ける前の状態では、ＢやＣのドアが当たりである確率もプレーヤーがドアを選ぶ前から変わってないことを示した。 　これらは全て、プレーヤーがドアを選んだ後のことで、プレーヤーがどのドアを選んでも傾向は変わらないとみなしていた。<a href="http://self.blog.so-net.ne.jp/2006-09-16" target="_blank" title="モンティ・ホール問題の解法 - 正己の異論・反論">【モンティ・ホール問題の解法】</a>ではプレーヤーが選ぶドアも含めて場合分けして考察しているが、最初にどのドアを選択しても同じ結果（ベイズ解）になることが示されている。実は、<a href="http://self.blog.so-net.ne.jp/2006-09-06" target="_blank" title="三囚人問題と変形三囚人問題 - 正己の異論・反論">【三囚人問題と変形三囚人問題】</a>の「追記（2006/9/9）」に次のような図へリンクしておいた。 <a href="http://self.blog.so-net.ne.jp/_images/blog/_e63/self/Monty01.png" target="_blank" title="モンティ・ホール問題と変形モンティ・ホール問題をプレーヤーの選択も含めて場合分けした円グラフ">（クリックで拡大）</a> 　この円グラフは一周で「確率＝１」である。一番内側の円はＡ，Ｂ，Ｃの各ドアが当たりである確率（P(A),P(B),P(C)）、その外側の円はプレーヤーが各ドアを選択する確率（P(sA),P(sB),P(sC)）、一番外側の円は司会者が各ドアを開く確率（P("-A"),P("-B"),P("-C")）を表している。 　一番左側（以下では「ケース１」と書く）の図は一般的なモンティ・ホール問題を解くための円グラフで各確率は次のようになっている。 <ol> <li>P(A)=P(B)=P(C)=1/3</li> <li>P(sA|A)=P(sB|A)=P(sC|A)=1/3</li> <li>P(sA|B)=P(sB|B)=P(sC|B)=1/3</li> <li>P(sA|C)=P(sB|C)=P(sC|C)=1/3</li> <li>P("-B"|sA,A)=P("-C"|sA,A)=1/2</li> <li>P("-A"|sB,B)=P("-C"|sB,B)=1/2</li> <li>P("-A"|sC,C)=P("-B"|sC,C)=1/2</li> </ol> 　中央（以下では「ケース２」と書く）の図は変形３囚人問題に似せた変形モンティ・ホール問題を解くための円グラフで各確率は次のようになっている。 <ol> <li>P(A)=P(B)=1/4, P(C)=1/2</li> <li>P(sA|A)=P(sB|A)=P(sC|A)=1/3</li> <li>P(sA|B)=P(sB|B)=P(sC|B)=1/3</li> <li>P(sA|C)=P(sB|C)=P(sC|C)=1/3</li> <li>P("-B"|sA,A)=P("-C"|sA,A)=1/2</li> <li>P("-A"|sB,B)=P("-C"|sB,B)=1/2</li> <li>P("-A"|sC,C)=P("-B"|sC,C)=1/2</li> </ol> 　一番右側（以下では「ケース３」と書く）の図は変形３囚人問題に似せた変形モンティ・ホール問題を解くための円グラフでケース２と似ているが、プレーヤーが各ドアを選択する確率を変えてあり、各確率は次のようになっている。 <ol> <li>P(A)=P(B)=1/4, P(C)=1/2</li> <li>P(sA|A)=P(sB|A)=1/4, P(sC|A)=1/2</li> <li>P(sA|B)=P(sB|B)=1/4, P(sC|B)=1/2</li> <li>P(sA|C)=P(sB|C)=1/4, P(sC|C)=1/2</li> <li>P("-B"|sA,A)=P("-C"|sA,A)=1/2</li> <li>P("-A"|sB,B)=P("-C"|sB,B)=1/2</li> <li>P("-A"|sC,C)=P("-B"|sC,C)=1/2</li> </ol> 　ケース１の図を見れば分かるとおり、プレーヤーが最初にどのドアを選択しても、司会者がドアを開いた後に「選択を変えずに当たる確率」（最初に選んだドアが当たりである確率）は1/3に、「選択を変えて当たる確率」（最初に選んだドアがハズレである確率）は2/3になる。グラフでは面積（角度）の割合で直感的に分かるが、通常はどちらもベイズの定理を使って解く。ケース２の図でも、「プレーヤーがＡを選んで司会者がＢのドアを開けた後の選択を変えずに当たる確率」など司会者がドアを開けた後の「選択を変えずに当たる確率」や「選択を変えて当たる確率」がベイズ解と一致することが分かる。ケース３のようにプレーヤが各ドアを選択する確率を変えてもベイズ解と一致する。 　そのことが分かったので、これまではプレーヤーが最初に選ぶドアについては重視してなかった。 　しかし、ケース２やケース３では、プレーヤーが最初に選ぶドアによって「選択を変えずに当たる確率」や「選択を変えて当たる確率」は異なる。ベイズの定理で解けることは一致するが、解が異なる。 　それでは、最初にプレーヤがドアを選択する前の「選択を変えずに当たる確率」や「選択を変えて当たる確率」はどのように計算したら良いだろうか。実は、<a href="http://gascon.cocolog-nifty.com/blog/2007/09/flash_c2ac.html" target="_blank" title="Flash：モンティ･ホール問題: ガスコン研究所">【Flash：モンティ･ホール問題: ガスコン研究所】</a>や<a href="http://nameniku.blog71.fc2.com/blog-entry-358.html" target="_blank" title="ニートが頑張るブログ　モンティ・ホール問題フラッシュ">【ニートが頑張るブログ　モンティ・ホール問題フラッシュ】</a>で提供されている自動計算のシミュレーションはプレーヤーが最初に選ぶドアが確定していない。最初に選ばれるドアが確定していない。おそらく1/3の確率で各ドアが選ばれるようになっているだろう。他のサイトで提供されているシミュレーションも同じではないだろうか。それらのシミュレーションを久しぶりに見て、最初に選ばれるドアが確定してない状態でベイズの定理を使って解くことが妥当だろうかという疑問が生じた。 　結論を先に書くと、最初に選ばれるドアが確定してない状態では「選択を変えずに当たる確率」と「選択を変えて当たる確率」は次の式のようになる。 <ul> <li>選択を変えずに当たる確率 = P(sA)P(A) + P(sB)P(B) + P(sC)P(C)</li> <li>選択を変えて当たる確率 = P(sA)(P(B)+P(C)) + P(sB)(P(A)+P(C)) + P(sC)(P(A)+P(B))</li> </ul> 　この式が導かれる過程は私のブログにコメントしてくれた<a href="http://d.hatena.ne.jp/dora_the_kid/" target="_blank" title="捨てる神あれば拾う神あり">ドラザキッド</a>さんがメモで示してくれた（<a href="http://bit.ly/c5OYSp" target="_blank" title="ツイート「http://twitter.com/dorathekid999/status/22772524157」メモ程度のものですがアップしました。memo.pdf">参照</a>）。ただし、私のブログでは各確率の記号を変えた。 　プレーヤーが各ドアを選択する確率（P(sA),P(sB),P(sC)）で、それぞれのドアが選ばれた場合の「選択を変えずに当たる確率」（例えばプレーヤがＡを選んだらP(A)）や「選択を変えて当たる確率」（例えばプレーヤーがＡを選んだらP(B)+P(C)）を加重平均した形になっている。それぞれのドアが選ばれた場合の「選択を変えずに当たる確率」や「選択を変えて当たる確率」は司会者がドアを開ける前の確率なので、<a href="http://self.blog.so-net.ne.jp/2006-09-20" target="_blank" title="モンティ・ホール問題：補足 - 正己の異論・反論">【モンティ・ホール問題：補足】</a>で書いたように、各ドアが開いた後のベイズ解を加重平均して求められ、「選択を変えずに当たる確率」は事前確率（各ドアが当たりである確率（P(A),P(B),P(C)））と同じになる。 　ドラザキッドさんのメモにも書いてあるが、「P(sA)=P(sB)=P(sC)=1/3」では、P(A),P(B),P(C)がどんな値でも、「選択を変えずに当たる確率」は1/3になり、「選択を変えて当たる確率」は2/3になる。これが各サイトで提供されているシミュレーションの結果だろう。事前確率を変えても結果が変わらないシミュレーションである。ベイズの定理を使って解くことに意味が見出せない。 　また、通常のモンティ・ホール問題のように「P(A)=P(B)=P(C)=1/3」ならばP(sA),P(sB),P(sC)がどんな値でも、「選択を変えずに当たる確率」は1/3になり、「選択を変えて当たる確率」は2/3になる。 　上記のケース１、ケース２、ケース３の円グラフでは次のように各領域の和になる。 <ul> <li>選択を変えずに当たる確率 =（イ＋ウ）＋（ス＋ソ）＋（ノ＋ハ）</li> <li>選択を変えて当たる確率 =（カ＋ク）＋（シ＋タ）＋（ト＋ニ）</li> </ul> 　ケース１、ケース２では、「選択を変えずに当たる確率」は1/3になり「選択を変えて当たる確率」は2/3になっていることが分かる。ケース２ではケース１と事前確率（各ドアが当たりである確率（P(A),P(B),P(C)））が異なるのに同じ結果になっている。 　ケース３では、「選択を変えずに当たる確率」は3/8で、「選択を変えて当たる確率」は5/8である。これは、事前確率ともベイズ解とも異なる。プレーヤーが最初に選ぶドアに偏りがあった結果である。 　ここで、少し注意が必要なので言及しておく。 　上記のケース１、ケース２、ケース３の全てで次の式が成立している。 <ol> <li>P(sA|A)=P(sA|B)=P(sA|C)</li> <li>P(sB|A)=P(sB|B)=P(sB|C)</li> <li>P(sC|A)=P(sC|B)=P(sC|C)</li> </ol> 　この式から次の式が成立する。 <ol> <li>P(sA)=P(sA|A)=P(sA|B)=P(sA|C)</li> <li>P(sB)=P(sB|A)=P(sB|B)=P(sB|C)</li> <li>P(sC)=P(sC|A)=P(sC|B)=P(sC|C)</li> </ol> 　この仮定は妥当だと思うが、妥当でないのならば、もう少し詳細な考察が必要だろう。 　ところで、以上のことを確認するためのExcelファイルを作った。 <ul> <li><a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/MontyHall_2.xls" target="_blank" title="モンティ・ホール問題を理解するためのシミュレーション用ファイルのver.2">MontyHall_2.xls</a></li> </ul> 　プレーヤーが最初に選ぶドアを固定して考察するのなら以前のバージョン（<a href="http://groups.yahoo.co.jp/group/selfmirror7777/files/MontyHall.xls" target="_blank" title="モンティ・ホール問題を理解するためのシミュレーション用ファイル">MontyHall.xls</a>）の方が使いやすい。 　MontyHall_2.xls では「ドア」を「箱」に置き換えてある。 　各箱が当たりである確率（P(A),P(B),P(C)）は箱に入れる玉の数（セルD8,D9,D10）で調整する。 　プレーヤーが各箱を最初に選択する確率（P(sA),P(sB),P(sC)）は「プレーヤーの選択」と書いてある枠の所（セルC18,C19,C20）で変える。例えば「プレーヤーが最初に選択する箱はＡ」と決めてシミュレーションする場合は、P(sA)に相当するＡの右（セルC18）を1にして他を0にする。 　プレーヤが箱を選んだ後に司会者が各箱を開ける確率（P("-B"|sA,A),P("-A"|sB,B),P("-A"|sC,C)）は「司会者の開ける確率」と書いてある枠の所（セルH9,L8,P8）で変える。P("-C"|sA,A),P("-C"|sB,B),P("-B"|sC,C)は自動的に計算される（セルH10,L10,P9）。 　「司会者の開ける確率」枠の一番右側の「A∪B∪C」列は各箱が開く確率であり、次の式に相当する。 <ol style="font-size:75%;"> <li>P("-A") = P(B)*P(sB)*P("-A"|sB,B) + P(C)*P(sB)*P("-A"|sB,C) + P(B)*P(sC)*P("-A"|sC,B) + P(C)*P(sC)*P("-A"|sC,C)</li> <li>P("-B") = P(A)*P(sA)*P("-B"|sA,A) + P(C)*P(sA)*P("-B"|sA,C) + P(A)*P(sC)*P("-B"|sC,A) + P(C)*P(sC)*P("-B"|sC,C)</li> <li>P("-C") = P(A)*P(sA)*P("-C"|sA,A) + P(B)*P(sA)*P("-C"|sA,B) + P(A)*P(sB)*P("-C"|sB,A) + P(B)*P(sB)*P("-C"|sB,B)</li> </ol> 　「再選択率」の枠（セルD14）は司会者が箱を開けた後に選択を変える確率を設定する。通常は0.5であるが、「変更する」と決めてシミュレーションする場合は1にして、「変更しない」と決めてシミュレーションする場合は0にする。 　シミュレーション結果の「当たり？」の列（J列）はプレーヤーが最終的に選んだ箱が当たりである場合は○で表示してハズレである場合は×で表示している。 　シミュレーション結果の「A∪B∪Cが開く」の列（K列、L列）は「当たり？」の列（J列）から選択の変更がなかった場合（変更なし）と変更があった場合（変更あり）を抽出している。 　シミュレーション結果の「Aが開いた場合」（M列、N列）「Bが開いた場合」（O列、P列）「Cが開いた場合」（Q列、R列）の列は「A∪B∪Cが開く」の列（K列、L列）から司会者によって各箱が開けられた場合を抽出している。 　「○の数」「×の数」の行（18行、19行）でシミュレーション結果のそれぞれの数をカウントしている。 　「○の率」「×の率」の行（16行、17行）は「○の数」「×の数」の行（18行、19行）の結果を確率に変換していて、「○の率」が当たる確率である。 　「理論値」の行（15行）は下の「○の率」と比較するために用意されていて、次のように計算している。 <a name="more"></a><ol style="font-size:75%;"> <li>「Ａが開いた場合」の「変更なし」（セルM15）： ( P(B)*P(sB)*P("-A"|sB,B) + P(C)*P(sC)*P("-A"|sC,C) )/P("-A")</li> <li>「Ａが開いた場合」の「変更あり」（セルN15）： ( P(C)*P(sB)*P("-A"|sB,C) + P(B)*P(sC)*P("-A"|sC,B) )/P("-A")</li> <li>「Ｂが開いた場合」の「変更なし」（セルO15）： ( P(A)*P(sA)*("-B"|sA,A) + P(C)*P(sC)*P("-B"|sC,C) )/P("-B")</li> <li>「Ｂが開いた場合」の「変更あり」（セルP15）： ( P(C)*P(sA)*P("-B"|sA,C) + P(A)*P(sC)*P("-B"|sC,A) )/P("-B")</li> <li>「Ｃが開いた場合」の「変更なし」（セルQ15）： ( P(A)*P(sA)*P("-C"|sA,A) + P(B)*P(sB)*P("-C"|sB,B) )/P("-C")</li> <li>「Ｃが開いた場合」の「変更あり」（セルR15）： ( P(B)*P(sA)*P("-C"|sA,B) + P(A)*P(sB)*P("-C"|sB,A) )/P("-C")</li> <li>「A∪B∪Cが開く」の「変更なし」（セルK15）： P("-A")*（セルM15）+ P("-B")*（セルO15）+ P("-C")*（セルQ15）</li> <li>「A∪B∪Cが開く」の「変更あり」（セルL15）： P("-A")*（セルN15）+ P("-B")*（セルP15）+ P("-C")*（セルR15）</li> <li>「当たり？」の列の理論値（セルJ15）： （セルD14）*（セルL15）+(1-（セルD14）)*（セルK15） </li> </ol> 　モンティ・ホール問題で多くの人が示している「ドアを変えた場合の確率」は「セルL15」にある理論値（シミュレーション結果は「セルL16」）のことで「ドアを変えない場合の確率」に相当する「セルK15」の理論値（シミュレーション結果は「セルK16」）と比較して大きいと解答している。三囚人問題ではプレーヤーが最初に選ぶ箱を一つに固定して（セルC18,C19,C20で一つを１にして他を０にする）、A,B,Cのどれかが開いた場合の確率（セルM15～R15）を見る。それはベイズ解に一致している。 　この理論値「セルK15」と「セルL15」については「セルK21」と「セルL21」に別の計算式を入力してある。それは、次の式に相当するが、「セルK15」と「セルL15」の値と一致していることが確認できる。 <ol style="font-size:75%;"> <li>「A∪B∪Cが開く」の「変更なし」（セルK21）： P(sA)*P(A) + P(sB)*P(B) + P(sC)*P(C)</li> <li>「A∪B∪Cが開く」の「変更あり」（セルL21）： P(sA)*(P(B)+P(C)) + P(sB)*(P(A)+P(C)) + P(sC)*(P(A)+P(B))</li> </ol> 　最後に私のブログでも次の式を導いておく。 <ul style="font-size:75%;"> <li>選択を変えずに当たる確率 = P(sA)P(A) + P(sB)P(B) + P(sC)P(C)</li> <li>選択を変えて当たる確率 = P(sA)(P(B)+P(C)) + P(sB)(P(A)+P(C)) + P(sC)(P(A)+P(B))</li> </ul> 選択を変えずに当たる確率 <ol style="font-size:75%;"> <li>選択を変えずに当たる確率 = P("-B",sA,A) + P("-C",sA,A) + P("-A",sB,B) + P("-C",sB,B) + P("-A",sC,C) + P("-B",sC,C)</li> <li>P("-B",sA,A)=P(A)P(sA|A)P("-B"|sA,A)</li> <li>P("-C",sA,A)=P(A)P(sA|A)P("-C"|sA,A)</li> <li>P("-A",sB,B)=P(B)P(sB|B)P("-A"|sB,B)</li> <li>P("-C",sB,B)=P(B)P(sB|B)P("-C"|sB,B)</li> <li>P("-A",sC,C)=P(C)P(sC|C)P("-A"|sC,C)</li> <li>P("-B",sC,C)=P(C)P(sC|C)P("-B"|sC,C)</li> <li>P("-B",sA,A)+P("-C",sA,A) = P(A)P(sA|A)(P("-B"|sA,A)+P("-C"|sA,A))</li> <li>P("-B",sA,A)+P("-C",sA,A) = P(A)P(sA|A) （∵P("-B"|sA,A)+P("-C"|sA,A)=1）</li> <li>P("-A",sB,B)+P("-C",sB,B) = P(B)P(sB|B)(P("-A"|sB,B)+P("-C"|sB,B))</li> <li>P("-A",sB,B)+P("-C",sB,B) = P(B)P(sB|B) （∵P("-A"|sB,B)+P("-C"|sB,B))=1）</li> <li>P("-A",sC,C)+P("-B",sC,C) = P(C)P(sC|C)(P("-A"|sC,C)+P("-B"|sC,C))</li> <li>P("-A",sC,C)+P("-B",sC,C) = P(C)P(sC|C) （∵P("-A"|sC,C)+P("-B"|sC,C)=1）</li> <li>選択を変えずに当たる確率 = P(A)P(sA|A) + P(B)P(sB|B) + P(C)P(sC|C)</li> <li>選択を変えずに当たる確率 = P(A)P(sA) + P(B)P(sB) + P(C)P(sC)</li> </ol> あるいは <ol style="font-size:75%;"> <li>選択を変えずに当たる確率 = P("-B",sA,A) + P("-C",sA,A) + P("-A",sB,B) + P("-C",sB,B) + P("-A",sC,C) + P("-B",sC,C)</li> <li>P("-B",sA,A)=P(sA)P(A|sA)P("-B"|sA,A)</li> <li>P("-C",sA,A)=P(sA)P(A|sA)P("-C"|sA,A)</li> <li>P("-A",sB,B)=P(sB)P(B|sB)P("-A"|sB,B)</li> <li>P("-C",sB,B)=P(sB)P(B|sB)P("-C"|sB,B)</li> <li>P("-A",sC,C)=P(sC)P(C|sC)P("-A"|sC,C)</li> <li>P("-B",sC,C)=P(sC)P(C|sC)P("-B"|sC,C)</li> <li>P("-B",sA,A)+P("-C",sA,A) = P(sA)P(sA|A)(P("-B"|sA,A)+P("-C"|sA,A))</li> <li>P("-B",sA,A)+P("-C",sA,A) = P(sA)P(A|sA) （∵P("-B"|sA,A)+P("-C"|sA,A)=1）</li> <li>P("-A",sB,B)+P("-C",sB,B) = P(sB)P(B|sB)(P("-A"|sB,B)+P("-C"|sB,B))</li> <li>P("-A",sB,B)+P("-C",sB,B) = P(sB)P(B|sB) （∵P("-A"|sB,B)+P("-C"|sB,B))=1）</li> <li>P("-A",sC,C)+P("-B",sC,C) = P(sC)P(C|sC)(P("-A"|sC,C)+P("-B"|sC,C))</li> <li>P("-A",sC,C)+P("-B",sC,C) = P(sC)P(C|sC) （∵P("-A"|sC,C)+P("-B"|sC,C)=1）</li> <li>選択を変えずに当たる確率 = P(sA)P(A|sA) + P(sB)P(B|sB) + P(sC)P(C|sC)</li> <li>選択を変えずに当たる確率 = P(sA)P(A) + P(sB)P(B) + P(sC)P(C)</li> </ol> 選択を変えて当たる確率 <ol style="font-size:75%;"> <li>選択を変えて当たる確率 = P("-C",sB,A) + P("-B",sC,A) + P("-C",sA,B) + P("-A",sC,B) + P("-B",sA,C) + P("-A",sB,C)</li> <li>P("-C",sB,A)=P(A)P(sB|A)P("-C"|sB,A)=P(A)P(sB|A) （∵P("-C"|sB,A)=1）</li> <li>P("-B",sC,A)=P(A)P(sC|A)P("-B"|sC,A)=P(A)P(sC|A) （∵P("-B"|sC,A)=1）</li> <li>P("-C",sA,B)=P(B)P(sA|B)P("-C"|sA,B)=P(B)P(sA|B) （∵P("-C"|sA,B)=1）</li> <li>P("-A",sC,B)=P(B)P(sC|B)P("-A"|sC,B)=P(B)P(sC|B) （∵P("-A"|sC,B)=1）</li> <li>P("-B",sA,C)=P(C)P(sA|C)P("-B"|sA,C)=P(C)P(sA|C) （∵P("-B"|sA,C)=1）</li> <li>P("-A",sB,C)=P(C)P(sB|C)P("-A"|sB,C)=P(C)P(sB|C) （∵P("-A"|sB,C)=1）</li> <li>選択を変えて当たる確率 = P(A)(P(sB|A)+P(sC|A)) + P(B)(P(sA|B)+P(sC|B)) + P(C)(P(sA|C)+P(sB|C))</li> <li>選択を変えて当たる確率 = P(A)(P(sB)+P(sC)) + P(B)(P(sA)+P(sC)) + P(C)(P(sA)+P(sB))</li> <li>選択を変えて当たる確率 = P(sA)(P(B)+P(C)) + P(sB)(P(A)+P(C)) + P(sC)(P(A)+P(B))</li> </ol> あるいは <ol style="font-size:75%;"> <li>選択を変えて当たる確率 = P("-C",sB,A) + P("-B",sC,A) + P("-C",sA,B) + P("-A",sC,B) + P("-B",sA,C) + P("-A",sB,C)</li> <li>P("-C",sB,A)=P(sB)P(A|sB)P("-C"|sB,A)=P(sB)P(A|sB) （∵P("-C"|sB,A)=1）</li> <li>P("-B",sC,A)=P(sC)P(A|sC)P("-B"|sC,A)=P(sC)P(A|sC) （∵P("-B"|sC,A)=1）</li> <li>P("-C",sA,B)=P(sA)P(B|sA)P("-C"|sA,B)=P(sA)P(B|sA) （∵P("-C"|sA,B)=1）</li> <li>P("-A",sC,B)=P(sC)P(B|sC)P("-A"|sC,B)=P(sC)P(B|sC) （∵P("-A"|sC,B)=1）</li> <li>P("-B",sA,C)=P(sA)P(C|sA)P("-B"|sA,C)=P(sA)P(C|sA) （∵P("-B"|sA,C)=1）</li> <li>P("-A",sB,C)=P(sB)P(C|sB)P("-A"|sB,C)=P(sB)P(C|sB) （∵P("-A"|sB,C)=1）</li> <li>選択を変えて当たる確率 = P(sA)(P(B|sA)+P(C|sA)) + P(sB)(P(A|sB)+P(C|sB)) + P(sC)(P(A|sC)+P(B|sC))</li> <li>選択を変えて当たる確率 = P(sA)(P(B)+P(C)) + P(sB)(P(A)+P(C)) + P(sC)(P(A)+P(B))</li> </ol> 　ここでも注意が必要なので言及しておく。 　ここでは次の式が成立していることを前提にしている。 <ol> <li>P(sA|A)=P(sA|B)=P(sA|C)=P(sA)</li> <li>P(sB|A)=P(sB|B)=P(sB|C)=P(sB)</li> <li>P(sC|A)=P(sC|B)=P(sC|C)=P(sC)</li> <li>P(A|sA)=P(A|sB)=P(A|sC)=P(A)</li> <li>P(B|sA)=P(B|sB)=P(B|sC)=P(B)</li> <li>P(C|sA)=P(C|sB)=P(C|sC)=P(C)</li> </ol> 　この前提は妥当だと思うが、妥当でないのならば、もう少し詳細な考察が必要だろう。 </article> <article> <h1>モンティ・ホール問題：補足４</h1> 正己 — Thu, 12 Aug 2010 02:14:17 +0900 　モンティ・ホール問題について書くのは久しぶりである。 　<a href="http://d.hatena.ne.jp/dora_the_kid/" target="_blank" title="捨てる神あれば拾う神あり">dora_the_kid</a>さんが私のブログを読んでくださり、<a href="http://self.blog.so-net.ne.jp/2006-09-17#tb6384846" target="_blank" title="Ｎドア問題の解法のトラックバック（2010年08月11日13時23分06秒）">トラックバック</a>も頂いた。「“巷でよく言われている回答”を数式で表現できないか」（<a href="http://d.hatena.ne.jp/dora_the_kid/20100811/1281500063" target="_blank" title="モンティ・ホール問題（ベイズの定理を使った解法） - 捨てる神あれば拾う神あり">参照</a>）ということで、どうやら、“巷でよく言われている回答”では次の確率を求めているらしい。 　まず、数式で使う変数について。 <ul> <li>ドアA,B,Cを小文字のa,b,cで表現</li> <li>X_1：プレイヤーが１回目に選ぶドア</li> <li>X_2：プレイヤーが２回目に選ぶドア</li> <li>H：当たりドア</li> <li>E：主催者が開けるドア</li> </ul> 　“巷でよく言われている回答”で求めている確率は次の通り。 <ul style="font-size:75%;font-weight:bold;"> <li>ドアを変えない場合の当たる確率＝P(X_1=a,H=a,E≠a,X_2=a)</li> <li>ドアを変えた場合の当たる確率　＝P(X_1=a,H≠a,E≠a,E≠H,X_2=H)</li> </ul> 　P()の()内は","で区切られているが、","で区切られた条件の全てが同時に成立する確率という意味である。（追記：「E≠a」が「E=b」でない点が重要。下の式ではさらに「H≠a」であり「H=c」ではない点が需要。） 　さて、dora_the_kidさんのブログでは、この確率を変形三囚人問題に当てはめると正答が得られないことが示されている（<a href="http://d.hatena.ne.jp/dora_the_kid/20100811/1281501029" target="_blank" title="変形三囚人問題とまとめ - 捨てる神あれば拾う神あり">参照</a>）。 　Ａが恩赦になる確率（ドアを変えない場合の当たる確率に相当する）については『事後確率の分子を1/2で割ることに等しいが、事後確率の分母は5/8なので、1/2は事後確率の分母の係数を考えていることにはならない。従って正答を得られない。』ということらしい。「事後確率の分母」とは P(E=b) のことである。すなわち、「1/2≠P(E=b)」だから正答にならないということらしい。この「1/2」とは図を見るとP(E=b|H=a)らしい。逆に考えれば、次の式が成立すればベイズの定理で求めた答と一致するということである。 P(E=b|H=a)＝P(E=b) 　Ａが恩赦にならない確率（看守が選ぶ囚人がＢなのでＣが恩赦になる確率であり、ドアを変えた場合の当たる確率に相当する）については『事後確率の分子を2/3で割ることに等しいが、事後確率の分母は5/8なので、2/3は事後確率の分母の係数を考えていることにはならない。従って正答を得られない。』ということらしい。「2/3≠P(E=b)」だから正答にならないということだが、「2/3」とは図を見るとP(H=c|H≠a)らしい。逆に考えれば、次の式が成立すればベイズの定理で求めた答と一致するということである。 P(H=c|H≠a)＝P(E=b) 　私は、<a href="http://self.blog.so-net.ne.jp/2006-09-15" target="_blank" title="モンティ・ホール問題 - 正己の異論・反論">【モンティ・ホール問題】</a>で“巷でよく言われている回答”で正答する条件を次の式で表した。 P(B)/P(C) = P("-C"|A)/P("-B"|A) 　上の変数を使うと次のような条件式になる。 P(H=b)/P(H=c) = P(E=c|H=a)/P(E=b|H=a) 　この式が成立すれば、モンティ・ホール問題で成立している「P(E=b|H=a)＝P(E=c|H=a) かつ P(H=b)＝P(H=c)」という条件を満たさなくても、“巷でよく言われている回答”がベイズの定理で求めた答と一致する。 　そこで、上記の条件式についても次のような変形ができるのではないかと思った。 <ul> <li>P(E=b|H=a)＝P(E=b) → P(H=b)/P(H=c)＝P(E=c|H=a)/P(E=b|H=a)</li> <li>P(H=c|H≠a)＝P(E=b) → P(H=b)/P(H=c)＝P(E=c|H=a)/P(E=b|H=a)</li> </ul> 　矢印の向きは逆でも良いが、私が確認したのは上のような向きである。そして、確認した結果、変形できることが分かった。 <a name="more"></a> 　読者が確認してくれれば良いのだが、再確認が面倒なので以下にメモしておく。 <ol style="font-size:75%;"> <li style="font-weight:bold;">P(E=b|H=a)＝P(E=b)</li> <li>P(E=b|H=a)＝P(H=a,E=b)+P(H=b,E=b)+P(H=c,E=b)</li> <li>P(E=b|H=a)＝P(H=a,E=b)+P(H=c,E=b)</li> <li>P(E=b|H=a)＝P(H=a)P(E=b|H=a)+P(H=c)P(E=b|H=c)</li> <li>P(E=b|H=a)＝P(H=a)P(E=b|H=a)+P(H=c)</li> <li>P(E=b|H=a)(1-P(H=a))＝P(H=c)</li> <li>P(E=b|H=a)(P(H=b)+P(H=c))＝P(H=c)</li> <li>(P(H=b)+P(H=c))/P(H=c)＝1/P(E=b|H=a)</li> <li>P(H=b)/P(H=c)+1＝1/P(E=b|H=a)</li> <li>P(H=b)/P(H=c)＝1/P(E=b|H=a)-1</li> <li>P(H=b)/P(H=c)＝(1-P(E=b|H=a))/P(E=b|H=a)</li> <li style="font-weight:bold;">P(H=b)/P(H=c)＝P(E=c|H=a)/P(E=b|H=a)</li> </ol> <ol style="font-size:75%;"> <li style="font-weight:bold;">P(H=c|H≠a)＝P(E=b)</li> <li>P(H≠a,H=c)/P(H≠a)＝P(H=a,E=b)+P(H=b,E=b)+P(H=c,E=b)</li> <li>P(H=c)/P(H≠a)＝P(H=a,E=b)+P(H=c,E=b)</li> <li>P(H=c)/P(H≠a)＝P(H=a)P(E=b|H=a)+P(H=c)P(E=b|H=c)</li> <li>P(H=c)/P(H≠a)＝P(H=a)P(E=b|H=a)+P(H=c)</li> <li>P(H=c)(1/P(H≠a)-1)＝P(H=a)P(E=b|H=a)</li> <li>P(H=c)(1-P(H≠a))/P(H≠a)＝P(H=a)P(E=b|H=a)</li> <li>P(H=c)P(H=a)/(P(H=b)+P(H=c))＝P(H=a)P(E=b|H=a)</li> <li>P(H=c)/(P(H=b)+P(H=c))＝P(E=b|H=a)</li> <li>(P(H=b)+P(H=c))/P(H=c)＝1/P(E=b|H=a)</li> <li>P(H=b)/P(H=c)+1＝1/P(E=b|H=a)</li> <li>P(H=b)/P(H=c)＝1/P(E=b|H=a)-1</li> <li>P(H=b)/P(H=c)＝(1-P(E=b|H=a))/P(E=b|H=a)</li> <li style="font-weight:bold;">P(H=b)/P(H=c)＝P(E=c|H=a)/P(E=b|H=a)</li> </ol> </article> <article> <h1>ブログの文字を拡大するためのボタンをブログに設置する方法</h1> 正己 — Fri, 25 Jun 2010 17:57:11 +0900 　私のブログでは右上に「文字拡大」「文字縮小」「リセット」のボタンがあり、文字のサイズを変更できるようになっている。このボタンについて問い合わせがあった（<a href="http://self.blog.so-net.ne.jp/2009-04-05#c41334010" target="_blank" title="「メイリオの欠点に合わせてプチリニューアル」コメント by kiriko (2010-06-23 11:38)">参照</a>）。このボタンは私のブログでは次のようになっている。 　まず、ヘッダ（<head></head>内）に次のように記述して外部のJavaScriptを読み込む。 <script type="text/javascript" language="JavaScript" src="<a href="http://www002.upp.so-net.ne.jp/self/robamimi/blog-self.js" target="_blank">http://www002.upp.so-net.ne.jp/self/robamimi/blog-self.js</a>"></script> 　次にbodyタグに次のように記述して読み込んだJavaScriptの一つを実行する。 <body onload="fscRef()"> 　ボタンのソースは次の通りである。 <table id="fsc-javascript" cellspacing="0" cellpadding="0" summary="文字サイズの変更スクリプト"> <tr><td align="center"><button onclick="fsc('larger');return false;">文字拡大</button></td></tr> <tr><td align="center"><button onclick="fsc('smaller');return false;">文字縮小</button></td></tr> <tr><td align="center"><button onclick="fsc('default');return false;">リセット</button></td></tr> </table> 　私のブログはソネブロから提供されたスキンのスタイルシートやＨＴＭＬソースを大幅に変更していて、他のソネブロユーザーのブログでは上の「文字拡大」ボタンが機能しない可能性があると思った。そこで、スタイルシートやＨＴＭＬソースを全く変更した覚えのない別のブログ<a href="http://self7777.blog.so-net.ne.jp/" target="_blank" title="正己 (self7777) from Twitter：So-netブログ">【正己 (self7777) from Twitter：So-netブログ】</a>で実験してみた。案の定、「文字拡大」ボタンで文字が大きくならなかった。 　Firefoxの「選択した部分のソースを表示」という機能で確認したところ、「文字拡大」ボタンでbodyタグには例えば次のように font-size が追加されていた。 <body style="font-size: 21px;"> 　それでも文字のサイズが変わらなかったのである。これは、変わって欲しい部分に別に font-size が指定されているからであった。調べたところ、このブログ【正己の異論・反論】では指定されてなかったが、<a href="http://self7777.blog.so-net.ne.jp/" target="_blank" title="正己 (self7777) from Twitter：So-netブログ">【正己 (self7777) from Twitter】</a>では次のように指定されていた。 .articles { font-size: small; } 　「body」の「font-size」が「21px」になったとしても、本文の入っているdivタグに「<div class="articles">」と指定してあれば本文のサイズは「small」になってしまう。それで、「文字拡大」ボタンを押しても文字は大きくならなかったのである。この「.articles { font-size: small; }」を無効にすれば、「文字拡大」ボタンで文字が大きくなる。（注意：他のスキンでは「.articles」以外にも font-size が指定されているかもしれませんので、それも無効にする必要があります。） 　スタイルシートに記述された「.articles { font-size: small; }」は削除すれば無効にできるが、ブログのサイドバーに記述する際は次のように指定すれば良いらしい。 .articles { font-size:100%; } 　これで「文字拡大」ボタンで文字が大きくなる。 　では、サイドバーに「カスタムペイン」を追加して「文字拡大」などとタイトルを変え、自由入力欄にはどの様に記述すれば良いか。<a href="http://self7777.blog.so-net.ne.jp/" target="_blank" title="正己 (self7777) from Twitter：So-netブログ">【正己 (self7777) from Twitter】</a>では次のように記述した。 <a name="more"></a> <div style="margin-top:0px;"> <style TYPE="text/css">  </style> <script type="text/javascript">  </script> <table id="fsc-javascript" cellspacing="0" cellpadding="0" summary="文字サイズの変更スクリプト"> <tr><td align="center"><button onclick="fscRef();return false;">保存サイズ</button></td></tr> <tr><td align="center"><button onclick="fsc('larger');return false;">文字拡大</button></td></tr> <tr><td align="center"><button onclick="fsc('smaller');return false;">文字縮小</button></td></tr> <tr><td align="center"><button onclick="fsc('default');return false;">リセット</button></td></tr> </table> </div> 　このブログ【正己の異論・反論】と異なり、ページを開いた時に前に見ていた時の文字サイズが読み込まれないので「保存サイズ」ボタンを押すことで読み込ませることにした。「保存サイズ」は「文字拡大」ボタンなどを押すたびに変わるので、使えるのはページを開いた時だけである。ページを再読み込みした後も「保存サイズ」ボタンを押せば文字サイズが再読み込み前に戻る。 　ページを開いた時の最初の文字サイズは「body { font-size:16px; }」で指定する。「リセット」ボタンを押した時の文字サイズは「var defaultFSize = 16;」で指定する。混乱するので同じサイズにしておいた方が良い。「body { font-size:16px; }」を指定しないと、ソネブロが提供しているスタイルシートに従い「body { font-size: small; }」になってしまう。 　さて、<a href="http://self.blog.so-net.ne.jp/2009-04-05#c41334010" target="_blank" title="「メイリオの欠点に合わせてプチリニューアル」コメント by kiriko (2010-06-23 11:38)">問い合わせ</a>をしてくださったkirikoさんにはコメント欄のように回答してしまったが、回答後に自分の回答では不十分であることに気付いた。問い合わせには「遠くの親戚や友人に赤ちゃんの成長を報告するため」とあるのに、ブラウザの設定などを変えることを助言してしまったのである。お礼のコメントに書いてある「実家に行った時に」で気付いた。すぐに両親が使うブラウザの設定などできるはずがないのである。ブログに「文字拡大」ボタンが必要だったのである。ちゃんと読まずに回答してしまって恥ずかしい。 　他のサイトのJavaScriptボタンを紹介したが、あれは自由に文字サイズを変えられない点が不満である。だから私は【正己の異論・反論】に「文字拡大」ボタンを作った。JavaScriptは以前に知人のXOOPSを管理するお手伝いをしたときに見つけたものである。かなり昔なので、今はどのサイトにあったか忘れてしまったが…。この「文字拡大」ボタンは 1px ずつサイズを変えられる。それは「var perOrder = 1;」の部分で指定してある。 2px ずつ変えることも可能である。 　話が逸れてしまったが、kirikoさんに回答した後、他のソネブロで【正己の異論・反論】の「文字拡大」ボタンが使えないことが悔しかったので、このエントリーのように文字サイズを変えるにはどうしたら良いか調べてみた。ソネブロ利用者で文字を拡大するボタンが欲しい人は上のJavaScript等を試して欲しい。もしも文字サイズが変わらないようだったらコメントを頂ければ、分かる範囲でお答えしたい。 <div style="display:none;"><a href="http://self.blog.so-net.ne.jp/2009-04-05" target="_blank">http://self.blog.so-net.ne.jp/2009-04-05</a></div> </article> </main></body></html>