Shift_JIS文化からUTF-8への移行ガイド - Qiita
まだまだ場所によってはShift_JIS文化は根強く、2015年が終わろうとしている現在でも、「ようやく我が社もUnicodeでシステムを作ることを考えるっ！」なんてところは多くあるかと思います。 そんな現場で、これまでJavaでShift_JISでシステム構築してきたSIer向けのUTF-8移行ガイドです。 文字長のチェック 文字長の入力チェックはShift_JISの世界では、半角文字は1バイト、全角文字は2バイトなので、以下のようなチェックロジックになっていたかと思います。 if (inputValue.getBytes("Windows-31j").length > 20) { errors.add("hoge", new ActionMessage("errors.maxlength", "ほげ", 10)); } UTF-8ではそれらの文字は、1バイト～3バイトで表されるので、バ
UTF-8小話 - Plan9日記
UTF-8はWikipediaに書かれている通り、 当初は、Plan 9で用いるエンコードとしてベル研究所で考案された。 ものだけど、最近古本屋で見つけた「インターネットヒストリー」の村井純先生のあとがきに気になる記述があった。 ちょっと長くなるけど引用する。 かなり昔の話だが、ベル研のUNIXを作ったオペレーティングシステムを担当していたグループにオペレーティングシステムについての講演を頼まれたときに「日本語」の話をしたことがある。正直にいうと、ケン・トンプソンやデニスリッチなど、コンピュータ界のノーベル賞といわれるチューリング賞をとった錚々たるメンバーを前にして、当時「ただの研究者」であった自分がオペレーティングシステムについて何を話したらよいのだろうと悩んでしまった。結局開き直って話すことにしたのが漢字の問題だったわけだ。しかし、このときの講演の内容が、彼らにとっては1バイト1文字と
Windows GVimのメニューが文字化けした場合の解決方法
このドキュメントの内容は、以下の通りです。 はじめに 原因 対処方法 はじめに 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全角カタカナでマッチ - blog unlearned
UTF-8全角カタカナでマッチさせたい。 バグが出た。。。 ワケわかんなくて 全カタカナキャラクターを書き下した正規表現の文字クラスをつくったんだが、 それってどうなの？って感じですよね。 んで社内にはすごい人がいるので、 irc的なところに質問したら、教えてもらえた！！ そうそう、バグがでるまでは、 euc-jpとかの感覚で [ァ-ヶ] って書けばいいだろうとおもっていたのだが、 Unicode対応 文字コード表 http://ash.jp/code/unitbl21.htm 上の「Unicode対応 文字コード表」を眺めてみると、、、 UTF-8だと [ァ-タダ-ヶ] だのですね。 あーただーけ って覚えやすいですね。 野村沙知代が野村克也に言いそうですね。 phpのpreg_matchを使うときはu修飾子をつけて /[ァ-ヶ]/u でもいけるようです。 ありがとうございました！！
開発メモ: UTF-8とUCS-4の変換メモ
UTF-8とUCS-4の相互変換をC/C++で書いた時のメモ。たぶんまた自分で読むので。 背景 文字のちょっとした正規化などの処理をしたいがiconvやICUなどの巨大なライブラリは使いたくないということがたまにある。嚴密な文字列処理をしたい場合にはそれらのライブラリを使った方が安全だし確実であることは言うまでもないが、ちょっとしたユーティリティを作るのにはちょっとオーバースペックである。 一方で、UTF-8文字列に対してはASCII用正規表現ライブラリを使えば検索や置換などの大抵の操作ができるので、自分でゴリゴリと変換処理を書かなければいけないことはあんまりない。 ただ、たまに自分で書きたくなることもある。ヨーロッパ系言語のアクセント記号を外したり、半角片仮名を全角片仮名にしたり、漢字の異体字表記を常用漢字に統一したりといった処理を一気にやりたい場合とか。そんな場合、各文字が可変長バイト
https://support.microsoft.com/ja-jp/help/943922
すべて 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の"UTF-8"にご用心 - yanok.net
拙著『プログラマのための文字コード技術入門』にも一言だけ書いたのですが、オープンソースのデータベース管理システムとして有名な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
UTF-8ならばXML宣言は入れなくてもいい: 世界中の１％の人々へ
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宣言を惰性で入れてきたのですが、昨年７月から明確な理由がなければXML宣言をいれなくなりました。 IE6の後方互換対策ができないわけでもないし、XML宣言を知らないから入れないわけでもありません。入れない理由は以下によります。 ルールの正当性：W3C勧告に条件を満たせば省略してよいと明記してある 物理的理由：ブラウザはDOCTYPE スイッチを読みHTMLの種類を判別する 作業の合理性：IE6の後方互換対策をする必要がないから 何人かの国内のHTMLの権威の人たちに確認したら例外なく「不要」と。 以下で、少
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://blogs.oracle.com/katakai/entry/netbeans_and_java_for_mac2
windowsのコマンドプロンプトでUTF-8 - connect.to.blog()