見た目はまったく同じなのに・・・

質問

とあるHPを修正していまして、
修正前と修正後のレイアウトに違いがあり、どこが原因か切り分けしていたところ、
ズレる→<form id="ajaxSearch_form" action="result.html" method="post">
正常　→<form id="ajaxSearch_form" action="result.html" method="post">
の１行に問題があるようでした。
（見た目は完全に同じなのですが）

この1行以外は両ファイルともコピペして同じものにしています。

ズレているファイルに、正常の方の1行を張り付ければ正常になります。
正常のファイルに、ズレる方の1行を貼り付けるとズレてしまいます。

でも、まったく見た目は同じです。

で、２つのファイルの違いを調べるソフトを使って調べたところ

ズレている方のファイルには
&iuml;&raquo;&iquest;&iuml;&raquo;&iquest;&iuml;&raquo;&iquest;&iuml;&raquo;&iquest;（←で表示される特殊文字。i>>？の逆さまのような文字）<form id="ajaxSearch_form" action="result.html" method="post">
と表示されているのです。
スペースも改行もなくして試しても同じ結果でした。

どなたか原因等わかる方、よろしくお願いします。

回答No.5

zxcv0000 · ベストアンサー

> ところで、このような現象はなぜ起きるのでしょうか…？

Unicodeの普及に向けた第一歩を誤ったからでしょうね。

Unicode系の文字コードとしては UTF-8 の他に UTF-16BE、UTF-16LE その他もろもろがあります。 今では UTF-8 が本命ですが、以前は UTF-16BE、UTF-16LE(またはそれに似た UCS2BE と UCS2LE) の ２本立てが本命視されていました。

BOMというのは Byte Order Mark の事で UTF-16BE と UTF-16LE を識別するためのマークです。 今では UTF-8 も識別できますが。

問題は、多くのユーザーやソフト作成者の間で BOM に関する知識が不足している事では無いでしょうか。 今回の問題も、各種の望ましく無い事が重なった結果だと思います。 (いずれかが欠けていたら顕在化しなかった)

1 BOMは、UTF-16 以外の場合には無い方が無難なのに元のテキストファイルに入ってしまった。

2 そのテキストファイルをHTMLに埋め込む処理で、BOMを削除しなかった。 (削除しないのが適切なケースは考え難い)

3 表示がくずれたブラウザは、BOMに関するいろんな条件への対応が不充分なのかも知れない。

最初から UTF-8 1本だったならBOMは誕生せずに問題の原因にもならなかったと思います。 しかし普及してしまったからには、使用上の注意をみんなが知っていなけりゃなりません。

みんなが「BOM無の UTF-8」以外の文字コードを使わなくなれば、解決するでしょう。 (usascii は、「BOM無の UTF-8」のサブセットなので使用可です)

参考URL：

http://www.atmarkit.co.jp/aig/01xml/bom.html

お礼

>問題は、多くのユーザーやソフト作成者の間で BOM に関する知識が不足している事では無いでしょうか。

おっしゃるとおりで、知識不足でした。
問題が起きてから調べるのではなく、疑問をもった時に調べるべきですね。

丁寧な解説ありがとうございました^^

回答No.4

Werner

> ところで、このような現象はなぜ起きるのでしょうか…？
ファイルの先頭に存在するU+FEFFはすなわちBOMですから、
編集に使用したテキストエディタが挿入したのでしょう。

例えばWindowsのメモ帳を使い、
何も文字を入力していない状態で
文字コードにUnicode、Unicode big endian、UTF-8のいずれかを指定して保存すると、
空のテキストファイルであるにもかかわらず
ファイルサイズが2バイトまたは3バイトになります。
（3バイトはUTF-8の場合。）
これはBOMが含まれているためです。

UTF-16はともかく、UTF-8はBOM無しが普通なのでBOMはつけない方が良いでしょう。
BOMをつけてしまうとAscii互換というUTF-8の利点も無くなってしまいます。

