スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

[PHP] mb_convert_encoding() でエラー

Q.
正常に動いていたはずのPHPスクリプトが、違うサーバに置いたところ
Warning: mb_convert_encoding(): Illegal character encoding specified in ~
というようなエラーがたくさん出るようになりました。

A.
おそらく、mb_detect_order() の文字コード検出の違いによるものかと思われます。
入力文字の文字コード判別の際に mb_detect_encoding() を使っており、
そこで第二引数(文字エンコーディングのリスト)を省略していませんか?
mb_detect_encoding() で第二引数を明示するか、mb_detect_order() を適切に
設定しましょう。

たとえばこういうこと。

mb_detect_encoding( $_POST['hoge'] );

mb_detect_encoding( $_POST['hoge'] ,"auto" );


また、文字エンコーディングを "auto" とした場合は文字列が短い場合に
思わぬ誤判断をする場合があるので、明示的に指定するのがよいでしょう。

mb_detect_encoding( $_POST['hoge'] ,"ASCII,JIS,UTF-8,EUC-JP,SJIS" );

スポンサーサイト

[PHP / Web] 住所情報を一括で GoogleMaps の座標に変換

APIたたくだけっちゅやあ、たたくだけなんですが。
自分的メモ。

Googleさんに住所文字列を投げるときにはUTF-8にしておくこと。
取得できなかったものに関してはその旨が返ってきます。
下記例で言うと、「関が原ウォーランド」がそうです。

参照:サービス - Google Maps API - Google Code
http://code.google.com/intl/ja/apis/maps/documentation/services.html#Geocoding_Direct






<?php
//調べたい住所を配列で与える
$adr = array(
"東京駅", "熊本城", "東京ディズニーランド",
"大阪城", "関が原ウォーランド","屋久島"
);
$key = "DUMMY"; // ここにはGoogleから取得したキー ■要変更■
$output = "csv"; // 出力形式

//配列をひとつずつAPIに投げる
for( $i = 0; $i < count( $adr ); $i++ ){
$str_adr = urlencode( $adr[$i] );
$api_url = "http://maps.google.com/maps/geo?q=".$adr[$i];
$api_url .= "&key=".$key."&output=".$output;
$buf = file_get_contents( $api_url );
print "<hr>".$adr[$i]."<br>".$buf;
}
?>

[IT] 工事進行基準の導入でトンデモIT業界が少しましになるかもという話

 パソコンを使った仕事をしておりますが、基本的にコンピュータとか
プログラム自体はそんなに好きでもないのでIT関係のニュースは
避けているわけです。おかげで最新情報に疎いです。

 いっときネットワーク系の知識が必要である程度はその系統の
情報を気にしていた時期もあったのですが、さっぱりです。
 IPv6とやらが今後主力となるとかいろいろ書いてたような気がしますが、
いまだにIP設定でいつもながらの XXX.XXX.XXX.XXX とは違うものには
お見かけしません。技術の進歩は早いようで、意外と遅かったりします。

 さて、システム屋さんへの支払とか契約形態とかが変わってくるかも
とかいうお話。
 IT知識のとぼしい私がざらっと読みしたところによると、いままでの

システム全体の検収 → 見積の全額の請求
から、
各フェーズの終了 → 各フェーズごとの売上計上、請求

となるそうです。

■工事進行基準がいよいよ導入へ(Microsoft Office Online)
http://www.microsoft.com/japan/office/2007/project/koji_reg/whats.mspx

上記のMicrosoftのページがわかりやすいです。
途中から製品の広告になるので、そこからは読まんでOKです。

ではそれによって何が起こるかというと、

・ハード・ソフト・そのほか面倒賃などを含めたグロスでの契約ができない
・要件定義を行わずに、開発を先行するようなことができない
・契約の変更を行わない限り、大幅な仕様変更ができない


 システム開発はよく家の建築にたとえられますが、ようは
「基礎工事」「屋根葺き」「内装」などでそれぞれ見積をたてて、それぞれの
契約を行って、それぞれの工程が済んだ段階で請求と支払を行いなさい、
「家建築」という一括の契約はだめだし、いったん建て始めたら2階のベランダを
もっと広くしろとか言わない、もしそうしたいなら契約を交わし直しなさいよと
いうことです(と私は把握しました)。
 詳しくは↓

■SI契約に変革迫る「進行基準」/IT業界に激震走る!(IT Pro)
http://itpro.nikkeibp.co.jp/article/COLUMN/20080606/306796/?ST=system&P=1

 当たり前といえば当たり前なのですが、いままでそうでなかったのが
この業界というもので、契約そのものが口約束だったりしたわけです。

 大手ベンダは来年度から「原則」適用ということですが、零細ソフト屋にも
なんらかの影響はでてくるかもしれませんね。

システム開発 火事場プロジェクトの法則―どうすればデスマーチをなくせるか?システム開発 火事場プロジェクトの法則―どうすればデスマーチをなくせるか?
(2006/09)
山崎 敏

商品詳細を見る


ソフトウェア業における工事進行基準の実務ソフトウェア業における工事進行基準の実務
(2008/06)
岩谷 誠治

商品詳細を見る
検索フォーム
リンク
最新記事
最新コメント
カテゴリ
RSSリンクの表示
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。