Unicodeとは？ その歴史と進化、開発者向け基礎知識
まず、Unicodeで規定されている文字1つ1つには、最大で21bits（16進数で5～6桁）の数値が割り振られている。この数値をコードポイント（code point： 符号点、符号位置）という。 ちなみに、Unicodeでは、コードポイントの数値で文字を表すための表記として、「U+16進数」という書き方を使う。例えば、「a」であればU+61、「あ」であればU+3042と表記する（以下、文字コードは全て16進数で表記する）。 一方で、この21bitsのコードポイントがそのままテキストファイルに保存されるわけではない。一定のルールでバイト列に符号化することになる。詳細については、後々、Unicodeの歴史を追いつつ説明していくが、おおむね以下の3つを押さえておけばいいだろう（加えてコードポイントがビッグエンディアンで格納されるか、リトルエンディアンで格納されるかも重要になる。が、今回と次回は
「MS ACCESS 95/97 の美しいソート順」の謎に答える - ものがたり(旧)
ええと、以前1度だけここでもリンクしたことがあるのですが、collationの分析まわりでは日本に偉大な先人がいたわけです。ここで説明されていることは、僕が知る限りLCMapStringの動作と矛盾しないので、おそらくAccessに限らずExcelなどでも同様のソーティングが行われるものと思いますが、LCMapStringの動作に深入りすることなくここまで調べ上げられた努力にはもう脱帽せざるを得ません。 さて、この文書の分析で、なお未解決の謎が残っているようなので、僕が勝手に補足してみます。ええ、もう大体のことは分かります。めっちゃ長いのでひさしぶりに「続く」を入れてみましょうか。 で、のっけからなんですが、AccessBasicのレベルで文字比較の推移律が成立しない理由は、僕には分かりません。もしかして、全角ダッシュがマイナス記号と見なされたりしていたりしますかね。だとするとsortke
Windows のコンソール端末と Unicode の相性
MacType が効いている MSYS2 の mintty は、雪だるまと令和合字の字送りの幅が半角扱いなことを除けば、概ね合格です。 サロゲートペアを扱えないのは、マルチバイトの文字コードを扱えない、シングルバイト圏のソフトウェアのような話です。 FontLinkレジストリの FontLink で欧文フォント等に和文フォント結び付けていると、意図しない形で FontLink と異なるフォントになることがあります。メモ帳で先ほど同様に試してみると、次のように。 どうやらコードポイントによって、FontLink のフォントでなく、システムの他のフォントで描画されてしまうようです。 ☃ U+2603 が Segoe UI Emoji𠮟 U+20B9F や 𠮷 U+20BB7 が 游明朝しかも、混入した 游明朝 の文字は、なぜか一回り大きな文字サイズです。標準の Segoe UI や Tah
第7回 Unicodeからの多対一の変換［前編］ | gihyo.jp
文字コードが引き起こすセキュリティ上の問題として、もっとも興味深いもののひとつである、Unicodeから他の文字コードへの「多対一の変換」で引き起こされる問題点について、今回と次回で説明します。 ご存じのとおり、Unicodeには非常に多数の文字が収録されていますが（現在最新版のUnicode 5.1.0では100,713文字が収録されているそうです）、Unicodeから他の文字コードへの変換においては、互換性や可読性の維持のためか、複数のUnicodeの文字が他の文字コードでは単一の文字に変換されることがあります。 この「多対一」の変換が、開発者も想定していなかったような問題を引き起こす原因となることが多々あります。 具体的な例として、Windows上でのUnicodeからの変換について説明します。 Windows上でのUnicodeからShift_JISへの変換 Windows上で
_T("")マクロだのL""マクロだのLPCTSTRだのの世界一詳しい解説
_T("")マクロについて 初心者の方へ 下の説明を読むのが面倒なら次のように設定を変更すれば わずらわしい思いはしなくてもよくなります。 また、下の設定をすればLPCTSTRとか訳の分からないものはconst char *と同じ意味になり、 自分でコードを書く時にも_T("") などと書く必要もなくなります。 VisualStudio2005での設定例（2003や2008でもほとんど同じです）： プロジェクト名で右クリックしてプロパティを選択 （ここでは太文字でcppTestと書いてあるやつ） 左側のツリーで構成プロパティ→全般を選択するとこのようなものが出てくる。 デフォルトでは文字セットのところが『Unicode 文字セットを使用する』となっているはず。 これを『マルチバイト文字セットを使用する』に変更してＯＫを押すと設定完了。 上級者向けの説明 おそらくVisual Studio2
UTF-32/UCS-4 に対応した islower/tolower 関数を作ってみよう - Engine Trouble
今回は、ロケールや処理系、標準ライブラリの実装に依存しない UTF-32/UCS-4 向けの islower/isupper/tolower/toupper 関数を作ります。 C++11 から UTF-32/UCS-4 の文字を格納できる型 char32_t が追加されたので、文字の型は char32_t で指定できるようにします。 また Unicode の文字セットをすべてカバーできるように、 Unicode Character Database を利用してみます。 レターケース (Letter case) 今回は Unicode の文字セットと UTF-32/UCS-4 エンコーディングされた文字を扱います。 アルファベットの中には 大文字 (Uppercase), 小文字 (Lowercase) などの区別ができるものがあります。 例えば A (U+0041) は大文字で、 a (U
漢字のようで漢字でないUnicodeの「康熙部首」と「CJK部首補助」｜TechRacho by BPS株式会社
きっかけ 以下のツイートで「埼玉埼⽟問題」と康煕部首を知りました。 「埼玉」と「埼⽟」の話。unicodedata.normalize('NFKC', '「埼玉」と「埼⽟」') でいけそう https://t.co/kte0sxDvZT — Haruhiko Okumura (@h_okumura) July 11, 2020 康煕部首とは ⼀⼁⼂⼃⼄⼅⼆⼇⼈⼉⼊⼋⼌⼍⼎⼏⼐⼑⼒⼓⼔⼕⼖⼗⼘⼙⼚⼛⼜⼝⼞⼟⼠⼡⼢⼣⼤⼥⼦⼧⼨⼩⼪⼫⼬⼭⼮⼯⼰⼱⼲⼳⼴⼵⼶⼷⼸⼹⼺⼻⼼⼽⼾⼿⽀⽁⽂⽃⽄⽅⽆⽇⽈⽉⽊⽋⽌⽍⽎⽏⽐⽑⽒⽓⽔⽕⽖⽗⽘⽙⽚⽛⽜⽝⽞⽟⽠⽡⽢⽣⽤⽥⽦⽧⽨⽩⽪⽫⽬⽭⽮⽯⽰⽱⽲⽳⽴⽵⽶⽷⽸⽹⽺⽻⽼⽽⽾⽿⾀⾁⾂⾃⾄⾅⾆⾇⾈⾉⾊⾋⾌⾍⾎⾏⾐⾑⾒⾓⾔⾕⾖⾗⾘⾙⾚⾛⾜⾝⾞⾟⾠⾡⾢⾣⾤⾥⾦⾧⾨⾩⾪⾫⾬⾭⾮⾯⾰⾱⾲⾳⾴⾵⾶⾷⾸⾹⾺⾻⾼⾽⾾⾿⿀⿁⿂⿃⿄⿅⿆⿇⿈⿉⿊⿋⿌⿍⿎⿏⿐⿑⿒⿓⿔⿕ KangXi Radica
Windows 10 で生じる文字化け対処法|NECフィールディング
文字化けの原因の一つにロケールと言うものがあります。PCごとに設定されているロケール（システムロケールとも言う）が異なると、文字化けすることがあります。 ロケールとは ロケールとは、そのPCで使用する言語や通貨などを地域ごとに定義する機能です。ロケールが異なるとOSの表示言語が変わるほか、ファイルの保存や読込時に用いるデフォルトの文字コードも変化します。ある文字コードで保存したテキストを異なる文字コードで読み込もうとするも文字化けしてしまいます。 ロケールの修正方法 ロケールの修正は次の手順で実施できます。 「設定」→「地域と言語」→「地域と言語」→「言語」を日本語にする。 日本語以外のテキストを含む場合は適宜言語を変更する。 特殊なケースですが、OSやアプリの用いるフォント名が重複している場合、正しく表示されない場合があります。 原因 Microsoftから報告されている例では次のような
文字列の文字数とバイト数: MFC小技メモ集
※ 注意事項 使用環境は、Windows XP sp3 Visual Studio 2008 sp1 VC++ MFC 使用 文字セットは「Unicode」使用ですが、マルチバイト文字にも対応できます。 文字セットをUnicodeとマルチバイトにした時の、文字列の文字数とバイト数について書きます。 まず、これから書いていくことは、 CString str = _T("123あいう"); // 基本の文字列 int iLength; // 文字数 DWORD dwSize; // 文字サイズ という、文字列を前提に話をしていきます。 この文字列は、見た目で文字数iLengthは"6"ということがわかりますが、これをコードで、 iLength = str.GetLength();と書くと、iLeng
Unicode 対応 - Windows API 入門
Unicode について Unicode (ユニコード) は，世界中のすべての文字を扱うことを目的として作られた，文字コードの規格です。 2014 年現在，約 11 万もの文字が Unicode に収録されています。 Unicode の文字符号化方式には，主に次のようなものがあります。 UTF-8: 1 文字を最小 8 ビット，最大 32 ビットで表現。 UTF-16: 1 文字を最小 16 ビット，最大 32 ビットで表現。 UTF-32: 1 文字を 32 ビットで表現。 Windows では，Win32 世代から Unicode がサポートされています。 Windows が採用している Unicode の文字符号化方式は，UTF-16 です。 ワイド文字 C の文字型には，char 型の他に，wchar_t 型 (ワイド文字) が存在します。 漢字など 1 字を表現するのに複数バイト
Windows と日本語のテキストについて - Windows Blog for Japan
すべての Microsoft 製品 Global Microsoft 365 Teams Copilot Windows Surface Xbox セール 法人向け サポート ソフトウェア Windows アプリ AI OneDrive Outlook Skype OneNote Microsoft Teams PC とデバイス Xbox を購入する アクセサリ VR & 複合現実 エンタメ Xbox Game Pass Ultimate Xbox Live Gold Xbox とゲーム PC ゲーム Windows ゲーム 映画とテレビ番組 法人向け Microsoft Cloud Microsoft Security Azure Dynamics 365 一般法人向け Microsoft 365 Microsoft Industry Microsoft Power Platform W
MySQL と寿司ビール問題 - かみぽわーる
MySQL と Unicode Collation Algorithm (UCA) - かみぽわーる に関連するトピックで、 MySQL には寿司ビール問題というのがある。 寿司ビール問題どっかで詳しくお話を聞くべきだよなぁ。。。— RKajiyama (@RKajiyama) March 18, 2015 これはどういう問題かというと、 MySQL の Unicode では binary collation にしてコードポイントで比較しないと🍣と🍺に限らず絵文字が同値判定されるという問題です。 あれ？ MySQL の utf8mb4 charset って、4バイト文字同士を比較すると同じ文字扱いされる？ SELECT '🍣'='🍺' → 1 MySQL的には寿司とビールは同じ扱い。— とみたまさひろ (@tmtms) December 22, 2014 MySQLで select
Swiftでの文字列比較におけるUnicode正規化を巡る注意点 - Qiita
Stringの比較は正規化をかけた上で行われる Swiftの文字列比較は，Unicode正規化をかけた上で行われます。 たとえば，次の例をご覧ください。 let gaC = "\u{304C}" // 「が」の結合形 let gaD = "\u{304B}\u{3099}" // 「が」の分解形 // NSString としての文字数（UTF16での文字数）は異なる (gaC as NSString).length // => 1 (gaD as NSString).length // => 2 // String としての比較 gaC == gaD // => true (!!) これは，こちらのサイトによると， Depending on your requirements, this may or may not be what you want, but it is certainl
Pythonで日本語文字列 (UnicodeとUTF-8, Shift-JIS, EUC-JPなどの相互変換) - プログラミング工場 / Python
2010年05月05日 22:37 カテゴリPython Pythonで日本語文字列 (UnicodeとUTF-8, Shift-JIS, EUC-JPなどの相互変換) Posted by yawamen No Trackbacks Tweet ※2.*系の話です．3.*系は違うので注意． Pythonで日本語を扱う場合，UTF-8やShift-JIS, EUC-JPなどの各種文字コードが使えますが， これらとは別にPythonにはUnicode文字列というものが存在します． ※PythonではUTF-8とUnicodeは別物です． 詳しくはマニュアルを読んで頂くとして，ここではソースコードの書き方やいろいろな変換について紹介します． 【ソースコード中に日本語を書くために】 まず最初に，基本的なこととして，何も考えずにソースコード中に日本語文字を書いてしまうと次のようなエラーが出る場合があ
UnicodeDecodeError/UnicodeEncodeErrorに悩まないPython 2.x プログラミング - atsuoishimoto's diary
最近、ときどきTwitterで「Python」を検索して眺めていたのだが、Pythonの分かりにくいところとして「UnicodeDecodeErrorが出てうざい」という不満をよく見かけるようだ。 確かに、Pythonでは、数字やアルファベット以外のユニコード文字を使おうとすると、対応する処理を書かなければUnicodeEncodeErrorやUnicodeDecodeErrorが出てしまう。Python3では色々改善されているのだが、Python2では分かりにくい点も多い。 このUnicodeDecodeErrorを見て、「Pythonは日本語が苦手だ」と考えてしまう人も多いだろう。確かにそう思ってしまっても仕方がないが、それは正しくない。日本人だけでなく、アメリカ人でもフランス人でもドイツ人でも、ユニコードを使う時はみんな等しく平等にこのエラーを出しているのである。 もちろん、慣れてし
UNICODEプログラムの作り方（入力＆表示編）
まず入力はNT系(NT4.0/2000/XP)だけなら何の苦労もいりません。普通にテキストボックスを作るだけで対応できます。 文字列の取得もGetWindowText()やSendMessage(..., WM_GETTEXT, ...)など、普通のテキスト取得関数で 対応できます。 しかし、表示はまた別でUnicodeフォントが無いNT4.0/2000はちょっと作業しないと自国語以外は化けてしまいます。 では、それ以外（…と言ってもXPしかないですが）はどうかと言うと、なにもインストールせずにUnicodeの表示までできます。 さすが最新ＯＳ！ヽ(￣▽￣)ノ なので、「WindowsXPのみ対応！」でよければこれでお終いなんですが、そんなアプリ作ったところで 誰も使ってくれないでしょう…（；´д⊂） さて、OS自体Unicodeに対応していない9X系(95/98/98SE/ME)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Windows と Unicode とボク
Unicodeコンソーシアムが提供する“最後の手段”フォント「Last Resort Font」／フォールバック指定しておけばフォントに含まれていないグリフを突き止められる【レビュー】
MySQLとUnicode
(削除しました)