Encode - 規格のバグまでは直せません : 404 Blog Not Found
2006年05月10日11:00 カテゴリLightweight LanguagesLogos Encode - 規格のバグまでは直せません それが規格だからです。 b:note: Encodeのナゾ 最近会う機会が無いので、トラックバックします。 $moji = "～"; Encode::from_to($moji, "euc-jp", "utf8"); print $moji; で出てきた文字をWindowsのメモ帳とか秀丸でみると、～の波形が反対になった文字になってしまいます。 ここでいう「～」はU+FF5E、Fullwidth Tildeのことです。 その答えは、「Unicode Consortiumが用意したJISX0212とUnicodeの変換表がそうだったから」ということになります。Encodeのせいではないのです。詳しくは、 Japanese <-> Unicode Map
PHPで、いわゆる機種依存文字の文字コード変換（EUC-JP→UTF-8）にはまる - WEBプログラミング NOW!
私が作るPHPのサイトは、大概、EUC-JPを内部エンコーディングと設定して作成しています。それで今まで特に困ったことはなかった（自動応答メールなどに「㈱」「髙」などの機種依存文字が含まれていると文字化けすることはありましたが、そのような場合、そのような文字を入力するユーザーの知識不足を問題視していることが実際多かったのですが・・・。）のですが、今回は困りました。 いわゆる機種依存文字（「①」「㈱」「Ⅱ」「㌔」など）をEUC-JPからUTF-8へ変換しようとすると、該当文字が「?」（クエスチョンマーク・はてなマーク）に化けてしまいます。変換不能状態です。我ながら今更ですが、mb_convert_encoding()関数において、「eucJP-win→UTF-8」のようににするとこれらの文字変換はうまくできるようになることが分かりました（＝下記サンプルコードの方法２）。 ただし、「髙」「纊」
『Trac： 検索実行でエラーが出る件を回避する』
実は、TracネタではなくPostgreSQLネタだったり・・・。 何時からか、Trac上で検索を実行してみると、こんなエラーが・・・ ERROR: invalid multibyte character for locale HINT: The server's LC_CTYPE locale is probably incompatible with the database encoding. STATEMENT: SELECT DISTINCT a.summary,a.description,a.reporter, a.keywords,a.id,a.time,a.status FROM ticket a LEFT JOIN ticket_change b ON a.id = b.ticket WHERE (b.field='comment' AND (b.newvalue ILI
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Unicode 6.0」が策定、絵文字が国際標準に
Unicode/UTF-8-character table - starting from code position 3200
