Windows 10のメモ帳、CRLF以外の改行コードサポート追加へ 229
ストーリー by headless
改行 部門より
改行 部門より
Microsoftは8日、Windowsの「メモ帳 (notepad.exe)」で現在の「CR+LF」に加え、「CRのみ」および「LFのみ」の改行(EOL)コードをサポートする計画を明らかにした(Windows Command Line Tools For Developersの記事、
BetaNewsの記事)。
現行のメモ帳ではLinuxやmacOSで作成したテキストファイルを開くと改行が正しく処理されない。改行コードのサポートを拡大することで、改行コードを変換することなく正しく表示できるようになる。また、ファイルを編集・保存しても改行コードの種類は維持されるほか、ステータスバーに改行コードの種類を表示する機能も追加される。
この機能はWindows 10 Insider Preview ビルド17661 (RS5)以降で既に実装されている。これまでカーソル位置表示にのみ使われていたステータスバーは「右端で折り返す」を選択すると表示されなくなっていたが、改行コード表示機能追加に伴って常時表示可能となっている。保存時に改行コードを変更する機能は用意されていないようだ。
なお、ファーストリングとSkip Ahead向けに9日提供が始まったWindows 10 Insider Preview ビルド17666のメモ帳では、選択したテキストをBingで検索する機能も追加されている。既定のWebブラウザーがMicrosoft Edgeの場合、Setsの新しいタブで検索結果が表示される。他のブラウザーを既定にしている場合は新しいウインドウが開いて検索結果が表示されることになる。
ビルド17666ではこのほか、Alt+Tabでウインドウに加えてMicrosoft Edgeのタブを切り替えられるようになっており、複数のクリップボード項目の保存およびデバイス間の同期(設定→システム→クリップボードでの設定が必要)やエクスプローラーのダークモード対応、スタートメニューのタイルフォルダーへの名前設定機能なども追加されている。
現行のメモ帳ではLinuxやmacOSで作成したテキストファイルを開くと改行が正しく処理されない。改行コードのサポートを拡大することで、改行コードを変換することなく正しく表示できるようになる。また、ファイルを編集・保存しても改行コードの種類は維持されるほか、ステータスバーに改行コードの種類を表示する機能も追加される。
この機能はWindows 10 Insider Preview ビルド17661 (RS5)以降で既に実装されている。これまでカーソル位置表示にのみ使われていたステータスバーは「右端で折り返す」を選択すると表示されなくなっていたが、改行コード表示機能追加に伴って常時表示可能となっている。保存時に改行コードを変更する機能は用意されていないようだ。
なお、ファーストリングとSkip Ahead向けに9日提供が始まったWindows 10 Insider Preview ビルド17666のメモ帳では、選択したテキストをBingで検索する機能も追加されている。既定のWebブラウザーがMicrosoft Edgeの場合、Setsの新しいタブで検索結果が表示される。他のブラウザーを既定にしている場合は新しいウインドウが開いて検索結果が表示されることになる。
ビルド17666ではこのほか、Alt+Tabでウインドウに加えてMicrosoft Edgeのタブを切り替えられるようになっており、複数のクリップボード項目の保存およびデバイス間の同期(設定→システム→クリップボードでの設定が必要)やエクスプローラーのダークモード対応、スタートメニューのタイルフォルダーへの名前設定機能なども追加されている。
いいぞ (スコア:0)
次はデフォルトの文字コードに手を付けてくれたまへ
Re:いいぞ (スコア:1)
うむ。
しかし20年前にやって欲しかったよなw
Re:いいぞ (スコア:2)
そういえば全然ハイパーでないハイパーターミナルも緊急時には使っていたけどDOS窓でDOSの通信ソフトを動かした方がまともだったりしたなぁ。
Re: (スコア:0)
確かに今更感はありますねw
※マルチプラットフォーム開発だと地味に面倒くさい
Re: (スコア:0)
PHPがプラットフォーム関係なくLFだぞって規格で決めててくれるのありがたいね。
Re:いいぞ (スコア:2)
WindowsNTは1994年。
3.5でも1995年。
Re: (スコア:0)
Windowsの文字コードって複数あるの？
Re:いいぞ (スコア:3, 参考になる)
ありますよ。
日本語版WindowsはデフォルトではShift_JISの派生のCP932ですし、各言語でデフォルトの文字コードが違います。
関連ストーリーでUTF-8をデフォルトに変更可能になった [srad.jp]というのも有ります。
その気になればMacの文字コードやメインフレームに使われていたEBCDICも扱えます。
参考：扱える文字コード一覧 [microsoft.com]
Re: (スコア:0)
> その気になればMacの文字コードやメインフレームに使われていたEBCDICも扱えます。
え、これは初耳と思ったが、「Macの文字コード」や、「EBCDIC」も使えるって話か
なーんだ。
Re: (スコア:0)
地域と言語によって違ってたはず。
Re: (スコア:0)
メモ帳のだぞ
デフォルトだとANSIになってる
他にUnicode、Unicode big endian、UTF-8が使える
最近はHTMLやソースコード関連がUTF-8推奨なので
デフォルトをUTF-8に変えても良さそう
Re:いいぞ (スコア:5, すばらしい洞察)
Re:いいぞ (スコア:1)
いや、むしろ他がBOMを必須にしてほしい
BOM は重要 (スコア:1)
BOMは文字エンコーディングやエンディアンを確実に判別できるという重要な役割を果たしているわけなんだけど
それが無かったら判別のためにテキスト全文を読んで、どの文字コードだと解釈すれば矛盾が無いかを評価しなくてはならず
非常に負荷が高い
その上、本文が短い場合には複数の文字コードで矛盾が生じないケースもあって、自動判別が不可能な場合まである
複数のファイルを結合して問題が生じる？
いや、BOMはファイルの先頭以外では無視しなければならない（幅0の空白文字）仕様なんだから不具合が生じる方がおかしい
そして、BOMのせいで動作しないアプリケーションはUnicode自体に非対応なのだから、Ascii だけ使ってればいいのでは
BOMで不具合を起こすようなアプリケーションは、UTF-8 が読めているように思えてもたまたま動いているだけで、
その他のUnicode制御文字も扱えないでしょう
シェルスクリプトから Ascii しか扱えないような古いスクリプトを呼び出して使いたいとかだったら
その前にBOM消してから渡す処理書けばいいだけでは、そんなの1分ありゃ書けるでしょ
UTF-8 において、BOMは必須でも推奨でもないけど、付けたからといって仕様違反ではない
扱えないアプリがタコ
Re:BOM は重要 (スコア:1)
何言ってんの、BOM 付き UTF-8 は、UTF-8 の最大の利点である、
ASCIIの範囲の文字しか使っていない場合は、従来のプレーンテキストと一切変わらず、古いプログラムでもそのまま処理できる
を投げ捨てているわけで、正直考えた奴は莫迦の極みでしかないエンコーディングなんだが
# windows 以外ではまず使われることがない、よくある「標準規格からちょっとズレたMS独自仕様」の名残だと思ってる
メリット＞デメリット (スコア:1)
BOM有りのメリット:
文字コードやエンディアンの誤認識を防げる
BOM無しのメリット:
ASCIIしか扱えないプログラムとの互換性を保てる
ただし、ASCII文字以外を含めない場合に限る
BOM無しのメリットが弱すぎると思うのですが
BOM有りのBOMを消すのは簡単だけど、BOM無しUFT-8で文字コード誤認識を完全に防ぐのは技術的に不可能ですからね
色々な環境で扱う可能性を考慮するなら、BOMが無いせいで文字コードが誤認識される場合も考慮すべきでは
Re: (スコア:0)
PCゲームの海外版の開発に関わっていたとき、あるキャラクタのロードでクラッシュするという謎の現象を追いかけていたらテクスチャのファイル名にいわゆる全角の漢字が含まれていたのが原因だった。
コスパ (スコア:0)
notepadって昔から使われているがほとんど変わってないよね。
最新の開発環境なら数日あれば作れそうなのに。
利用時間を開発コストで割ると全ソフトウェアでも世界最高近くのコストパフォーマンスかもしれない。
正直手を付けられる人、手を付けようとする人はほとんどいないんじゃないか？
ソリティア・マインスイーパーよりよほど書き直した方がいいソフトだと思うけどな。
Re:コスパ (スコア:1)
一切の仕様変更をしないのなら書き直す意味がないし、何らかの仕様変更を伴うならユーザーの反発を覚悟しないといけない。
書き直すのにリスクばかりが高くなる案件だと思うけどな。
Re:コスパ (スコア:2, すばらしい洞察)
だよね。
ミニマムのツールはミニマムのツールとしてデフォルト、デファクトになる信頼性を持って存在し続ける事に意味がある。
Re:コスパ (スコア:1)
ミニマムのツールねぇ…
誰も語らなかったメモ帳のすごい隠し技 [arinco.org]
Re:コスパ (スコア:1)
[HKEY_CURRENT_USER\Software\Microsoft\Notepad]
"lfEscapement"=dword:00000000
"lfOrientation"=dword:00000000
"lfWeight"=dword:00000190
"lfItalic"=dword:00000000
"lfUnderline"=dword:00000000
"lfStrikeOut"=dword:00000000
"lfCharSet"=dword:00000000
"lfOutPrecision"=dword:00000003
"lfClipPrecision"=dword:00000002
"lfQuality"=dword:00000001
"lfPitchAndFamily"=dword:00000031
"iPointSize"=dword:00000050
"fWrap"=dword:00000001
"fSavePageSettings"=dword:00000000
"lfFaceName"="Andale Mono"
"szHeader"="&n"
"szTrailer"="Page &s"
"iMarginTop"=dword:000009c4
"iMarginBottom"=dword:000009c4
"iMarginLeft"=dword:000007d0
"iMarginRight"=dword:000007d0
これのことだな
lfで始まるのはLOGFONT構造体にそのまま対応しているだけだな
typedef struct tagLOGFONT {
LONG lfHeight;
LONG lfWidth;
LONG lfEscapement;
LONG lfOrientation;
LONG lfWeight;
BYTE lfItalic;
BYTE lfUnderline;
BYTE lfStrikeOut;
BYTE lfCharSet;
BYTE lfOutPrecision;
BYTE lfClipPrecision;
BYTE lfQuality;
BYTE lfPitchAndFamily;
TCHAR lfFaceName[LF_FACESIZE];
} LOGFONT, *PLOGFONT;
Re:コスパ (スコア:2, 参考になる)
もとは32kbしか編集できなかったメモ帳に何を求めているんだ？
Re: (スコア:0)
UIが変わらないだけで、中身が変わってないとは限らないかと
メモ帳って、Vi動かすまでしか使わないよね (スコア:0)
タイトルは冗談ですが、本的にメモ帳って使っている人居るのでしょうか
居るから騒がれるんでしょうけど)
自分の場合、OSインストール直後かクライアントのローカル設定時位にしか
使ったことないもんで
Vi(Vim)って、Emacs動かすまでしか使わないよね (スコア:2, おもしろおかしい)
タイトルは冗談で、WindowsではサクラエディタやAtomを使っていますが
*.txtの関連付けはメモ帳からは変えませんね。
メモを書くならメモ帳です。
# え？ OneNote？ 何ですかそれは。
Re:メモ帳って、Vi動かすまでしか使わないよね (スコア:2, 興味深い)
すみません、私、本（ 200 ページ弱）を一冊だけ出したことのあるナンチャッテライター（昨年改訂版出せた）なんですが、メモ帳で書きました。
テキストファイルダブルクリックだけですぐに開きますし、頭の中で考えたことを垂れ流すだけなので、他の機能も不要でした。
あるといいなと思った機能としては表記の揺れのチェックくらいでしょうか。
別に他のエディタでもいいのでしょうが、勝手に落ちたりとかも経験がないので、私にとっては安定のアプリケーションですね。
Linux 上で扱うファイルを見るにはワードパッドで開けば改行問題は解消（保存はしない）できるので、メモ帳で不便を感じたこともありません。
Re: (スコア:0)
Windowsサーバーの本番環境などメモ帳以外の選択肢が無い環境ってのも結構有ります。
Windowsだけで環境が固まってれば良いですが、
それ以外とファイルをやり取りする場合、改行コードはネックになりますね。
Re:メモ帳って、Vi動かすまでしか使わないよね (スコア:1)
気持ちはわかるけど本番環境にログインしてエディタで何かしら編集するってのは時流的にダメなのでは
Re:メモ帳って、Vi動かすまでしか使わないよね (スコア:1)
その場合であってもFTP転送モードのascii/binaryを理解しないまま逆に使って
ダイジェスト値が合わないとかその他のすったもんだがよくある話のひとつ。
Re:メモ帳って、Vi動かすまでしか使わないよね (スコア:1)
ftpとか。
ええと、元の話としては、「本番環境」として「時流的に」どうか、なんだよね。
で、ftpって、本番環境でなくとも時流的にどうなの?
サーバ上でエディタを使うのと比べても、かな～～～～～～り時代遅れな気がするけど。
Re:メモ帳って、Vi動かすまでしか使わないよね (スコア:1)
tftpと読み替えて、サーバ・ワークステーションだけでなくネットワーク機器も
含むと話をまとめ直すと時代遅れでも妥協できるのではないかと思う。
Re:メモ帳って、Vi動かすまでしか使わないよね (スコア:1)
SIerじゃなくても、諸般の事情で、いろんなPC使っていると、メモ帳とか、NotePadは必須。
Unix系で、Viを使うみたいに。
効率は悪いが、ある事が期待できるツール。
Edlinより、ずっとまし。
Re:メモ帳って、Vi動かすまでしか使わないよね (スコア:1)
ＶzエディタのソースコードってEdlinで書いたものだったらしい。すげぇ。
Re:メモ帳って、Vi動かすまでしか使わないよね (スコア:1)
そのcatもUnixブート起動時に走る nantoka.rc に織り込まれている
catとほぼ等価のサブセットのシェル・スクリプトではないかという話は
さすがにないか…
余談だが vi 開発の際 BSD マシンが飛んだことは一度や二度ではなかったはず。
Re:メモ帳って、Vi動かすまでしか使わないよね (スコア:1)
最初の入力にはcatを使ったかもしれないけど、
viより前にラインエディタであるedやexがあったあら、
さすがにcatでは編集・修正はしてないと思う。
そのexやedは、viの祖先みたいなもんだから、edがcatで書かれた可能性は無くは無い。
けど、edの祖先のQEDってのはあったみたいだから、catのみ、ってことも無さそうな。
Re:メモ帳って、Vi動かすまでしか使わないよね (スコア:1)
というより、今でもexとviは同じものだね。
Re:メモ帳って、Vi動かすまでしか使わないよね (スコア:2)
それは、「今でも」の証拠にはなってない。
「今だから」の可能性がある。
充分な互換性があるものを、シンボリックリンクにしていることはときどき存在する。
Re:メモ帳って、Vi動かすまでしか使わないよね (スコア:1)
＞「今だから」の可能性がある。
手元実機じゃなく脳内エビデンスだけど
20年位前の HP だったか Sun のワークステーションでは
vi と ex と edit がハードリンクだったような記憶。
Re:メモ帳って、Vi動かすまでしか使わないよね (スコア:1)
それは、「今でも」の証拠にはなってない。
「今だから」の可能性がある。
そうだね。
単にシンボリックリンクの存在を示しただけなら、「今でも」の証拠にはならない。
しかしながら、スレッドの流れを読んでもらえないかな?
歴史的に、exからviが作られたのは事実 [wikipedia.org]。
その事実に基づいて、lsの結果を示して「今でも」と言っている。
viは、exスーパーセットなので、今や独立にexだけ独立しているコードは使われてないと思うよ。
あるいは、それはviではなくvimだ、と言いたいのかもしれないけど、それなら最初から素直にそう申告するように。
それならそれなりの議論をする。
下らない揚げ足取りは無駄。
Re:メモ帳って、Vi動かすまでしか使わないよね (スコア:1)
ご教示多謝。
Edlinで開発したのはＶzエディタと命名される前のごく初期だけで
以後はM.C.エッシャーのモノクロ絵、Drawing Hands [google.com]同様なのですね。
その方がしっくり来ます。納得。
Re:CRのみ (スコア:1)
その昔、
Macが、CRのみで、UnixがLF のみ、DOSが CR+LF と覚えていた。
で、通信規約(どこの?)を見ると、正しいのが、CR+LF で、LFのみも OKとあったと記憶している。
当時の(今も)MACは唯我独尊で、接続時に苦労したことばかり。ファイル名を漢字で作って、MACに行って帰ってすると悲惨なことになる事が、、上司が大好きで、、お蔭で色々と勉強に。
消せないファイルの消し方も知ったし。
当然、ファイル内の改行コードは混在。コンパイルエラーの原因が分からないとか。(親切じゃない) そう言えば、ファイルの最後に 改行が無いと意味不明のエラーを出すコンパイラもあった。それで最後に必ず、改行の習慣、、、最近の Pythonだと逆に警告。
Re:CRのみ (スコア:1)
> ファイル名に漢字(ASCII文字以外)を使う時点で論外のような気が。
上司が大好きだったんです。
漢字だったかの記憶は正確でないですが、Ascii文字以外だったのは確か。
で、9割以上は問題無かった。(なぜだ?)
ちなみに漢字コードも Shift-JIS と EUCが混在。Macはなんだったか?
MS-DOS - Unix - Macの混在環境。
Unix上のファイルを Macから使うと問題発生。
読めなくなったら、アクセス可能なファイルをよそにコピーして、ディレクトリごと削除。
Re:メモ帳使いを何と呼ぶ？ (スコア:1)
一般人
Re:メモ帳に欲しい機能 (スコア:1)
個人的には、そこまでの機能は求めないな。
文章ならWord(とかExcelとか(笑))で書く、って人が多そうだし、メモ帳の機能としては需要が少な過ぎて採用されなさそう。
そういう意味で、改行コードも今までは需要が少ないと思われてたんじゃないかな。
改行コードを問題にするのは、一部のユーザだけで、その他大多数のユーザにとっては気にもしないところでしょう。
あるいは、戦略的にLinuxなんかを無視してた、ってことなのかもしれんけど。
Re:マイクロソフトなんかどうでもいい (スコア:1)
MSなんかどうでもいいという偏見の人もこの10年くらいは流石に少なくなってたので、こういう意見はむしろ新鮮…。
そのMicrosoftが作ったエディタである Visual Studio Code は、いまやGitHub最人気プロジェクトの1つになってますね。あまりに優秀なので最近はAtomなんかの3倍以上の速度でスターが伸びています。PC初心者はメモ帳でよくて、文字コードとか理解できるレベルの人になったら vscode ってことでいいんじゃないですかね。
Re:マイクロソフトなんかどうでもいい (スコア:1)
Appleの製品よりはマシなのでokです。
#親コメの言い様に合わせた言い方にしました。
Re:10年遅い (スコア:1)
入力もせず、元々あったファイルを「asisの保存」するのって、何か意味があるの?
Copy-Itemじゃダメなの?
Re:10年遅い (スコア:1)
んー、判らんではないけど、それは誤って保存してしまうのが悪いんだよね。
改行を正しく扱うエディタであっても発生しうる事故だし、
むしろ必要なのは、閲覧専用で開く機能なのでは?
閲覧するだけなら、moreで開けば書き込みは無いし、改行コードも問題にならないよ。
もちろん、Get-Contentでもいいし、IEやEdgeで開いたっていい。
Re:どーでもいい (スコア:1)
メーカーとか色々見てきたけど、
何してもいい所なんてのは大手になるほど無くなっていく印象。
PCにインストール出来るものすら限られてくる。
クローズドネットワークならそれも許されたりするけど、
開発としてはやりにくいよね。