プロが教える店舗&オフィスのセキュリティ対策術

お世話になります。
UNIXの "nl" コマンド相当の機能が必要になり、Cでプログラム作成中です。
「動作を停止しました」となるファイルがあるので検証するに、ASCII文字が2バイトで表されるコード体系があることを知りました(汗)。
1行の終端を示す CR+LF が 0x0D 0x0A だけかと思いきや 0x0D 0x00 0x0A 0x00 もあるのですね。
フリーソフトの TeraPad で 「文字コード指定保存」 を行って、ASCIIと漢字雑じり .txt を16進ダンプして下記を得ました。
これで宜しいですか? また UTF-8 の不明点について教えてください。

● ASCIIが2バイトとなるのは Unicode のみ。SHIFT-JIS、JIS、EUC、UTF-8、UTF-8N は1バイト。
● Unicode ファイルの冒頭2文字は 0xFF 0xFE である。これはリトルエンディアンを示すBOMである。
● UTF-8 ファイルの冒頭3文字は 0xEF 0xBB 0xBF である。これは何を意味するのでしょうか?

質問者からの補足コメント

  • HAPPY

    テキストの表現法には難しい問題があるようなのは脇に置かせていただいて・・・
    小生の知りたいこと全てに答えてくださってますので、ベストアンサーとしました。

    No.5の回答に寄せられた補足コメントです。 補足日時:2016/04/15 21:08
gooドクター

A 回答 (7件)

> ASCIIが2バイトとなるのは Unicode のみ。


実用上その理解で問題ありません。
(細かいことを言うとUnicodeではなくUTF-16です。UnicodeとUCSは一応別です。他にマイナーなものが無いとは言い切れません。)

> Unicode ファイルの冒頭2文字は~
リトルエンディアンのUTF-16ファイルならそうです。
WindowsではリトルエンディアンのUTF-16を「Unicode」、ビッグエンディアンのUTF-16を「Unicode big endian」と呼ぶことがあるので紛らわしいです。

> UTF-8 ファイルの冒頭3文字は~
BOMです。Zero Width No-Break Spaceではありません。
英語版Wikipediaにまとまっていました。
https://en.wikipedia.org/wiki/Byte_order_mark
UTF-8について、「BOMの仕様は必須でなく推奨もしないが、他のBOM付きのエンコーディングから変換した場合やBOMをUTF-8のシグネチャとして使用している場合に現れうる」とされています。
ですのでBOM付きのUTF-8が読めない(先頭のU+FEFFをZero Width No-Break Spaceと扱う)ソフトは規格違反です。
BOMなしのUTF-8が読めないソフトは文字コードの自動判別に失敗しているだけなので不便ですが特に規格に反してはいません。
この回答への補足あり
    • good
    • 0

> いえ、そんな単純な話ではないんです。


はい、そうですね。
実情に合わない規格が作られることや、規格違反のソフトが主流になることはよくあることです。
規格に触れずに話が進んでいるのが問題だと思ったので規格について述べたまでですが、規格が絶対だと取れるような書き方はまずかったかもしれません。
    • good
    • 0

>ですのでBOM付きのUTF-8が読めない


>(先頭のU+FEFFをZero Width No-Break Spaceと扱う)ソフトは
>規格違反です。

いえ、そんな単純な話ではないんです。

元々アスキーとの互換性を利点に始まったUTF-8は
多くの英語用アプリが無改造で使えることが「売り」
だったんですが、BOMがそれを吹き飛ばしてしまいました。
シェルとかphpを使っている人は身の回りからいかにBOM付
UTF-8を排除するかに腐心されていると思います。

XMLも、UTF-8はBOM無ししか読めないパーサーが多く
BOM有のXMLはトラブルの元です。
JavaでふつうにXMLアプリを作るとBOMはサポートされません。
Javaではテキストを読む際、UTF-8のBOMをシグニチャとして
認識する提案が何度も有ったようですが、未だ
実装される気配は有りません。多くの開発言語でも同様です。

