« デジカメ写真の数え方 | トップページ | ゴーオンジャー:GP38 乙女ノホンキ »

2008年11月 8日 (土)

UTF-8とUTF-8N

今日は天気も悪く、特に出かける用事もなかったので、部屋に引きこもり(笑)。
せっかくなので、かねてから思っていたツール作成をすることに。

自宅のサーバー(FreeBSD)で使うファイル解析のツールなのですが、バイナリデータを扱うので「C」で書くことに。サーバーのロケールを「UTF-8」にしているので、ソースファイルの文字コードを「UTF-8」にして保存(編集はWindowsでやってたので)。サーバーにアップしてコンパイル。
コンパイルエラー(||li ̄▽ ̄li)
「ま、そんなもんさ」と笑いながらエラーを取るが、なかなか取れない。というか、1行目でエラー。それも、ヘッダファイルとソースファイルの両方とも。まてまて、ヘッダファイルの1行目はコメント行だし、ソースファイルだってお決まりの「#include <stdio.h>」なのだが…。よくよくエラーメッセージを見ると、見慣れないエラーメッセージ(下記3行。ファイル名は割愛w)。
error: stray ‘\357’ in program
error: stray ‘\273’ in program
error: stray ‘\277’ in program

早速、ググる。で、ファイルの文字コードに起因するエラーだということが判明。さらにそこからリンクが張られていた四元輝博さんのブログ「シリコンバレー24時」の記事(http://www.skymerica.com/blog/yotsumoto/arch/2007/05/08/000765.html )を辿り、ファイルの文字コードを「UTF-8」ではなく、「UTF-8N」で保存すればよいという解決策を見て、その通りに保存、再びコンパイルを通すと、無事完了。とりあえず、ツールはファイルフォーマットの調査で今日は終了として、ついでに四元さんのブログからUTF-8についての調査記録を読んだ。
ウィキペディアにも書かれているのだが、「UTF-8」には「UTF-8」と「UTF-8N」の2つが存在し、「BOM」が付くものを「UTF-8」、付かないものを「UTF-8N」としているそうである。ただし、これは日本国内のみであり、国際的には認知されていない仕様だそう。つまり「方言」ですな。しかも、この「BOM」の有無でアプリケーションの挙動にも変化があるそうです。

いやぁ、仕事だけでプログラム書いてたら、お目にかかれなかったんだろうな(笑)。

|

« デジカメ写真の数え方 | トップページ | ゴーオンジャー:GP38 乙女ノホンキ »

パソコン・インターネット」カテゴリの記事

コメント

よく、この古い記事にたどり着きましたね(笑)。

UTF-8のこの仕様には泣かされますね。Windowsとそれ以外(OS的にはUnix環境、ソフト的にはオープンソフト)とで扱いが分かれるんですよね。
ちなみに、純粋にWindowsだけで動かす(作る)もので、UTF-8を使うのなら(って、今はほとんどこうだろうけど)「BOM付き」、Windows以外でも動かすなら「BOM無し」と覚えていれば、ほぼ間違いないです。
例え、Windows上で動かすにしてもPythonやRubyといったオープンソース開発の言語(やツール)に使う場合はBOM無しでないと引っかかることが多いです。

投稿: あ~かいば | 2016年8月 2日 (火) 21時52分

ほ,仏さまッ(笑)
Hello, world!の段階でとん挫してもうCはあきらめようと思ってました.
文字コードの些細な違いになんて気づきもしませんでしたわ...
本当に助かりました

投稿: Bの補集合 | 2016年8月 2日 (火) 16時30分

コメントを書く



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


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/126287/43052895

この記事へのトラックバック一覧です: UTF-8とUTF-8N:

« デジカメ写真の数え方 | トップページ | ゴーオンジャー:GP38 乙女ノホンキ »