PHPの内部エンコーディングでUTF-8を使う | Let's POSTGRES
日本語などASCII以外の文字集合を使う場合は、そのシステムでどの文字セットをメインに使用するか、ということが最初に決めるべき事項の１つです。代表的なものにShift_JIS（SJIS、SJIS-win）、EUC-JP（eucJP-win）、UTF-8、UTF-16などがあります。 ただShift_JISなど、バックスラッシュ（≒エスケープ記号）が通常の文字の２バイト目として含まれてれる可能性のある文字エンコーディングでは、正規表現関数（preg_*** あるいは eregなど）や、マルチバイト文字列関数（mb_***）などの関数が正しく動かないケースや、各種エスケープ処理が意図した通りには動作してくれないことが多々あります。 また、PHPの内部エンコーディングをPostgreSQLで使用する文字セットと揃えておくことで、変換にかかるサーバ上のコストや変換で生じる脆弱性を低減することができ
PCREはUnicode文字プロパティをサポートするとは限らない - hnwの日記
（2011/05/19追記）CentOS5のpcreパッケージについて言えば、2010年7月以降Unicode文字プロパティが有効になっているそうです。安心ですね！（via「 CentOS5.5でCakePHP1.3系のInflector::slugを正常動作させる方法 - Lism.in * blog - nekoya (id:studio-m)」） PCREというのは、Perl互換の正規表現ライブラリです。PCREは例えばPHPのpreg系関数で利用されていますし、他の処理系でも多く利用されているかと思います。ところで、PCREの挙動は環境ごとに異なる可能性があることをご存知でしょうか。具体的には、Unicode文字プロパティをサポートする環境としない環境とがあり、同じ正規表現でも挙動が変わることがあります。僕はそんなことを考えた事もなかったので、ビックリしました。 同じ原因で、以前の
PHPのマルチバイト文字列関数で”ISO-2022-JP”, “JIS”, “ISO-2022-JP-MS”の違い | おふろめ
PHPのマルチバイト文字列関数で”ISO-2022-JP”, “JIS”, “ISO-2022-JP-MS”の違い PHP5.2.1ぐらいから”ISO-2022-JP-MS”というのも使えるそうなので”ISO-2022-JP”,”JIS”とどう違うか試してみました。 <?php /* UTF-8からISO-2022-JP, JIS, ISO-2022-JP-MSに変換してみる */ setlocale( LC_ALL, 'ja_JP.UTF-8' ); /* ダメ元で☎ ☃なども */ $str = 'ｱｲｳｴｵ ㈱ ㈲ ① ② Ⅰ Ⅱ ℡ ㎏ ㎎ 﨑 髙 神 ☎ ☃'; header( 'Content-Type: text/plain; charset=ISO-2022-JP' ); printf( "%sn", 'PHP' . PHP_VERSION ); $encodings =
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
