【IT】「メモ帳」がLinuxの改行コードをサポート
■ このスレッドは過去ログ倉庫に格納されています
Microsoftの開発者向けイベント“Build 2018”が米国シアトルにて開催中で、今日は2日目のキーノートセッションが行われていました。新しい機械学習技術やクロスデバイス体験などがお披露目されましたが、なかでも会場を沸かせたのがこれ。
https://forest.watch.impress.co.jp/img/wf/docs/1120/764/image1_s.jpg
なんと「メモ帳」が改行コード“LF(0x0A)”をサポートするのだそうです。Linuxなどで作成されたテキストファイルを「メモ帳」で開くと改行が認識されず、すべて一行で表示されてしまったりしますが、こうした不便が解消されます。
改行コードというのは、テキストの“改行”を表す特殊な文字(制御文字)のこと。一般的に“キャリッジリターン(CR:0x0D)”と“ラインフィード(LF:0x0A)”の2つをいい、もともとはタイプライターで紙を移動させる装置(キャリッジ)を元に戻す(リターン)操作と、紙を一行(ライン)だけ上に送る(フィード)操作を表しているのだそうです。
どの制御文字を改行コードとして採用するかは歴史的な事情でプラットフォームごとに異なります。
Windows(CR+LF):CRとLFの2文字で改行を表す
Linux(LF):LFのみで改行を表す
古いMac(CR):CRのみで改行を表す
“行を改めて行頭へカーソルを移動させる”操作を考えるとキャリッジリターンしてラインフィードする“CR+LF”が本来の意味に忠実な気がしますが、それだけのために2文字も使うのは馬鹿らしいという考えにも一理あると思います(現在ではあまり気になりませんが、かつてはメモリもディスクもネットワークも今よりずっと貴重でした)。
さて、「メモ帳」の改善については公式ブログ“Windows Command Line Tools For Developers”で詳しく説明されていますが、それによると
最新の「Windows 10 Insider Preview」で試せる(編集部にてBuild 17661で確認)
新規作成ファイルは従来通りCR+LFコードで作成される
LFだけでなくCRもサポートする
ステータスバーに改行コードの種類を表示する
互換性に問題がある場合はレジストリを編集して元の挙動に戻せるようにする
のだそうです。Linuxで開発されたソフトのライセンスや利用許諾、設定ファイルはLFコードで書かれていることが多いですが、わざわざサードパーティ製のテキストエディターをダウンロードしなくても「メモ帳」で閲覧・印刷できるようになるのは結構うれしいですね。
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1120764.html >>92
パイソンはちょっとしたものを作るのに優れてるけど、大規模開発に耐えられるかなぁ〜? >>101
できないことはないけど、基本はグルーだね >>62
BOM付けないと、エンコーディング指定できないメモ帳では何の文字コードで表示すればいいか分からんだろ Excelが、UTF-8のCSVを読み込めないというバカなんだけど。 >>101
そもそも大規模って何作るのさ
いくつかの小さなPythonコードと、
大規模データベースと、HTMLのUI繋げりゃ
大抵の用途はカバーできると思うが >>107
大規模開発やったことないの?
自分はそこまで本格的な小規模開発やったことないけど。 >>2
異なる改行コードが混在してたらどう表示して保存時にどうすればいいのかとか
CRLFじゃなくてLFCRだったら1つの改行にするのか2つの改行にするのかとか
イレギュラーなケースを考え始めると面倒くさくなって
まいっかで放置する気持ちはわかる >>2
この皮肉がわからない奴は
外であまり喋らない方がいい メモ帳は良く使う
ワードパッドは全く使わない
ワードパッドって残す意味あるの? メモ帳の対応より先にテキストファイルの改行コードすら統一出来てない方を問題視しろよ >>116
確かに
UTF-8のRFCあたりで改行コードの推奨があっても良かったかも 素晴らしい。
欲をいえば、標準でvi使えませんかね。 >>62
まあいい加減Linux側もBOM読み飛ばすようにしろよって思う
どっちもどっちだわ 要するに、ソフトのインストールが制限される派遣とかには朗報って事? 在日韓国・朝鮮人は単なる「不法入国犯罪者」です。
戦後の混乱で強制送還できず、しかたなく「朝鮮戦争の難民」という扱いで
特別に在留を法的に許可してる状態です。
つまり、朝鮮戦争が終結すると祖国へ帰らなければならないのです。
日本政府「「在日61万人中、徴用者は245人、あとは勝手に来て住み着いた者」で間違いない」
https://hayabusa9.5ch.net/test/read.cgi/news/1525094153/
在日韓国人3世に「永住権」なし 日韓基本条約で受け入れ義務なし
http://www.thutmosev.com/archives/57555487.html 素直にUNIXをパクればよかったのに、どうして余計なオリジナリティを入れちゃったの? ディレクトリの区切り文字も >>125
MS-DOS開発時にUNIXはパクられるほどメジャーではなかったからでしょ 昔のDECのOSを真似たのがCP/Mで、さらにそれを真似たのがMS-DOS
PDP-11の頃はCR+LFが改行コードだった CRが行頭復帰でLFが行送りだからあってるっちゃあってるんだよ
タイプライターやテレタイプではw >>121
BOMってパイプ処理との相性最悪じゃね そういや「Linuxの改行コード」であって「UNIXの改行コード」じゃないのね。
商標だから名前を出せないって事情とも思えないけど。 日本のシステム的にはUTF8は無駄の固まり
トラフィックが最大で1.5倍程度になるとか UTF8はデコードが面倒くさいからUTF16の方がいいな 日本向け文字コードを云々より、日本人が英語をメインにすべき
まあ無理だろうがな もうとにかくUTF8で統一しろ
エンコードで時間を浪費するのはもうたくさん >>144
UTF8はエンコード・デコード時間かかるだろ >>146
それは俺じゃなくて>>144に言うべきだろう >>145
開発者が文字化けで浪費する時間が無駄だって言ってんの。
現代のPCの性能ならエンコードの処理なんて一瞬だし不可もクソ軽いだろ。 MSは既にOSで稼がない方針になってると聞くけど、
Windowsはオープンソース化すればいいのに >>149
> Windowsはオープンソース化すればいいのに
着々と進んでるぞ
第一弾はファイルマネージャだ!
https://github.com/Microsoft/winfile
第二弾があるかどうかは知らんけど... UTF-8BOM有無とかUTF-16とかサロゲートペアとか文字コード関連の仕様はめんどくさいわ
統一してくれ 自分でサーバー立ててみたりオタッキーなことしようとしたらLinuxは使う >>159
実力に不相応なまでに虚飾のプライドが高くなる危険性があるよね(自戒)
そういう危険を避ける意味ではlinuxのがおすすめ EUC-JPの事言うなら、MS932もやめてほしい。
メールもUTF-7で統一しちゃって。 >>143
Muri ja nai yo
Eigo kantan >>161
未だに8bit通さないMTAとかあるの? >>46
馬鹿が発言するとこうなるといういい例ですね >>151, >>164
だから不要と思えば読み飛ばせよ
メモ帳がいつまでもBOMつけるのもどうかと思うがいつまでもBOMついてたらエラーにするのもどっちもどっちだろ >>168
BOMついているのを能動的に感知してエラーになる訳じゃなくて、BOMに対応していない多くのアプリケーションで不具合が出るんだよ
utf-8はasciiのみ解釈してそれ以外のバイト列を素通しするだけのフィルタ的なプログラムがそのまま動作するところが大きなメリットなのに
その他の文字コードも基本的にそういう設計思想で作られている >>169
だからそう言う自分は正しいって言う姿勢をいつまで続けるんだって話
ユーザーから見たらそんなアホな思い込みは迷惑なだけ >>170
アプリが個別対応する必要があるんだよ
別にlinuxでもコンパイラとか、テキストファイルとして扱うことが決まっているやつは今どき対応しているが、sedやらawkやらでユーザーがバイナリ的に扱いたいのに勝手に対応されてストリーム加工されるのは迷惑だし >>171
話の流れを読めないバカは絡んでくるなよ
>>172
> sedやらawkやらでユーザーがバイナリ的に扱いたいのに勝手に対応されてストリーム加工されるのは迷惑だし
ストリームにBOM付きで流すなよ...
ファイルオープンの時に処理すればいいだけでしょ >>173
ファイルにBOMを記録するなよって話な ほぼほぼ役に立たないBOMをわざわざつける必要無いわけで そもそもメタ情報をデータ本体に記録するというのが筋が悪いんだが >>174-176
だからそんなのはみんなわかってる
それでも文句だけ言ってても誰も幸せにならんだろって話な
「送信は厳格に、受信は寛容に」
RFC 1958 にも書いてある >>173
>>177
個々のコマンドで対応するより前段にBOMStripperかますのが筋がいいと思うよお
sedあたりで作れそうだが >>179
>>172みたいな人にはそれでいいかもね
ただストリーム云々言ってる奴は実態を知らずに語ってるだけで、実際の問題は設定ファイルが読めないとかデータの頭にゴミか付くとかなのでBOMStripperとやらで対応するのは難しい 文字列UTF8で扱うのにBOM付いたら読めなくなるって
それRFCとか規約通りに実装してないってことだろ?
RFCにはBOMについても記述してあるだろうに
元々BOMの概念がないASCIIやらJIS規格との
共用のために考えられた仕組みなのに、
規約通り実装しないならもうASCIIで全部記述して
日本語とかのマルチバイト入力をアプリで禁止させろ >>181
文字列UTF8で扱う規定なぞ無い設定ファイルでコメントにutf8入れても、BOM無しなら他の大多数のascii互換のエンコーディングと同様に問題は出ないが、BOM有りだと問題が出る
設定ファイルをメモ帳でちょこっといじってセーブしただけで今まで問題なかったものがおかしくなる。
それをBOMとはなんぞやとわからん様な素人がやるから質悪い ファイル名やディレクトリ名にスペースが入ってるとバグるプログラム
そんなのを作ってスペース入れるなと文句言ってる無能に似た雰囲気を感じる
Linuxでもスペース入りはサポートしてるのにMSをディスってるのも同じ BOMの有無を問題視してるバカってどう見ても仕事できない役立たずだわなw IEってWindowsユーザーにはもう使われていないウェブブラウザでしょうか? >>184
技術的な反論はできないからとりあえず煽ってみました
ってかww >>186
技術的とかバカかw
いまどきBOM非対応ソフトなんて使う方が頭悪いだけ
とっとと捨てろ BOM非対応って、どうせ1バイトのASCII前提で、BOMなしファイルだったとしても、フォント指定
したところで日本語をちゃんと表示できないんじゃないかな?
カーソル動かす時に、2バイト文字だと、矢印キーを2回押さないと次の文字へ
移動しないとか、DOS/V時代のスクリーンエディタとかそんなソフトに需要あるか? メモ帳で.shファイル作ってそのままLinuxで使うと酷い目に遭う
うちの新人がそれでハマって泣きを入れてきた UTF8にバイトオーダーは無いのにエンコード種別判定の
ためにBOMを使うというアイデアがもう古臭い >>195
知ってる知識で、UTF8とUTF16の違いを説明してよ。 1文字は何バイト? よく知らんけど1コードポイントでUTF8可変長バイトUTF16 2バイトでは? >>199のgrepにはどんなすごい機能があるんだろう? >>200
grepコマンドはfindstrと違って行ではなく
直接指定した文字を見つけて抜き出せる。
あまり違いがないように見えるけどそれは大間違いで
findstrでは行全体しか抜き出せないけど
grepでは"○○の後ろの3文字"という形でそれだけを抜き出せる。
環境変数として使ったり抜き出した文字を使って新しいファイルを生成したりと
grepの方が使い道が多い。 ■ このスレッドは過去ログ倉庫に格納されています