2021/04/04(Sun)
○[Windows] Windows10のメモ帳が文字化けする
やはりあのスターの球団って、大輔という名前の監督は鬼門なんじゃないかな(挨拶)、毛髪の有無は無関係なもよう。 そろそろ「 三浦大輔監督とともに苦難を乗り越えてゆくスレ」が建ってたりするんだろうかね…
＿＿＿＿＿＿_ ／ ＼ ／ 81 _＿ノ ／ ／＼/＼＿＿_ノ＼ | ／ ＼ , , ／ ＼ |:::::::: （●） （●） | |:::::::: ＼＿＿_／ | ヽ::::::::::::::: ＼／ ノ 「今日は負けないヨ・ロ・シ・ク！！」 . . .... ..: : :: :: ::: :::::: :::::::::::: : ::::::::::::::::::::::::::::::::::::::::::::: Λ＿Λ . . . .: : : ::: : :: ::::::::: ::::::::::::::::::::::::::::: /:彡ミ゛ヽ;）ー､ . . .: : : :::::: ::::::::::::::::::::::::::::::::: / :::/:: ヽ、ヽ、 ::i . .:: :.: ::: . ::::::::::::::::::::::::::::::::::::::: / :::/;;: ヽ ヽ ::ｌ . :. :. .:: : :: :: :::::::: : :::::::::::::::::: ￣￣￣（_,ノ ￣￣￣ヽ､_ノ￣ 「試合ねぇだろ…」
さて本題、昔はUTF-8で保存すると本来あってはならないBOMを先頭にいれて保存しやがるタチの悪い振る舞いをしたWindowsの「メモ帳」アプリだけども、最近はふつーにBOM無しで保存してBOMつきで保存するには文字コード選択ドロップダウンで「UTF-8(BOM付き)」を選ばんとならんのだな。
ところで21世紀になるかならないかの頃に一部の人がBOMありが正しい！BOMなしのUTF-8はUTF-8Nと呼ぶべき！みたいな主張をしたせいで未だに数多くの珍記事が検索にヒットするわけだが、チェストん前名前訊くんは女々か？ まぁインターネッツがいくら誤情報だらけになろうがもはや気にしたって時間の無駄である、書籍に還るよワイは。
そんなことよりもだね、デフォルトがBOM無しになったことでShift_JIS(Windows-31J)とUTF-8(BOMなし)の自動判定がアレになって文字が化けよることがママあるのよな。
うーんこんな実装だと、 UTF-8N復権派が「なぜなら俺は始祖マークを信じてる！」「うおおおおおおおおおおおおおおおおおおおおおおおおお！」して歴史捏造しだしそうなのでどうにかせーや。
というか こっちの記事だと「なおBOM無しはUTF-8Nと呼ばれることがある」なんて書いてあってまだまだ活動中の模様である。
この始祖マークってのは元IBMで現GoogleのMark Davisの事、なお進撃ネタでなくマジモンで始祖(Unicode Consortiumの創始者のひとり)である。
彼がIBM時代に書いた このページ(消失してるのでwebarchiveより)の中段くらいの「Table 2: UTF serializations」ってのがあってそこに
- UTF-8 … BOMあり
- UTF-8N … BOMなし
って書かれてたもんで、これをソースにしてたんだよなUTF-8N派は。
それでは始祖ご本人による弁明を お読みください、いやUTF-8Nはイタリック体だからセーフってさ、あなたUTF-8の項にBOMありと仕様相違なこと書いてたよね…これはお前が始めた物語だろ。
つーことで始祖も否定したUTF-8Nなんだが、復権派って輩ってのはまだほとんど解読できてない古語でも手前勝手に解釈してそれを真実と信じこむタイプだからな厄介なのよね。
そもそもUTF-8のメリットってのはUS-ASCII互換な事なのだけど、BOMありだと
- システムコールのexecve(2)はテキストファイルの先頭に「#!」つまりshebangがあったらスクリプトと判断し後に続くインタプリタを起動する
- しかしexecve(2)はBOMつきUTF-8のスクリプトだと、「#!」より先に「0xEF 0xBB 0xBF」があるのでスクリプトと認識しない
という問題があってそっちの方がより重大な問題なのですわ。 文字コード自動判定なんてできたら便利ですね程度のシロモノのために、スクリプトがUTF-8で書けなくなるとかアホでしょ。
まぁプログラムがどうやって動くかなんてまともに知らん人でも口つっこめるのが文字コードの話であって以下略、なんか自分に盛大にブーメランが返ってくるのだが気にしない、イタタタタタ。
だいぶ脱線(いつも)したので話を戻そう、このメモ帳の文字化け問題でおもしろいのは同じファイルであっても
- ダブルクリック(あるいは右クリックのメニュー)で開く … 問題なし
- メモ帳のメニューから「開く」で読みこむ … 文字化け
って謎の挙動を示すことなんだよな、なもんで大半の人はダブルクリックでしか開かんだろうからまずこの文字化けにはお目にかからないのであまり問題になって無さげ。
なぜこういう挙動を示すのかを考えてみると、もしかしてダブルクリックした時の文字コードの自動判定ってメモ帳ではなくシェル(エクスプローラー)側でやってんのかなぁと。 メモ帳は昔から変わらずおバカのままで、BOMあったらUTF-8無ければShift_JISと解釈してるのでは疑惑がある。
もしかしたらNTFSの拡張属性に文字コード名保存してるのかもと思ったけど、SysinternalのStreamsコマンド(もしかすると同等の機能がPowerShellにあるかもしれないが調べるのめどい)で確認したけど無さげ。 まぁシェルでなくメモ帳がやってるとしても、ダブルクリックとファイルで違う自動判定ロジックが動いてんだからまぁアレだわな。
いやまぁ自分はAAの編集以外はメモ帳でなくいまだCygwin上のvimであれこれ書くのでこれ以上深追いする気はないんだけどね。
いつまでCygwin使ってんのかといっても、もはやWSL(Windows Subsystem for Linux)という名前すら忘れてて今この記事に「みんなとっくにSFUに乗り換えたんだろうけど」とか書きそうになってしまったゾ。 おいおいSFU(Subsystem For Unix)っていつの時代だ、SUA(Subsystem for Unix-based Application)ですらねえ！
まぁCygwinがいまだにB21の頃のちょっとでもなにかしようとするとトラブルにぶち当たるアレだったなら速攻で乗り換えたんだろうが、もう何年もCygwinならしゃーない的な問題にぶち当たったことが無いのですわ。 いや単純に馴れきってしまっただけなんだろうか。
そいや文字コード自動判定がらみの話でついでだけど、perl5のEncode::Guessってけっこう優柔不断でうーんどっちか判んない！とばかりに候補複数返すの、古のjcode.pl使ってる歴史的コードを修正するときに案外使いづらいなって昔感じたことを思い出した。
まぁそもそも文字コー自動判定そのものが悪というのはワイは何年も前から言い続けてるわけですが、まぁ蝉の鳴き声に耳傾ける人なんてのはいないってことで。