![「慶応」も「コンクリート」も漢字1文字で ~Unicode標準に新しいブロックが提案中/手書きでしばしば用いられる「部首+カナ」スタイルの略式漢字【やじうまの杜】](https://cdn-ak-scissors.b.st-hatena.com/image/square/7bc29a511983b4e30af4c687a5da949c711a1e03/height=288;version=1;width=512/https%3A%2F%2Fforest.watch.impress.co.jp%2Fimg%2Fwf%2Flist%2F1597%2F030%2Fimage1.png)
まえがき ミャンマーでは公用語としてビルマ語が使われている。ビルマ語の表記にはビルマ文字を用いるのだが、このビルマ文字のインターネット上での使用は、混迷を極めていた。そしておそらく今もまだ…。なぜか? それは、Unicodeという文字コードの標準がありながら、Zawgyiというものが広く使われていたためである。なぜそのようなものが登場し、普及することとなったのか、この記事で解説する。 目次 まえがき 目次 凡例 この記事で使う名称について ビルマ語表記 コードポイント ラテン文字表記について Zawgyiの概説と歴史 Zawgyiとは Zawgyiのダウンロード Zawgyi誕生・普及の経緯 複雑なビルマ文字 ビルマ文字とUnicode 回避策としてのビルマ文字フォントの登場 Zawgyiの普及 Zawgyiの実装 実装の方針 文字の並べ替えをせず、左から右に書く 文字の形のバリエーション
A static site to link people to when their code is displaying Japanese wrong. View the Project on GitHub heistak/your-code-displays-japanese-wrong Why am I here? If someone gave you a link to this page, that person probably thinks your code displays Japanese wrong. In short, from a native Japanese eye, yѳur ҭєxҭ lѳѳκs κιnd ѳf lικє ҭЋιs. This page will give you a brief description of the glyph appe
かつてWindowsでテキストファイルといえばシフトJIS形式のものが大半だった。しかし最近では、UTF-8形式のテキストファイルも普通に見かけるようになってきた。世の中はUTF-8が主流になりつつあると言っていいだろう。 しかし、WindowsでUTF-8を使うと、ちょっと困ったことがある。それは、エクスプローラーの検索欄などで用いるWindows Searchが、UTF-8にはしっかり対応していないのである。正確に言うと、Windows Searchはファイル先頭に「BOM」のあるUTF-8は認識して正確にインデックス化し、ファイルの全文検索が可能になるが、BOMのないUTF-8では正しくインデックス化できず、ファイルの全文検索はASCIIコードのみ可能で、日本語などの非ASCII文字では全文検索ができない。 同じ内容のテキストをUTF-8、UTF-8 BOM付き、UTF-16ビッグエ
美乳テーブルとは 「美乳テーブル」という物がある。 「EUC-JP の文章を Shift_JIS だと誤認識されない様に、EUC-JP 固有のバイト値を文章先頭付近に埋め込んでおく」という物。 具体的に、Shift_JIS には 0xFD と 0xFE が現れず、EUC-JP にはそれが現れるので、その値を含む文字コードを書いておこうという事で、その文字の集合に付いた名前。 “美” = 0xC8FE、“乳” = 0xC6FD。 各文字エンコーディングの事情 但し、これは EUC-JP での話。 一応、文章の先頭付近に日本語の文字を書いておくのは、他の文字エンコーディングでも認識のヒントにはなるけど。 逆に「Shift_JIS の文章を EUC-JP だと誤認識されない様にする」には、EUC-JP にはないバイト値の 0x80〜0xA0 を書けばいいんだろうけど、これは沢山ありそうだから、慎
きっかけ 以下のツイートで「埼玉埼⽟問題」と康煕部首を知りました。 「埼玉」と「埼⽟」の話。unicodedata.normalize('NFKC', '「埼玉」と「埼⽟」') でいけそう https://t.co/kte0sxDvZT — Haruhiko Okumura (@h_okumura) July 11, 2020 康煕部首とは ⼀⼁⼂⼃⼄⼅⼆⼇⼈⼉⼊⼋⼌⼍⼎⼏⼐⼑⼒⼓⼔⼕⼖⼗⼘⼙⼚⼛⼜⼝⼞⼟⼠⼡⼢⼣⼤⼥⼦⼧⼨⼩⼪⼫⼬⼭⼮⼯⼰⼱⼲⼳⼴⼵⼶⼷⼸⼹⼺⼻⼼⼽⼾⼿⽀⽁⽂⽃⽄⽅⽆⽇⽈⽉⽊⽋⽌⽍⽎⽏⽐⽑⽒⽓⽔⽕⽖⽗⽘⽙⽚⽛⽜⽝⽞⽟⽠⽡⽢⽣⽤⽥⽦⽧⽨⽩⽪⽫⽬⽭⽮⽯⽰⽱⽲⽳⽴⽵⽶⽷⽸⽹⽺⽻⽼⽽⽾⽿⾀⾁⾂⾃⾄⾅⾆⾇⾈⾉⾊⾋⾌⾍⾎⾏⾐⾑⾒⾓⾔⾕⾖⾗⾘⾙⾚⾛⾜⾝⾞⾟⾠⾡⾢⾣⾤⾥⾦⾧⾨⾩⾪⾫⾬⾭⾮⾯⾰⾱⾲⾳⾴⾵⾶⾷⾸⾹⾺⾻⾼⾽⾾⾿⿀⿁⿂⿃⿄⿅⿆⿇⿈⿉⿊⿋⿌⿍⿎⿏⿐⿑⿒⿓⿔⿕ KangXi Radica
gistfile1.md PDF に謎の漢字が含まれるとき PDF などの中にある一部の日本語の漢字が、見た目は同じだけど異なる謎の文字に変換されていることがある 例 1: https://www.mhlw.go.jp/content/10906000/000628667.pdf 「長野」と「長崎」の「長」が、 U+9577 ではなく「⾧ (U+2FA7)」になっている 例 2: https://www.dpri.kyoto-u.ac.jp/news/12739/ 大量にある、どうしてこうなった PDF ではないので何かからコピーして書いた? この文字は 康煕部首 (Kangxi Radicals) というもので、部首としての文字である MS ゴシックなど Kangxi Radicals の字形がないフォントを指定すると表示できないので区別しやすい どこから来たのか? これらは(フォントに
中国語の文字コードについての解説ページです。 日本語の文字コードについては、文字コードについてを参照してください。中国語についてのページもあります。 中国語の文字コードの種類 中国語には、繁体字(Traditional Chinese)と、簡体字(Simplified Chinese)があります。 繁体字は香港や台湾で使われていて、簡体字は中国本土やシンガポールで使われています。 簡体字は、繁体字の画数を減らし、簡単に読み書きできるように改良したものですが、文字コード体系が全く異なるため、全く互換性はありません。 繁体字中国語の文字コードは、台湾のメーカー5社が策定した「Big5」がよく使われています。 ただ、Big5は、ISO-2022準拠でないため、「CNS11643(EUC_TW)」も作られました。 CNSは、Chinese National Standardsの略です。 簡体字中国
1992年三重生まれ、会社員。ゆるくまじめに過ごしています。ものすごく暇なときにへんな曲とへんなゲームを作ります。 前の記事:無糖の飲みものに砂糖を入れる > 個人サイト ほりげー インターネットは文字化けと共にある インターネットが普及して20年をゆうに超える。メール、添付ファイル、Webブラウザなど、様々な場面で我々は文字化けに苦しめられてきたし、今でもたまに苦しめられる。「文字が化ける」と書いて文字化け。そこにはお化けみたいで悪いイメージがあるが、それも仕方がない。読めないのだから。必要な情報が読めないのはシンプルに悪いことだ。 DPZの記事を無理やり文字化けさせてみると、こうなる。 でも、一方的に文字化けを避けていては、文字化けと仲良くなれない。文字が化けた先にあるのは文字だ。化ける前の文字ばかり愛していては、化けた後の文字がかわいそうではないか。我々は、化けた後の文字をもっと愛す
Unicode 12では4つの言語(script)、554種類の文字が追加されました。これによりUnicodeに収録されている言語は150、文字は13万7292種類になりました。 追加された文字には日本語の文字が7種類、小さな文字としての「ゐ」「ゑ」「を」「ヰ」「ヱ」「ヲ」「ン」が含まれています(通常の大きさの文字は以前からありました)。これらは古い文書を記述するために使われるとされています。 そのほか、現在のイラン南西部に存在したアケメネス朝で使われていたアラム語のElymaic文字。南インドのサンスクリット語、カンナダ語で使われていたNandinagari文字。ラオス、タイ、ベトナム、フランス、オーストラリア、カナダ、米国などで使われていた現代White Hmong語、Green Hmong語のNyiakeng Puachue Hmong文字。インド、ミャンマー、ブータンの現代Wanc
C++ Advent Calendar 2018 この記事はC++ Advent Calendar 2018 15日目の記事です。 14日目: VTKライブラリ 16日目: C++のエラー処理との付き合い方 当初見積もりよりも大幅に長い記事となり、投稿したのは12/22で1週間遅刻です。すみません。 お知らせ cpprefjpにchar8_t型追加について解説を書きました。ぎゅぎゅっとコンパクトに、また査読を受けて中立的な表現で書いていますので、よければどうぞ。 UTF-8エンコーディングされた文字の型としてchar8_tを追加 - cpprefjp C++日本語リファレンス 追記 全ての開発者が知っておくべきUnicodeについての最低限の知識 - GIGAZINE Unicodeについて簡潔にまとまってるいい記事を見つけました。 Caution この文章には以下の要素が含まれます。苦手
理由 SHIFT キーはキーコードを -0x20、CTRL キーはキーコードを -0x40 する機能 全文 vim-jp.slack.com の #random から。 heavenshell [10:08 AM] TouchBar MBP にしたら強制的に C-[ になるので、オススメです!ようやく矯正できた。 mattn [10:09 AM] 人間の方が最適化されている yoshitia [10:12 AM] Escが物理的にない状況用にデフォルトでCtrl-[ 用意してるのすごい mattn [10:14 AM] いや、用意した訳ではないです。 SHIFT キーはキーコードを -0x20、CTRL キーはキーコードを -0x40 する機能なのです。 なので `[` つまり 0x5b は 0x1b になる。 0x1b = ESC 同様に CTRL-H は H が 0x48 なので 0x
UnicodeのUTF-16エンコーディングではほとんどの文字(コードポイント)は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語
さよならレガシーエンコーディング。 文字エンコーディング宣言が存在するかどうかにかかわらず、文書のエンコードに使用される実際の文字エンコーディングはUTF-8でなければならない。 4.2.5.5 文書の文字エンコーディングを指定する - HTML Standard 日本語訳 Require utf-8 when specifying character encoding by sideshowbarker · Pull Request #3091 · whatwg/htmlにより、HTMLで使用できるエンコーディングはUTF-8のみとなりました。これにより、古いHTMLでは許容されていた、Shift_JIS、ISO-2022-JP、EUC-JP、UTF16LEといった文字エンコーディングは適合するHTMLではなくなりました。すでにNu Html CheckerでUTF-8以外の文字エンコー
Intro textarea などに入力された文字数を、 JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、 BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID
The Pitfalls and Complexities of Chinese to Chinese Conversion 汉字简繁转换的复杂性和陷阱 漢字簡繁轉換的複雜性和陷阱 Jack Halpern President, The CJK Dictionary Institute Jouni Kerman Chief of Software Development, CJK Dictionary Institute Contents Abstract 1. Introduction 2. The Four Conversion Levels 3. Discussion and Analysis 4. A New Conversion Technology Acknowledgements References Appendixes About the Authors The CJK
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く