パスワードを忘れた? アカウント作成
188971 story

Webで利用される文字コード、UTF-8がもうすぐ50%を突破 116

ストーリー by soara
次はUTF-16? 部門より

あるAnonymous Coward 曰く、

Google Blogによると、WWWで利用されている文字コードのうちUTF-8が占める割合が50%に近づいたそうだ。

UTF-8の利用は2006年あたりから急激に増加しており、一方でUS-ASCIIやW.Eu.(ISO/IEC 8859-1/Windows 1252のことだと思われる)の割合が減少してる。日本語(SJIS等)についてはもともと10%以下しか無かったが、こちらもUTF-8への以降が進んでいるようだ。

かつては「文字化け」で(ブラウザの設定を変えないと)見られないサイトもよく見られたが、現在では確かにこのようなサイトは少なくなってきた。/.J読者の皆様の関わっているサイトはUTF-8対応しているだろうか?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2010年01月31日 15時05分 (#1711429)

    アメリカはともかく、ヨーロッパは従来、文字コードについて非常に混乱した状況にありました。
    西欧はだいたいISO8859-1で済んだのですが、東欧諸国はISO8859-2、北欧はISO8859-4、などと
    いうように。

    ユーロ導入とともに、ユーロマーク(€)が入ったISO8859-15/16などが使われるようになり、
    ヨーロッパ人の多くが、「文字化け」という現象を初めて知ると同時に、その対策として、
    文字コードを意識せざるを得ない状況に追い込まれたと思われます。
    さらに、ヨーロッパの統合が進むにつれ、文字コードもEU全体で使えるものが実際に必要になり、
    それが原動力になったのではないかと思います。文字化けに悩まされながらISO8859シリーズを
    注意深く使い分けるよりは、UTF-8に移行してしまった方が楽だと思ったのでしょう。

  • unicodeにまともに対応した日本語フォントで丸文字的なカワイイのとか
    実用で安価に上質なものが展開できるようになれば、なぜunicodeフォントが
    つかえないのですか?ってことになって、もっと発展すると思うんですがねえ。
    わざわざ違う文字領域にハートマークとかマップしなくても、最初から
    ハートに限らず多彩なマッピング領域があるわけですから。

    googleがケータイ絵文字を標準化するとかありませんでしたっけ
    あれも文字コードとして確率しちゃえば、ホラーな顔文字セットとか
    ギャル向けの顔文字セットとか 季節感を出したセットとか 統一された
    コード空間でデザインを競う=発展 とかなるんじゃないですか
    とかおもうんですけどねえ。まずはタタキ台がほしいとおもいますですよ。

    中華圏は法的な問題と(正確には国の許可がいります)、人海戦術で
    一気に製造できるというコストパフォーマンスもあって、やろうと思えば
    一気だと思うんです。ハングルも日本語よりも組み合わせで生成できるので
    3万文字作るより簡単でしょう。

    どこかでみた 漢字のパスdb?wikiを書体ごとに登録・管理して使えればなー

    --
    ( ´・ω・`)いままでとこれからを比べる生活
    ぱんかれ
  • by Anonymous Coward on 2010年01月31日 12時14分 (#1711350)

    たとえば安岡先生の調査によると「𠮟」(口へんに七)を検索できたのはGoogleだけ [srad.jp]。むしろさすがGoogleと言うべきか。でも「以下がIPアドレス帯域です(キリッ [takagi-hiromitsu.jp]」なGoogleジャパン発のGoogle日本語入力では「𠮟」を変換できないのよね。ATOKやVista以降のMS-IME、Office IME 2007ではできるのに。
    そもそもこのスラッシュドット・ジャパンだって安岡先生の日記が含まれているとRSSが読めなくなるという問題が発覚してようやく重い腰を上げてBMP外文字に対応したけど、それまではまったく表示する手段がなかったし、現在でも4バイトUTF-8の直接入力はできない(入れるとそこ以降がぶった切られる)始末。

  • by mitchie1970 (12436) on 2010年01月31日 12時19分 (#1711352)

    自分のすべての HTML ファイルを Shift JIS で書いてるんですが、UTF-8 化するには
    何をどうすればよい?

    以前は Content-Type の Charset を Shift_JIS から UTF-8 に変えただけの“対応”を
    したペイジに出くわした事もあるけれど、今どきはさすがにないんでしょうか。

    • by fukapon (4131) on 2010年01月31日 12時38分 (#1711360) ホームページ

      ファイルそのものの文字コードとContent-Typeを変えれば十分なのでは?
      UTF-8が「必要」と考えるならばその他の理由もあるでしょうから、その理由に対する変換をしてあげればいいだけで。「阿吽」を「阿呍」にするとか?
      # 別にShift_JISのファイルだってそのように表示はできるんだけどさ

      ちなみに私もほぼ全てShift_JISで書いていますが、当分変えるつもりはありません。

      Shift_JISのまま:
       メリット: 過去のブラウザでも読める
       デメリット: 別にない
      UTF-8:
       メリット: 別にない
       デメリット: 過去のブラウザで読めない

      私にとってはこんな感じなので。過去のブラウザを気にしても意味のないシーンでは、Shift_JIS or UTF-8で扱いやすい方を扱ってます。

      親コメント
      • by Anonymous Coward on 2010年01月31日 13時31分 (#1711384)

        > UTF-8:
        >  メリット: 別にない
        >  デメリット: 過去のブラウザで読めない
        デメリット追加: ファイルサイズが150%ぐらい増加する。

        親コメント
    • by Anonymous Coward on 2010年01月31日 13時01分 (#1711367)

      MultiTextConverter [rk-k.com]とか。ヘッダも自動で書き換えてくれます。
      Windows版へのリンクは下の方に。

      #先日、本文UTF-8でcharsetがShift_JISのままなページを見かけた。

      親コメント
    • HTML文章ならば、HTML Tidy [sourceforge.net]を試してみてはいかがでしょうか。

      文字コードとか、HTMLのバージョンなどはコンフィギュレーションファイルを書いておいて・・・

      お掃除したいHTMLファイルを標準入力にいれると、結果が標準出力より出力されます。

      PS;久しく使っていない&&うろ覚えなので、的外れだったらごめんなさい。

      --
      大槻昌弥(♀) http://www.ne.jp/asahi/pursuits/ootsuki/
      親コメント
    • by Anonymous Coward

      まとめて nkf して、Charset を一括置換……というだけでは足りないのでしょうか?

      • by Anonymous Coward on 2010年01月31日 13時11分 (#1711375)

        まとめて nkf して、Charset を一括置換……というだけでは足りないのでしょうか?

        いやいやいや全然全く足りませんよ
        そもそもUTF-8はShiftJISの上位互換では無いですから、単純にnkfすれば良いという訳ではないです
        ましてやUTF-8自体もBOM有り/無しとありまして、OSによっては片方のみをUTF-8として認識し、もう片方は認識出来ずに文字化けの嵐なんて事もありますし

        私も昨年、PostgreSQLのDBをEUC_JPからUTF-8に変換しようとして難儀しましたよ
        有名なバックスラッシュとなみ線問題から、一部の漢字の誤変換問題
        更にはそれらをシコシコと手作業で直していたのですが、端末上ではVim、Windowsでは秀丸を使っていましたら、改行はLFで統一されていたものの、何故かBOMが混在した状態になってしまっていたりして・・・・・本当に疲れた

        親コメント
        • by Anonymous Coward on 2010年01月31日 13時58分 (#1711398)

          上位互換ですよ。
          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については、どうやって混乱を収束する方向に行っているのか知りません。

          親コメント
          • by Anonymous Coward on 2010年01月31日 21時48分 (#1711568)

            どうも、混沌としていますが…

            「上位互換」という言葉の使い方がややこしいんだと思います。元コメが言わんとしているのは、上位互換ではなく、「後方互換が維持されている上位互換」ですね。例えば、US-ASCIIの文書は、そのままUTF-8と称して何の問題もなく使えます。一方、Shift-JISで表現されうる文字は全てユニコードに文字が割り振られていますから、Shift-JISの文章は全てUTF-8に変換可能です。そういう意味ではユニコードを表現できるUTF-8はShift-JISの上位互換ですが、Shift-JISの文章をUTF-8でデコードすると、文字化けします。デコード自体には後方互換性がありません。こういうのを「互換」と言っていいのか迷いますが。むしろ上位規格とか、そういう感じかと。

            だから、#1711398は何の瑕疵もない主張なんですが、元コメの言葉足らずを考慮すると、どこかで議論の軌道修正が必要だと思います。

            親コメント
            • by pz00 (10663) on 2010年02月01日 0時36分 (#1711624)

              人によってはWindows-31JのことをShift-JISって言ってる場合もあるんで余計ややこしかったりして。

              #もともとの文字集合が似て非なるものが複数存在する状態なのが不幸の始まりか。
              #それにエンコーディングで輪をかける感じ?

              親コメント
            • by numa (4467) on 2010年02月01日 1時46分 (#1711641) ホームページ 日記

              「上位互換」とか「互換性」とか言う話をするからややこしいんであって、何が同じで何が違うのか、という話をすればいいのです。

              Unicode(あるいはISO/IEC 10646)は、Shift_JISなりEUC-JPなりISO-2022-JPなり(さらにはWindows_31Jなり)を、文字セット(使える文字のレパートリー)としては、包含している。よって、それらのいずれにも存在する文字は、Unicodeへの変換によって、損なわれない。

              一方、文字エンコーディングとしては、UTF-8もUTF-16も、Shift_JISなりEUC-JPなり……とは、異なっている。よって、変換が必要である。

              そういうことでしょ。

              親コメント
      • nkf使える人(存在を知っているような人)はShift JISでHTML書かないのでは?

        --

        #またここに自分用のメモを書いてしまった。。。
        親コメント
    • by Anonymous Coward
      手作業で済む量でしたらサクラエディタに文字コード変換機能がありますよ。
      • by moca (33770) on 2010年01月31日 14時24分 (#1711404) 日記

        私が言うのもなんですが、Windows 2000以上ならメモ帳でできますよ
        ただし、もれなくBOMがついてきます。

        親コメント
        • 帳票設計ソフトが吐くUTF-8なXMLファイルをメモ帳で開いて確認し、
          ウッカリ保存してしまってBOMが付いてしまい
          設計ソフトがパースエラー起こすようになったりとか・・・・・・

          テキストをいくら眺めてもエラーの原因がわからないので、勝手にBOMつけるのも
          BOM付いたぐらいでエラー吐くパーサーにも殺意が沸くわぁ

          親コメント
  • by Anonymous Coward on 2010年01月31日 12時48分 (#1711363)

    UTF-16 は UTF-8 の上位互換ではないよ。というか、UTF-8 のほうがよりマシな状況も多々ある。
    もし表現できる文字数上限を気にしているなら、32bit以上で符号化すべきだし。

  • 各言語ごとに文字コード変えてたら大変ですからね。
    例えば Twitter を UTF-8 以外で提供することは考えにくいです。
    各種の Wiki や、blog なども多言語に対応させるため UTF-8 がほとんどだと思います。
    l10n よりも i18n の流れが進んだのでしょう。
    # 私の場合、テキストエディタのデフォルトが UTF-8 だし、最近はほとんどのテキストデータで UTF-8 です。
    # UTF-8 以外を使うのは、メールぐらいですかね。
  • by nipo (34616) on 2010年01月31日 14時56分 (#1711423)
    UTF-8のウェブページの半分はGoogleのものです。
  • GnuCashのWebページ [gnucash.org]を翻訳したときに
    namazu がヨーロッパ系の言語では ISO-8859, 日本語では EUC-JP
    しか設定できないため日本語の部分だけフレームのフォーマットが
    異なっています。またそれに起因する文字化けも一部発生しています。

    まあ影響は軽微なのでそのままにしてますが、いずれは UTF-8対応して欲しいなと思います。
    なんか良い方法があれば gnucash-develに投げてくださるとうれしいです。

  • ソースコード中に世界中のどんな文字でも"・・・"と書けるのは便利です。
    もう戻れない
typodupeerror

アレゲは一日にしてならず -- アレゲ研究家

読み込み中...