国産 CMS のメリットってどんなん? UTF-8 対応はうれしいの? 64
ストーリー by reo
使える文字が増えるーとか… 部門より
使える文字が増えるーとか… 部門より
i.love.lemontea 曰く、
japan.internet.com の記事で、沖縄の「のれんずプロ」という会社が開発した CMS が標準で UTF-8 に対応、というタイトルのものがある。
そもそも CMS 自体そんなに触ったことがないので分からないのだが、国産の CMS だから備えてるメリットみたいなのってあるのだろうか。UTF-8 対応のメリットにはどんな事があろうのだろうか。CMS に詳しい人教えてください。
デモサイト (スコア:5, おもしろおかしい)
<?xml version="1.0" encoding="shift_jis"?>
と書いておきながら、数行後には
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
もうね……
(実際にはUTF-8で書かれているようです)
Re:デモサイト (スコア:1)
改定常用漢字表 (スコア:3, 興味深い)
年末にも内閣告示になる予定の改定常用漢字表 [bunka.go.jp]には、JIS X 0208では表現できない字体が含まれていますので、今後のことを考えればUTF-8（+Extension B）への対応は必須ではないでしょうかね。
参考：
新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能 [nikkeibp.co.jp]
Nullius addictus iurare in verba magistri
Re:改定常用漢字表 (スコア:4, おもしろおかしい)
UTF8は日本語と中国語の判別もできない欠陥コードです。
なんて言って周囲を興ざめさせるやつが出てこないか心配です。
ま、UTF8対応は常識になってくるんでしょうね。
中国語と日本語の区別がつかないことがあるなんて、ほとんどの人には
どうでもいい気がする。
Re:改定常用漢字表 (スコア:2, おもしろおかしい)
それを書くならＵＴＦ−８って書かなくちゃ。
Re:改定常用漢字表 (スコア:2)
と、言語を区別する方法にもいろいろあるわけで、どの方式を採用するかは確かにほとんどの人にはどうでも良いですが、何らかの方法では区別できるようにしておかないと困るように思います。
Re:改定常用漢字表 (スコア:1)
言語と文字セットは別の概念ですから、別に定義するのが妥当な考え方ですよね。
XHTML だと、xml:lang は、様々な要素にセットできますから、
Content-type: text/xml; charset=UTF-8
で XHTML を返して、要素ごとに日本語か中国語かを入れていけば一番よいのでは？
# ところで、漢文はどっちとして扱うのでしょうか？
Re: (スコア:0)
簡体字か繁体字か日本の漢字かで判断するしかないですね。
「骨」とか一見似ていて、日中でちょっと違うとかいう漢字があると、
混乱します。
Re: (スコア:0)
その前に、ラテン語の文字と英語の文字を区別できる画期的なコードセットを……
Re: (スコア:0)
> UTF8は日本語と中国語の判別もできない欠陥コードです。
じゃあ中国語を判別とか以前に書くことすらできないガラパゴスコードなんて欠陥とか論評する以前の論外コードですね。
Re:改定常用漢字表 (スコア:1, すばらしい洞察)
例示字形が違うだけで、JIS X0208 では包摂されてるんだから、表現できないわけじゃないでしょ。
字形が違うのはフォントの問題であって文字集合の問題ではないし。
Re:改定常用漢字表 (スコア:2)
ご指摘のとおりです。
「JIS X 0213:2004で包摂分離された字体」、と書かなければいけませんでした。
ただ、PC用OSではJIS X 0213:2004への対応が進んでいますので、UTF-8サポートは望ましいと思います。
Nullius addictus iurare in verba magistri
Re:改定常用漢字表 (スコア:2)
どちらも Unicode 文字集合の問題ではありません。サロゲートペアに至ってはただの仕様であって「問題」ですらないような。
Re:改定常用漢字表 (スコア:2)
UTF-8 や UTF-16 といった符号化方式にそれぞれ対応の面倒臭そうな点があるのは事実ですが、それとあなたがおっしゃる「常用漢字表ではデザインの違いということになっているものを分離している文字集合の問題」とは全然関係ありません。
SoyCMS使ってます (スコア:2, 興味深い)
国産ということで言えば、最近は軽いSOY CMS [soycms.net]を使ってます。
軽いというかごちゃごちゃと余計なことをしてほしくないHTML直書き派にはいいかも。
SQLiteでもMySQLでも動くようですが、私はとにかく簡便にサイトを作りたい時に使っているのでSQLite派です。
屍体メモ [windy.cx]
このページもUTF-8ですよ (スコア:2)
はしご髙や、たつ﨑などの EUC-JP に無い漢字も使えるので便利ですよ。
でも、携帯用に変換するとき、
ちゃんと、高と崎に変換するか？です。
ドキュメントが日本語 (スコア:2, すばらしい洞察)
・・・・国産CMSだけどドキュメントが英語だけなんてのがあったらどうしよう。
外じゃなくて、中が大切。 (スコア:2, 興味深い)
内部処理でちゃんと日本語が通るようにしてる可能性が高いので比較的安心？
少なくともデバッグ時(&テスト時)に態々英語のみでテストしないでしょうから、日本語が通るように出来ている可能性が高いです。
たとえば、DBの言語設定が日本語で格納出来るように気を使ってセットアップが作られてるとかとか、
バックエンドのDBサーバーへの格納時に、バイト制限があるからといって文字の途中でブチ切るなんて起きないようにしたりとか、
日本語のファイル名をアップロードしても、URLエンコードするなり、完全リネームしてURL内に日本語の生表記が残らないようにしたりとか、
個人情報を入れたいケースでも日本にあわせた書式や支援機能(県選択から郵便番号による入力支援)、携帯メールのリスト選択が付いてたりとか
後は翻訳の質ですかね。結局エンドユーザーが使う部分に英語を出す訳には行かないので。
番外として、高速化の為に一部外部プログラムにとかいうケースで、
気をつけないと足し算で大文字に変換してたりとか、そーゆ酷い文字列の扱いしてないかも。
といった辺りで便利かもしれない。
# /.も昔は1バイト目で切って、タイトル化けさせてましたよねぇ・・・
「メモ帳でも編集できます！」って言いたいんじゃないの? (スコア:1)
保守性、という回答がないような。
すでにあらゆる(プログラミング|スクリプト)言語とOSがUTF-8ネイティブにリプレースをされており、
日本語環境＝Shift_jisというかつての常識は最大派閥であるWindowsXPマシンがいずれリプレースされる前提では近いうちに過去のものとなるでしょう。
メモ帳クラスの簡易テキストエディタのデファクトスタンダードがUTF-8になりつつある現在を理解した上で、あえて放置する理由は見当たらないように思います。
Youthの半分はバファリンでできています。
訂正とお詫び。 (スコア:1)
＃勢いで書いてしまった感あり・・・。
原典らしき文書、信用できるソースを探しきれなかったのですが、
「あれ？どこかのSPのタイミングでwindowsXPの内部コードがutf-8になったような・・・」と曖昧な記憶の裏をとって見たところ、windowsの内部コードは、少なくともXP以降UTF-16 [wikipedia.org]とのこと。
＞日本語環境＝Shift_jisというかつての常識は最大派閥であるWindowsXPマシンがいずれリプレースされる前提では近いうちに過去のものとなるでしょう。
これはメモ帳において新規文書作成時に採用される文字コードのデフォルトはWinXP登場時点ではShiftjis、確かVistaからutf-8になったという曖昧な記憶を元に書きました。
上のような間違いをしている人間なのでできればどなたかに補足をお願いしたいです。
ということで、
＞すでにあらゆる(プログラミング|スクリプト)言語とOSがUTF-8ネイティブにリプレースをされており、
・現在もメンテされている
・マルチバイトのネイティブ対応を謳っている
と言う条件のもとで「最新安定版におけるマルチバイトのデフォルトがユニコードでないものを私が知らない」と言うだけですので、
s/あらゆる/ほとんどの/
とさせていただきます。
Youthの半分はバファリンでできています。
Re:訂正とお詫び。 (スコア:1)
メモ帳で UTF-8 で保存すると先頭に BOM が付き、これを適切に処理できない場合問題が発生しやすいっていうネタは良くある話かと思います。
# WordPress でも「wp-config.php をメモ帳で編集するな」とかありますね。
なお、メモ帳も相変わらず基本は ANSI (ローカルキャラクターセット) が標準であって、ファイル保存時に UTF-8 を選択するか、開いたファイルが UTF-8 だった場合のみ初期状態も UTF-8 かと思います。
ご参考に (スコア:1)
気にしなくてもいいですよ (スコア:0)
機種依存文字とか、どうでもいい細かいマナーで宗教論争に入るのはまっさらごめ(ry自分がメリットを感じていないのでしたら、気にする必要ありません。だいじょぶだいじょぶ。
Re: (スコア:0)
○ まっぴら
日本人？
Re:気にしなくてもいいですよ (スコア:1)
さっぱり日本人でしょう。狂乱家族日記の優歌ちゃん的には。
だから、日本人＝大日本帝国臣民、と言う意味かもしれない。
fjの教祖様
とりあえず、 (スコア:0)
どうなん? (スコア:0)
??
Re: (スコア:0)
道南って、どうなん？
# 道産子＋関西人か？
# いや、
ミスターどうでしょうダメ人間あたりのダジャレだな。# 新作楽しみだなぁ...。
UTF-8はいいですよ (スコア:0)
Re: (スコア:0)
国産でCMSがでない→日本の技術力発想力云々・・
国産でCMSができた→どんなん？うれしいの？
こうして日本は衰退していく
当たり前 (スコア:0)
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ソリューションって項目があるのが怖いくらい。
Re:当たり前 (スコア:1, 参考になる)
標準でEncodeがあるのに今さらJcode.pmを使い始めるものがあるのでしょうか。
つか「～」ってSiftJIS(cp932)との変換における波ダッシュと全角チルダの問題だろうけど、それを文字化けするバグというのは不勉強すぎ。
問題があるのは確かだけど、そうじゃない。
# あとJcode.plじゃなくてjcode.plな。
批判するのはもうちっと勉強してからな。
Re:当たり前 (スコア:1, 参考になる)
Encode.pmってJcode.pmを内包する形で搭載されたからJcode.pmのバグはそのまま引き継がれているんじゃないの?
>つか「～」ってSiftJIS(cp932)との変換における波ダッシュと全角チルダの問題だろうけど、それを文字化けするバグというのは不勉強すぎ。
でも対応が不十分なのは事実。
Re:当たり前 (スコア:3, 参考になる)
"～"のマッピングの違いなら、規格が違うからとしか。
cp932とunicodeのマッピング(テキスト) [unicode.org]
0x8160 0xFF5E #FULLWIDTH TILDE
Shift_JISとunicodeのマッピング(テキスト)(obsolete) [unicode.org]
0x8160 0x301C # WAVE DASH
波ダッシュ [wikipedia.org]
テストコード
結果
Re: (スコア:0)
どうすればいいのか、後学のためにおしえてください。
Re:当たり前 (スコア:1)
このネタをぶら下げるならこの辺が適当とみた。
「私のために争わないで」文字コードのUTF8さん、自殺 [bogusne.ws]
ちなみに速攻で反応しているdankogaiのTB [livedoor.jp]まで読んでね。
Youthの半分はバファリンでできています。
Re: (スコア:0)
codoには突っ込まないのかよ。
Re: (スコア:0)
+1
文化面とか重要です (スコア:0)
文字コードの今年かネタにならないって...
UTF-8普及前のものを26文字しか頭に入ってない連中がメンテしてるようなものだと100%の対応は期待できませんが、それ以降のものはだいたい大丈夫。
それよりももっと文化的な面、日本人に合ったUIとか、日本人好みだけど海外では見向きもされない（人呼んでガラパゴス）機能とかその辺じゃあないんでしょうか。
Re:文化面とか重要です (スコア:2, 興味深い)
CMSで更新日時なんかを埋め込めるようなものだと、日付表示フォーマットなんかは問題になりえるかと思います。
英語圏のソフトだと、「Tue Aug 24 15:07:46 2010」って表示したり、
年月日が全部数字でも「08/24/10」といった月日年順なフォーマットになってたり、
そういう形式固定で、日本的な表記に変更できないものも時々みかけます。
私は英語表記なんかが混じってもそれほど気にしないのですが、
一般人だと、ちょっとでもアルファベットが入るだけで、読むことを拒否するような人は結構見かける気がします。
上述のような日付表示でも、「日付表示が英語になってる」というのではなく
「日付表示がおかしい」というクレームが入ったりとか。
#FreeBSD の strftime が ja_JP で %c が「火 8/24 15:07:29 2010」になるのは、ちょっと呆れてしまいましたが…
#あまりにも直訳すぎ…
Re: (スコア:0)
そうですね日本（パーフェクト）クオリティでlocalizationが完了しているというのは重要なポイントかもしれませんね。
# 26字の人たちをバカにするのもいいけど
# かくいう自分もrtlへの配慮はできてないことを意識するようにはしている
Re: (スコア:0)
そのあたりも、最近のはiso8601(というよりはサブセットのRFC3339)を使ってたりするんで、
「2010-08-24T00:01:02」とかになってたりしません？
あぁあ (スコア:0)
非ASCII (スコア:0)
英語オンリーでも、必ずしもASCII文字オンリーにはならんのよ。
Latin1に入ってれば平気で非ASCII文字使ってくる人いるし……
# そしてまたビルドに失敗する。
Re: (スコア:0)
5年前に出ていれば使っていたんですけどね。
携帯電話向けのスクリプトが皆無でしたから。
UTF-16は？ (スコア:0)
内容は日本語メインだったら、内部UTF-16にはなって欲しいな。ディスクスペースがすごく安くなったのは分かる。ただ殆んど２バイトで済むものを３バイト以上使って保存するのがどうしても美しくないと考えてしまうんだ。
Re:UTF-16は？ (スコア:1)
どうしても美しくないと考えてしまうんだ。
Re:UTF-16は？ (スコア:1)
アプリケーションの内部だけが UTF-16 になっても、ユーザー出力や DB とかへの出力も UTF-8 だったりすると、内部 UTF-16 にするメリットってほぼ皆無だったりしませんか?
UTF-8 に対応していれば UTF-\d+ すべてに対応している、なんてことはありませんし、単体のみで完結するものでない限り、内部 UTF-16 にあまりメリットがあるようには思えません。
Web ブラウザー類の JavaScript エンジンが仕様通り内部 UTF-16 で作っていたとしても、それで大きなメリットがあるかと言えば……。
Re: (スコア:0)
サロゲートペア使ってる時点であんま変わんない気が。
Re:既にUTF-8は貴方の身近に (スコア:3, 参考になる)
> デジタル放送の番組情報で使われている文字コードはUTF-8とかが使われている。(ワンセグを除く)
「興味深い」ひともおられるようですが、気のせいでしょう。
国内デジタル放送のSI/EPG(番組情報)の文字列フィールドで使用されている8単位符号系は、UTF-8とは別物です。
既存文字セット＋放送拡張をGR/GLに呼び出して使うなど、典型的なJIS系の符号化運用かと。
なおBS、広帯域CS、地上波(フルセグ、ワンセグ)と同じ符号系ですので、「ワンセグだけ違う」ってことも無いです。
データ放送コンテンツの文字符号は携帯キャリアからの要望もあって「ワンセグは別」だけど、やっぱりUTF-8じゃないし。
コンテンツメタデータの活用のために、付録でUTF系への変換規則が追加規定されてるあたりを勘違いしたのかな？
＃ そっちも放送拡張文字([Ｓ]や[天]：厳密には周りは矩形)のマッピングあたりはかなり無理している印象だったり。