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

2010年 3月 30日 (火) 17:47:55 JST

重松さん

重ね重ねのご指摘・ご意見、ありがとうございます。

今後の新規システムでは、考慮したいと考えます。

参考にさせていただきます。

了


             shige02 ＠ mac.com                                               
             送信者:                                                       
             php-users-bounces                                        宛先 
             @php.gr.jp                 PHP-users ML <php-users ＠ php.gr.jp> 
                                                                        cc 
                                                                           
             2010/03/30 17:38                                         件名 
                                        [PHP-users 35077] Re: 文字変換のに 
                                        コードについて                     
               PHP-users ML                                                
             <php-users ＠ php.gr                                             
                  .jp> へ                                                  
             返信してください                                              
                                                                           
                                                                           
重松です。

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

_______________________________________________
PHP-users mailing list  PHP-users ＠ php.gr.jp
http://ml.php.gr.jp/mailman/listinfo/php-users
PHP初心者のためのページ - 質問する前にはこちらをお読みください
http://oldwww.php.gr.jp/php/novice.php3