  |
はてなキーワード: UNICODEとは
やー。面倒でした。
古い情報だと Outlook Express を経由しろと書いてあるので、後継であるらしいWindows Live Mail を経由して（Windows Live Mail からエクスポートする方法で）
Outlook に移行したのだが、どういうわけか宛名が文字列として移行されてしまい、xxx@example.com というメールアドレスの移行ができなかったんです。
で eml → msg もしくは pst 形式への変換ソフトを探すのですが、無料のものが見つからなくてあんまり情報もありませんでした。が、ありましたよ！お兄さん。
====
MAPI data collection and parsing tool. Supports property tag lookup, error translation, smart view processing, rule tables, ACL tables, contents tables, and MAPI<->MIME conversion. MrMAPI currently knows: 3916 property tags 801 dispids 35 types 58 guids 148 errors 27 smart view parsers Usage: MrMAPI -? MrMAPI [-Search] [-Dispids] [-Number] [-Type <type>] <property number>|<property name> MrMAPI -Guids MrMAPI -Error <error> MrMAPI -ParserType <type> -Input <input file> [-Binary] [-Output <output file>] MrMAPI -Flag <flag value> [-Dispids] [-Number] <property number>|<property name> MrMAPI -Rules [-Profile <profile>] [-Folder <folder>] MrMAPI -Acl [-Profile <profile>] [-Folder <folder>] MrMAPI [-Contents | -HiddenContents] [-Profile <profile>] [-Folder <folder>] [-Output <output directory>] [-Subject <subject>] [-MessageClass <message class>] [-MSG] [-List] MrMAPI -ChildFolders [-Profile <profile>] [-Folder <folder>] MrMAPI -XML -Input <path to input file> -Output <path to output file> MrMAPI -FID [fid] [-MID [mid]] [-Profile <profile>] MrMAPI -MAPI | -MIME -Input <path to input file> -Output <path to output file> [-CCSFFlags <conversion flags>] [-RFC822] [-Wrap <Decimal number of characters>] [-Encoding <Decimal number indicating encoding>] [-AddressBook] [-Unicode] [-Charset CodePage CharSetType CharSetApplyType] All switches may be shortened if the intended switch is unambiguous. For example, -T may be used instead of -Type. Help: -? Display expanded help. Property Tag Lookup: -S (or -Search) Perform substring search. With no parameters prints all known properties. -D (or -Dispids) Search dispids. -N (or -Number) Number is in decimal. Ignored for non-numbers. -T (or -Type) Print information on specified type. With no parameters prints list of known types. When combined with -S, restrict output to given type. -G (or -Guids) Display list of known guids. Flag Lookup: -Fl (or -Flag) Look up flags for specified property. May be combined with -D and -N switches, but all flag values must be in hex. Error Parsing: -E (or -Error) Map an error code to its name and vice versa. May be combined with -S and -N switches. Smart View Parsing: -P (or -ParserType) Parser type (number). See list below for supported parsers. -B (or -Binary) Input file is binary. Default is hex encoded text. Rules Table: -R (or -Rules) Output rules table. Profile optional. ACL Table: -A (or -Acl) Output ACL table. Profile optional. Contents Table: -C (or -Contents) Output contents table. May be combined with -H. Profile optional. -H (or -HiddenContents) Output associated contents table. May be combined with -C. Profile optional -Su (or -Subject) Subject of messages to output. -Me (or -MessageClass) Message class of messages to output. -Ms (or -MSG) Output as .MSG instead of XML. -L (or -List) List details to screen and do not output files. Child Folders: -Chi (or -ChildFolders) Display child folders of selected folder. MSG File Properties -X (or -XML) Output properties of an MSG file as XML. MID/FID Lookup -Fi (or -FID) Folder ID (FID) to search for. If -FID is specified without a FID, search/display all folders -Mid (or -MID) Message ID (MID) to search for. If -MID is specified without a MID, display all messages in folders specified by the FID parameter. MAPI <-> MIME Conversion: -Ma (or -MAPI) Convert an EML file to MAPI format (MSG file). -Mi (or -MIME) Convert an MSG file to MIME format (EML file). -I (or -Input) Indicates the input file for conversion, either a MIME-formatted EML file or an MSG file. -O (or -Output) Indicates the output file for the convertion. -Cc (or -CCSFFlags) Indicates specific flags to pass to the converter. Available values (these may be OR'ed together): MIME -> MAPI: CCSF_SMTP: 0x02 CCSF_INCLUDE_BCC: 0x20 CCSF_USE_RTF: 0x80 MAPI -> MIME: CCSF_NOHEADERS: 0x0004 CCSF_USE_TNEF: 0x0010 CCSF_8BITHEADERS: 0x0040 CCSF_PLAIN_TEXT_ONLY: 0x1000 CCSF_NO_MSGID: 0x4000 CCSF_EMBEDDED_MESSAGE: 0x8000 -Rf (or -RFC822) (MAPI->MIME only) Indicates the EML should be generated in RFC822 format. If not present, RFC1521 is used instead. -W (or -Wrap) (MAPI->MIME only) Indicates the maximum number of characters in each line in the generated EML. Default value is 74. A value of 0 indicates no wrapping. -En (or -Encoding) (MAPI->MIME only) Indicates the encoding type to use. Supported values are: 1 - Base64 2 - UUENCODE 3 - Quoted-Printable 4 - 7bit (DEFAULT) 5 - 8bit -Ad (or -AddressBook) Pass MAPI Address Book into converter. Profile optional. -U (or -Unicode) (MIME->MAPI only) The resulting MSG file should be unicode. -Ch (or -Charset) (MIME->MAPI only) Character set - three required parameters: CodePage - common values (others supported) 1252 - CP_USASCII - Indicates the USASCII character set, Windows code page 1252 1200 - CP_UNICODE - Indicates the Unicode character set, Windows code page 1200 50932 - CP_JAUTODETECT - Indicates Japanese auto-detect (50932) 50949 - CP_KAUTODETECT - Indicates Korean auto-detect (50949) 50221 - CP_ISO2022JPESC - Indicates the Internet character set ISO-2022-JP-ESC 50222 - CP_ISO2022JPSIO - Indicates the Internet character set ISO-2022-JP-SIO CharSetType - supported values (see CHARSETTYPE) 0 - CHARSET_BODY 1 - CHARSET_HEADER 2 - CHARSET_WEB CharSetApplyType - supported values (see CSETAPPLYTYPE) 0 - CSET_APPLY_UNTAGGED 1 - CSET_APPLY_ALL 2 - CSET_APPLY_TAG_ALL Universal Options: -I (or -Input) Input file. -O (or -Output) Output file or directory. -F (or -Folder) Folder to scan. Default is Inbox. See list below for supported folders. Folders may also be specified by path: "Top of Information Store\Calendar" Path may be preceeded by entry IDs for special folders using @ notation: "@PR_IPM_SUBTREE_ENTRYID\Calendar" MrMAPI's special folder constants may also be used: "@12\Calendar" "@1" -Pr (or -Profile) Profile for MAPILogonEx. -M (or -MoreProperties) More properties. Tries harder to get stream properties. May take longer. -No (or -NoAddins) No Addins. Don't load any add-ins. -On (or -Online) Online mode. Bypass cached mode. -V (or -Verbose) Verbose. Turn on all debug output. Smart View Parsers: 1 Additional Ren Entry IDs Ex 2 Appointment Recurrence Pattern 3 Conversation Index 4 Entry Id 5 Entry List 6 Extended Folder Flags 7 Extended Rule Condition 8 Flat Entry List 9 Folder User Fields Stream 10 Global Object Id 11 Property 12 Property Definition Stream 13 Recipient Row Stream 14 Recurrence Pattern 15 Report Tag 16 Restriction 17 Rule Condition 18 Search Folder Definition 19 Security Descriptor 20 SID 21 Task Assigners 22 Time Zone 23 Time Zone Definition 24 Web View Persistence Object Stream 25 Nickname Cache 26 Encode Entry ID 27 Decode Entry ID Folders: 1 Calendar 2 Contacts 3 Journal 4 Notes 5 Tasks 6 Reminders 7 Drafts 8 Sent Items 9 Outbox 10 Deleted Items 11 Finder 12 IPM_SUBTREE 13 Inbox 14 Local Freebusy 15 Conflicts 16 Sync Issues 17 Local Failures 18 Server Failures 19 Junk E-mail Examples: MrMAPI PR_DISPLAY_NAME MrMAPI 0x3001001e MrMAPI 3001001e MrMAPI 3001 MrMAPI -n 12289 MrMAPI -t PT_LONG MrMAPI -t 3102 MrMAPI -t MrMAPI -s display MrMAPI -s display -t PT_LONG MrMAPI -t 102 -s display MrMAPI -d dispidReminderTime MrMAPI -d 0x8502 MrMAPI -d -s reminder MrMAPI -d -n 34050 MrMAPI -p 17 -i webview.txt -o parsed.txt
A Beautiful Site (http://abeautifulsite.net/)さんの
jquery.fileTreeを利用させてもらった。
以下、留意点...
パスを指定しないと、もとのhtmlがあるパス(ディレクトリ)にあるものと解釈する。
(/jqueryFileTree.php と指定すると、公開しているルートディレクトリにあるjqueryFileTree.phpを探しにいく)
http://...と指定して他のサーバへ問い合わせるのも可能な模様(だが、試していない)。
root:
d:/
d:/temp/
など
hemlentries -> htmlspecialchars は必須。
http://treatment-head.blogspot.com/2008/11/jquery-file-tree_21.html
ただし、UTF-8やEUC-JPでページを記述している場合は、さらに処理が必要。
windowsでは、mbstringの設定にかかわらず、引数SJIS渡し、戻り値SJIS返しの模様。
したがってUTF-8やEUC-JPでページを記述している場合は、
その点を考慮してconnectorsフォルダにあるjqueryFileTree.phpを書き換える必要がある。
$_POST['dir'] = urldecode($_POST['dir']);
という行があるが(スーパーグローバル変数はデコード済みで、さらにデコードするのは危険とphpマニュアルに記載されている)
どのみちUnicode文字列のURLデコードはこの関数では無理なようなので、phpマニュアルのUserNoteから拝借。
http://php.net/manual/en/function.urldecode.php
こちらにズバリが掲載されているか...と試してみたが、どうも動作がうまくいかなかった
http://ameblo.jp/pushurinko/entry-10287161493.html
他、ご参考
顧客から宛名データを預かって、挨拶状の封筒に印字出力などをする仕事をしていて、
宛名データの中を見ると、住所の番地がたいてい「－（マイナス記号）」で入力されています。
テンキーだけで番地を入力すれば「－（マイナス記号）」になるので当然かと思っていましたし、
更に自分は「－（マイナス記号）」をハイフンだと思ってきていました。
これが「－（マイナス記号）」ではなくて、
「ー（長音符号）」や「―（ダッシュ）」で入力されている、はたまた本当のハイフン「‐」で入力されてくると、
何で「－（マイナス記号）」ではないのだろう？ と。
ついに「－（マイナス記号）」の代わりに「−（Unicodeの数学記号）」で入力されているデータまで見てしまって、
それよりももっと不思議に感じていることがあって、
宛名の会社名・部署名・役職名・個人名に「ー（長音符号）」以外が使われていることです。
ハイフンが使われるべきところでハイフンが使われているなら気にもならないのですが、
例えば『マネージャー』が『マネ―ジャ―』というように、
音引きの部分が、「－（マイナス記号）」や「―（ダッシュ）」や「‐（ハイフン）」で入力されてくると、
Sift-JISやCP932にある全角ローマ数字は日本語圏のローカルな文字コードなので、できれば汎用性の高い文字を使いたい。
そこで半角でIやVを打ちたい所だが、インターナショナルなUnicodeにも全角記号でローマ数字は存在するし、欧米でどうやってこれらが使われているかを詳しく知る必要がある。
コンピュータで文字を打つにしてもディスプレイに映し出したり文書として印刷したり、場合によってはアート目的でフォントをいじる可能性があるので、コンピュータ以外でどの様に使われていたかも留意していないといけないだろう。
思い当たる項目を挙げると、
を考慮に入れておけば「どんな場面でどの様な使い方をすればいいか」的確な判断ができそうだ。
いまや巷で大流行、新聞やテレビでもその名を見かける Twitter ですが、そろそろ Twitter 歴 4 年目に突入する長老たちが増えてきたのではないでしょうか。
大昔は、全角文字と半角文字の間に半角スペースやドットを入れたりしないと日本語が使えなかったり、
GoogleTalk から発言できる IM という機能があったりしましたが、それもすべて昔話。
時代は変わり、 RT やハッシュタグを利用した、昔は想像も出来なかったような Twitter に風変わりしてしまいました。
そんな時代に取り残された長老たちのための Twitter 再入門講座をしたいとおもいます。
Twitter 新参の若者たちは、古参の風習なんて知りません。まして RT を会話に使ってはいけないなんて知らないんです。
だって、あの有名な芸能人だって RT で会話してるでしょ? だから私も RT を使うの。
RT を利用した会話に寛大になりましょう。むしろ、率先して RT を使いましょう。
RT は ReTweet だ? 公式 RT ? そんな人は放っておきましょう、 Block しましょう、それが Twitter です。
古参アカウントをそのまま運用しても良いのですが、ここは気分一新、新しくアカウントを作りましょう。
特に難しく考える必要はありませんが、名前は分かりやすい、読みやすいものが良いですね。
アイコンは、 Twitter 上での顔とも言える重要な部分です。是非ともアニメ系のアイコンは避けておきたいところですが、
特に思い付かないときには好きな食べものの写真とかにしておくと良いでしょう。私はカツレツにしていました。
どちらにするか悩ましいところですが、ここは是非ともパブリックアカウントにしておきましょう。
というのも、後述する「フォロー時の挨拶」がプロテクトアカウントでは出来ないからです。
また、プロテクトアカウントの RT をためらってしまう優しい人もいるので、ここは是非ともパブリックにしておきましょう。
日本語で書いてください。 Tokyo, Japan とかちょっとカッコいいですけど、日本人相手なので、東京って書きましょう。
とーきょー、とかでも良いですね。
ここには間違っても d.hatena.ne..... とか書いてはいけません。はてなとか誰も使いません。
もちろん iddy とかも書いてはダメです。 iddy ? ナニソレ?
オススメはアメーバとか jugem でブログを書いて、そこへの URL を書きましょう。
でも、この講座を受けている皆さんは持っていない方が大半だと思われますから、無いなら書かなくて良いです。
Bio の欄は自己紹介を書きましょう。ここは古参であるとか新参であるとか、あまり気にしないで良いと思います。
自分の興味のある単語をタグクラウド的に繋げていきましょう。でも技術っぽい内容は NG です。
好きな歌手とか、音楽のジャンルとか書いておけばいいでしょう。
「フォローご自由に」と書いてはいけません、ちょっとお爺ちゃんっぽいですよ。ここには「 follow me ♪」と書いておくと若者っぽいです。
さて、フォローをしましょう。長老たちはどうやったか? ついったー部の「フォローご自由に」のページですね。とても重宝しました。
ですが、ここではそんなことはしてはいけません。ハッシュタグを検索します。そう #followmejp から適当にフォローしましょう。
さて、フォローをした後には、どうしたら良いでしょう?
そうです、感謝の気持ちを伝えなければいけません。何事にも礼儀を主んじる日本人らしい行動ですね。
@kohmi フォローさせて頂きました。これから宜しくお願いします〜♪ #followmejp #sougofollow
こういう風に発言できれば完璧です。
これを見て分かるように、ハッシュタグを有効に使うことが大切です。特に #sougofollow を付けている場合は、
相互フォローお願いします、と言ってみるのも良いでしょう。
フォローをして、リフォロー(フォロー返しのことです)されたら、すかさず DM で感謝の気持ちを伝えましょう。
同様に、新しくフォローされた場合には、直ぐにリフォローすることが大切です。
こうやって少しずつフォロワーを育てていきましょう。
皆さんの大嫌いな非公式 RT を使って会話をします。 Reply なんてインテリぶった機能は使いません。
RT の方がみんな見れて良いし、知らない人にも共感してもらえるので、とても良い機能ですよ。是非とも使いましょう。
mixi でやれ
日本人と食事する機会があって、話してたら英語圏への愚痴がおおくて苦笑いした
たしかになぁと思う部分をここに書く
要約すると
英語圏の開発者は、とにかく私的で内輪ネタを好む。そして後先を考えない。
というお話なんだけど
この前、Unix特有の言葉の語源のことをその人も知ってたんだけど
元ネタはウィーザードリーっていう海外発のゲームだと知って苦笑いしてた。
幼稚だなって言ってた。個人ならともかく企業やまとまな開発者がやる事じゃないと。
そのひとが渡米したのは、もともとはソフトウェア開発のためなんだけど
アメリカでの開発で一番困ったのは、その場のことしか考えない開発体制と方針だそうだ
とくに怒ってたのは、ファイル名を入れたり選択したり表示する画面があるんだが
日本の人からすれば、マルチバイト文字の名前もあたりまえのようにあるから、考慮してくれればいいのに
アメリカの開発者達は当たり前のようにASCIIだけにしようとしている
「ローカライズするときにかえればいいよ」と返してきて困ったそうだ
「後でかえるくらいなら、今かえればいいじゃないか」といってもアメリカの開発者は聞かないそうだ。
将来は海外でも発表するソフトなのにマルチバイト圏の分かる人の指示を聞こうとしない
俺に一言聞けばいいのに・・って言ってた。
当然、世界で発売するときにはかなり根っこのプログラムから変えなければいけない事になる。
こんな事が何十回もあったそうだ
web向けフレームワークや Windows なら.NET Frameworkの普及で、UNICODEを意識するようになってこういう事例は少しは減ったらしいが、
企業やグループのイメージに関わるのに、なんでこんな事を平気でするんだって不思議がってた。
欧米人はとくに家庭や身内にたいしてはギチギチにルールを強制するけど
ちょっと外に出たら、こんなにゆるい国はないという
googleストリートビューの問題で、プライバシーの問題が起こったけど
アメリカでは外で平気でキスやセックスしてるくせにプライバシーの侵害とかいうのはおかしいと怒ってた
（日本だからといわず外で性行為は下品だからと禁止だったりするのが普通らしい。
外での行為は異常性愛者で、かりにヤルと、常に監視している近所のおばちゃんが通報して、かなり地域住民の関心事らしい）
ちょっと下のエントリで、少し前のgoogleと絵文字とUnicodeのお話を思い出したのだけど、よく考えてみればUnicodeに全角半角が残ってるってのもなんだかな、って気はするな。しかも、半角ひらがながないし。歴史的経緯っていえばそれまでだが。
つか、現時点でも存在すら知らない文字ってのが多々あるわけで。
⊦(assertion)とかどこの業界？とか├でいいじゃんっていう文字もあるし、✩✪✫✬✭✮✯✰とか正直そんないらないし。①⑴⒈⒜Ⓐ❶➀➊〷㈠㈪㈶㈸㊀㊒㊊㊜㋀㋐と丸文字括弧文字も意外とあるし。㌂㌕はまだしも㌅㌊㍅だし。なぜか㍘から㍰だし、と思ったら時の間違いかよMSゴシック。
そういえばこの前、□にチェックってなんかあったよなと思いつつ線をひっぱった。使わなきゃ意味ないじゃん☑☒✓✔✕✖✗✘
http://d.hatena.ne.jp/mamoruk/20090327/p1
「いちばん」かどうかはわかりませんが、うちの会社の製品ではpythonを主力に使った自然言語処理を含む製品を販売しているので、実際の感想を。
うちでは、pythonを元データの整備のための運用バッチ処理から、客が最終的に手にする情報の生成、実際に客が使うWEBインターフェースまで、pythonを主力にしています。
別のチームが作った別の製品ではS2Struts(JAVAね。)でWEBを作っている部分もありますが。
mecabが使えて、Unicodeが使えて、正規表現が使えれば、まあ、どの言語を使ってもそんなに大差はないのではないでしょうか。
あとはsennaのような日本語用の全文検索エンジンなども使いますが、そこらへんに近い部分は基本的にC++で書きます。
pythonとは言っても、速度を重視する部分はやはり迷わずC++です。
C++で書いたものはswigを使うか、又はC言語で手書きのbindingを使ってpythonに接続します。
でもこないだswigでつないで製品をリリースしたら、WEBからの並列アクセスにswigがうまく対応できず、リリースした日に急いで手書きbindingを書いた経験があります。swigの使い方はきちんと理解していないので非常に難しい。
nltkとか、wordnetの話はたしかに使えそうかもと思ったことはありますが、nltkはうちでは使っていません。
うちの会社では自然言語処理の研究段階から自社で行っているので、nltkにあるようなできあいのルーチンを実戦投入する事はなく、基本的に地味に自分達でpythonで書いています。
自然言語処理と言っても、核心の処理はやはり泥臭い個別事例への対処が多いです。不要語処理とか。
自然言語処理のアルゴリズムは8割程度の精度を出すのは簡単で、すぐに思いつきで書けるものですが、残り2割の精度をいかに埋めて行くかが、頭のいい人とそうでない人の差が現れる部分だと思います。
どうしてもいいアルゴリズムを思いつかない場合は、泥臭い個別事例処理がうねうねと並んだプログラムになります。学術的なものではなく商売になればいいので、うちはとりあえずそれで十分。（これは自然言語処理に使う機械学習のアルゴリズムたちも同様。というか自然言語処理と機械学習て、区分けがあいまいな部分が多いですよね。）
そういう感じなので、pythonの可読性の高さは非常に有効。
また、変数名や関数名などをexplicitに書く文化も業務で使うのに適していると思います。（他の言語でもexplicitに書けばいいだけですが、それを言語開発者自身が推奨するほど強調はしていないですよね。）
英文の処理で、wordnetの辞書データの一部を研究に使った記憶はある。
しかし、あそこまで精緻な辞書データを使う程高度な処理は今の所必要ない。
うちで自作した不要英単語辞書と、特別扱いする英単語辞書で間に合わせていたと思います。（その辺記憶があいまい。）
djangoは非常に明快で、快適。
画面の機能を追加するのに、例えばS2Strutsのアクションの定義の煩雑さに比較すると、天と地との差ほどにdjangoは簡単。
あと、pythonを使える開発者は日本には少ないとの事ですが、うちでもそれは同様です。
しかし、自分の隣の席の同僚はperlに非常に熟達していて、彼はすぐにpythonの達人に変わりました。
優秀な方にとっては言語なんて何をつかってもあまり変わらないみたい。
Sleipnirスレッドでfavicon.icoを取りに行く時にSleipnir/*.*.*をAgentに付けるのを何とかしろ、とか言っている奴が居たので、その解決方法を二つほど。
1.オミトロンを通す
言わずと知れたこの方法。正直これ使えば良いじゃんと。広告とかも表示されなくなるしお勧めなんだけれども。
2.バイナリエディタで頑張る
なんか某所で見かけたような気がするんだけれども、次のような方法があった気がする。
Unicode版：Sleipnir.exeを「55 55 55 55 52」で検索して、52を55に置き換える。 mbcs版：Sleipnir.exeを「53 53 53 53 FF 75 F0」で検索してFF 75 F0を53 90 90に置き換える。
WinXP SP3でSleipnir 2.8.2(Unicode & mbcs)とtest2(Unicode)でそうしてオミトロンで見た感じうまくいっているっぽいので、結構信憑性あり？俺は使わんし知らんがな。
まあ、自己責任って言うことです。
ただそれだけ。
みつを
最近、プログラミング言語があんまし進化していないような気がする。
まあ、確かにフレームワークとかはできたけど、苦労の割にはあんまし便利になっていない。
覚えなきゃいけないことも増えているし。
ところで、面白いプログラミング言語を見つけた。
言語自体はかなりへっぽこ。
（SAPの人、すみません。あくまで私見です）
でも、便利な部分があるのだわ。
SAPが開発した部分って、基本的には変更不可能。
まあ、そりゃそうです。まともに動かなくなったら困るしね。
でも、新しいバージョンではちょっと違う。
もともとあるプログラムの上にレイヤーを重ね、そこにプログラムを書くことができる。
これ、便利だわ。
SAPの方にバグがあったら、SAPのプログラム修正版を上書きする。
その時、レイヤーみたいな形式で俺が上書きしたプログラムは無視される。
なので、俺のプログラムは残ってる。
標準のプログラムの上にレイヤーみたいな感じでプログラムが組めると、こんなに便利だとは思わなかった。
ちょっと考えてみてほしい。
レンタルサーバのさくらインターネットを借りたとしよう。
PC上にXAMPPをインストールして、検証環境にしてみたとする。
さくらインターネットのMySQLはバージョンが古い。
なぜかUnicode限定。
こんな時、SQL分を実行する際、execute系の関数を上書きできたら便利じゃない？
EUCでもUnicodeでも使えるようにするとか、オープンソース上のコードを全部調べるとか。
でも、それめんどう。
こんな時、レイヤーを重ねてexecute系の関数の入り口で文字コード変換できたら・・・・
すっげー楽になる。
