アカウント名:
パスワード:
自分のすべての 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年前には本当に混沌としていましたが、今はマイクロソフトの変換表がメジャーになりつつあるようです。波線とかは積極的にFULLWIDTH FORMに変換するのが特徴で、規格として汚いけど実用的ではあります(マイクロソフトらしいやりかただと思います)。Linux (glibc) においても、マイクロソフト式の変換表が用意され、それに基づくSJISやEUC-JPが使えるようになっています。
ただし、あるShift_JISファイルがあったとして、それをWindowsを使ってUTF-8に変換したのと、Macintoshを使って変換したのと、別のシステムを使って変換したのと、では異なる結果になってしまう(同一性が保てなくなる。diffをとると大変なことになる)という問題がありますが。
BOMについては、どうやって混乱を収束する方向に行っているのか知りません。
どうも、混沌としていますが…
「上位互換」という言葉の使い方がややこしいんだと思います。元コメが言わんとしているのは、上位互換ではなく、「後方互換が維持されている上位互換」ですね。例えば、US-ASCIIの文書は、そのままUTF-8と称して何の問題もなく使えます。一方、Shift-JISで表現されうる文字は全てユニコードに文字が割り振られていますから、Shift-JISの文章は全てUTF-8に変換可能です。そういう意味ではユニコードを表現できるUTF-8はShift-JISの上位互換ですが、Shift-JISの文章をUTF-8でデコードすると、文字化けします。デコード自体には後方互換性がありません。こういうのを「互換」と言っていいのか迷いますが。むしろ上位規格とか、そういう感じかと。
だから、#1711398は何の瑕疵もない主張なんですが、元コメの言葉足らずを考慮すると、どこかで議論の軌道修正が必要だと思います。
人によってはWindows-31JのことをShift-JISって言ってる場合もあるんで余計ややこしかったりして。
#もともとの文字集合が似て非なるものが複数存在する状態なのが不幸の始まりか。 #それにエンコーディングで輪をかける感じ?
「上位互換」とか「互換性」とか言う話をするからややこしいんであって、何が同じで何が違うのか、という話をすればいいのです。
Unicode(あるいはISO/IEC 10646)は、Shift_JISなりEUC-JPなりISO-2022-JPなり(さらにはWindows_31Jなり)を、文字セット(使える文字のレパートリー)としては、包含している。よって、それらのいずれにも存在する文字は、Unicodeへの変換によって、損なわれない。
一方、文字エンコーディングとしては、UTF-8もUTF-16も、Shift_JISなりEUC-JPなり……とは、異なっている。よって、変換が必要である。
そういうことでしょ。
おおむね同意するけど、Wave Dash問題はそれらとは若干次元の異なる話だよな。
最大のシェアを持つWindowsが間違ったコードを割り当ててる所為でみんなが迷惑してる、というだけの話だが。
UnicodeはJIS X 0208-1978(JIS C 6226-1978)とJIS X 0208-1990を区別しないので、ISO-20220-JPをUnicodeに変換すると情報が欠落しますね。
Windowsのcp932-unicodeの変換規則は別に間違ってませんよ?Windows以外のshift_jis-unicodeの変換も間違っているわけではありませんが、あんなものを(shift_jis|cp932)の変換の標準とされてしまったら、実用上、大迷惑だというのはありますが。
> そもそもUTF-8はShiftJISの上位互換では無いですから、上位互換ならそもそも変換の必要はありませんから、上位互換でないのは自明だと思いますが…(でもこのものすごい部門名を見るとそう自明でもないのかな)。> UTF-8自体もBOM有り/無しとありまして、OSによっては片方のみをUTF-8として認識し、元コメントの人は> 自分のすべての HTML ファイルをと言っています。HTMLに限って言えば両方認識できなければならないことは明確ですし実際のブラウザもそうなっています。まあ手もとで作業するとき文字化けすると不便かもしれませんが。本当はHTMLに限
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」と見なす、というルールと混同していませんか? (もっとも、これは後方互換性のためのようですが。)
DB はともかくとして、漢字の誤変換問題は、nkf に --ic=CP932 オプションつければ大体はOKなような。BOM に関しては、後で一括でつけるなり外すなりすればいいような気がするし。
nkf使える人(存在を知っているような人)はShift JISでHTML書かないのでは?
DOS版NKFを使ってたら別におかしいことでもなんでもない。
DOSでHTMLを管理(作成とか)してた人はたしかに希少かもしれないが。(でも私はしてた。思いついたネタをその場でモバイルギアで書いて、あとで通信できる機械にコピーしてアップしてた)
もちろん「使える人」にはPCにMS-DOS版なりMS Windowsコンソール版を入れてる人も想定して書いていますよ?
nkfが必要で(それが何をするモノなのか知っていて)わざわざPCにインストールする人はふつーsjisでHTML置いたりしないでしょ
モバギはsjisかもしれないけど、コピー時やアップロード時にeucjpなりなんなりに変換してなかったんですか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
Shift JIS→UTF-8変換。 (スコア:1)
自分のすべての HTML ファイルを Shift JIS で書いてるんですが、UTF-8 化するには
何をどうすればよい?
以前は Content-Type の Charset を Shift_JIS から UTF-8 に変えただけの“対応”を
したペイジに出くわした事もあるけれど、今どきはさすがにないんでしょうか。
Re:Shift JIS→UTF-8変換。 (スコア:0)
まとめて nkf して、Charset を一括置換……というだけでは足りないのでしょうか?
Re:Shift JIS→UTF-8変換。 (スコア:3, 参考になる)
いやいやいや全然全く足りませんよ
そもそもUTF-8はShiftJISの上位互換では無いですから、単純にnkfすれば良いという訳ではないです
ましてやUTF-8自体もBOM有り/無しとありまして、OSによっては片方のみをUTF-8として認識し、もう片方は認識出来ずに文字化けの嵐なんて事もありますし
私も昨年、PostgreSQLのDBをEUC_JPからUTF-8に変換しようとして難儀しましたよ
有名なバックスラッシュとなみ線問題から、一部の漢字の誤変換問題
更にはそれらをシコシコと手作業で直していたのですが、端末上ではVim、Windowsでは秀丸を使っていましたら、改行はLFで統一されていたものの、何故かBOMが混在した状態になってしまっていたりして・・・・・本当に疲れた
Re:Shift JIS→UTF-8変換。 (スコア:2, 参考になる)
上位互換ですよ。
Unicode/ISO10646は、従来の主要な文字コードに対して上位互換になるように設計されています。
(ただし、ISO-2022-JPに対しては上位互換になっていますが、ISO-2022に対しては上位互換に
なっていません。たとえばCJK統合漢字における「骨」のグリフをどうするかといった問題)。
波線とかバックスラッシュとかの問題は、従来の文字コードとUTF-8との変換表が整備されていないのが原因。
最初に「これが標準」と決めてしまえばよかったのでしょうが、実際にはそうならず、そのせいで
10年前には本当に混沌としていましたが、今はマイクロソフトの変換表がメジャーになりつつある
ようです。波線とかは積極的にFULLWIDTH FORMに変換するのが特徴で、規格として汚いけど
実用的ではあります(マイクロソフトらしいやりかただと思います)。Linux (glibc) においても、
マイクロソフト式の変換表が用意され、それに基づくSJISやEUC-JPが使えるようになっています。
ただし、あるShift_JISファイルがあったとして、それをWindowsを使ってUTF-8に変換したのと、
Macintoshを使って変換したのと、別のシステムを使って変換したのと、では異なる結果になってしまう
(同一性が保てなくなる。diffをとると大変なことになる)という問題がありますが。
BOMについては、どうやって混乱を収束する方向に行っているのか知りません。
Re:Shift JIS→UTF-8変換。 (スコア: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って言ってる場合もあるんで余計ややこしかったりして。
#もともとの文字集合が似て非なるものが複数存在する状態なのが不幸の始まりか。
#それにエンコーディングで輪をかける感じ?
Re:Shift JIS→UTF-8変換。 (スコア:2, 参考になる)
「上位互換」とか「互換性」とか言う話をするからややこしいんであって、何が同じで何が違うのか、という話をすればいいのです。
Unicode(あるいはISO/IEC 10646)は、Shift_JISなりEUC-JPなりISO-2022-JPなり(さらにはWindows_31Jなり)を、文字セット(使える文字のレパートリー)としては、包含している。よって、それらのいずれにも存在する文字は、Unicodeへの変換によって、損なわれない。
一方、文字エンコーディングとしては、UTF-8もUTF-16も、Shift_JISなりEUC-JPなり……とは、異なっている。よって、変換が必要である。
そういうことでしょ。
Re: (スコア:0)
おおむね同意するけど、Wave Dash問題はそれらとは若干次元の異なる話だよな。
最大のシェアを持つWindowsが間違ったコードを割り当ててる所為でみんなが迷惑してる、というだけの話だが。
Re: (スコア:0)
UnicodeはJIS X 0208-1978(JIS C 6226-1978)とJIS X 0208-1990を区別しないので、ISO-20220-JPをUnicodeに変換すると情報が欠落しますね。
Re: (スコア:0)
Windowsのcp932-unicodeの変換規則は別に間違ってませんよ?
Windows以外のshift_jis-unicodeの変換も間違っているわけではありませんが、
あんなものを(shift_jis|cp932)の変換の標準とされてしまったら、
実用上、大迷惑だというのはありますが。
Re: (スコア:0)
> そもそもUTF-8はShiftJISの上位互換では無いですから、
上位互換ならそもそも変換の必要はありませんから、上位互換でないのは自明だと思いますが…(でもこのものすごい部門名を見るとそう自明でもないのかな)。
> UTF-8自体もBOM有り/無しとありまして、OSによっては片方のみをUTF-8として認識し、
元コメントの人は
> 自分のすべての HTML ファイルを
と言っています。HTMLに限って言えば両方認識できなければならないことは明確ですし実際のブラウザもそうなっています。まあ手もとで作業するとき文字化けすると不便かもしれませんが。本当はHTMLに限
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
Re: (スコア:0)
DB はともかくとして、漢字の誤変換問題は、nkf に --ic=CP932 オプションつければ大体はOKなような。
BOM に関しては、後で一括でつけるなり外すなりすればいいような気がするし。
Re:Shift JIS→UTF-8変換。 (スコア:1)
nkf使える人(存在を知っているような人)はShift JISでHTML書かないのでは?
#またここに自分用のメモを書いてしまった。。。
Re: (スコア:0)
DOS版NKFを使ってたら別におかしいことでもなんでもない。
DOSでHTMLを管理(作成とか)してた人はたしかに希少かもしれないが。
(でも私はしてた。思いついたネタをその場でモバイルギアで書いて、あとで通信できる機械にコピーしてアップしてた)
Re:Shift JIS→UTF-8変換。 (スコア:1)
もちろん「使える人」にはPCにMS-DOS版なりMS Windowsコンソール版を入れてる人も
想定して書いていますよ?
nkfが必要で(それが何をするモノなのか知っていて)わざわざPCにインストールする人は
ふつーsjisでHTML置いたりしないでしょ
モバギはsjisかもしれないけど、コピー時やアップロード時にeucjpなりなんなりに
変換してなかったんですか?
#またここに自分用のメモを書いてしまった。。。