いかん、ネタが切れてきた。。。
今回は、文字コードと改行コードについて書く。
日本語でソースファイルを書くと、だいたいこの辺を考慮することになるんじゃなかろうか。
- 文字コード
- 改行コード
- タブの方式
改行コードとタブは日本語と関係ないが、まあいいや。
私は、今はこういう書き方をすることが多い。
- 文字コード : UTF-8
- 改行コード : LF
- タブの方式 : スペース4つ
Windowsがメイン環境なので、デフォルトではShift-JISとCR/LFになることが多いのだけど、日本語で出力することが少ないのと、githubなんかに置くとUTF-8じゃないと化けそうだから、UTF-8にしている。
ただ、WindowsだとBOMありのUTF-8にされることもあるので気が抜けない。。。
notepadで、そのまま保存するとShift-JIS、UTF-8で保存するとBOMありになった。
そうなってくると面倒なので、じゃあ改行コードもLFにして、UNIX風というかLinux風というかのソースファイルにしておけば間違いは少なかろう、ということで、そうしている。
これも「ただ」がつくのだが、Windowsでgitを使うと改行コードが変換されることがあり、これはこれで気が抜けない。
Linuxで編集したり、Samba経由でWindows使ったり、gitをLinuxで使ったりWindowsで使ったり、ツールの設定をチームで決めていなかったりしたせいで、けっこうひどい目にあった。。。
チーム開発をするときには、ツールの設定も危険なところについては統一するべきだった、という手痛い教訓だ。
その昔は、あまり気にしていなかった。
日本語はコメントのところしかないから、だいたいうまくいっていたのだ。
が、ある日よくわからないコンパイルエラーが発生した。
どう見てもおかしいところがないのだが、なぜかエラー。
さんざんやって、もうわからん、とコメントを消したら通った。
そこは「//」コメントで「○○機能」と書いているだけだった。
そう、機能の「能」はShift-JISで0x945C。
後半の0x5Cは、文字にすると「\」。
そう、コンパイラがShift-JISを判断してくれず、次の行に継続する扱いにしていたのだ。
もしCコメント形式だったら回避できたのだろうが、//で行末に0x5Cが来たため、そう見なされたのだろう。
当時はまだUTF-8は標準だったから、日本語EUCに変換する習慣を付けたり、ソースファイルを一括置換するツールを探したりと、とにかく回避するよう心がけた。
失敗すると、ノウハウがたまるから、大ごとでなければよいのだよ。
0 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。