Windowsのメモ帳(notepad)に文字化けするバグ 131
ストーリー by GetSet
XPでは確認したけど、他のVerはどうだろう? 部門より
XPでは確認したけど、他のVerはどうだろう? 部門より
WindVoice曰く、"Windowsに付属するnotepadに、ファイル読み込み時に文字化けするバグが発見されている。(参考：CNET Japanの記事)
4+3+3+5byteの文字列、例えば"tiny bug for nards"と書き込んで保存し、再度ファイルを開くと文字化けして表示されるというもの。ファイルを開くときにANSI文字コードを誤ってUnicodeと判定するために発生する問題であるようだ。バグの報告を探してみたが、マイクロソフト社関係のサイトからは見つけることができなかった。"
えーうっそー (スコア:5, おもしろおかしい)
# 後はよろしく
Re:えーうっそー (スコア:4, すばらしい洞察)
なので、そちらのほうがバグの残ってる確率は低いのではないかと、、、
というのは良いとして、真面目な話 バグの無いソフトなんて実在するんですか？
cat や ls のような利用頻度のアプリにでも known bug は存在しますよ。
誰も使わないソフト (スコア:5, すばらしい洞察)
機能がないソフト(例えばコード長0のソフト）
にはバグがありません。
前者はよく存在します。
Re:えーうっそー (スコア:4, すばらしい洞察)
どこまでをバグと判定するかにもよりますが、一般的に「バグが無い」というのは「（そのソフトの開発者が認める）バグが（まだ）見つかっていない」という状態であるため、「バグが無いソフト」は十分ありえますよ。
今後一切のバグが見つからない（今後もずっと「バグが無い」状態であり続ける）ことを保障できるかは別問題ですが。
Re:えーうっそー (スコア:2, 興味深い)
W2Kなら確か落ちたような・・・
XPなら画面の描写がおかしくなるだけですが。
Re:えーうっそー (スコア:1)
Re:えーうっそー (スコア:3, おもしろおかしい)
ちょ、おま…セガサターンのソフトに大量のバグがあるとでも言うのか！
# 否定できないのでAC
Re:えーうっそー (スコア:2, おもしろおかしい)
「Tiny Bug for nards」だと化けない (スコア:5, 参考になる)
「Tiny Bug for nards」だと化けない。
大文字2文字、2文字以上含まれていれば化けないのかな？
テストにしては少ないけど。
Re:「Tiny Bug for nards」だと化けない (スコア:3, 参考になる)
「TiNy bug for nards」でも化けます。
「Tiny bUg for nards」でも化けます。
各文字列の最初の文字が大文字なのが2文字以上だと化けない？
Re:「Tiny Bug for nards」だと化けない (スコア:2, 参考になる)
「tiny bug foR narDs」だと化けます。
「tiny bug foR Nards」だと化けません。
文字列の最初か最後に大文字が2文字以上だと化けない？
Re:「Tiny Bug for nards」だと化けない (スコア:2, 参考になる)
「Tiny bug foR nards」でも化けません。
Re:「Tiny Bug for nards」だと化けない (スコア:3, 参考になる)
別コメントにもあるように、2バイトずつ区切ってリトルエンディアンの
UTF-16として解釈するみたいだけど、「 B」(0x20,0x42→U+4220)はUnified
CJK Ideographs(U+4E00 - U+9FBF)の範囲を逸脱し、CJK Ideographs
Extension Aの範囲になってしまうので、Unicode文字列である可能性が
ぐっと低くなるとみなされるのでしょう。
どなたか、さらなる解析をお願いします。
Re:「Tiny Bug for nards」だと化けない (スコア:2, 参考になる)
規格として定義されているのかは確認できませんが、
RFC 2781 [rfc.net]の3.2 Byte order mark (BOM)、
及びunicode.orgのFAQ、UTF-8, UTF-16, UTF-32 & BOM [unicode.org]
でBOMについてふれらていますので、ローカルルールとまではいかない気がします。
あとFAQでは、BOMはUTF16だけではなく、UTF32はもちろんUTF8でも付けられると書いてます。
知らなかった...
Re:「Tiny Bug for nards」だと化けない (スコア:2, 参考になる)
ローカルルールどころか、BOMを付けるのが UTF-16の本来の姿。
UTF-8はバイトオーダー誤認が無いように作られてるので、BOMをつけてる一部のエディタは、そのエディタのローカルルールだけどね。
起動オプション (スコア:5, 参考になる)
/A : ANSI（とゆーか、日本語版ではShift-JIS）として読み込み
文字化けするファイル hoge.txt をANSIとして読むばやい、
notepad /A hoge.txt
とすればおっけーです。
（同じく /W もあるみたい）
Re:起動オプション (スコア:2, 参考になる)
容疑者？ (スコア:5, 参考になる)
IsTextUnicode
なんてAPIをリンクしています。
で、MSDNを調べると、こんな注意書きがあったり。
>IS_TEXT_UNICODE_STATISTICS をセットした場合と
>IS_TEXT_UNICODE_REVERSE_STATISTICS をセット
>した場合は、統計的分析が行われます。
>この２つのテストは絶対的確実性を持っていません。
>統計的なテストでは、文字列の上位バイトと下位バイ
>トの間である程度の変動を想定しているため、ASCII
>文字列が ASCII 文字列として認識されないことがあ
>ります。
まぁ、ぶっちゃけ、完全な自動認識なんて無理、って事でしょうねぇ。
たしか、IEだかMozzillaも文字コードの認識を「統計的分析」でやってるのでタマに失敗する。
でも、それは致し方ない事だ、って話があったような記憶があるのですが。
わざわざ取り上げるようなことなのでしょうか？ (スコア:4, 興味深い)
確かに、4+3+3+5byteの文字列なテキストファイルをクリックして選択するとANSI→Unicodeに変わります(中を見て判別してるのでしょう)。
そのまま開くと文字化けするのは当然ですが、明示的にANSIを指定して開けば問題なかったです。
文字コードの自動判別を間違うソフトなんて山ほどあります(自分が愛用してるEmEditorもよく間違います)。
ブラウザだってHTMLで明示的に文字コード指定されてない場合間違うことがあります。
一々取り上げるようなネタではないのでは？
Re:わざわざ取り上げるようなことなのでしょうか？ (スコア:3, 興味深い)
むかーし、NEC PC-98用MS-DOSのラインエディタにバグが見つかった、とかでNHK、民放各局のニュースで画面映像、NEC社員へのインタービューつきで報道していたのを覚えてる。
バグの内容は覚えてなけど、そんなの報道してどうなるの? と思ったのは覚えている。
Re:わざわざ取り上げるようなことなのでしょうか？ (スコア:3, 興味深い)
マイクロソフトのソフトの問題(それもごく限られた状況で起きる)なのに NEC 製品の欠陥のように報道され、少なくとも一人の人生に多大な影響を与えてしまったという...
今回のバグも、巡り巡って誰かの人生を狂わせてしまったりするのでしょうか :p
Treason, like beauty, is in the eye of the beholder.
Re:わざわざ取り上げるようなことなのでしょうか？ (スコア:3, 参考になる)
ASCIIと衝突するような文字コードが、今まであまり使われてこなかった
ということじゃないでしょうか。EUCにしてもシフトJISにしても、
その他ISO2022系やISO8859系の文字コードにしても、ASCIIの上位互換を
保っていますので、これらの間でASCIIテキストを誤判別することはありえません。
(ISO2022系で、シフト状態が欠落した場合などを除き)。
ただ、UTF-16はそうではない、ということ。今までUTF-16はまじめに
使われてきませんでしたが、今後、もしプレーンテキストにUTF-16が広く
使われるようなことがあれば、文字化けが生じるかもしれません。もし
そうだとしたら、今回はその"はしり"と言えるでしょう。もしそうでは
なければ、UTF-16をサポートしたnotepadの判断ミスということになるのでしょう。
# もしかしたら、EBCDICもASCIIと衝突する？
# でも、EBCDICが実際に使われていた時代には、
# 自動判別なんて、リソースがもったいなくて
# やってられなかったのかもしれません。。。
嬉しい (スコア:4, おもしろおかしい)
英語で、しかもWindowsの標準のアプリを使用してる人にも文字化けがちゃんと起こってるって知って、とっても嬉しいです。
文書の文字コードを求めて文字コードを総当たりする苦しみを思い知るがいいのさー。
うちらは今更文字化けの要因が一つや二つ増えたところでどうってことないんじゃー。ぼけー。
Re:嬉しい (スコア:3, おもしろおかしい)
みたいなことを考えそうだ
Vista β2でも再現 (スコア:3, 参考になる)
スペルチェッカが動くバグ？ (スコア:3, おもしろおかしい)
と入力したのに、スペルチェッカが動いて、勝手に "tiny bug for nerds" と修正されてしまうとかいうバグだったりして。
Re:スペルチェッカが動くバグ？ (スコア:3, おもしろおかしい)
＃notepadにもスペルチェッカ機能が欲しいですね！
人生は七転び八起き、一日は早寝早起き
フレームの元？ (スコア:3, 参考になる)
文字化けが発生する条件は、上記ページからリンクされてるここ [wired.com]に載ってますが、ここに書かれた条件を満たしているからと言って、必ず文字化けする訳でも無いようです。
しかし、「Bush hid the facts」だの「Japs ate our child」で文字化けするって、笑うには、ちとヘビーすぎますな。
ついでに、私が試してみた限りでは「Java mac osx linux」とかも文字化けしました。
開発者の言い訳 (スコア:3, おもしろおかしい)
特定文字列でもないし、さすがに無理がありすぎるか･･･。
日付日時を挿入する機能 (スコア:3, 興味深い)
notepad って、ファイル末(冒頭だったかな)に ".log" という4バイトを書いておくと、ファイルオープン時に日付日時を勝手に書き込んでくれる機能がついてませんでしたっけ？
そもそもこのソフトウェアは大切なバイト列を扱うには向いていないものだ、という認識でおりました。今ではこの機能を無効にしたり出来るようになっているのかな。
今は UNIX を触っていたので細かい点は確認せずに書き込んでいます。
Re:日付日時を挿入する機能 (スコア:4, 参考になる)
メモ帳のヘルプ LOG ファイルより。
経験あり (スコア:3, 興味深い)
「20点・・・・・・・・」になります。
2000でもXPでも起こります。
ド素人なので、遭遇しても何も出来ず、途方に暮れるだけでした。
ああ (スコア:3, 参考になる)
プログラムのミスかなっと思ったのですが、悪いのはnotepad.exeだったんですね。
// この機能？（バグ）って暗号に使える？
//
Li-ion DC 1.2V（定格：3.7V) 500mA 乾電池はリサイクルへ
これはバグなのか？ (スコア:3, すばらしい洞察)
それを、作った人の意図はASCIIだったからといって、UTF-16LEで解釈したら
バグ、というのはなんだかなあと思います。じゃあ逆に、作った人の意図が
UTF-16LEだったとしたら、ASCIIとして解釈するソフトのほうがバグだって
ことになりますよ。
日本人の感覚だと、たとえばS-JISとしてもEUCとしても解釈できるファイルを、
そのファイルを作った人の意図とは違う文字コードとして自動判別してしまう
ソフトがあっても、それは仕方のないことだと思うんですが。
もちろん、文字コードとして解釈可能である、という以上の解析も可能ですし、
ある程度はそういうことも期待していいとは思います。たとえば、
候補となる文字コードすべてについて、その文字コードで解釈した場合に、
いろんな言語について「その言語で書かれた文章らしさ」を数値化し
（たとえば、日本語の文章だと、ひらがなが多いと日本語の文章らしさが
大きくなるが、記号や、JISX0208に含まれない文字が多用されていると
得点が下がるなど）、その（言語間での）最大値が最も大きくなる
文字コードであると判別するなど。おそらく今回のファイルは、
このレベルの判別で人間の意図を正しく類推できるはずでしょう。しかし、
それでも完全ではありません。もうひとつ上の精度を目指すとすると、
世界中の言語の辞書や文法チェッカーでチェックして妥当な結果になる
文字コードであると判別するという方法が考えられます。しかし、
それでもまだ完全ではありません。意図したいのはでたらめな文字列
だったかもしれないですし、そうすると、そのファイルを作った人間の
頭に電極を差し込んで意図を判別するしかなくなってしまいます。
Re:これはバグなのか？ (スコア:3, おもしろおかしい)
#誰も使わなそう
バグといえるでしょう。 (スコア:3, すばらしい洞察)
そして、メモ帳自身がANSIで保存したつもりのファイルが開けないのを仕様とするのはおかしな話です。
ファイルの中身を変更せずにファイル仕様をアプリケーションが特定する為の仕組みとして、昔から拡張子が用いられてきました。
メモ帳が保存時に文字コード別の拡張子をふれば、メモ帳自身で開く場合に誤認識はなくせます。
また、自動認識に頼る場合はANSI文字コードで保存する場合に「正しく認識できる内容かどうか」を判定することは容易いのですから、次回オープン時に文字化けしてしまう旨を警告する事も可能です。
UNICODE文字をANSIで保存するときは、失われる文字があると警告しているのですから、何も警告せずに保存したデータを失ってしまうのは、ソフトウェアの重大な欠陥だといえます。
上限サイズ (スコア:2, 興味深い)
んGB(だっけ？)以上のファイル(テキスト)が開けないのは仕様だっけ？
Re:上限サイズ (スコア:3, 参考になる)
アドレス空間が足りなくなりますからね。
64bit版なら増えてるかも。
確認はしてませんが。
#Meまでの32kなんかの限界に比べれば全く問題無いと思います
Re:上限サイズ (スコア:2, 興味深い)
実質的な上限はもっと下かと。
しかし、PocketPC版のPocketwordや同OS向けの大半のテキストエディタの
あまりのダメさ加減に比べればまだまだかわいいモノではあります。
#別のソフトで置き換えるから実害はあまり無いですが
#状況はいつも最悪、でもそれが当たり前
XP以外 (スコア:2, 興味深い)
こちらは普通に開けましたよ、他の方はどうなのでしょう。
しかし、この差ってなんだろう？
//95系だと大丈夫なのだろうか…
『それは仕様です。』 (スコア:2, おもしろおかしい)
でも、それはバグではないと知人より教わりました。
Re:XP以外 (スコア:5, 参考になる)
バグ仕様です。WinNT系のメモ帳はこのAPIの判定結果に従ってるだけ。
そもそもASCIIのテキストをUTF-16と誤認しているのが「バグ」の原因なのに、なぜUTF-8が出てくるのでしょうか? 仮にUTF-8と誤認してもASCIIのみのテキストは一切化けません。
参考:
Sorting It All Out : Behind 'How to break Windows Notepad' [msdn.com]
Unicode (スコア:2, おもしろおかしい)
この漢字のコードポイントはU+6974ですが、tとiのASCIIコードがそれぞれ0x74と0x69です。
というわけで、リトルエンディアンであることがわかりました。
Re:Unicode (スコア:1)
Re:Unicode (スコア:1, 参考になる)
notepad.exeのヘルプを見ると判りますが、
「ビッグエンディアンのUnicodeテキスト」ファイルも扱えるのですよ。
(PowerPCベースのMacでそういうファイルが作れる、ようなことを書いてあります。)
Re:Unicode (スコア:1)
# まあ漏れなく little-endian をサポートしている、とは言えるのかも。
# というわけで自衛策として BOM 付けると幸せになれるのでは、と
# 非常に無意味なことを言ってみるテスト。
とりあえず (スコア:2, 参考になる)
だいぶ前から知られているのに、なぜ今ごろ？
サポート (スコア:2, 参考になる)
notepad.exe /a で回避の模様。
出てきた文字列 (スコア:1)
２つ目：文字化け
３つ目：ANSI規格外の文字
４つ目：杵
５つ目：映
６つ目：ANSI規格外の文字
７つ目：渠
８つ目：牡
９つ目：文字化け
秀丸エディタ及びEmEditorでUTF-8を選択したら、そのまま保存が出来ました。
Super Souya
既報 (スコア:1)