パスワードを忘れた? アカウント作成
248993 story
インターネット

国産 CMS のメリットってどんなん? UTF-8 対応はうれしいの? 64

ストーリー by reo
使える文字が増えるーとか… 部門より

i.love.lemontea 曰く、

japan.internet.com の記事で、沖縄の「のれんずプロ」という会社が開発した CMS が標準で UTF-8 に対応、というタイトルのものがある。

そもそも CMS 自体そんなに触ったことがないので分からないのだが、国産の CMS だから備えてるメリットみたいなのってあるのだろうか。UTF-8 対応のメリットにはどんな事があろうのだろうか。CMS に詳しい人教えてください。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • デモサイト (スコア:5, おもしろおかしい)

    by Anonymous Coward on 2010年08月24日 13時02分 (#1814372)
    ちらっと見ただけだけど、
    <?xml version="1.0" encoding="shift_jis"?>
    と書いておきながら、数行後には
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    もうね……
    (実際にはUTF-8で書かれているようです)
  • by oguma (17986) on 2010年08月24日 13時09分 (#1814377)

     年末にも内閣告示になる予定の改定常用漢字表 [bunka.go.jp]には、JIS X 0208では表現できない字体が含まれていますので、今後のことを考えればUTF-8(+Extension B)への対応は必須ではないでしょうかね。

    参考:
    新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能 [nikkeibp.co.jp]

    --
    Nullius addictus iurare in verba magistri
    • Re:改定常用漢字表 (スコア:4, おもしろおかしい)

      by Anonymous Coward on 2010年08月24日 13時18分 (#1814383)
      また頓珍漢な事を。
        UTF8は日本語と中国語の判別もできない欠陥コードです。

      なんて言って周囲を興ざめさせるやつが出てこないか心配です。
      ま、UTF8対応は常識になってくるんでしょうね。
      中国語と日本語の区別がつかないことがあるなんて、ほとんどの人には
      どうでもいい気がする。
      親コメント
      • Re:改定常用漢字表 (スコア:2, おもしろおかしい)

        by vn (10720) on 2010年08月24日 20時39分 (#1814636) 日記

        また頓珍漢な事を。
        UTF8は日本語と中国語の判別もできない欠陥コードです。

        それを書くならUTF−8って書かなくちゃ。

        親コメント
      • 中国語と日本語の区別がつかないことがあるなんて、ほとんどの人には
        どうでもいい気がする。

        • 文字集合や符号化方式で区別する (「charset=SHIFT_JIS ってことはきっと日本語だな」など)
        • 文字で区別する (「平仮名が多く含まれているから日本語だろう」「CJKV 包摂を廃止するべきだ!」「ついでに英語の A とフランス語の A も違う文字にするべきだ!」など)
        • テキストより上のレイヤーで区別する (「<html lang="ja"> と書いてあるから日本語」など)

        と、言語を区別する方法にもいろいろあるわけで、どの方式を採用するかは確かにほとんどの人にはどうでも良いですが、何らかの方法では区別できるようにしておかないと困るように思います。

        親コメント
      • by nim (10479) on 2010年08月24日 13時48分 (#1814405)

        言語と文字セットは別の概念ですから、別に定義するのが妥当な考え方ですよね。
        XHTML だと、xml:lang は、様々な要素にセットできますから、

        Content-type: text/xml; charset=UTF-8

        で XHTML を返して、要素ごとに日本語か中国語かを入れていけば一番よいのでは?

        # ところで、漢文はどっちとして扱うのでしょうか?

        親コメント
        • by Anonymous Coward

          簡体字か繁体字か日本の漢字かで判断するしかないですね。

          「骨」とか一見似ていて、日中でちょっと違うとかいう漢字があると、
          混乱します。

      • by Anonymous Coward

        その前に、ラテン語の文字と英語の文字を区別できる画期的なコードセットを……

      • by Anonymous Coward

        > UTF8は日本語と中国語の判別もできない欠陥コードです。
        じゃあ中国語を判別とか以前に書くことすらできないガラパゴスコードなんて欠陥とか論評する以前の論外コードですね。

    • Re:改定常用漢字表 (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2010年08月24日 21時23分 (#1814657)

      年末にも内閣告示になる予定の改定常用漢字表には、JIS X 0208では表現できない字体が含まれていますので

      例示字形が違うだけで、JIS X0208 では包摂されてるんだから、表現できないわけじゃないでしょ。
      字形が違うのはフォントの問題であって文字集合の問題ではないし。

      親コメント
      • by oguma (17986) on 2010年08月25日 10時03分 (#1814858)

        例示字形が違うだけで、JIS X0208 では包摂されてるんだから、表現できないわけじゃないでしょ。

         ご指摘のとおりです。
         「JIS X 0213:2004で包摂分離された字体」、と書かなければいけませんでした。

         ただ、PC用OSではJIS X 0213:2004への対応が進んでいますので、UTF-8サポートは望ましいと思います。

        --
        Nullius addictus iurare in verba magistri
        親コメント
  • by Livingdead (18685) on 2010年08月24日 13時51分 (#1814409) ホームページ 日記

    国産ということで言えば、最近は軽いSOY CMS [soycms.net]を使ってます。
    軽いというかごちゃごちゃと余計なことをしてほしくないHTML直書き派にはいいかも。
    SQLiteでもMySQLでも動くようですが、私はとにかく簡便にサイトを作りたい時に使っているのでSQLite派です。

    --
    屍体メモ [windy.cx]
  • by reininn (35924) on 2010年08月24日 14時30分 (#1814435)
    UTF-8は、他の言語を簡単に混ぜられるし、
    はしご髙や、たつ﨑などの EUC-JP に無い漢字も使えるので便利ですよ。
    でも、携帯用に変換するとき、
    ちゃんと、高と崎に変換するか?です。
  • ドキュメントが日本語 (スコア:2, すばらしい洞察)

    by saitoh (10803) on 2010年08月24日 19時20分 (#1814587)
    やっぱドキュメントやhelpが日本語で用意されているのが最大の利点じゃないでしょうか。

    ・・・・国産CMSだけどドキュメントが英語だけなんてのがあったらどうしよう。

  • by kei100 (5854) on 2010年08月24日 23時43分 (#1814740) ホームページ

    内部処理でちゃんと日本語が通るようにしてる可能性が高いので比較的安心?
    少なくともデバッグ時(&テスト時)に態々英語のみでテストしないでしょうから、日本語が通るように出来ている可能性が高いです。
    たとえば、DBの言語設定が日本語で格納出来るように気を使ってセットアップが作られてるとかとか、
    バックエンドのDBサーバーへの格納時に、バイト制限があるからといって文字の途中でブチ切るなんて起きないようにしたりとか、
    日本語のファイル名をアップロードしても、URLエンコードするなり、完全リネームしてURL内に日本語の生表記が残らないようにしたりとか、
    個人情報を入れたいケースでも日本にあわせた書式や支援機能(県選択から郵便番号による入力支援)、携帯メールのリスト選択が付いてたりとか
    後は翻訳の質ですかね。結局エンドユーザーが使う部分に英語を出す訳には行かないので。

    番外として、高速化の為に一部外部プログラムにとかいうケースで、
    気をつけないと足し算で大文字に変換してたりとか、そーゆ酷い文字列の扱いしてないかも。

    といった辺りで便利かもしれない。
    # /.も昔は1バイト目で切って、タイトル化けさせてましたよねぇ・・・

    --
    誰も信じちゃいけない、裏切られるから。
    私を信じないで、貴方を裏切ってしまうから。
  • 保守性、という回答がないような。

    すでにあらゆる(プログラミング|スクリプト)言語とOSがUTF-8ネイティブにリプレースをされており、
    日本語環境=Shift_jisというかつての常識は最大派閥であるWindowsXPマシンがいずれリプレースされる前提では近いうちに過去のものとなるでしょう。

    メモ帳クラスの簡易テキストエディタのデファクトスタンダードがUTF-8になりつつある現在を理解した上で、あえて放置する理由は見当たらないように思います。

    --
    Youthの半分はバファリンでできています。
    • #勢いで書いてしまった感あり・・・。

      原典らしき文書、信用できるソースを探しきれなかったのですが、
      「あれ?どこかのSPのタイミングでwindowsXPの内部コードがutf-8になったような・・・」と曖昧な記憶の裏をとって見たところ、windowsの内部コードは、少なくともXP以降UTF-16 [wikipedia.org]とのこと。
      >日本語環境=Shift_jisというかつての常識は最大派閥であるWindowsXPマシンがいずれリプレースされる前提では近いうちに過去のものとなるでしょう。
      これはメモ帳において新規文書作成時に採用される文字コードのデフォルトはWinXP登場時点ではShiftjis、確かVistaからutf-8になったという曖昧な記憶を元に書きました。
      上のような間違いをしている人間なのでできればどなたかに補足をお願いしたいです。

      ということで、

      >すでにあらゆる(プログラミング|スクリプト)言語とOSがUTF-8ネイティブにリプレースをされており、
      ・現在もメンテされている
      ・マルチバイトのネイティブ対応を謳っている
      と言う条件のもとで「最新安定版におけるマルチバイトのデフォルトがユニコードでないものを私が知らない」と言うだけですので、

      s/あらゆる/ほとんどの/

      とさせていただきます。

      --
      Youthの半分はバファリンでできています。
      親コメント
      • by Stealth (5277) on 2010年08月26日 11時18分 (#1815614)

        メモ帳で UTF-8 で保存すると先頭に BOM が付き、これを適切に処理できない場合問題が発生しやすいっていうネタは良くある話かと思います。

        # WordPress でも「wp-config.php をメモ帳で編集するな」とかありますね。

        なお、メモ帳も相変わらず基本は ANSI (ローカルキャラクターセット) が標準であって、ファイル保存時に UTF-8 を選択するか、開いたファイルが UTF-8 だった場合のみ初期状態も UTF-8 かと思います。

        親コメント
  • by fukuso (40682) on 2010年08月29日 11時54分 (#1816958)
    今年の8月から、うちの会社では提案に利用する場合、↓のCMSに一本化してます。 SITE PUBLIS ベーシックライセンス(http://www.micsnet.co.jp/basic/ [micsnet.co.jp]) というCMSで、ミックスネットワークという会社が開発してます。 機能・性能面で考えると、今一番ホットな製品とマネージャーが判断したようです。
  • by Anonymous Coward on 2010年08月24日 12時40分 (#1814346)

    機種依存文字とか、どうでもいい細かいマナーで宗教論争に入るのはまっさらごめ(ry
    自分がメリットを感じていないのでしたら、気にする必要ありません。だいじょぶだいじょぶ。

  • by Anonymous Coward on 2010年08月24日 13時20分 (#1814384)
    スルーカを鍛えなさい。
  • by Anonymous Coward on 2010年08月24日 13時32分 (#1814395)
    どうなん?
    ??
    • by Anonymous Coward

      道南って、どうなん?

      # 道産子+関西人か?
      # いや、ミスターどうでしょうダメ人間あたりのダジャレだな。

      # 新作楽しみだなぁ...。

  • by Anonymous Coward on 2010年08月24日 13時56分 (#1814411)
    国産だからって日本でしか使わなくちゃいけない理由はありませんから。 それにオープンソースならなおさらですね。
    • by Anonymous Coward

      国産でCMSがでない→日本の技術力発想力云々・・
      国産でCMSができた→どんなん?うれしいの?

      こうして日本は衰退していく

  • by Anonymous Coward on 2010年08月24日 14時24分 (#1814427)

    UTF-8対応ってすでにオープンソースなCMSだと有名どころは当たり前に対応していますね。

    でこのAD-EDIT2ってUTF-8でさらには携帯対応って事だから
    UTF-8からSJISへの変換はどうしているのかな?
    有名なJcodo.pmあたり使っている?
    数年前の事だけどJcodo.pmにしてもJcodo.plにしても文字コード変換で「~」など一部文字で文字化けが発生するバグがあったけど
    今は大丈夫になったのかな?

    でWebサイトを作成する会社として
    AD-EDIT2側のhttp://adedit.norenz.net/
    こっち側はいいとして
    会社側のhttp://www.norenz.net/
    こっちのサイト。
    ・デザインセンスなし
    ・サイト構造がスタイルシートではなくてテーブルレイアウト
    ってあり得ないよ。
    これでWebソリューションって項目があるのが怖いくらい。

  • by Anonymous Coward on 2010年08月24日 14時39分 (#1814441)

    文字コードの今年かネタにならないって...
    UTF-8普及前のものを26文字しか頭に入ってない連中がメンテしてるようなものだと100%の対応は期待できませんが、それ以降のものはだいたい大丈夫。

    それよりももっと文化的な面、日本人に合ったUIとか、日本人好みだけど海外では見向きもされない(人呼んでガラパゴス)機能とかその辺じゃあないんでしょうか。

    • by taka2 (14791) on 2010年08月24日 15時11分 (#1814456) ホームページ 日記

      CMSで更新日時なんかを埋め込めるようなものだと、日付表示フォーマットなんかは問題になりえるかと思います。

      英語圏のソフトだと、「Tue Aug 24 15:07:46 2010」って表示したり、
      年月日が全部数字でも「08/24/10」といった月日年順なフォーマットになってたり、
      そういう形式固定で、日本的な表記に変更できないものも時々みかけます。

      私は英語表記なんかが混じってもそれほど気にしないのですが、
      一般人だと、ちょっとでもアルファベットが入るだけで、読むことを拒否するような人は結構見かける気がします。
      上述のような日付表示でも、「日付表示が英語になってる」というのではなく
      「日付表示がおかしい」というクレームが入ったりとか。

      #FreeBSD の strftime が ja_JP で %c が「火 8/24 15:07:29 2010」になるのは、ちょっと呆れてしまいましたが…
      #あまりにも直訳すぎ…

      親コメント
      • by Anonymous Coward

        そうですね日本(パーフェクト)クオリティでlocalizationが完了しているというのは重要なポイントかもしれませんね。

        # 26字の人たちをバカにするのもいいけど
        # かくいう自分もrtlへの配慮はできてないことを意識するようにはしている

      • by Anonymous Coward

        そのあたりも、最近のはiso8601(というよりはサブセットのRFC3339)を使ってたりするんで、
        「2010-08-24T00:01:02」とかになってたりしません?

  • by Anonymous Coward on 2010年08月24日 15時06分 (#1814454)
    CMSと言えば、VM/CMSだったのに。時代は変わったなぁ
  • by Anonymous Coward on 2010年08月24日 15時13分 (#1814460)

    英語オンリーでも、必ずしもASCII文字オンリーにはならんのよ。
    Latin1に入ってれば平気で非ASCII文字使ってくる人いるし……
    # そしてまたビルドに失敗する。

    • by Anonymous Coward

      5年前に出ていれば使っていたんですけどね。
      携帯電話向けのスクリプトが皆無でしたから。

  • by Anonymous Coward on 2010年08月24日 18時59分 (#1814564)

    内容は日本語メインだったら、内部UTF-16にはなって欲しいな。ディスクスペースがすごく安くなったのは分かる。ただ殆んど2バイトで済むものを3バイト以上使って保存するのがどうしても美しくないと考えてしまうんだ。

    • by vn (10720) on 2010年08月24日 21時06分 (#1814648) 日記
      UTF-16BE とか UTF-16LE とか UTF-16 (BOM付き) とかがあるのって
      どうしても美しくないと考えてしまうんだ。
      親コメント
    • by Stealth (5277) on 2010年08月26日 11時15分 (#1815613)

      アプリケーションの内部だけが UTF-16 になっても、ユーザー出力や DB とかへの出力も UTF-8 だったりすると、内部 UTF-16 にするメリットってほぼ皆無だったりしませんか?
      UTF-8 に対応していれば UTF-\d+ すべてに対応している、なんてことはありませんし、単体のみで完結するものでない限り、内部 UTF-16 にあまりメリットがあるようには思えません。

      Web ブラウザー類の JavaScript エンジンが仕様通り内部 UTF-16 で作っていたとしても、それで大きなメリットがあるかと言えば……。

      親コメント
    • by Anonymous Coward

      サロゲートペア使ってる時点であんま変わんない気が。

typodupeerror

計算機科学者とは、壊れていないものを修理する人々のことである

読み込み中...