XMLやCSV等のデータをJavaで色々加工して出力したりといったことをしてると必ずハマるのが波線などの文字化け問題です。 文字化けが発覚するたびにググって場当たり的な対処を繰り返すのに疲れたのでよく問題になる文字と形が似た文字をリストアップして、更にそれをJavaで各種エンコーディングに変換したらどの文字になるかを頑張って纏めました。 ついでに文字化けしないよう上手いこと出力可能な文字に置換する関数も作ってみました。 Javaの変換テーブル 表中の U,S,W,E,J はそれぞれ、UTF-8、Shift_JIS、Windows-31J、EUC-JP、ISO-2022-JP で出力した際の文字です。 見た目で分からないくらい似た文字ばかりなので、各セルにマウスカーソルを乗せたらツールチップで確認できるようtitleにコードポイントを書いておきました。 分かりやすいよう、青は文字化けなし、黄
という2chのスレがかなり勉強になったのでまとめ。 少しでも有用だと思ったものは載せてあるので結構長いです。 Unicodeのような文字集合(符号化文字集合?)やUTF-8のようなエンコーディング方式に限らず色んな文字コードにまつわる話があります。 たびたび話が繰り替えされますがそれは確認ということで。 (元スレ) 追記:簡単にまとめました。 1 :デフォルトの名無しさん:2007/04/30(月) 20:02:37 ビッグインディアンとかなんとかかんとか 3 :デフォルトの名無しさん:2007/04/30(月) 20:05:48 また、頭の悪そうなスレが・・・ >>1 それは魚とマグロの違いを訊ねるようなもんだ。 4 :デフォルトの名無しさん:2007/04/30(月) 20:06:49 魚と鮪というよりは、魚と刺身の違いのような気がする。 5 :デフォルトの名無しさん:2007/04/
文字コードの標準化について日記を書いたのだが、内容がいまいちだったのでボツにして気を取り直してUnicodeについて一言いっておくことにする。先日、といっても昨年(2008年)の10月なんだけど、その中でちょと文字コードの標準化について話をしている。*1 もう1つ自分の経験としてあるのが、漢字の文字コードがあるんですけど、番号で言うとJIS X 0208とか0212とか規格の番号で皆言うわけなんですけど、実は1988年にその日本語の文字コードの改正の委員会にいたんですね。 その当時、私は 30歳ぐらいなんですけど、「富士通」とか「日立」とか「NEC」の部長さんぐらいの偉い人たちが来てて、私なんか外資系で且つ30前後のぺーぺーだから、全然格下なんですよ。 そういうところで議論の主軸を担ってるのは、「富士通」「日立」「NEC」「日本IBM」「東芝」「沖」、外資でいえば「ユニシス」とかの錚々たる
Unicode Entity Codes for the Tamil Script Return to Tamil Page | Return to the South Asian Page Use these codes if you need to insert a word or short phrase within a multilingual text. Go to the About the Codes section to see how they are implemented. This Page Tamil Vowels Tamil Consonants Tamil Signs (Diacritics/Punctuation) Tamil Symbols and Numbers About the Codes These charts show basic char
2008年10月9日に開催されたBlack Hat Japan 2008で、「趣味と実益の文字コード攻撃」というテーマでネットエージェント株式会社の長谷川陽介氏が発表した。長谷川氏はアプリケーション側の文字コード処理に関するバグを利用したり、文字コードや文字を巧みに操作することで、Webアプリケーションなどに対して攻撃を行うことが可能だと示した。 ●Unicodeへの移行期に起きている混乱 Unicodeは世界で使われる全ての文字を使える文字コードという発想で作られたもので、日本では従来はEUC-JPやShift_JISなどの文字コードが使われていたが、徐々にUnicodeに移行している。その移行期である現在、従来の文字コードとUnicodeとの差違がセキュリティ的な問題を生んでいる。 安全な文字列の確認や危険な文字列の検出といった、文字列を比較して処理するというセキュリティの
Sennaでは、UTF-8の文字列を正規化しています。 たとえば、「?」は「ミリバール」に、「AbRACADAbra」は「abracadabra」に、「ハラヘッタZO」は「ハラヘッタZO」に変換されます。 これで、文字のゆれに対応した検索ができるわけです。 さて、某サービスでWAVE DASH(〜)とFULLWIDTH TILDE(〜)を同一視してほしい、 という要望が届きました。 そういうときはlib/nfkc.cをいじるとよいです。 lib/nfkc.cのいじり方について説明します。このソースコードは自動生成されていますので、直にいじるのはちょっと大変です。 lib/nfkc.c自動生成のためのプログラムは、util/unicode/以下に入っています。 util/unicode/icudump.cに以下のようなパッチを当てれば、FULLWIDTH TILDEを全てWAVE DASHに
といった感じ。ちなみにjava.util.regexとPerlのUnicodeブロックは接頭子Inを使うが、.NETの場合は接頭子Isを使う、という差異があります。 Unicodeスクリプトとブロックの違いがビミョーに見えるけど、ブロックがコードブロックをゴリッと指定したものに対して、スクリプトは特定言語に関係する文字の種類を直接指定するものなのでブロックよりも断定的、って感じで見れば良かなと。ちなみにUnicode関連のドキュメントによるとUnicodeプロパティとスクリプトで日本語の文章を表そうとすると m/(?:(?:\p{Hiragana}|\p{Katakana}|\p{Han}|\p{Latin}|\p{Common}) (?:\p{Inherited}|\p{Me}|\p{Mn})?)+/x; こんな感じになるそうな。実際流通している文章はこれより多様なので現実とは微妙に乖離
2008年05月02日04:00 カテゴリLightweight Languages Unicode - 似た文字同士にご用心 後者はハイフンでなくてマイナス記号でんがな。 [を] UTF-8 の全角ハイフンが Perl の正規表現にマッチしなくて悩んだ で、元のテキストファイルの全角ハイフンを「od -t x1」 で見てみると「ef bc 8d」と「e2 88 92」の2種類が混じっていました。 前者は「\p{Hyphen}」にマッチするのですが後者はダメ。 まあ原因は分かったので、前処理でバイナリ置換して解決しました。 で、紛らわしそうなのを名前のHYPHENとMINUS SIGNでgrepするとこんな感じになる。 egrep '(HYPHEN|MINUS SIGN)' /usr/local/lib/perl5/5.10.0/unicore/Name.pl -002DHYPHEN-MI
DOMを使ってRSSをパースしているとたまに以下のエラーがおきることがあります。(Livedoorブログ、FC2、Amebaブログとかが多い) An invalid XML character (Unicode: 0x14) was found in the element content of the document.Unicode: 0x14の部分は0xbだったりいろいろです。 原因は、絵文字を使っていたり、文字化けしたりといったことによって制御文字が挿入されたためのようです。 ASCIIコードでは0x00〜0x1Fと0x7Fのコード範囲が制御文字になり、これが含まれているXMLはinvalidになるようです。 Javaの場合、RSSをパースする前に以下のようにこの制御文字を削除しました。 str.replaceAll("[\\00-\\x1f\\x7f]", ""); 上記のコード
<< 2007/03/ 1 1. [Ruby] Rubyist Magazine - Rubyist Magazine 0018 号 2. ストレートタイプのスマートフォン「NOKIA E61」レポート 3. ITmedia エンタープライズ:TopCoderで世界と渡り合う日本IBMの異才 - 夷藤勇人 4. My Sleepless Nights in the Big Apple: Apple、サブノート市場へ再参入へ 5. ITmedia Biz.ID:失敗しないプロジェクトマネジメント -- Appleやはてな、Googleに学ぶ3つのヒント 6. 平成19年度「情報大航海プロジェクト(モデルサービスの開発と実証)」に係る委託先の公募について 7. [言語] PyCon 2007 Review 8. [Ruby] deep_science:Re:バザール「オープンソース、そして「R
2004.10.17 新規作成。2004.12.19 加筆。2005.04.02加筆。 最近、コンピュータで扱う文字列の文字コードがUnicodeでなければならない場面が増えてきた。UnicodeとシフトJIS、EUC-JPを変換する機会が多い。この変換は変換表で行うが、変換表が実際的なものでなければ、文字化けが発生することになる。 おかしな変換表は、これまでは、特にLinuxなどの上で動作するオープンソースソフトウェアで多く見られた。おそらく規格原理主義者が多かったためだろう。そもそも、規格どおりに変換表を作ると、実用的な変換表にはならない。しかし、最近ではまともな変換表を実装しているものも増えてきて、うまく選ぶだけでいいようになってきている。 変換表の違いをまとめたページはよく見かけるが、実際にどのような条件を満たして変換するものを選べばいいか不明なので、まとめてみた。 変換表に求めら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く