なお、たいていのテキストエディタでは保存時にBOMの有無を選択できます。
（メモ帳はできません。この点を含め、メモ帳なんて低機能なエディタを使う利点は無いです。）

お礼

ありがとうございます。

そういうことだったんですね。
あまり意識せずにBOMの有無を選択していました…

基本は大事だってことを再認識しました。

回答No.3

Werner

読み込んでいるファイルのどこかに
Unicodeのコードポイントで示すとU+FEFFとなる文字が存在しているのだと思います。

U+FEFFはZero Width No Break Spaceで、BOMとしても使われます。
この文字は幅がゼロで改行もしない文字なので存在していても表示には全く影響がなく、
ゆえにUnicodeに対応したエディタでは見ることが出来ません。

U+FEFFをUTF-8で符号化すると EF BB BF と言うバイト列になりますが、
これをLatin-1であると解釈すると、
「&#xEF;&#xBB;&#xBF;」、すなわち「&iuml;&raquo;&iquest;」
となります。
やはりUTF-8のU+FEFFが紛れ込んでいるのだと思いますよ。

> 呼び出す元のファイルには&#65279はありません。
どうやって確認しましたか？
Unicodeに対応したエディタで見ているので表示されていないだけではないですか？

> No.2
> Unicodeでの文字の番号と言うのは http://ja.wikipedia.org/wiki/Category:Unicode%E8%A1%A8 のことですが、
> ここにはさすがにBOMは載ってないですね。
たぶん、Zero Width No Break Spaceが載ってるのだと思います。
可読文字ではないので表示はされてないでしょうけど。

お礼

ありがとうございます！

>どうやって確認しましたか？
>Unicodeに対応したエディタで見ているので表示されていないだけでは>ないですか？

HTMLファイルだったのでブラウザでエンコードを変更して確認してましたが、SHIFT-JISを選択しても選択されていない状態でした。
エディタでSHIFT-JISで読み直してみると、呼び出す元のファイルの先頭部分にU+FEFFが紛れ込んでいました。
その他のPHPファイルにも紛れ込んでました。
おかげで、レイアウトの問題も解消しました。^^

本当にありがとうございました。

ところで、このような現象はなぜ起きるのでしょうか…？

回答No.2

zxcv0000

65279 は 16進表現では feff。 BOMですね。  が HTML中に混入した事自体が何かの間違いでしょう。 削除してください。

P.S.
HTML 中の ✏ や &#xffff; の書式は、常にUnicodeでの文字の番号を表します。そのHTMLの文字コードが何であるかは無関係です。

Unicodeでの文字の番号と言うのは http://ja.wikipedia.org/wiki/Category:Unicode%E8%A1%A8 のことですが、ここにはさすがにBOMは載ってないですね。

&iuml;&raquo;.... は、多分、... を UTF-8 に変換した結果をバイトに分解して表現してるんでは無いかと。

 を埋め込むソフトも &iuml;&raquo;... を違いとしてレポートするソフトも、正しい使用法の結果それなら、トホホなソフトですね、きっと。

お礼

ありがとうございます。

確かに消せればそれでOKなんですが、実はPHPで動作するCMSでWEBサイトを作っていまして、UTF-8のHTMLにphpで検索窓を呼び出すと、この現象が起こっています。

呼び出す元のファイルには&#65279はありません。
呼び出す時にそれが挿入され、さらにUTF-8に変換されて&iuml;&raquo;.... となって混入されているということでしょうか？

各ブラウザでShift-jisにて表示するとすべてのブラウザに挿入されて表示しました。
ちなみに、これらの文字は
IEとFireFoxでは、"見えないけれど文字があるものとして解釈"
SafariとOperaは、"全く無いものとして解釈"
ということになるのでしょうか？

回答No.1

MOMON12345


これってUTF8か何かですかね。
文字コードが書かれていないので分からないですが、他の文字がSJISで出来ていてこのコードがあると、ブラウザには表示されませんが（実際にはそこにコードがあるので）位置はずれます。