Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

UTF-8はWikipediaに書かれている通り、 当初は、Plan 9で用いるエンコードとしてベル研究所で考案された。 ものだけど、最近古本屋で見つけた「インターネットヒストリー」の村井純先生のあとがきに気になる記述があった。 ちょっと長くなるけど引用する。 かなり昔の話だが、ベル研のUNIXを作ったオペレーティングシステムを担当していたグループにオペレーティングシステムについての講演を頼まれたときに「日本語」の話をしたことがある。正直にいうと、ケン・トンプソンやデニスリッチなど、コンピュータ界のノーベル賞といわれるチューリング賞をとった錚々たるメンバーを前にして、当時「ただの研究者」であった自分がオペレーティングシステムについて何を話したらよいのだろうと悩んでしまった。結局開き直って話すことにしたのが漢字の問題だったわけだ。しかし、このときの講演の内容が、彼らにとっては1バイト1文字と
このドキュメントの内容は、以下の通りです。 はじめに 原因 対処方法 はじめに Windows で使っていた GVim のウィンドウのメニューが文字化けしてしまいました。 右クリックしたときに表示されるメニューも文字化けしていました。 はじめは、GVim が壊れてしまったのか、と思ったのですが、どうやら、_vimrc の設定を変更したことによると考えて、調査しました。 原因 encoding の設定を utf-8 にしてしまったのが問題でした。 対処方法 encoding の設定を utf-8 から変更する気がなかったので、別の方法を探しました。 _vimrc ではなく、 _gvimrc に下記の設定を加えて対処しました。 $HOME/_gvimrc source $VIMRUNTIME/delmenu.vim set langmenu=ja_jp.utf-8 source $VIMRUN
UTF-8全角カタカナでマッチさせたい。 バグが出た。。。 ワケわかんなくて 全カタカナキャラクターを書き下した正規表現の文字クラスをつくったんだが、 それってどうなの?って感じですよね。 んで社内にはすごい人がいるので、 irc的なところに質問したら、教えてもらえた!! そうそう、バグがでるまでは、 euc-jpとかの感覚で [ァ-ヶ] って書けばいいだろうとおもっていたのだが、 Unicode対応 文字コード表 http://ash.jp/code/unitbl21.htm 上の「Unicode対応 文字コード表」を眺めてみると、、、 UTF-8だと [ァ-タダ-ヶ] だのですね。 あーただーけ って覚えやすいですね。 野村沙知代が野村克也に言いそうですね。 phpのpreg_matchを使うときはu修飾子をつけて /[ァ-ヶ]/u でもいけるようです。 ありがとうございました!!
UTF-8とUCS-4の相互変換をC/C++で書いた時のメモ。たぶんまた自分で読むので。 背景 文字のちょっとした正規化などの処理をしたいがiconvやICUなどの巨大なライブラリは使いたくないということがたまにある。嚴密な文字列処理をしたい場合にはそれらのライブラリを使った方が安全だし確実であることは言うまでもないが、ちょっとしたユーティリティを作るのにはちょっとオーバースペックである。 一方で、UTF-8文字列に対してはASCII用正規表現ライブラリを使えば検索や置換などの大抵の操作ができるので、自分でゴリゴリと変換処理を書かなければいけないことはあんまりない。 ただ、たまに自分で書きたくなることもある。ヨーロッパ系言語のアクセント記号を外したり、半角片仮名を全角片仮名にしたり、漢字の異体字表記を常用漢字に統一したりといった処理を一気にやりたい場合とか。そんな場合、各文字が可変長バイト
すべて Microsoft 製品 Microsoft 365 Office Windows Surface Xbox セール サポート ソフトウェア Windows アプリ OneDrive Outlook Skype OneNote Microsoft Teams PC とデバイス Xbox を購入する アクセサリ VR & 複合現実 エンタメ Xbox Game Pass Ultimate Xbox Live Gold Xbox とゲーム PC ゲーム Windows ゲーム 映画とテレビ番組 法人向け Microsoft Azure Microsoft Dynamics 365 Microsoft 365 Microsoft Industry データ プラットフォーム Power Platform 法人向けを購入する Developer & IT .NET Visual Studio
拙著『プログラマのための文字コード技術入門』にも一言だけ書いたのですが、オープンソースのデータベース管理システムとして有名なMySQLのバージョン5.0とか5.1とかは、UTF-8として3バイトまでしか対応していません。 これは今どき考えられないくらい古い仕様です。3バイトのUTF-8というのは、Unicodeの基本多言語面(BMP) という、16ビット固定で世界中の文字を符号化するんだと(誤って)言い張っていた、古き良き時代のUnicodeの範囲しか扱えません。 MySQLの5.5.3というバージョンではようやく4バイトのUTF-8への対応が図られたようです。5.5.3の変更点を記したページに記されています。 これを使えば、魚の名前の𩸽(ほっけ、U+29E3D)だとか、偏旁の𧾷(足偏、U+27FB7)だとか、あるいは日本の地名として𣖔木作(ほうのきざく、福島県)の「𣖔」(U+23
2010年3月| 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 明確な理由がなければXML宣言はいれないことにした。 このブログをはじめとして、仕事ではずっと、XML宣言を惰性で入れてきたのですが、昨年7月から明確な理由がなければXML宣言をいれなくなりました。 IE6の後方互換対策ができないわけでもないし、XML宣言を知らないから入れないわけでもありません。入れない理由は以下によります。 ルールの正当性:W3C勧告に条件を満たせば省略してよいと明記してある 物理的理由:ブラウザはDOCTYPE スイッチを読みHTMLの種類を判別する 作業の合理性:IE6の後方互換対策をする必要がないから 何人かの国内のHTMLの権威の人たちに確認したら例外なく「不要」と。 以下で、少
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く