とあるシステムでデータベースから引いてきたデータの表示が文字化けするという不具合がありました。 データベース内のデータとしては文字化けしていない状態で格納されていることはわかっていたので、どこかしらの文字変換で化けていることはわかっています。まずはどの誤変換により文字化けするのか原因切り分けのために、decode/encode の組み合わせによる文字化けパターン一覧を作りました。おかげさまでどのパターンに類するものか判別することができ、無事に改修することができました。 その話はまた別にするとして、今も昔も変わらず文字化けに悩む人は意外と多いと思います。誤変換結果一覧は原因解析の参考になると思い、記事としてまとめることにしました。 文字コード変換ミスによる文字化けパターンを可視化するプログラムと一覧表 まずは誤変換を生成する perl スクリプトです。プログラムはとっても簡単で、「文字化けで
charcodeに関するshckorのブックマーク (23)
-
shckor 2013/04/19
-
OS X 10.8.2のMail.appで新種の文字化け - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
この項10月5日追記。OS X v10.8.2追加アップデート1.0により、次項以下で言及している本文の文字化けは解消された（ローマ数字の「Ⅴ」が「㈸」に化けるのは仕様なので従来どおり）。アップデート後に受信したメッセージについては、本文・件名ともに化けない。ただし、受信済みのメッセージについては、アップデート後に本文の文字化けは直ったが、件名の文字化けは直らなかった（下図）*1。 OS X 10.8.2のMail.appでは、Windows外字入りのISO-2022-JPを受信すると、メッセージ全体が化けることがある*2。たぶん、下図ピンク地の文字が1つでも含まれていると、メッセージ全体が（まるでソースを表示しているように）化ける。 下図は、Thunderbirdから本文に「ローマ数字のⅤ」「ローマ数字のⅥ」と書いたメールを送信し、OS X 10.8.2のMail.appで受信・表示した
-
Ｓｊｉｓ漢字コード表
====================================================== ＪＩＳでは漢字の始めと終わりに制御コードをつけて１バイト 文字と区分していましたが ＳｉｆｔＪＩＳではキーボードの１バイト文字に使われていない コード「８１～９Ｆ」と「Ｅ０～ＥＦ」を２バイト文字の１桁目 に使い、二桁目は「４０～ＦＣ（７Ｆを除く）」の組み合わせで 決められています。 １桁目のコードが「８１～９Ｆ」と「Ｅ０～ＥＦ」なら続く もう一桁を結合させ漢字に変換し、そうでなければ１バイト文字 として処理します。 そのため漢字の始めと終わりに制御コードが不要になりました。 以下Ｓ－ＪＩＳコード表を作りましたので参考にしてください ====================================================== 先頭に戻る ===============
-
-
異体字データベース
異体字データベースは、各種文献に記載されている異体字・関連字情報を収集・整理したものです。本データの一部は、情報処理学会 試行標準 IPSJ-TS 0008:2007 「大規模漢字集合の異体字構造」に記載されている異体字情報を整理、バグフィックスしたものです。 全ての異体字関係は、「トリプル」形式で表現されます。これは、「漢字A」、「関係」、「漢字B」の３項目をカンマで区切って表現するものです。関係に対してコメント情報がある場合は、さらに４項目目に記述しています。また、「関係１」,"<rev>",「関係２」のトリプルにより、逆関係も定義します。 ファイル名 注記 UCS 互換漢字 compat-variants.txt
-
史料編纂所データベース異体字同定一覧
史料編纂所データベース異体字同定一覧 確認日：2021年7月15日 No.異体字 1 亜 亞 2 唖 啞 瘂 3 悪 惡 4 芦 蘆 5 鯵 鰺 6 圧 壓 7 庵 菴 葊 8 案 桉 9 囲 圍 10 為 爲 11 医 醫 12 育 毓 13 一 弌 14 壱 壹 15 稲 稻 16 因 囙 17 姻 婣 18 飲 飮 19 淫 婬 滛 20 隠 隱 21 陰 阴 隂 22 卯 夘 23 丑 丒 24 嘘 噓 25 欝 鬱 26 厩 廐 廏 廄 27 叡 睿 28 営 營 29 映 暎 30 曳 曵 31 栄 榮 32 穎 頴 33 英 偀 34 衛 衞 35 詠 咏 36 駅 驛 37 円 圓 圎 38 堰 椻 39 焔 焰 40 煙 烟 41 縁 緣 42 艶 艷 豔 豓 43 鉛 鈆 44 塩 鹽 45 汚 汙 46 奥 奧 47 往 徃 48 応 應 49 横 橫 50 欧 歐
-
-
JIS X 0208と0213と機種依存文字
Windows-31J(JIS X 0208 + α) の機種依存文字は13区、89-92区、115-119区の３つの部分です。 このうち13区は、ほぼそのまま JIS X 0213 に取り込まれたので JIS X 0213 準拠であれば機種依存でなくなりました。 89-92区のNEC選定IBM拡張文字の漢字は JIS X 0213 では別の文字が登録されています。つまり Windows-31Jで書かれた文書を JIS X 0213 として扱うとこの部分は別の文字に替わってしまいます。しかしこの部分は115-119区IBM拡張文字の漢字を重複して登録したもので、Windowsでもかなり前からデータを保存し直す時には115-119区のコードに書き換えられていましたので、この問題はあまり起こらないでしょう。 115-119区はShift_JISにした時の第一バイトが0xFA-0xFCと最後の部
-
-
-
Unicode�$BBP1~�(B �$BJ8;z%3!<%II=�(B
�$B!!�(BUnicode�$BBP1~$N�(BJIS�$BBhFs?e=`4A;z$NJ8;z%3!<%II=$G$9!#�(B �$B!!%V%i%&%6$r;H$C$F!"J8;z$dJ8;z%3!<%I$r8!:w$7$FC5$9$3$H$,$G$-$^$9!#�(B Unicode�$BBP1~$K$D$$$F�(B �$B!!�(BUnicode�$B$KBP1~$7$F!"6hE@HV9f!"�(BJIS�$B%3!<%I!"%7%U%H�(BJIS�$B%3!<%I!"�(BEUC�$B%3!<%I!"�(BUnicode(UTF-8, UTF-16)�$B$NBP1~I=$r:n@.$7$F$_$^$7$?!#�(B �$B!!�(BUTF-16�$B$O!"�(BUTF-16BE�$B!J%S%C%0%(%s%G%#%"%s!K$GI=<($7$^$9!#�(B
-
株式会社ネクシィーズ（Nexyz.）
初期投資ゼロのレンタルサービスネクシィーズ・ゼロシリーズ ネクシィーズ・ゼロシリーズは、一括では購入しにくい厨房機器や、 リプレイスが難しい照明・空調などの業務用設備を、初期費用をかけずに導入できるサービスです。 リスクなく最新の省エネ設備を導入いただけます。
-
山﨑髙島問題 - マイノート
山﨑髙島問題とは、コード変換によって、 髙島が→？島 山﨑が→山？ と表示されるなどの問題である。(勝手に定義) そして、コード変換によって文字が正しく表示されることを確認するテストを 山﨑髙島テストと呼び、リリース前に実施しよう。 それぞれの文字の俗称 髙・・・はしごだか 﨑・・・たつさき [文字化けが発生するケース] ■■システムの構成■■ ブラウザ(charset=euc-jp) ↓write ↑read Oracle(NLS_LANG=Japanese_Japan.JA16EUC) ↓read ↑write Windowsアプリ(CP932？) Windowsアプリが、Oracleに書き込んだデータをブラウザで参照したときに、文字化けが発生しています。 ブラウザ, Oracle間では、髙の読み書きは正常だったので、OracleとWindowsアプリの間で正しくコード変換がされて
-
第33回 enc2xs：標準の文字コード表にはない文字を変換する | gihyo.jp
Encodeを使っても文字化けするとき Encodeは特定のエンコーディングにしたがって配列されたバイナリを「文字列」に置き換えるためのモジュールですが、かならずしもすべてのエンコーディングがあらゆるバイナリの組み合わせに対応しているわけではありません。 たとえば、「シフトJIS」環境における機種依存文字の例としてよく取り上げられる丸付き数字をEncodeのお作法通りにdecode、encodeする場合、「シフトJIS」だからと思って安易にshiftjis系列のエンコーディングでdecodeしてしまうと、丸付き数字のマッピングデータがないため「?@」のように文字化けを起こしてしまいます。 use strict; use warnings; use Encode; my $binary = pack('C*', 0x87, 0x40); # ①; my $string = decode(
-
文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2010年9月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPカンファレンス2010にて「文字コードに起因する脆弱性とその対策」というタイトルで喋らせていただきました。プレゼンテーション資料をPDF形式とslideshare.netで公開しています。 文字コードのセキュリティというと、ややこしいイメージが強くて、スピーカーの前夜祭でも「聴衆の半分は置いてきぼりになるかもね」みたいな話をしていたのですが、意外にも「分かりやすかった」等の好意的な反応をtwitter等でいただき、驚くと共に喜んでいます。土曜にPHPカンファレンスに来られるような方は意識が高いというの
-
文字コードに起因する脆弱性とその対策
4. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • その他 – 1990年にPascalコンパイラをCabezonを開発、オープンソースで公開 「大学時代のPascal演習がCabezonでした」という方にお目にかかること
-
JIS X 0213:2004(JIS2004) で本当に文字化けする文字
とします。Perl で文字コードを操作する方法は、Encode.pm と旧Jcode.pm （0.8系）がメジャーどころなので、その２つについて調査しました。Encode.pm に関しては、Encode::JP と Encode::JIS2K を対象としました。 まず結論から。Encode::JIS2K を使う限り、文字化けする SJIS コードは以下の３５文字です。 JIS2004 で追加された１０文字：879F 889E 9873 989E EAA5 EFF8 EFF9 EFFA EFFB EFFC カ行に半濁音（゜）を付けた文字など一部の文字： 82f5 82f6 82f7 82f8 82f9 8397 8398 8399 839a 839b 839c 839d 839e 83f6 8663 8667 8668 8669 866a 866b 866c 866d 866e 8685 8
-
文字コード変換ツール「nkf」の最新版が公開 | パソコン | マイコミジャーナル
NKFプロジェクトは20日、文字コード変換用コマンドの最新版「nkf 2.0.9」を公開した。UNIX系OS汎用のソースコードは、zlibライセンスのもとオープンソースソフトウェアとして提供される。 2007年7月以来約1年半ぶりとなる今回のリリースでは、新たに「-Z4」オプションを追加。JIS X 0208 カタカナ (全角カタカナ) をJIS X 0201 カタカナ (半角カタカナ) に変換することが可能になった。「-g」オプションを利用し、改行コードを推測する機能も実装されている。 全角カナを半角カナに変換できるnkfの最新版が公開された
-
404 Blog Not Found:ajax - 文字化け判定表
2007年04月14日01:20 カテゴリLightweight Languages ajax - 文字化け判定表 「誰か」という時にhyukiさんの視線を感じたのは気のせいかしらん。 結城浩のはてな日記 以下のような「文字化け判定表」があるといいなあと思って作り始めましたが、飽きちゃいました（←おい）。誰か作って…。というわけで、そっこーで作ったのが以下。 を で表示 漢字、カタカナ、ひらがなの入ったquery。 これはUTF-8で書かれたテスト 文字化けを解決することは 鯖側のソースはこちら倉側はお使いのブラウザーで「ソースを見て」下さい。 Enjoy! Dan the Man with too Many Mojibake to Fix See Also: 文字化けクイズ(解答編) - 西尾泰和のはてなダイアリー 「Lightweight Languages」カテゴリの最新記事
-
UTF-8 エンコーディングの危険性 - WebOS Goodies
基本的に、まともな国際化ライブラリを使っていれば、上記のような不正な文字コードはきちんと処理してくれるはずです。実際、 Opera, Firefox, IE ともに適切にエスケープしてくれました。また、 UCS に変換した後にエスケープ処理を行うことでも対処できるかもしれません。しかし、複数のモジュールで構成されるような規模の大きいアプリケーションでは、そのすべてが適切な処理を行っていると保証するのも、なかなか難しいかと思います。ここはやはり、すべての外部入力に含まれる不正なシーケンスを、水際で正規化するという処理を徹底するのが一番かと思います。 例えば Ruby の場合、不正な UTF-8 コードを検出する最も簡単な方法は、 String#unpack を使って UCS へ変換してみることです（昨日の記事への kazutanaka さんからのはてぶコメントにて、 iconv でも同様なこ
Blogger
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2024 Hatena. All Rights Reserved.
設定を変更しました