[PHP-users 35077] Re: 文字変換のにコードについて

[shige02 ＠ mac.com]

重松です。

Windows は殆ど使っていませんし、どのようなシステムを構築されているのか分かりませんが、Windows 自体が Unicode をサポートしていますので、ユーザは無意識のうちに Unicode でしか扱えない範囲のデータを利用していると思います。

当然ですが、後から unicode に対応しなくてはいけなくなるのは目に見えていますから、最初から器は大きいほうが楽でしょう。（たとえば、ハングルが入力できないとか、繁体字で書き込みたいとか、そういう要望が出たとして、できて困る理由がありますか？）

文字化けがどのような理由によるものか分かりませんが（まあ、大抵はバックスラッシュというか円マークというかの問題でしょうけど）、今スクラッチで開発していて、ケータイを対象としているものでないのに SJIS でやる積極的な理由はないし、自分が楽という理由よりも、ユーザビリティを優先すべきだし、文字化けという問題に場当たり的に対処するにしても、hex に変換するよりは、いっそ UTF-8 にしてしまったほうが、ありとあらゆる意味で楽だと思いますし、後々良いと思います。自分ならば、携帯サイトを構築する場合でも、内部的には UTF-8 を使うと思います。

それから皆必要とする処理は大体同じで、よくある処理は PHP に組み込まれていたり、組み込まれてなくても、ライブラリがあったりします。
逆にない、ということは、それが余程三菱さんの社内的に特殊な処理でない限りは、アプローチというか、ロジックというか、実装の仕方自体がよく言えば独創的、悪く言えば、標準からズレている、ということですから、どうしてもその方法でないといけないのなら別ですが、流れには逆らわないほうがいいと思います。
# 以前 MSS さんの仕事をした時に、そういう特殊な処理が沢山ありましたけど。

ですから、今どきもう無いとは思いますが、8bit が通らないのなら、base64 を使うのは常識ですし、文字化けするのなら、対策には「定石」があり、その定石を踏むべきでしょう。

ハネムーンナンバーとか、トラックナンバーとかいうんですが、余り独創的な実装をすると、何かあった時にそれ、誰も保守できないか、保守しづらいものになると思います。base64 の意味を知らない人はいないけど、謎のエンコード処理がありそれにバグがあれば、その時実装者しか保守できないからです。個人のウェブサイトの足跡帳の開発なら別ですが、社内で長く使おうとするものなら、保守のことも考えるべきです。
だから、「コードを書かないほうがいい」といっているわけです。
コードを書かなければ、バグが入る事はありません。今回がいい例です。
広く周知されている技術を無視して、同じようなことを一から開発する行為を車輪の再発明といいます。

ところで、PHP って、昔は、UTF-8N でないとダメで、BOM がついた UTF-8 だと、おかしなことになった気がしたんだけど、今手元で試したら、問題なく通りますね。

$ php -v
PHP 5.3.0 (cli) (built: Jul 19 2009 00:34:29) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

On Mar 30, 2010, at 4:20 PM, eiichi_maekawa ＠ mhi.co.jp wrote:

> また、開発のマシンが、windowsマシンで、sjisが扱いやすいこともあります。

-- 
Osamu Shigematsu