アカウント名:
パスワード:
自分のすべての HTML ファイルを Shift JIS で書いてるんですが、UTF-8 化するには何をどうすればよい?
以前は Content-Type の Charset を Shift_JIS から UTF-8 に変えただけの“対応”をしたペイジに出くわした事もあるけれど、今どきはさすがにないんでしょうか。
まとめて nkf して、Charset を一括置換……というだけでは足りないのでしょうか?
いやいやいや全然全く足りませんよ そもそもUTF-8はShiftJISの上位互換では無いですから、単純にnkfすれば良いという訳ではないです ましてやUTF-8自体もBOM有り/無しとありまして、OSによっては片方のみをUTF-8として認識し、もう片方は認識出来ずに文字化けの嵐なんて事もありますし 私も昨年、PostgreSQLのDBをEUC_JPからUTF-8に変換しようとして難儀しましたよ 有名なバックスラッシュとなみ線問題から、一部の漢字の誤変換問題 更にはそれらをシコシコと手作業で直していたのですが、端末上ではVim、Windowsでは秀丸を使っていましたら、改行はLFで統一されていたものの、何故かBOMが混在した状態になってしまっていたりして・・・・・本当に疲れた
BOM付きUTF-8なんてローカルルールで標準ではないんですよ。
→ 付ける必要は無いが、付けた場合でも規格の範囲内。
ISO-2022-JPで半角カナを拡張して使ってるようなもんです。
→ 規格外。
では? もっとも、HTTPはエンコードを指定できるプロトコルなので、BOMを禁止するべきである (RFC 3629) という話はありますが。
RFCもISOの規格票もTUSも読まないでBOM付きのUTF-8はローカルルールだとか勝手に思い込んでる人がこんなに多いんじゃ、面倒でも毎回毎回言及するたびに引用するしかないですね…。
Unicode Consortiumは「UTF-8 can contain a BOM」と言ってます。 (cf. Unicode FAQ [unicode.org]) もっとも、UTF-8の並びはエンディアンネスは関係無いので「BOM」の役割ではなく、シグネチャ的な用途にとどまりますが。
…もしかして「(Unicodeの規格ではなく) 一部のローカルルールでは標準的ではない」という意図でしょうか? 場所によってはそのようなローカルルールがあることは否定しません。 たとえば文字コードをUTF-8に決め打ちする場合、BOMを付けないルールは有用でConsortiumのガイドラインにも適っていると思います。
付けた場合はBOMではなく幅のないスペースです。
途中に現れた場合に「ZERO WIDTH NON-BREAKING SPACE」と見なす、というルールと混同していませんか? (もっとも、これは後方互換性のためのようですが。)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
Shift JIS→UTF-8変換。 (スコア:1)
自分のすべての HTML ファイルを Shift JIS で書いてるんですが、UTF-8 化するには
何をどうすればよい?
以前は Content-Type の Charset を Shift_JIS から UTF-8 に変えただけの“対応”を
したペイジに出くわした事もあるけれど、今どきはさすがにないんでしょうか。
Re: (スコア:0)
まとめて nkf して、Charset を一括置換……というだけでは足りないのでしょうか?
Re: (スコア:3, 参考になる)
いやいやいや全然全く足りませんよ
そもそもUTF-8はShiftJISの上位互換では無いですから、単純にnkfすれば良いという訳ではないです
ましてやUTF-8自体もBOM有り/無しとありまして、OSによっては片方のみをUTF-8として認識し、もう片方は認識出来ずに文字化けの嵐なんて事もありますし
私も昨年、PostgreSQLのDBをEUC_JPからUTF-8に変換しようとして難儀しましたよ
有名なバックスラッシュとなみ線問題から、一部の漢字の誤変換問題
更にはそれらをシコシコと手作業で直していたのですが、端末上ではVim、Windowsでは秀丸を使っていましたら、改行はLFで統一されていたものの、何故かBOMが混在した状態になってしまっていたりして・・・・・本当に疲れた
Re: (スコア:0)
ISO-2022-JPで半角カナを拡張して使ってるようなもんです。
Re:Shift JIS→UTF-8変換。 (スコア:2)
→ 付ける必要は無いが、付けた場合でも規格の範囲内。
→ 規格外。
では? もっとも、HTTPはエンコードを指定できるプロトコルなので、BOMを禁止するべきである (RFC 3629) という話はありますが。
HIRATA Yasuyuki
Re: (スコア:0)
RFCもISOの規格票もTUSも読まないでBOM付きのUTF-8はローカルルールだとか勝手に思い込んでる人がこんなに多いんじゃ、面倒でも毎回毎回言及するたびに引用するしかないですね…。
Re: (スコア:0)
Re: (スコア:0)
→ 付ける必要は無いが、付けた場合でも規格の範囲内。
付けた場合はBOMではなく幅のないスペースです。
Re:Shift JIS→UTF-8変換。 (スコア:2)
Unicode Consortiumは「UTF-8 can contain a BOM」と言ってます。 (cf. Unicode FAQ [unicode.org]) もっとも、UTF-8の並びはエンディアンネスは関係無いので「BOM」の役割ではなく、シグネチャ的な用途にとどまりますが。
…もしかして「(Unicodeの規格ではなく) 一部のローカルルールでは標準的ではない」という意図でしょうか? 場所によってはそのようなローカルルールがあることは否定しません。 たとえば文字コードをUTF-8に決め打ちする場合、BOMを付けないルールは有用でConsortiumのガイドラインにも適っていると思います。
途中に現れた場合に「ZERO WIDTH NON-BREAKING SPACE」と見なす、というルールと混同していませんか? (もっとも、これは後方互換性のためのようですが。)
HIRATA Yasuyuki