アカウント名:
パスワード:
アメリカはともかく、ヨーロッパは従来、文字コードについて非常に混乱した状況にありました。西欧はだいたいISO8859-1で済んだのですが、東欧諸国はISO8859-2、北欧はISO8859-4、などというように。
ユーロ導入とともに、ユーロマーク(€)が入ったISO8859-15/16などが使われるようになり、ヨーロッパ人の多くが、「文字化け」という現象を初めて知ると同時に、その対策として、文字コードを意識せざるを得ない状況に追い込まれたと思われます。さらに、ヨーロッパの統合が進むにつれ、文字コードもEU全体で使えるものが実際に必要になり、それが原動力になったのではないかと思います。文字化けに悩まされながらISO8859シリーズを注意深く使い分けるよりは、UTF-8に移行してしまった方が楽だと思ったのでしょう。
unicodeにまともに対応した日本語フォントで丸文字的なカワイイのとか実用で安価に上質なものが展開できるようになれば、なぜunicodeフォントがつかえないのですか？ってことになって、もっと発展すると思うんですがねえ。わざわざ違う文字領域にハートマークとかマップしなくても、最初からハートに限らず多彩なマッピング領域があるわけですから。
googleがケータイ絵文字を標準化するとかありませんでしたっけあれも文字コードとして確率しちゃえば、ホラーな顔文字セットとかギャル向けの顔文字セットとか 季節感を出したセットとか 統一されたコード空間でデザインを競う＝発展 とかなるんじゃないですかとかおもうんですけどねえ。まずはタタキ台がほしいとおもいますですよ。
中華圏は法的な問題と（正確には国の許可がいります）、人海戦術で一気に製造できるというコストパフォーマンスもあって、やろうと思えば一気だと思うんです。ハングルも日本語よりも組み合わせで生成できるので３万文字作るより簡単でしょう。
どこかでみた 漢字のパスdb？wikiを書体ごとに登録・管理して使えればなー
たとえば安岡先生の調査によると「𠮟」(口へんに七)を検索できたのはGoogleだけ [srad.jp]。むしろさすがGoogleと言うべきか。でも「以下がIPアドレス帯域です(キリッ [takagi-hiromitsu.jp]」なGoogleジャパン発のGoogle日本語入力では「𠮟」を変換できないのよね。ATOKやVista以降のMS-IME、Office IME 2007ではできるのに。そもそもこのスラッシュドット・ジャパンだって安岡先生の日記が含まれているとRSSが読めなくなるという問題が発覚してようやく重い腰を上げてBMP外文字に対応したけど、それまではまったく表示する手段がなかったし、現在でも4バイトUTF-8の直接入力はできない(入れるとそこ以降がぶった切られる)始末。
自分のすべての 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バイトですから。
何をそんなに必死なのか...。あくまで「私にとって」ですよ?単純なテキストばかりのページで、不都合がなかった古いブラウザを突然あえて切り捨てる理由が、私には思いつきません。# 古いブラウザを使い続けるべきかは、別の問題ですよ
私が過去との互換性をある程度大事にしているページでは、過去に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のままなページを見かけた。
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なり……とは、異なっている。よって、変換が必要である。
そういうことでしょ。
BOM付きUTF-8なんてローカルルールで標準ではないんですよ。
→ 付ける必要は無いが、付けた場合でも規格の範囲内。
ISO-2022-JPで半角カナを拡張して使ってるようなもんです。
→ 規格外。
では? もっとも、HTTPはエンコードを指定できるプロトコルなので、BOMを禁止するべきである (RFC 3629) という話はありますが。
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」と見なす、というルールと混同していませんか? (もっとも、これは後方互換性のためのようですが。)
nkf使える人(存在を知っているような人)はShift JISでHTML書かないのでは?
もちろん「使える人」にはPCにMS-DOS版なりMS Windowsコンソール版を入れてる人も想定して書いていますよ?
nkfが必要で(それが何をするモノなのか知っていて)わざわざPCにインストールする人はふつーsjisでHTML置いたりしないでしょ
モバギはsjisかもしれないけど、コピー時やアップロード時にeucjpなりなんなりに変換してなかったんですか?
私が言うのもなんですが、Windows 2000以上ならメモ帳でできますよただし、もれなくBOMがついてきます。
帳票設計ソフトが吐くUTF-8なXMLファイルをメモ帳で開いて確認し、ウッカリ保存してしまってBOMが付いてしまい設計ソフトがパースエラー起こすようになったりとか･･････
テキストをいくら眺めてもエラーの原因がわからないので、勝手にBOMつけるのもBOM付いたぐらいでエラー吐くパーサーにも殺意が沸くわぁ
UTF-16 は UTF-8 の上位互換ではないよ。というか、UTF-8 のほうがよりマシな状況も多々ある。もし表現できる文字数上限を気にしているなら、32bit以上で符号化すべきだし。
UTF-16はASCII互換じゃないから、Apacheの設定がいい加減でエンコードの指定をmetaタグに依存しているページの場合、文字化けしないのかなぁ。
7bitしか通さない環境と言えば、メールはIP reachableな範囲より広い範囲までuucp/BITNETの昔から転送されてきましたので、IP reachableな世界を全世界とみなして、その外にゲートウェイを通じてつながっている世界を切り捨てる覚悟が必要になるのかもしれません。
MIME以前の環境なら、7ビットしか通さないとかいう議論もあったでしょうが、今の今時、文字エンコーディングが指定されていないメールなんて、実用的にはないに等しいはず。
ならば、ゲートウェイだって、そのエンコーディング指定（Content-Type: ヘッダーフィールドのcharsetパラメーター）を読み取って、適切に変換すればいいわけではないかと。
GnuCashのWebページ [gnucash.org]を翻訳したときにnamazu がヨーロッパ系の言語では ISO-8859, 日本語では EUC-JPしか設定できないため日本語の部分だけフレームのフォーマットが異なっています。またそれに起因する文字化けも一部発生しています。
まあ影響は軽微なのでそのままにしてますが、いずれは UTF-8対応して欲しいなと思います。なんか良い方法があれば gnucash-develに投げてくださるとうれしいです。
そうですか？元コメントは「世界中のどんな文字でも」とありますが、そこまできちんと対応しているエディタは少ないように思うのですが。
以前、フランス語やドイツ語のテキストファイルを処理しなければいけないことがあったんですが、大抵の「Unicode対応エディタ」というものは、内部的にはSJISで処理していて入出力時にUTF-8に変換するだけという代物であるため、これらの言語を正しく扱えません。そのとき探したエディタの中で、多言語をまともに使えたのはEmEditorだけだったと思います。秀丸とかは試してないので分かりません。
DIS 10646:1991の方がいいなあ--ACったらAC
これ、自分で面白いと思って書いたんだろうか
部門名への皮肉かなと思いました。
#こういう皮肉の是非についてはノーコメント。
> モバイル機器の増加IPアドレスみたいにモバイル機器一台ごとにコードポイント1つ使ってりしませんが。つーかそもそもガラパゴスケータイがいくら増えてもShift_JISの範囲すらはみ出せませんが。面白くもないジョーク飛ばしてる暇があったらガラケーのUnicode対応からやってください。> UTF-16のような小手先の回避策ではなく、ビット数に余裕のあるUTF-32へのUTF-16もUTF-32も定義域は同じ(U+10FFFFまで [unicode.org])です。面白くもないジョーク考える前にせめてその程度のことは調べてください。
人間ひとりひとりに、絵文字で似顔絵を割り当てるっていうのはどうかなぁ？
UTF-8は符号化方法なので、もともとの文字コード表の仕様とちゃんと合うようにさえ選ばれていたら、足りなくなることはないはずです。
そして、もともとの文字コード表については既に16bitじゃ足りなくなっていて1996年のUnicode 2.0で拡張されています。その規格は、一番最初の面を0面として、さらに追加で16面用意され、計17面用意されています。
この中途半端な拡張は、UTF-8よりむしろUTF-16の都合によるもので、UTF-16でどうにか他の面の文字を参照する仕組みであるサロゲートペアが1024個の文字2つ=20bit=16bit*(2^4面)を利用するため、そういう制限になっています。
UTF-8は、現行規格では有効な文字コードは第16面までと制限されていますが、その制限を取っ払えば、今と同じ方法で31bitまで表現できます。
いくらなんでも言掛かりあなたは自分の知識を疑った方がよいと思う
昔はこういう用途はISO-2022で、むしろUnicodeはこういう用途に使いたい人から攻撃されてきたのですけどね（CJK統合漢字とか）。
モーダルな（つまり、状態シフトのある）文字コードなんて使いにくくて仕方がない（対応ソフトを作るのも面倒なので、Muleくらいしかない）ので、やはりUnicode/ISO10646には負ける運命にあったのでしょう。
# ソフトウェア開発者は、それぞれの目的を満たすために開発するのであって、# 文字コードなんかに興味はないのですから。文字コードに興味がある開発者のみしか# 対応アプリケーションを書いてくれないような文字コードなんて、将来性はなかった# と言って良いと思います。
変換ミスじゃなくて、2ch語では？(2chで「確率」と書いたら「確立」だと言われた。アホらしくて行かないから今は知らない)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
ユーロ(€)が原動力？ (スコア:2, 参考になる)
アメリカはともかく、ヨーロッパは従来、文字コードについて非常に混乱した状況にありました。
西欧はだいたいISO8859-1で済んだのですが、東欧諸国はISO8859-2、北欧はISO8859-4、などと
いうように。
ユーロ導入とともに、ユーロマーク(€)が入ったISO8859-15/16などが使われるようになり、
ヨーロッパ人の多くが、「文字化け」という現象を初めて知ると同時に、その対策として、
文字コードを意識せざるを得ない状況に追い込まれたと思われます。
さらに、ヨーロッパの統合が進むにつれ、文字コードもEU全体で使えるものが実際に必要になり、
それが原動力になったのではないかと思います。文字化けに悩まされながらISO8859シリーズを
注意深く使い分けるよりは、UTF-8に移行してしまった方が楽だと思ったのでしょう。
Re:ユーロ(€)が原動力？ (スコア:1)
フォントも充実すればいいのにねえ (スコア:2)
unicodeにまともに対応した日本語フォントで丸文字的なカワイイのとか
実用で安価に上質なものが展開できるようになれば、なぜunicodeフォントが
つかえないのですか？ってことになって、もっと発展すると思うんですがねえ。
わざわざ違う文字領域にハートマークとかマップしなくても、最初から
ハートに限らず多彩なマッピング領域があるわけですから。
googleがケータイ絵文字を標準化するとかありませんでしたっけ
あれも文字コードとして確率しちゃえば、ホラーな顔文字セットとか
ギャル向けの顔文字セットとか 季節感を出したセットとか 統一された
コード空間でデザインを競う＝発展 とかなるんじゃないですか
とかおもうんですけどねえ。まずはタタキ台がほしいとおもいますですよ。
中華圏は法的な問題と（正確には国の許可がいります）、人海戦術で
一気に製造できるというコストパフォーマンスもあって、やろうと思えば
一気だと思うんです。ハングルも日本語よりも組み合わせで生成できるので
３万文字作るより簡単でしょう。
どこかでみた 漢字のパスdb？wikiを書体ごとに登録・管理して使えればなー
( ´・ω・`)いままでとこれからを比べる生活
ぱんかれ
「まともに」UTF-8対応してるページはどれだけあることやら (スコア:1, 興味深い)
たとえば安岡先生の調査によると「𠮟」(口へんに七)を検索できたのはGoogleだけ [srad.jp]。むしろさすがGoogleと言うべきか。でも「以下がIPアドレス帯域です(キリッ [takagi-hiromitsu.jp]」なGoogleジャパン発のGoogle日本語入力では「𠮟」を変換できないのよね。ATOKやVista以降のMS-IME、Office IME 2007ではできるのに。
そもそもこのスラッシュドット・ジャパンだって安岡先生の日記が含まれているとRSSが読めなくなるという問題が発覚してようやく重い腰を上げてBMP外文字に対応したけど、それまではまったく表示する手段がなかったし、現在でも4バイトUTF-8の直接入力はできない(入れるとそこ以降がぶった切られる)始末。
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: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:Shift JIS→UTF-8変換。 (スコア:1)
文字コードを変えたからって、やり方って変わるかな?
そこまで低レベルなページの書き方をしていない（ファイルの操作はエディタ頼み）なので、保存時のエンコードを変えるだけだと思うのですが...。
実際、同じエディタで編集しているファイルでも、表示環境にそう心配のないファイル、PerlスクリプトなんかはとっととUTF-8に移行しました。もっとも、こちらはUTF-8にするメリットが大きかったのですが。
Re:Shift JIS→UTF-8変換。 (スコア:2, 参考になる)
MultiTextConverter [rk-k.com]とか。ヘッダも自動で書き換えてくれます。
Windows版へのリンクは下の方に。
＃先日、本文UTF-8でcharsetがShift_JISのままなページを見かけた。
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:Shift JIS→UTF-8変換。 (スコア:2)
→ 付ける必要は無いが、付けた場合でも規格の範囲内。
→ 規格外。
では? もっとも、HTTPはエンコードを指定できるプロトコルなので、BOMを禁止するべきである (RFC 3629) という話はありますが。
HIRATA Yasuyuki
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:Shift JIS→UTF-8変換。 (スコア:1)
nkf使える人(存在を知っているような人)はShift JISで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付いたぐらいでエラー吐くパーサーにも殺意が沸くわぁ
部門名：次はUTF-16?・・・ぉぃぉぃ (スコア:1, 参考になる)
UTF-16 は UTF-8 の上位互換ではないよ。というか、UTF-8 のほうがよりマシな状況も多々ある。
もし表現できる文字数上限を気にしているなら、32bit以上で符号化すべきだし。
Re:部門名：次はUTF-16?・・・ぉぃぉぃ (スコア:1)
UTF-16はASCII互換じゃないから、Apacheの設定がいい加減でエンコードの指定をmetaタグに依存しているページの場合、文字化けしないのかなぁ。
1を聞いて0を知れ!
グローバルなサービスが増えたから (スコア:1)
例えば Twitter を UTF-8 以外で提供することは考えにくいです。
各種の Wiki や、blog なども多言語に対応させるため UTF-8 がほとんどだと思います。
l10n よりも i18n の流れが進んだのでしょう。
# 私の場合、テキストエディタのデフォルトが UTF-8 だし、最近はほとんどのテキストデータで UTF-8 です。
# UTF-8 以外を使うのは、メールぐらいですかね。
Re:グローバルなサービスが増えたから (スコア:1)
7bitしか通さない環境と言えば、メールはIP reachableな範囲より広い範囲までuucp/BITNETの昔から転送されてきましたので、IP reachableな世界を全世界とみなして、その外にゲートウェイを通じてつながっている世界を切り捨てる覚悟が必要になるのかもしれません。
Re:グローバルなサービスが増えたから (スコア:1)
MIME以前の環境なら、7ビットしか通さないとかいう議論もあったでしょうが、今の今時、文字エンコーディングが指定されていないメールなんて、実用的にはないに等しいはず。
ならば、ゲートウェイだって、そのエンコーディング指定（Content-Type: ヘッダーフィールドのcharsetパラメーター）を読み取って、適切に変換すればいいわけではないかと。
50%の内訳 (スコア:1)
namazu がEUC-JPなのがネック (スコア:1)
GnuCashのWebページ [gnucash.org]を翻訳したときに
namazu がヨーロッパ系の言語では ISO-8859, 日本語では EUC-JP
しか設定できないため日本語の部分だけフレームのフォーマットが
異なっています。またそれに起因する文字化けも一部発生しています。
まあ影響は軽微なのでそのままにしてますが、いずれは UTF-8対応して欲しいなと思います。
なんか良い方法があれば gnucash-develに投げてくださるとうれしいです。
ウエブだけではなくてほぼすべてのテキストファイルで移行済みです (スコア:0)
もう戻れない
Re:ウエブだけではなくてほぼすべてのテキストファイルで移行済みです (スコア:1)
Re:むしろ最近は使えないエディタ探す方が大変だと思うけど (スコア:1)
そうですか？元コメントは「世界中のどんな文字でも」とありますが、そこまできちんと対応しているエディタは少ないように思うのですが。
以前、フランス語やドイツ語のテキストファイルを処理しなければいけないことがあったんですが、大抵の「Unicode対応エディタ」というものは、内部的にはSJISで処理していて入出力時にUTF-8に変換するだけという代物であるため、これらの言語を正しく扱えません。そのとき探したエディタの中で、多言語をまともに使えたのはEmEditorだけだったと思います。秀丸とかは試してないので分かりません。
Re:それじゃあ早速、枯渇の話をしようじゃないか。 (スコア:1, 興味深い)
DIS 10646:1991の方がいいなあ
--
ACったらAC
Re: (スコア:0)
Re:それじゃあ早速、枯渇の話をしようじゃないか。 (スコア:1)
部門名への皮肉かなと思いました。
#こういう皮肉の是非についてはノーコメント。
LIVE-GON(リベゴン)
Re:それじゃあ早速、枯渇の話をしようじゃないか。 (スコア:1)
#なるべくポジティブにとらえたい
Re: (スコア:0)
> モバイル機器の増加
IPアドレスみたいにモバイル機器一台ごとにコードポイント1つ使ってりしませんが。つーかそもそもガラパゴスケータイがいくら増えてもShift_JISの範囲すらはみ出せませんが。面白くもないジョーク飛ばしてる暇があったらガラケーのUnicode対応からやってください。
> UTF-16のような小手先の回避策ではなく、ビット数に余裕のあるUTF-32への
UTF-16もUTF-32も定義域は同じ(U+10FFFFまで [unicode.org])です。面白くもないジョーク考える前にせめてその程度のことは調べてください。
Re:それじゃあ早速、枯渇の話をしようじゃないか。 (スコア:1)
人間ひとりひとりに、絵文字で似顔絵を割り当てるっていうのはどうかなぁ？
1を聞いて0を知れ!
Re:誤読した (スコア:1)
UTF-8は符号化方法なので、もともとの文字コード表の仕様とちゃんと合うようにさえ選ばれていたら、足りなくなることはないはずです。
そして、もともとの文字コード表については既に16bitじゃ足りなくなっていて1996年のUnicode 2.0で拡張されています。
その規格は、一番最初の面を0面として、さらに追加で16面用意され、計17面用意されています。
この中途半端な拡張は、UTF-8よりむしろUTF-16の都合によるもので、UTF-16でどうにか他の面の文字を参照する仕組みであるサロゲートペアが1024個の文字2つ=20bit=16bit*(2^4面)を利用するため、そういう制限になっています。
UTF-8は、現行規格では有効な文字コードは第16面までと制限されていますが、その制限を取っ払えば、今と同じ方法で31bitまで表現できます。
1を聞いて0を知れ!
Re: (スコア:0)
いくらなんでも言掛かり
あなたは自分の知識を疑った方がよいと思う
Re:必要です (スコア:1, すばらしい洞察)
昔はこういう用途はISO-2022で、むしろUnicodeはこういう用途に使いたい人から
攻撃されてきたのですけどね（CJK統合漢字とか）。
モーダルな（つまり、状態シフトのある）文字コードなんて使いにくくて仕方がない
（対応ソフトを作るのも面倒なので、Muleくらいしかない）ので、やはり
Unicode/ISO10646には負ける運命にあったのでしょう。
# ソフトウェア開発者は、それぞれの目的を満たすために開発するのであって、
# 文字コードなんかに興味はないのですから。文字コードに興味がある開発者のみしか
# 対応アプリケーションを書いてくれないような文字コードなんて、将来性はなかった
# と言って良いと思います。
Re:シフトJIS野郎は喫煙者と同じ (スコア:1)
Re:一方 email は… (スコア:1)
Re:それ以前に (スコア:1)
変換ミスじゃなくて、2ch語では？
(2chで「確率」と書いたら「確立」だと言われた。アホらしくて行かないから今は知らない)
the.ACount