【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 20年以上かけてやっと実装できたのか
こんなの簡単そうなのに、実際にはものすごく高度な技術が必要だったんだろうな オープンソースのnkfみたいな
日本語の文字コード変換便利な
Win用フリーソフトてありますか？ Windowsが面倒なところは、ディレクトリをサーチして文字列の配列として取ってくるとShift-JIS、なのに
ファイルの中身はUTF-8、だからLinuxとプログラムが同じにならない。どうやって中身を調べるか、ある
encodeを全部試してみる...だから、労働生産性が悪いんだよ。かな漢字変換入力も結構ムダだ。 ってかデフォルトで秀丸エディタ位の機能は付いててほしい というかWindowsをUNIXベースにすればいいんじゃね？
MacOSXみたいに 文章いろいろ書いたから、「トランプ大統領」って書いてあるのを探したい。
Linuxならgrepで1行で探せる。Windowsの標準にそういう機能ないからなぁ。
だいたい便利さの年季が違うんだよ。 >>10
秀丸くらいがどういったものを期待しているか知らないけれど
Win10なら標準でCode Writerついてるから改行コードと文字コードは対応できるよ >>15
以前からfindstrというコマンドついてる 機材入れ変えると、取り急ぎ
サクラエディタ、winscp、teratermを
入れないと仕事ができない。
メモ帳・・使わんな。 いやこんなのよりviクローンだせよ
そして標準アプリとしていれとけ >>17
Select-stringも使えるけれど、そのWindowsローカルなルールがもう時代遅れだよ。
grepにそろればいいだけの話。 >>18
コマンドプロンプトがSSH対応すれば楽なのにね メカニカルなタイプライターを知らない世代は「キャリッジリターン」「ラインフィード」の本来の意味も分からないだろうからなあ。 \も疫病神だなぁ。c:\windowsぐらいの時代はよかったんだが、5階層ぐらいあるときとか
TeXで文章を書いているときは、金まみれになる。フォントを切り替えれば良いんだが、
教科書が\で書いてあると絶望的な気分になる。 >>20
過去の互換性維持の問題もあるからね
UNIXコマンドに慣れてる人はcygwinなり
Windows subsystem for Linuxなりいれるだろうし UTF-8には対応してたっけた
してくれてたら嬉しいけどな EUC-JPが混在してるLinuxには言われたくないだろう まじかよ
主にこのためにわざわざエディタ入れてたんだよ Androidで作成した文章をPCに転送すると一行になるのはこれだったのか ジョブズならこれがいかに革新的なことなのかドラマチックにプレゼンする 別にやるなとまでは言わないが、今さらどうした？とは言いたい 大昔から殆どのフリーソフトは、既に実装している機能だけどね。
まあ、真っ黒ソフトの技術力からすれば、技術力が付いたねと褒めて
おいてあげようｗｗｗ 既にWindows10はLinuxになってるに、1票 独自色を出したかったんでしょ？
マックも同じだろ
でもパンピーがWindows使わなくなったから単純にWindowsユーザーだけが
Windowsの特殊仕様で割を食うようになった もうちょっとすればguiアプリもプラットフォーム依存が消えそうだな vi でいいからプリインストールしとけビルゲイツよ ダブルクリックで単語選択できなくなったのは治ってないの？環境のせい？
以前はできていたのにWindows 10 Updateのいつからかできなくなった
あとUTF-8保存すると強制的にBOMが付くのも改善されたりしないのかな >>2
技術よりも大変なのは人の考えとその考えが積み重なった文化を変えること。
昔の偉人は月に人を送り込めたのは途中に人間の国がなかったからだと言っている。 >>1
シフトjisを止めてUTF-8にするとかだな・・・
もっと先にやることあるだろ・・・ >>7
変換自体はそこらのエディタでできるけど、nkfみたいにパイプで自由にってのはないから、WSLでそのままnkf使ったら？ >>15
開発環境とクライアント専用環境比較されてもね。
君らがいくらlibux持ち上げても、windowsからlinuxに移る人は多くない。
それが答えだよ。 utf8のbom地雷は相変わらずなんだろ。 どうせ。 skypeとか買収するぐらいならまずは秀丸でも買収しておけばよかったのに メモ帳でutf8のhtmlなどを編集してはいけません。 地獄が待っています。 >>7
Windowsのnkfあるし
10ならサブシステムにUbuntu積んでるし
最悪仮想pcやdockerでも良いでしょ
少しは頭使ってこ？ 昨日、ＷＩＮ１０アップデートしたら、テキストファイルを「メモ帳」で開くと日本語が文字化けするようになった。
メモ帳でなんかソースコードいじってるだろ。
もとに戻せ！ばかやろう！ 下手に変な使い方するくらいなら分からない言葉は使わないほうがいいという良い例 そんなことより、[Ctrl-H]をバックスペースにしてくれ。 >>5
保存すると勝手にBOMつけるじゃんよ。
アレすごく困るんだが。
スクリプトが動かなくなったとかで調べると先頭にBOMついてた、ってケースが希によくある…。
大抵、メモ帳で修正して保存したとかなんよね。 以前からUbuntuで作ったテキストファイルをWin１０の「メモ帳」で開くと文字化けしてた。
最近、Ubuntuを使う人が増えた気がする。Win１０はいろいろ困ることがあるから。 >>64
それやりたいならresetかstashの方が良くない？ レガシーソフトのexcelががん細胞なんだよな。 メモ帳がutf8bom付き仕様になってるのって。
excelもutf8をサポートしてるけどbom付き前提だからな。
bom付きだとwebあぷり開発に途轍もない支障が出る。 >>65
自分の好きな方法使えよw
俺は一番手っ取り早い方法書いただけだから 良くないってかエラーになる気がする
綺麗な状態以外ではcheckoutした試しがないから分からないけど
少くともオプションないと無理じゃないかって気がする >>69
今試したらエラーは無かったけど何も起きなかったぞ
事前にpushしてクリーンな状態
追加ファイルも消えなきゃ
追記した文字列も戻らない >1
んなこたぁ下々がさわぐ事じゃ無い
与えられた環境で仕事しろ Windowsの人向けにわざわざCRLFで保存するのが面倒だったのがやっと改まるのか そもそもブランチを切り替えるコマンドにリセット機能がデフォで付いてたら世間は阿鼻叫喚だよ
そんなことは試さなくても分かってたことだけどね
エラーも何も起こらないとは予想外だったけど
man見てみたらローカル変更は保持するって書いてあるから規定動作なんだな >>70
それはおかしいねえw
「.」 を付けてないというオチじゃないでしょうね >>74
最後にメモメモしてるくらいだし
そいつが理解できてないんじゃない？
https://i.imgur.com/1Fuz56j.png
すくなくとも俺は実際にコマンド試したんだから君も試してみたら？ スマホの方wifiに入れるの忘れてた
まあ話の流れでわかるよね？ くだらねえ。
死ねよメモ帳と思いながら、他のエディタで開くのが好きなんだよ。 >>34
ジョブズは、
実装していない間はその機能が如何に必要ないクソであるかを罵り、
実装したとたん世界をAppleが変革したとドヤ顔。
そんなジョブズが大好きマカーマカー。みんなも笑ってる るーるるるるー MSももうパソコンはコンシューマー用途としては無くなっていく運命なのがわかってて、
今後は開発機としての寿命が重要になってくるのもわかってるんでしょ。 >>76
https://i.imgur.com/ylf3lLl.png
これでいいかな
viでファイルaaを編集した結果が
git checkout .
で取り消されているのがお分かりいただけるでしょう >>85
なるほどファイルがコミット時点で現存してるときに限り
内容が巻き戻るのか
試してくれてありがとう勉強になった >>87
ニュースだろ。正式発表されたのは昨日今日だし。 >>87
Microsoftがシェアの多さを盾に俺様仕様を貫いてきた糞歴史が大幅に変わろうとしてるんだからそりゃ大ニュースよ
歴史で例えるなら中国が事実上資本主義に移行したり韓国が先軍政治やめたり日本の明治維新なみの話よ >>89
そういえば、今度のMicrosoftのC++は、やっと、標準準拠になるそうだ。 >>91
今更感半端ないねー
c#やphpもそうだけどもはや廃れる言語だよね
さっさと全世代な言語体系捨ててkotlinやswiftみたいにpython風に迎合すれば良いのにね
自分はろくにpython自体は触ったこと無いけどw もうセミコロン打たないとコンパイラが行を認識できない時代は終わったと実感する いやー、pythonの言語仕様って褒められたもんじゃないぞ。
インデント必須の言語だからな。うっかりインデントふっとばすと地獄を見る。
python対応モード装備のIDEやエディタでないと編集はおすすめしない。 >>94
確かに中括弧を使わずインテントで賄うってCOBOLかよって思うもんね
コロン区切りも含めてそこんとこの仕様はkotlinやswiftは毛嫌いしてるからね
良いものは取り入れて糞は捨ててくスタイルは良いと思う
今のところswiftは最適解を導いてるとは思う
偉そうに言ってるけどkotlinは書式は知ってるけど触ったことない
ただSwiftの!や?の仕様は隠蔽しようとして仕切れないポインタの苛立ちを覚える
cのRef落ちやjavaのヌルポは嫌いだけどおんぶに抱っこしてくれるならせめてphpレベルで隠蔽してくれないとね
モバイルを考えるとメモリが潤沢じゃない環境があるのは理解してるけどさ
そこが上から下まで舐め通すIDEやコンパイラの見せ所じゃねっても思う
こればっかは確かに一企業やOSSにお任せってわけにも行かず
ぼくはそういう実行時ExceptionこそMLに食わせたらどうなるかとか思ってたりする
今後の進化に期待だね ネスト多めで可読性の悪いjsはもちろんそのうち廃れるべき存在だと思う
いくらnodeで進化しても結局jsはjsだよね
Chromeを始めwebkitがKotlinを標準対応したら多分早々に消える
というかjavaはappletの頃から触ってるけどやっぱりクソ
世界的には重宝してるけど個人的にはC++のMFCとさして違いがない >>2
彡⌒ ヾ
( ＾ω＾)MSで一番難航した超高度な技術だったんだろ >>1
彡⌒ ヾ
( ＾ω＾)もうWindowsにKDEを乗せろや >>92
ﾊﾟｲｿﾝはちょっとしたものを作るのに優れてるけど、大規模開発に耐えられるかなぁ〜？ >>101
できないことはないけど、基本はグルーだね >>62
BOM付けないと、エンコーディング指定できないメモ帳では何の文字コードで表示すればいいか分からんだろ Excelが、UTF-8のCSVを読み込めないというバカなんだけど。 >>101
そもそも大規模って何作るのさ
いくつかの小さなPythonコードと、
大規模データベースと、HTMLのUI繋げりゃ
大抵の用途はカバーできると思うが >>107
大規模開発やったことないの？
自分はそこまで本格的な小規模開発やったことないけど。 >>2
異なる改行コードが混在してたらどう表示して保存時にどうすればいいのかとか
CRLFじゃなくてLFCRだったら１つの改行にするのか２つの改行にするのかとか
イレギュラーなケースを考え始めると面倒くさくなって
まいっかで放置する気持ちはわかる >>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が行送りだからあってるっちゃあってるんだよ
タイプライターやテレタイプではｗ >>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の有無を問題視してるバカってどう見ても仕事できない役立たずだわなｗ IEってWindowsユーザーにはもう使われていないウェブブラウザでしょうか？ >>184
技術的な反論はできないからとりあえず煽ってみました
ってかww >>186
技術的とかバカかｗ
いまどき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の方が使い道が多い。 >>201
マジレスかよ w
>>15
> Linuxならgrepで1行で探せる。Windowsの標準にそういう機能ないからなぁ。
そんな機能は求められてないぞ w >>201
まあそんなのはコンシューマー用のOSには無くて問題ないもんだわな
開発者が使えればいいんだから >>202
一般のPCユーザーはgrepどころかテキストファイルを扱う機会すらほとんど無いからな >>96
その的外れな批判であなたが現代のjavascriptを知らないと判断できる
深いネストや可読性の悪さは昔の話
javascriptの人気がなぜ今さら上昇しているのかを理解しましょう ブラウザのコトリン対応よりもWebAssemblyの普及の方が現実的だね プログラマなら、grepとか、wcコマンド相当のプログラムくらい、ちゃっちゃと作れると思うのだが？ クローン牛ならぬ、クローン社蓄に過ぎない、BOMなしファイルしか扱えないコピペ房が、
車輪の再発明とかって、自己矛盾を感じないのかねぇ？ >>211
じゃあお前が作れ
からの
「俺プログラマじゃないし」
まででセット？ 正規表現ライブラリを一から作成するとかちゃっちゃとできるわけないだろ コピペプログラマーは、Boostライブラリで正規表現がサポートされていることすら
知らないんだね。 秀丸エディタをメモ帳にしてしまえばいいじゃん
マイクロソフトがちょちょっとお金出せばおわりじゃん >>216
そんなもん使わずに自分で作れって言われてるんだよ 古い人間なので昔のプリンタの動作が頭にあるから、どちらかというとLFだけで改行になるのが違和感あるわ。紙が送られるだけだろ？ 1803にしたら、便利になった。
フォントも感じよくなったし。 >>220
アホかお前ｗ
そんなもの使おうが使うまいが自分で作るとか只のバカだと言ってるんだ >>223
それ、grepやwcを書いたヤツにも言ってやれ。 漫画なんてカネ払って買うより、
漫画村でタダで読めるし、ましてや漫画を自分で描いたりなんてバカだろとかな。 >>224
どうしようもないバカだなお前ｗ
最初に開発した人は偉人でそれを真似るのは凡人で同じものを再発明したがるのがバカって事だ >>225
ワンパターンのバカ呼ばわりで、マウントするいしかない能無し？ 別にコピーを
作る必要はないのだが？ AT互換機だって、いまやオリジナルのPC/ATとはまったく
異なるからな。 まさか、grepとか、wcってファイル名が同じというだけで、全部
同じ実装だとでも思ってるのか？ 改行コードの違いをを理解させるのに良い教材だったのに
いっそのこと標準LFにしてくれ grepみたいな低機能じゃなくて、同時に複数の検索語を指定して、指定フォルダ
下のファイルを検索して、単語毎の出現行や桁位置を、対象ファイル別に、ワーク
シートを分けて、Excel化形式ファイルに出力したいとか思ったら、自分で作るしか
ないし、まぁその程度のプログラムなら、基本機能だけであれば3日もあれば書ける
だろうな。 タダで乞食に使わせる気はないけど。 無能は黙って乞食に徹していればいいのに、意識高い系が故に、草を生やさずには
いられない性分なんですね。わかります。 >>230
なぜUnix系のコマンドが単機能ばかりなのか少しは足りない頭で考えろ間抜け excelとaccessの改行コードの扱いが違うのがまたｗｗｗ
どっちも自社製ソフトなんだから統一しろと思うわｗ
まあoffice自体がレガシーで、データ再利用性の低いゴミを生産してるようなもんだしな。
windowsとofficeが日本のITの生産性を落としてるのは間違いないな。
いつまでこんなレガシーソフトにしがみついているのか。 >>231
>>231
よう単細胞、草を生やすの忘れてますよwwwwwwwwwwwwwww
その単機能のgrepコマンドを組み合わせて、任意の組み合わせの複数単語が指定順に
現る行番号を抽出して、その行中の特定語のみを、置換するといった芸当ができる
のかね？
もっと実用的な例を挙げれば、C言語のソース中の文字列検索や置換で、コメント
中や、文字列リテラル内でのマッチは検索結果や置換対象からはずすとかな。
コメントや文字列は、エスケープ文字で複数行に渡る場合もあるからな。
せいぜいsedとかシェルスクリプトでがんばれや。 車輪の再発明もできない
自称ハッカー君。 >>232
Unixの方がよっぽどレガシーだろ。Linuxとかそれこそ車輪の再発明だしな。
拡張子が違うだけで、新しいOfficeドキュメントは、中身は複数のXMLファイルを
フォルダ圧縮したzipですよ？ >>232
もともとExcelはAppleのMacintosh用が先に出ているから、Macに引きづられて
他のDOS/Windowsソフトと互換性がなくなってる。 >>233
救いようのないバカだな
小学校からやりなおすか適性ゼロだからPC使うの止めろ >>215
ちゃちゃっとやるのは難しくても
たいていのプログラマが一回は作ってるんじゃない？
ちなみに自分は学生時代に夏休みの課題で作らされたが >>237
たいていのプログラマは既存のライブラリを使うんだよ >>237
勉強のために作るのはいいんだよ
ダメなのは既存のソフトウェア資産があるのにそれを活用しないで>>228みたいな自己満足でしかないゴミを作ること ■ このスレッドは過去ログ倉庫に格納されています
