2016/09/13

[c/c++]私のC言語(16) - 文字コードと改行コード

いかん、ネタが切れてきた。。。
今回は、文字コードと改行コードについて書く。

 

日本語でソースファイルを書くと、だいたいこの辺を考慮することになるんじゃなかろうか。

  • 文字コード
  • 改行コード
  • タブの方式

改行コードとタブは日本語と関係ないが、まあいいや。

 

私は、今はこういう書き方をすることが多い。

  • 文字コード : 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 件のコメント:

コメントを投稿

コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。