日本語や中国語などの一部の言語は巨大な文字セットを扱います。 これらの言語に対応するために Microsoft Foundation Class ライブラリ (MFC) では巨大な文字セットを処理する 2 つの機能が用意されています。 Unicode、 wchar_t ベースのワイド文字、および UTF-16 としてエンコードされた文字列。 マルチバイト文字セット (MBCS)は、ロケール固有の文字セットでエンコードされた char ベースのシングルまたはダブルバイトの文字および文字列です。 Note Microsoft では、すべての新しい開発に MFC Unicode ライブラリを使用することをお勧めします。 MBCS ライブラリは、Visual Studio 2013 および Visual Studio 2015 で非推奨になりました。 この点は変更されました。 Visual Stu
いつまでたってもエンジニアを悩ませる問題として「文字コード」があります。 その中でも質が悪いのが Microsoft ページコード 932 いわゆる Windows-31J だと思います。 Unicode がだいぶ普及したとは言え、まだまだ根深い問題です。 本稿では Shift_JIS と Windows-31J の違いについてまとめてみたいと思います。 とは言え筆者自身、Shift_JIS や Windows-31J などが誕生した当時にリアルタイムで歴史を見てきた人間ではありませんので、あくまで Wikipedia をベースに筆者なりにまとめたという点をご了承ください。 (誤りがあった場合にはご指摘頂ければ幸いです) Shift_JIS (CP932) の誕生 Shift_JISは、漢字を含む日本語を表現できる文字コードとして1982年に誕生しました。 Shift_JIS はマイクロソ
Python 2 に比べるとずっと楽になったものの、環境によっては Python 3 で予期せぬ UnicodeError に遭遇することがあります。 Python 3.6 時点での、 Python の各種エンコーディングの扱いを整理してみます。 Python のエンコーディング filesystem encoding (sys.getfilesystemencoding()) 主にファイルパスに使うエンコーディングですが、コマンドライン引数にも使われます。 (そうでないとファイルパスをコマンドライン引数に渡したときに困る) また locale が関連するので、実際にはそれ以外にも glibc とかと連携するときに使われます。 Python 2 時代の名残りでしょうが、今では filesystem encoding というより system encoding と呼んだほうが実態を表している
こんにちは、hachi8833です。 少し前に、babaさんから「Rubyの内部文字コードはUTF-8じゃないよ」とツッコミがありました。 （追記: 上は会話の途中から切り取りましたのでご了承ください） いきなりの展開にくらくらきましたが、babaさんはさらにたたみかけます。 こうしたことはとっくにご存じの方も多いと思いますが、「Rubyといえば2.0以来UTF-8完全対応なんじゃないの」と勝手に思い込んでた私は脳に掌底を食らったような思いです。ああ、でもこういうことがあるから面白い。 ⚓ プログラミング言語と内部文字コードの関係 まず最初に押さえておきたい点です。プログラミング言語で文字コードに関連する部分は、「文字列」「正規表現」「入出力」「コード中の文字リテラル（""の中など）」「コード中の文字リテラル以外の要素（変数名など）」「ファイル名」などが中心になります。そして文字列に関連し
今日、ミラクルリナックスの吉岡さん主催の 「文字コードヲタクで集まってピザとビールを楽しむ会」に参加してきた。 （うそ、本当はレガシーエンコーディング変換機能の開発オフラインミーティング） ちょっと（だいぶ)遅刻してしまいご迷惑をおかけしてしまったのだが、 いやー、ヲタク同士の極めて濃ゆい会話を堪能させていただいた。 普段リアルで顔を会わせる面子で文字コードで盛り上がるなんて不可能だから こういう集まりは素直にうれしい。 さて、あの場で酒の勢いでいろいろと放言してしまったのだが、 たぶん、今日の酒の量だとほとんどの人は明日には忘れ去られていると思うので 改めてこのブログで意思表明をしたい。 ・ISO2022-JP-MSは撤回してほしい、世の中で求められているのは Outlook Expressが送ってくる拡張ISO2022-JPを受信できることであって それ以外のエンコーディングは必要ない
cles::blog 平常心是道 blogs: cles::blog NP_cles() « dlvr.it でブログのポストを Twitter に流す :: 23日で東北新幹線開業30周年 » 2012/06/03 ISO-2022-JP と CP50220 と Encoding::UndefinedConversionError ruby charset 60 0へぇ Ruby は 1.9 から文字エンコード周りが変更されているので、先月も Encoding::CompatibilityError ではまってしまいましたが、今回は Encoding::UndefinedConversionError というエラーにどっぷりはまってしまいました。メールスプールのファイルを読み込むプログラムが書きたかったのですが、メールが厄介なのはファイルを開いてヘッダを調べてみないと文字コードが判別
MORIYAMA Masayuki moriy****@mirac***** 2006年 3月 23日 (木) 14:53:22 JST 前の記事 [LE-talk-ja 2] オープンソースカンファレンス2006 Tokyo/Spring 次の記事 [LE-talk-ja 4] Re: ISO-2022-JP-MS について 記事の並び順: [ 日付 ] [ スレッド ] [ 件名 ] [ 著者 ] ミラクル・リナックスの森山です。 いろいろと反響があり説明が必要と思われますので、ISO-2022-JP-MS について 説明したいと思います。 まず比較のため、次の5つの文字コードの簡単な定義を示します。 ・x-iso2022jp-cp932 ・CP50220 ・CP50221 ・CP50222 ・ISO-2022-JP-MS これら 5 つは、Unicode 経由で cp932 と相互変
Wanderlustをもう5年以上使っているが、丸数字を含むメールで苦労していた。ローカルのファイルの読み書きは問題ないが、Wanderlust上では送信・受信でうまくいかない。 昔は Content-Type に charset=ISO-2022-JP って書いてありながら、iso-2022-jpの文字集合にない文字を使うようなメールは容赦なく切り捨てていた。添付ファイルの扱いも変だし、そんなうんこメー(ry 時は流れて、今や方眼紙Excelとメールに明け暮れるスーツな毎日。今時メールで丸数字や人名にハシゴ高が使えないメールソフトを使い続けるのは単に痛い人でしかない。というより、FromやToの欄にiso-2022-jp以外の文字集合の人（例えば(株)とか）がいるだけでアウトなので自分が辛い。 もう世間はGmailでUTF-8で本文を送っても問題が無くなり、しかも cp50220 という
Legacy Encoding Project † オープンソースソフトウェアでのレガシーエンコーディング(シフトJIS、日本語EUC、7ビットJISコード)の文字コード変換で生じる問題の解決を目指すプロジェクトです。 本プロジェクトはIPA (情報処理推進機構) の 2005年度下期 オープンソースソフトウェア活用基盤整備事業 で「オープンソースソフトウェアにおける統一したレガシーエンコーディングの変換機能の開発」として採択され支援を受けています。 概要 IPA オープンソースソフトウェア活用基盤整備事業 キャラクタセットの詳細 cp932 cp51932 eucJP-ms ISO-2022-JP-MS 各キャラクタセットの対応関係 ↑
9. 参考) 確かめかた (Windows の場合) • 確かめたい文字をコピーします。 • WordPad を起動し、コピーした文字を貼り付けます。 • 確かめたい文字を一文字選択し、ALT + X を押します。 • コード (UCS-4) が表示されます。 • U+301C が波ダッシュ • U+FF5E が全角チルダ 10. 基礎知識1) チルダとは何か？ • こういうやつらしい。 ÃÕÑ • 鼻音に関する音をあらわす、ダイアクリティカルマークの一種 • ダイアクリティカルマークってこんなやつら (よくしらない) À Á Â Ä Å Ă Ą Ā http://ja.wikipedia.org/wiki/%E3%83%80%E3%82%A4%E3%82%A2%E3%82%AF%E3%83%AA%E3%83 %86%E3%82%A3%E3%82%AB%E3%83%AB%E3%83%9E%
ごあいさつ 皆様はじめまして、文字コードおじさんです。細々とカメラ屋を営んでおりましたが、エンジニアとしての技量を評価され、ALBERTのシステム開発・コンサルティング部で働くことを許されました。特技はサーバーの統廃合です。 今回は最初ということですが、Unicodeにおける全角・半角の取り扱いについて触れてみようと思います。なお、さも連載するかのように第1話と銘打っていますが、上層部の無慈悲な裁決によっては1話打ち切りもありえますので、その際はご容赦ください。 固定観念を捨てよう 「全角50文字、半角100文字まで」といったような文言を見かけたことがあると思います。 特にUnicode以前のレガシーな処理系では全角文字に2バイト、それ以外は1バイトという割り当てが慣習となっていました。 このため、「全角=2バイト文字、半角=1バイト文字」という観念が世間に定着しているのが現状です。 しか
XMLやCSV等のデータをJavaで色々加工して出力したりといったことをしてると必ずハマるのが波線などの文字化け問題です。 文字化けが発覚するたびにググって場当たり的な対処を繰り返すのに疲れたのでよく問題になる文字と形が似た文字をリストアップして、更にそれをJavaで各種エンコーディングに変換したらどの文字になるかを頑張って纏めました。 ついでに文字化けしないよう上手いこと出力可能な文字に置換する関数も作ってみました。 Javaの変換テーブル 表中の U,S,W,E,J はそれぞれ、UTF-8、Shift_JIS、Windows-31J、EUC-JP、ISO-2022-JP で出力した際の文字です。 見た目で分からないくらい似た文字ばかりなので、各セルにマウスカーソルを乗せたらツールチップで確認できるようtitleにコードポイントを書いておきました。 分かりやすいよう、青は文字化けなし、黄
K.Takata @k_takata 「Unicode文字列型が複数の内部表現をサポート」ってどういうこと？「Python 2系からの移植を容易にするため…Unicodeリテラルシンタックスも復活」これは良い。 http://t.co/LxkUP45x 2012-03-06 21:44:00
入力ソースがシステム環境設定の「キーボード」パネルに表示されない場合や、絵文字、記号、アクセント記号付き文字のビューアを開けない場合は、以下の手順で対処してください。 以下のいずれかの症状が認められる場合は、この記事後半の手順を実行してください。 別の言語で入力できるように入力ソースを追加する際に、一部の言語が入力ソースのリストに表示されない。 システム環境設定の「キーボード」パネルの「メニューバーにキーボードビュアと絵文字ビューアを表示」を選択しても解除されてしまう、選択しても「絵文字と記号を表示」メニュー がメニューバーや「入力」メニューに表示されない。 メニューバーから「編集」>「絵文字と記号」の順に選択しても文字ビューアが開かない。 アクセント記号付きの文字や代用文字がある文字キーを長押ししても、それらの特殊文字が表示されない。 環境設定の「キーボード」で音声入力機能を有効にしても
Leopard以前の「文字パレット」は、Snow Leopard（Mac OS X 10.6）では「文字ビューア」になった。でもファイル名は「CharacterPalette.app」。Mac OS Xにおける「パレット」と「ビューア」の定義の違いって何なのだろう。 Leopardの文字パレットは一般的なアプリケーションのウインドウと同様、Spacesにおいて単一の操作スペースに表示されるため、操作スペースを切り替えると置き去りにされてしまい不便だった。文字ビューアはすべての操作スペースに（同時に）表示される。 文字ビューアでは「説明とコード」と記された検索フィールドが追加された（括弧内追記。いま自宅のLeopardマシンで確認したら、これ、Snow Leopardの新機能じゃないですね。「説明とコード」というテキストが表示される点は新しくて、そのせいで新機能かと早とちりしました。言い換え
自転車やMac・AppleScript、映画・小説やドラマのレビュー、備忘メモ・クイズなどを置いています。 漢字を出せないでいます - 教えて！goo（オリジナルは結局はWindowsでしたが）という質問がありましたので、Mac OS X Leopard で文字コードを指定して漢字（文字）を入力する方法を確認しました。 質問はこんな内容です。人名に使われている漢字を探しています。 「さき」という字ですが、上に「山」続いて下に「大」、「可」となっているのですが見つからないのです。 どなたか出せる方いらっしゃいませんか？ どうぞよろしくお願いします 早速トライしてみました。 目的の文字コードを 調べます 。（今回の目的の漢字はリンク先には見つかりませんでした。結局は『漢字源』で調べました） 今回はユニコード「37E2」でした。 「さき」と読むそうですが、ことえりで「さき」と入力しても変換候補に
Pythonで以下のコードを実行すると、UnicodeEncodeErrorになってしまいます。 u'ﾊﾝｶｸ'.encode('iso-2022-jp') 厳密には、オリジナルiso-2022-jpの文字セットは、半角カナや一部の記号等、他の日本語エンコーディングの文字セットに存在する文字を含みません。ところが実際は、多くのアプリケーションでSJISやEUC-JPとの相互運用を考慮した拡張実装になっています。（MicrosoftがNEC機種依存文字をうんたらかんたら、という昔話はうんざり…いまは、Unicodeのサブセットとして、特定のロケールで使う文字が網羅できているかどうかですよね） 万全を期すなら、使用できない文字をフィルタするべきですが、「とりあえず動く」Pythonicな現実解プログラムを書くための現実解としては、 u'ﾊﾝｶｸ'.encode('iso-2022-jp-ext
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
