2009年08月07日15:00 カテゴリCode Unicode - JISマークは一文字! 私もびっくりしたのですが、事実です。 まずは以下をご覧下さい。 〄は一文字です(U+3004)。 フォントまわりをカスタマイズしていないIEでも表示を確認できました。UbuntuのFirefoxでは空白でしたが。 なぜ気がついたかと言えば、unicode@unicode.org にこんな書き込みが登場したからです。 At http://en.wikipedia.org/wiki/Japanese_Industrial_Standards, a new symbol for JIS is shown and discussed. Will there be a new character in the Standard? (Not a new glyph in the same codepoint
思うに、私が最初のOSに不自由なWindowsを選んだのは正解だったかもしれない。すくなくとも、Win32 APIはPOSIXよりはるかに使いやすい。 問題はiconvだ。一体どこの糞が何をキメながら設計したらこうなったんだ。狂っているにも程がある。 size_t iconv (iconv_t cd, const char ** inbuf, size_t * inbytesleft, char ** outbuf, size_t * outbytesleft) ; ポインターのポインターであるには理由がある。iconvは、すべて書き換えるからだ。ポインターを書き換えるのでポインターへのポインターを要求する。当然だ。当然であって欲しくないが当然だ。 なんでそんなに馬鹿げた副作用を持ち込むんだ。それでは必ずlvalueを渡さなければならないし、大抵の場合、もとの値を保持しておきたいから、オブ
一ヶ月ほど前の話。Mac OS X を使っている人から Skype で送られてきた Excel ファイルが WinMerge でうまく開けなくて。「xdoc2txt が .xlsx に対応してない?いやそんなはずは・・・」とかいろいろ調べてて、ふと思い立って dir すると こんな感じと。今まで仕事で Mac OS X を使っている人には出会ったことがなかったので、「これが噂の濁点問題かー」とちょっと嬉しくなって、このファイルをいじりまわして遊んだのでそのお話。 簡単に現象&用語を説明 詳しいことは Unicode正規化 紹介マニアどらふと版: Mac OS X におけるファイル名に関するメモ(NFC, NFD等) あたりを読んでいただくのが確実なんですが、今回問題になった濁点まわりに限定してかいつまんで説明すると・・・。 Unicode で「が」という文字を表したい場合、以下の二種類の表
Firefoxは内部的に変換処理を行うようになっているようです。 問題はSafariとOperaですね。 選択されたファイルのパスからJavaScriptで ファイル名を抜き出してタイトルに設定する部分で、 正しく扱えるような文字コードに変換することにしたいと思います。 基本的な流れとしては、UTF-8-MAC特有の「U+3099」(COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK)、 「U+309A」(COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK)がファイル名に含まれている場合は、 その前の文字と結合して濁音・半濁音の文字にしてあげればいいでしょう (ひらがな・カタカナのみの暫定的な対処に過ぎませんが)。 変換用の文字テーブルを用意して、逐一変換していくかたちにしたいと思います。 というわけ
最近、画像に表示されているように、文字化けがごくまれに起きるようになりました。 この画像はFirefoxを使った時のGoogle検索結果の一部です。 これは「グランドアクシス」という文字が入るようですが、濁音だけうまく表示されていません。 「グランドアクシス」と検索した際の文字表示はすべて問題ないのですが・・。 これは何が起こっているのでしょうか?
昨日のエントリ(「iPhoneのMailから送ったメッセージ全体が文字化け」のまとめ)読みましたよー。iPhoneから送るメールの文字化け防止策は、署名に「♡」を入れておけばOKなんですよね? うん。ただまあ、ちょっと気にする人はいるかもなあ。 男子に誤解されちゃう、と? いや、そういうのじゃなくて、つまり、化けちゃうんだよね。 えっ? 相手の環境によっては「♡」が化けるんだよ。 何ですかそれ。文字化け対策で入れた文字が化けたら意味ないじゃないですか。 意味はあるよ。iPhoneから送ったメールは相手先で全体が化けて読めなくなる可能性があるけど、「♡」でcharset=UTF-8にしておけば、この「全体化け」を防げるんだから。ただし、相手がケータイだったりすると、「♡」自体は「・」とか「?」とかになっちゃうってこと。 自らは捨て石となってメッセージ全体を救うということですか。UTF-8にな
下図は、SoftBank iPhoneのMailが用いるShift_JISのIBM拡張文字領域*1。どうだ、驚いたろう。 SoftBank iPhoneのMailは、charset=Shift_JISをよく使う。髙村薫の「髙」や宮﨑あおいの「﨑」などのWindows外字もShift_JISで送るし、絵文字もShift_JISで送る。しかし、WindowsのIBM拡張文字領域とSoftBankの絵文字領域は、もともと衝突しており、共存できない。なので、SoftBank iPhoneのShift_JISでは、IBM拡張文字のうち下図ピンク部分が使えない。 だったらその分は、NEC選定IBM拡張文字のほうを使えばいいじゃないですか、どうせダブってるんだから(下図)。というのが、大ざっぱに言えば、SoftBank iPhoneのMailが用いるShift_JISである。 その外字領域をまとめると、
これ、Unicodeのコードチャートに載ってる文字なんだけど、何かわかる? イースター島のモアイさんですね。 いや、正解は渋谷のモヤイ像なんだけどね。 そりゃまあ渋谷にもありますけど……。 Unicode Standardには、ちゃんとこう書いてあるぞ。 イースター島のモアイ像に似た日本の石像 おおー。イースター島のと渋谷のとって、見た目の違いがあるんですか? 実はけっこう違うよ。いちばんのポイントは、髪の毛だな。イースター島のモアイ像には長い髪なんてないでしょ。ほら、こんなかんじ。 ああ、これこれ。言われてみれば、こっちが本家モアイ像ですね。 ところが実はこれ、Appleの絵文字フォントで表示したU+1F5FF MOYAIなんで、理屈の上では渋谷のモヤイ像のはずなんだよね。 え? でも、絵としては、明らかに本家モアイ像ですよね。Appleのデザイナーさんも「モヤイ像って単なるモアイ像のコ
「漢字1文字は2バイト」という常識が、大きく変わろうとしている。現在改正中の「常用漢字表」に対応するためには、Unicodeの4バイト文字を使用する必要があるが、それだけでは済まない恐れがある。今後、戸籍や住民基本台帳で使われている文字がUnicodeに追加されると、漢字1文字が最大8バイトになるかもしれない。文字コードに詳しい京都大学人文科学研究所附属東アジア人文情報学研究センターの安岡孝一准教授が、問題の核心を解説する。(日経コンピュータ) 先日公開した『新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能』の読者から、「今後のシステムでは漢字1文字を最大4バイトで処理すればいいのか」という質問を頂いた。実は、UTF-8あるいはUTF-16で漢字を表す場合、最新のUnicodeにおけるIVS(Ideographic Variation Sequence)を考慮すると、漢
カーミット (Kermit) はコンピュータファイル転送プロトコルおよび通信ソフトウェアの名称である。カーミットはファイル転送、端末エミュレータ、スクリプト言語プログラミング、および異なるハードウェアやオペレーティングシステム間での文字コード変換の機能を提供する。 カーミットプロトコルは、全二重および半二重/8ビットおよび7ビットのシリアル通信の上で、システム/媒体の非依存の形式で、テキストファイルとバイナリファイルの転送の機能を提供し、数百の異なるコンピュータ/オペレーティングシステムの上に実装されている。全二重通信を使用した場合、スライディングウィンドウプロトコルによる選択的な再送が使用され、優れた性能とエラー回復を実現する。コロンビア大学のカーミットソフトを適切に実装すれば、ZMODEM、YMODEM、XMODEMのようなほかのプロトコルと同等か、より優れた性能を実現することができる
家内ネットワークのファイル/IMAPサーバとして使いはじめたDebian GNU/Linux 4.0の日本語環境はデフォルトがUTF-8みたいです。 xxx@julie:~$ echo $LANG ja_JP.UTF-8 ついにうちにもUTF-8の環境が出来てしまったみたいです。 で、EUC-JPのVine Linux 4.1からtelnetでDebian GNU/Linux 4.0にアクセスした際に文字化けする現象が発生していました。 (後述しますが、私の設定の問題です。) 次のような文字化けの現象が発生していました。 ・KDEのKonsole(以下Konsole)の「設定」ー「エンコーディング」をutf8にしても文字化けが解消されない ・GNU Screen(以下screen)を使用していない状態でKDEのKonsoleの「設定」ー「エンコーディング」をutf8に変更すると文字化けしな
etchのときはデフォルトのlocaleをEUC-JPで運用していたのだが,lennyにアップグレードしたらmanの日本語表示が文字化けしたりしたので,UTF-8に変更した. とりあえず,コマンドの実行結果やlessで日本語を表示できるレベルにしたときの手順メモ. システム標準のロケールを変更する .dpkg-reconfigure localesと実行してUTF-8のロケールを生成して,デフォルトに設定する. # dpkg-reconfigure locales ja_JP.UTF-8のロケールがすでに生成されていれば,update-localeするだけでもいいかもしれない. # update-locale LANG=ja_JP.UTF-8 .cshrcを書き換える.EUC-JP用の設定をしていたのをUTF-8用にする. 設定前は, setenv LANG ja_JP.eucJP set
_ [Ubuntu][Arch] Dropboxと日本語ファイル名 Dropbox、便利だなぁと思いながら使っているが、導入時に書いたように名前に日本語を含むファイルは無視されていた。 ところが、Ubuntu8.10 で dropbox - kameidの日記に ちなみに、日本語ファイル名も全然問題ない。 と書かれている。 あれ?と思いながら、名前に日本語を含むファイルを~/Dropboxに置いてもやっぱり無視される。 ふと思い立ち、電源ONで走るようになっていたdropboxdを一端終了させ、X下の端末から % ~/.dropbox-dist/dropboxd & を実行して、~/Dropboxに名前に日本語を含むファイルを置いてみると、何やらアップしている模様。 Webで確認してみるとちゃんと同期されている。 何が違うのかと考えてみたが、X下であることを除くと思いつくのはlocale
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く