アカウント名:
パスワード:
自分のすべての HTML ファイルを Shift JIS で書いてるんですが、UTF-8 化するには何をどうすればよい?
以前は Content-Type の Charset を Shift_JIS から UTF-8 に変えただけの“対応”をしたペイジに出くわした事もあるけれど、今どきはさすがにないんでしょうか。
ファイルそのものの文字コードとContent-Typeを変えれば十分なのでは?UTF-8が「必要」と考えるならばその他の理由もあるでしょうから、その理由に対する変換をしてあげればいいだけで。「阿吽」を「阿呍」にするとか?# 別にShift_JISのファイルだってそのように表示はできるんだけどさ
ちなみに私もほぼ全てShift_JISで書いていますが、当分変えるつもりはありません。
Shift_JISのまま: メリット: 過去のブラウザでも読める デメリット: 別にないUTF-8: メリット: 別にない デメリット: 過去のブラウザで読めない
私にとってはこんな感じなので。過去のブラウザを気にしても意味のないシーンでは、Shift_JIS or UTF-8で扱いやすい方を扱ってます。
> UTF-8:> メリット: 別にない> デメリット: 過去のブラウザで読めないデメリット追加: ファイルサイズが150%ぐらい増加する。
ああ、そうか。そうですよね、それは結構問題。普段は全く気にならないんですが、遅い/品質の低い回線を使わざるを得ないときに実感する...。
極端にやる必要はありませんが、できれば、ファイルサイズは小さくしておきたいですもんね。# 未だにたまに、改行やインデントを見直してちょこっとダイエットしている私
すごくどうでもいいツッコミですが、増加するのは50%ですね。2バイト→3バイトですから。
さらに補足します.
UTF-8 では ASCII の範囲内は 1 バイトで表現できますから, HTMLファイルなら,よほど本文が長いものでない限り,50%も増えません.
極端な例では, slashdot.jp のトップページでは,8%の違いでした (UTF-8 の場合 79423 Byte,Shift_JIS (CP932) の場合 73499 Byte)個人サイトなどでスクリプトや広告が無い場合でも,ちゃんと必要なタグを書いてあるならば,大抵は 30% 以下の増加でしょう.
また,最近では HTML ファイルは圧縮転送される事が多いですが,圧縮した場合にはこの差はさらに縮みます.(大抵の場合は)
> また,最近では HTML ファイルは圧縮転送される事が多いですが,圧縮した場合にはこの差はさらに縮みます.(大抵の場合は)
理想的な圧縮状況であれば圧縮した結果はその文書が持つ情報量に依存するので、元の文字コードが何であれ、同じサイズになるはずですね。
「過去のブラウザ」ってNetscape 3とかIE 3くらいまでさかのぼりますよ? そんな非現実的な状況設定を持ち出すより「ガラケーで読めない」のほうがよほど説得力があるでしょう。困ったことに。> Shift_JISのまま:> デメリット: 別にないで、そこまで古いブラウザを気にしてるなら、「x-sjisと書かないとNetscapeの一部バージョンで文字化けしちゃうよ問題」も当然気にしてるんですよね。なんでISO-2022-JPで書かないんですか? あ、ISO-2022-JPだとOperaの5以前で文字化けしますね。
何をそんなに必死なのか...。あくまで「私にとって」ですよ?単純なテキストばかりのページで、不都合がなかった古いブラウザを突然あえて切り捨てる理由が、私には思いつきません。# 古いブラウザを使い続けるべきかは、別の問題ですよ
私が過去との互換性をある程度大事にしているページでは、過去にNetscape/IE 3.xはもちろん、NCSA Mozaic 2.1.1, Netscape 2.02, Opera 3.1, Cello 1.01a等での表示状況を確認した状態を引き継いでいます。今も表示できることを確認する価値があるとは思っていませんが、故意に切り捨てる必要はないと思っています。あなたの言うガラケー(日本の携帯のことをこう言うんですね)にも対応すべく、未だにHDML(だっけ?)とH" LINK対応の日記ページは残してあったりもしますよ。それぐらいの配慮をした上で、Shift_JISをそのままにしています。
ま、ベストエフォートでいろんな人に見てもらいたいなってのを形にしているだけです。
That's Insightful:+1!However, 'いろんな人' could mean various -Japanese speaker-, depends on the context, heh
アグネスが嫌いな僕としては、むしろペットボトルのキャップを集めいたいところですな。もう少しわかってあげてください。
文字コードを変えたからって、やり方って変わるかな?そこまで低レベルなページの書き方をしていない(ファイルの操作はエディタ頼み)なので、保存時のエンコードを変えるだけだと思うのですが...。
実際、同じエディタで編集しているファイルでも、表示環境にそう心配のないファイル、PerlスクリプトなんかはとっととUTF-8に移行しました。もっとも、こちらはUTF-8にするメリットが大きかったのですが。
MultiTextConverter [rk-k.com]とか。ヘッダも自動で書き換えてくれます。Windows版へのリンクは下の方に。
#先日、本文UTF-8でcharsetがShift_JISのままなページを見かけた。
#1711367です。
ちょっと確認してみたんですが、<head>〜</head>が元々ない場合はcharsetのメタ情報を埋め込んでくれないようです。
扱う側で問題が出るかも?SJISだと読めてたけどUTF-8の自動判定に失敗して文字化けするとか。
ーーーいままではcharsetなしのSJIS(UTF-8以外?)なHTMLはSpotlightのインデックスが作成されなかったのですが、UTF-8ならcharsetの有無に関係なくインデックスが作成されるようになりました。(何かヒットしねえなと思ってたらこれかぁ)
headが無いって時点で元の問題が大きい様な気がする。そうなると元々のデータが少しおかしいんだから、自動判別に頼らずにKanjiTranslator [kashim.com]みたいに右から左に全部変換してしまうソフトでコードを一括変換してから、ヘッダをDevas [gimite.net]でも使って正規表現駆使して変換した方が、手作業修正ページが少ないだろうね。
#インターネット上で使用が禁止されている半角カタカナ#ってフレーズにちょっとクスっときた。
HTML文章ならば、HTML Tidy [sourceforge.net]を試してみてはいかがでしょうか。
文字コードとか、HTMLのバージョンなどはコンフィギュレーションファイルを書いておいて・・・
お掃除したいHTMLファイルを標準入力にいれると、結果が標準出力より出力されます。
PS;久しく使っていない&&うろ覚えなので、的外れだったらごめんなさい。
まとめて 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なりなんなりに変換してなかったんですか?
私が言うのもなんですが、Windows 2000以上ならメモ帳でできますよただし、もれなくBOMがついてきます。
帳票設計ソフトが吐くUTF-8なXMLファイルをメモ帳で開いて確認し、ウッカリ保存してしまってBOMが付いてしまい設計ソフトがパースエラー起こすようになったりとか・・・・・・
テキストをいくら眺めてもエラーの原因がわからないので、勝手にBOMつけるのもBOM付いたぐらいでエラー吐くパーサーにも殺意が沸くわぁ
ブラウザによっては、UTF-8に切り替えたらフォントが変わってしまうものもあるので、フォント依存のレイアウトをしていたらそれも要チェックですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
Shift JIS→UTF-8変換。 (スコア:1)
自分のすべての HTML ファイルを Shift JIS で書いてるんですが、UTF-8 化するには
何をどうすればよい?
以前は Content-Type の Charset を Shift_JIS から UTF-8 に変えただけの“対応”を
したペイジに出くわした事もあるけれど、今どきはさすがにないんでしょうか。
Re:Shift JIS→UTF-8変換。 (スコア:2, 興味深い)
ファイルそのものの文字コードとContent-Typeを変えれば十分なのでは?
UTF-8が「必要」と考えるならばその他の理由もあるでしょうから、その理由に対する変換をしてあげればいいだけで。「阿吽」を「阿呍」にするとか?
# 別にShift_JISのファイルだってそのように表示はできるんだけどさ
ちなみに私もほぼ全てShift_JISで書いていますが、当分変えるつもりはありません。
Shift_JISのまま:
メリット: 過去のブラウザでも読める
デメリット: 別にない
UTF-8:
メリット: 別にない
デメリット: 過去のブラウザで読めない
私にとってはこんな感じなので。過去のブラウザを気にしても意味のないシーンでは、Shift_JIS or UTF-8で扱いやすい方を扱ってます。
Re:Shift JIS→UTF-8変換。 (スコア:1, 興味深い)
> UTF-8:
> メリット: 別にない
> デメリット: 過去のブラウザで読めない
デメリット追加: ファイルサイズが150%ぐらい増加する。
Re:Shift JIS→UTF-8変換。 (スコア:1)
ああ、そうか。そうですよね、それは結構問題。
普段は全く気にならないんですが、遅い/品質の低い回線を使わざるを得ないときに実感する...。
極端にやる必要はありませんが、できれば、ファイルサイズは小さくしておきたいですもんね。
# 未だにたまに、改行やインデントを見直してちょこっとダイエットしている私
Re:Shift JIS→UTF-8変換。 (スコア:1)
すごくどうでもいいツッコミですが、増加するのは50%ですね。2バイト→3バイトですから。
Re: (スコア:0)
さらに補足します.
UTF-8 では ASCII の範囲内は 1 バイトで表現できますから, HTMLファイルなら,よほど本文が長いものでない限り,50%も増えません.
極端な例では, slashdot.jp のトップページでは,8%の違いでした (UTF-8 の場合 79423 Byte,Shift_JIS (CP932) の場合 73499 Byte)
個人サイトなどでスクリプトや広告が無い場合でも,ちゃんと必要なタグを書いてあるならば,大抵は 30% 以下の増加でしょう.
また,最近では HTML ファイルは圧縮転送される事が多いですが,圧縮した場合にはこの差はさらに縮みます.(大抵の場合は)
Re: (スコア:0)
> また,最近では HTML ファイルは圧縮転送される事が多いですが,圧縮した場合にはこの差はさらに縮みます.(大抵の場合は)
理想的な圧縮状況であれば圧縮した結果はその文書が持つ情報量に依存するので、
元の文字コードが何であれ、同じサイズになるはずですね。
Re: (スコア:0)
「過去のブラウザ」ってNetscape 3とかIE 3くらいまでさかのぼりますよ? そんな非現実的な状況設定を持ち出すより「ガラケーで読めない」のほうがよほど説得力があるでしょう。困ったことに。
> Shift_JISのまま:
> デメリット: 別にない
で、そこまで古いブラウザを気にしてるなら、「x-sjisと書かないとNetscapeの一部バージョンで文字化けしちゃうよ問題」も当然気にしてるんですよね。なんでISO-2022-JPで書かないんですか? あ、ISO-2022-JPだとOperaの5以前で文字化けしますね。
Re:Shift JIS→UTF-8変換。 (スコア:2, 興味深い)
何をそんなに必死なのか...。あくまで「私にとって」ですよ?
単純なテキストばかりのページで、不都合がなかった古いブラウザを突然あえて切り捨てる理由が、私には思いつきません。
# 古いブラウザを使い続けるべきかは、別の問題ですよ
私が過去との互換性をある程度大事にしているページでは、過去にNetscape/IE 3.xはもちろん、NCSA Mozaic 2.1.1, Netscape 2.02, Opera 3.1, Cello 1.01a等での表示状況を確認した状態を引き継いでいます。今も表示できることを確認する価値があるとは思っていませんが、故意に切り捨てる必要はないと思っています。
あなたの言うガラケー(日本の携帯のことをこう言うんですね)にも対応すべく、未だにHDML(だっけ?)とH" LINK対応の日記ページは残してあったりもしますよ。それぐらいの配慮をした上で、Shift_JISをそのままにしています。
ま、ベストエフォートでいろんな人に見てもらいたいなってのを形にしているだけです。
Re:Shift JIS→UTF-8変換。 (スコア:1, おもしろおかしい)
If you hope more people will become interested in your documents,
they should be written in English instead of Japanese.
Re:Shift JIS→UTF-8変換。 (スコア:1)
That's Insightful:+1!
However, 'いろんな人' could mean various -Japanese speaker-, depends on the context, heh
Re: (スコア:0, フレームのもと)
Re: (スコア:0, オフトピック)
アグネスが嫌いな僕としては、むしろペットボトルのキャップを集めいたいところですな。もう少しわかってあげてください。
Re: (スコア:0)
Re:Shift JIS→UTF-8変換。 (スコア:1)
文字コードを変えたからって、やり方って変わるかな?
そこまで低レベルなページの書き方をしていない(ファイルの操作はエディタ頼み)なので、保存時のエンコードを変えるだけだと思うのですが...。
実際、同じエディタで編集しているファイルでも、表示環境にそう心配のないファイル、PerlスクリプトなんかはとっととUTF-8に移行しました。もっとも、こちらはUTF-8にするメリットが大きかったのですが。
Re: (スコア:0)
Re:Shift JIS→UTF-8変換。 (スコア:2, 参考になる)
MultiTextConverter [rk-k.com]とか。ヘッダも自動で書き換えてくれます。
Windows版へのリンクは下の方に。
#先日、本文UTF-8でcharsetがShift_JISのままなページを見かけた。
Re: (スコア:0)
#1711367です。
ちょっと確認してみたんですが、<head>〜</head>が元々ない場合はcharsetのメタ情報を埋め込んでくれないようです。
扱う側で問題が出るかも?
SJISだと読めてたけどUTF-8の自動判定に失敗して文字化けするとか。
ーーー
いままではcharsetなしのSJIS(UTF-8以外?)なHTMLはSpotlightのインデックスが作成されなかったのですが、UTF-8ならcharsetの有無に関係なくインデックスが作成されるようになりました。(何かヒットしねえなと思ってたらこれかぁ)
Re: (スコア:0)
headが無いって時点で元の問題が大きい様な気がする。
そうなると元々のデータが少しおかしいんだから、自動判別に頼らずに
KanjiTranslator [kashim.com]みたいに右から左に全部変換してしまうソフトでコードを一括変換してから、
ヘッダをDevas [gimite.net]でも使って正規表現駆使して変換した方が、手作業修正ページが少ないだろうね。
#インターネット上で使用が禁止されている半角カタカナ
#ってフレーズにちょっとクスっときた。
Re:Shift JIS→UTF-8変換。 (スコア:1)
HTML文章ならば、HTML Tidy [sourceforge.net]を試してみてはいかがでしょうか。
文字コードとか、HTMLのバージョンなどはコンフィギュレーションファイルを書いておいて・・・
お掃除したいHTMLファイルを標準入力にいれると、結果が標準出力より出力されます。
PS;久しく使っていない&&うろ覚えなので、的外れだったらごめんなさい。
大槻昌弥(♀) http://www.ne.jp/asahi/pursuits/ootsuki/
Re: (スコア: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なりなんなりに
変換してなかったんですか?
#またここに自分用のメモを書いてしまった。。。
Re: (スコア:0)
Re:Shift JIS→UTF-8変換。 (スコア:1)
私が言うのもなんですが、Windows 2000以上ならメモ帳でできますよ
ただし、もれなくBOMがついてきます。
Re:Shift JIS→UTF-8変換。 (スコア:1)
帳票設計ソフトが吐くUTF-8なXMLファイルをメモ帳で開いて確認し、
ウッカリ保存してしまってBOMが付いてしまい
設計ソフトがパースエラー起こすようになったりとか・・・・・・
テキストをいくら眺めてもエラーの原因がわからないので、勝手にBOMつけるのも
BOM付いたぐらいでエラー吐くパーサーにも殺意が沸くわぁ
Re: (スコア:0)
ブラウザによっては、UTF-8に切り替えたらフォントが変わってしまうものもあるので、
フォント依存のレイアウトをしていたらそれも要チェックですね。
Re: (スコア:0)