« iPhone4Sを8.2に! | トップページ | 定期点検(RN1) »

2015年3月13日 (金)

UTF-8Nって何だ?

最近会社で(Windows)でgccのcompileでLinkerがこんなwarningを出しているのに気が付いた。

・・・・・1: ignorring invalid character `\357'
・・・・・1: ignorring invalid character `\273'
・・・・・1: ignorring invalid character `\277'

はて? 1行目はコメント行なんだけど。 何言ってるんだろう?    エディタ(Win.ではTeraPad使用)で開けてみても原因がさっぱりわからない。  なんだろう?  と気になってはいたのだが放置していた。(←おぃ!)

ところがdiffでソースの差分を見ていて「あっ!?」と見つけてしまったのだ。

Df

Fileの先頭に3byte、変なコードが入ってるじゃないの。
ははぁ、そうか。 Win.ではunicode=UTF16LEでの保存時には先頭にBOMという識別コードが付くんだった。 UTF-8にもBOM付けてるってこと?(そんなバカな!)

どうやらTeraPadの保存時の文字コード指定に「UTF-8」と「UTF-8N」があるのに気がついたのだが、
UTF-8→3byteのBOM付きUTF-8、
UTF-8N→BOMなしの純然たる「UTF-8」 、、ということがわかった。

つまり、BOMなしの「UTF-8N」で保存すれば先のwarningは出なくなるのだ。(正式な文字エンコーディング名にUTF-8Nなどというものは本来ありません)

まとめよう。
Windowsはunicodeと言ったらUTF16LEのことを指し、これはLEかBEかを判別するのにBOMを付けるのが通例らしい。 その流れのせいか? UTF-8にもBOMを付けるようで、BOMなしの純然たるUTF-8のTEXTを作る場合には、TeraPadならUTF-8Nを意識して選ばないといけない。

私は家ではMacを使っている。System内のxmlやTEXTは普通に純然たる「UTF-8」だ。  htmlやCやperlもUTF-8で書いている。 最近のLinuxもUTF-8が普通。  これらはBOMなしが普通なのだ。

世の中、WindowsだけがBOM付きUTF16LEを使い、さらにはエンディアンに関係ないUTF-8にまでBOMを付けるというヘンテコ仕様なのか。 まぁ、、一応理由らしきものを推測してみると。。

現在でも日本語にShift-JISをSystemFontに使うWin.は、BOMなしのUTF-8は英数字TEXT部分が全く同じなために、Shift-JISとUTF-8を判別するのが困難なのだ。 だからUTF-8にもBOM付けた、と。 BOMがなければ今まで通り、US-ASCllか、ShiftJISなわけだ。

unicode(UTF16LE)をいち早く採用したWindowsNTだが、95APIと統合した副作用で後方互換性の問題からShift-JISの呪縛から逃れられなくなった。 その後、UTF-8が主流になり、さらにはBOMを付けたヘンテコなUTF-8を作ってしまったせいでさらに自分の首を絞めている。 MacやLinuxはあっさりUTF-8ベースに移行完了してるのにね。(iOSやAndroidは言わずもがな。)

どうするんだろうね? (^^; 知ーらない。(笑)

Mactxt

Macのエディタ(これはmi)には「UTF-8N」などという指定はない。UTF16と指定したらそれはBigEndian(=UTF16BE)であり、BOMなし。 仮にUTF16LEを指定してもBOMは含まない。

|

« iPhone4Sを8.2に! | トップページ | 定期点検(RN1) »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: UTF-8Nって何だ?:

« iPhone4Sを8.2に! | トップページ | 定期点検(RN1) »