アカウント名:
パスワード:
自分のすべての 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が混在した状態になってしまっていたりして・・・・・本当に疲れた
上位互換ですよ。Unicode/ISO10646は、従来の主要な文字コードに対して上位互換になるように設計されています。（ただし、ISO-2022-JPに対しては上位互換になっていますが、ISO-2022に対しては上位互換になっていません。たとえばCJK統合漢字における「骨」のグリフをどうするかといった問題）。
波線とかバックスラッシュとかの問題は、従来の文字コードとUTF-8との変換表が整備されていないのが原因。最初に「これが標準」と決めてしまえばよかったのでしょうが、実際にはそうならず、そのせいで10年前には本当に混沌としていましたが、今はマイクロソフトの変換表がメジャー
どうも、混沌としていますが…
「上位互換」という言葉の使い方がややこしいんだと思います。元コメが言わんとしているのは、上位互換ではなく、「後方互換が維持されている上位互換」ですね。例えば、US-ASCIIの文書は、そのままUTF-8と称して何の問題もなく使えます。一方、Shift-JISで表現されうる文字は全てユニコードに文字が割り振られていますから、Shift-JISの文章は全てUTF-8に変換可能です。そういう意味ではユニコードを表現できるUTF-8はShift-JISの上位互換ですが、Shift-JISの文章をUTF-8でデコードすると、文字化けします。デコード自体には後方互換性がありません。こういうのを「互換」と言っていいのか迷いますが。むしろ上位規格とか、そういう感じかと。
だから、#1711398は何の瑕疵もない主張なんですが、元コメの言葉足らずを考慮すると、どこかで議論の軌道修正が必要だと思います。
人によってはWindows-31JのことをShift-JISって言ってる場合もあるんで余計ややこしかったりして。
＃もともとの文字集合が似て非なるものが複数存在する状態なのが不幸の始まりか。 ＃それにエンコーディングで輪をかける感じ？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
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: (スコア:2, 参考になる)
上位互換ですよ。
Unicode/ISO10646は、従来の主要な文字コードに対して上位互換になるように設計されています。
（ただし、ISO-2022-JPに対しては上位互換になっていますが、ISO-2022に対しては上位互換に
なっていません。たとえばCJK統合漢字における「骨」のグリフをどうするかといった問題）。
波線とかバックスラッシュとかの問題は、従来の文字コードとUTF-8との変換表が整備されていないのが原因。
最初に「これが標準」と決めてしまえばよかったのでしょうが、実際にはそうならず、そのせいで
10年前には本当に混沌としていましたが、今はマイクロソフトの変換表がメジャー
Re: (スコア:1, 参考になる)
どうも、混沌としていますが…
「上位互換」という言葉の使い方がややこしいんだと思います。元コメが言わんとしているのは、上位互換ではなく、「後方互換が維持されている上位互換」ですね。例えば、US-ASCIIの文書は、そのままUTF-8と称して何の問題もなく使えます。一方、Shift-JISで表現されうる文字は全てユニコードに文字が割り振られていますから、Shift-JISの文章は全てUTF-8に変換可能です。そういう意味ではユニコードを表現できるUTF-8はShift-JISの上位互換ですが、Shift-JISの文章をUTF-8でデコードすると、文字化けします。デコード自体には後方互換性がありません。こういうのを「互換」と言っていいのか迷いますが。むしろ上位規格とか、そういう感じかと。
だから、#1711398は何の瑕疵もない主張なんですが、元コメの言葉足らずを考慮すると、どこかで議論の軌道修正が必要だと思います。
Re:Shift JIS→UTF-8変換。 (スコア:2)
人によってはWindows-31JのことをShift-JISって言ってる場合もあるんで余計ややこしかったりして。
＃もともとの文字集合が似て非なるものが複数存在する状態なのが不幸の始まりか。
＃それにエンコーディングで輪をかける感じ？