というわけでBOM有UTF-8の使用は非常にリスキーです。
    • good
    • 0

ちょっと誤解してるようなので指摘しておくと, 「Unicode」自体は「文字に対して数値を割り当てる方法」でしかありません. その数値をどのように表すかは別の話で, UTF-8 も「Unicode」の一種です (ほかにも UTF-16, UTF-32 などがある).



ちなみに UTF-8 の 0xEF 0xBB 0xBF, つまり Unicode の u+FEFF は Zero-Width No-Break Space (ZWNBSP) を表します. だから UTF-8 の先頭に「BOM」を付けること自体を「おかしい」とするのはちょっと言い過ぎな気もします... というか, 本来の ZWNBSP として扱えばいいだけなんだよなぁ.
    • good
    • 0

>1行の終端を示す CR+LF が 0x0D 0x0A だけかと思いきや


>0x0D 0x00 0x0A 0x00 もあるのですね。

おそらく UTF-16LE ですね。

ちなみに、UTF-16 は1文字を2バイト又は4バイトで表す
符号化形式です。所謂サロゲートペアをサポートしているので
UCS-4の一部の文字も含まれていて、100万文字まで表現できます。

1文字=2バイトではなくて可変長なのでご注意を。
    • good
    • 0

Unicode(UTF-16)は厳密には ASCII互換ではありません。


Unicodeの16bitをそのまま2バイト(16bit)で表現するのが UTF-16です。
漢字等の他のコードで複数バイトで表現されるような文字も 16bitの「一文字」で表現します。


現在、16bitを、8bit単位で処理するファイルに読み書きする場合に、2通りの方法が主に使われます。
・ビッグエンディアン: 上位8bit 下位8bit の順に並べる
・リトルエンディアン: 下位8bit 上位8bit の順に並べる

例えば
0x0D 0x00
という2バイトは
ビッグエンディアンなら 0x0D00
リトルエンディアンなら 0x000D
となります。


UTF-16の場合、ビッグ/リトルどちらを使え、とは決まっていません。
順番を間違えると文字化けしてしまいます。
そこで、どちらを使ったかを表わすコードを先頭に入れる、という約束を用意しました。
それが ビットオーダーマーク BOM と呼ばれるもので、 0xFF 0xFE はリトルエンディアンを示すBOM となります。


UTF-8は、Unicodeの16bitを一定の法則で8bitの文字が1文字以上になるように変換したものです。
逆に8bit複数文字から16bitに戻す計算式も決まっています。
そのため、UTF-16のBOMのような仕組は、本来は必要ありません。

ですが、何を勘違いしたのか、 UnicodeにはBOM が必須とでも考えたのか、 「BOMをUTF-8のルールに従って変換した文字列」を先頭に付けたものが出てきました。
これが 0xEF 0xBB 0xBF です。


エディタ等では、BOMの有無両方扱わなければならなくなりました。
ただ、本来のものでは無いので、呼び方にバラツキがあります。
・有) UTF-8(BOM付き) / 無) UTF-8
 BOMが付いてる方が「特殊」なので、無い方をUTF-8とする
・有) UTF-8 / 無) UTF-8N
 Windowsの主なソフトがBOM付きでないとUTF-8として扱ってくれない、等から、 BOM無しを「特殊」として別の名前を付ける
    • good
    • 0

>1行の終端を示す CR+LF が 0x0D 0x0A だけかと思いきや 0x0D 0x00 0x0A 0x00 もあるのですね。



Unicode(UTF-16)では?
BOMなしで保存される場合もあるようですので注意が必要かとは思いますが。

>● UTF-8 ファイルの冒頭3文字は 0xEF 0xBB 0xBF である。これは何を意味するのでしょうか?
BOMかと。
https://ja.wikipedia.org/wiki/%E3%83%90%E3%82%A4 …
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

gooドクター

人気Q&Aランキング