円記号問題とウェブブラウザ - はてなるせだいあり
起源 円記号問題の始まりは1960年代にまで遡ります。1967 年に文字コード最初の国際規格である ISO R 646 が制定されましたが、その規格では 0x5C をはじめとして一部の文字が置き換え可能になっていました。アメリカの制定した ASCII では 0x5C に対して REVERSE SOLIDUS を割り当てました。一方、日本版である JIS X 0201 では YEN SIGN を割り当てました。 問題の拡大 7bit では扱いきれない文字を扱うため、世界で ISO 646 系のコードを拡張した文字コードが生まれました。日本ではシフトJIS、日本語 EUC、いわゆる JIS コードの三種類の文字コードが現れ、それぞれに多くの亜種が生まれました。では、それぞれの文字コードの 7bit 領域は ASCII と JIS X 0201 のどちらだったのでしょうか。 日本語 EUC 日本
文字列の表記揺れをUnicode正規化で簡単に解決する方法 - Qiita
ユニコード正規化をすると、半角英数字や機種依存文字などの表記が統一できます。 表記ブレが吸収されることで検索性が高まったり、データの比較なども行いやすくなります。 正規化の手法にはNFD, NFC, NFKD, NFKCがありますが、その中でもNFKCという次のような正規化を行う方法をコードを交えて紹介します。 ウ゛ェ → ヴェ ＡＢＣ → ABC ① → 1 ㊤ → 上 Ⅲ → III ㌶ → ヘクタール ﾊﾝｶｸｶﾅ → ハンカクカナ ﹣ → - ※ 左辺はU+FE63 Small Hyphen-Minus: 小さいハイフンマイナス － → - ※ 左辺はU+FF0D Fullwidth Hyphen-Minus: 全角ハイフンマイナス 動作環境
文字コード地獄秘話 第3話：後戻りの効かないUnicode正規化 | ALBERT Engineer Blog
はじめに おっと、またまた会いましたね。文字コードおじさんです。前回、Unicodeにおける結合文字列という話題を取り上げました。思わず「いやあ、結合文字列は強敵でしたね」と口走りそうになる代物でしたが、今回はそれに関連したUnicode正規化のお話をしてみようと思います。 ざっと前回のおさらい 詳しいことは前回の記事をご覧いただくとして、 最低限の用語についてざっくりおさらいしておきましょう 結合文字列 複数の文字を使って見かけ上の1文字を表現する仕組み 「て（U+3066）」 の後に、 「濁点（U+3099）」 を配置することによって 「で」 を表現する 合成済み文字 「で（U+3067）」などのあらかじめ合成されている文字 Unicode正規化 結合文字列を合成済みに統一したり、合成済み文字を結合文字列にしたりする処理 少々語弊がありますが、イメージがつかめればOKです。 正規化の4
Unicode 内のそれぞれの文字種の範囲 - みちのぶのねぐら 工作室 旧館
郵便番号データを利用するサンプル を作っている最中に気になって、ひらがな、カタカナなどの文字種の Unicode の文字コードの範囲を調べました。 資料として http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/SHIFTJIS.TXT を使います。 “OBSOLETE” となっていますが参考にはなります。これを表計算のシートに貼り付けて Unicode 順に並べ替えるとわかりやすいです。以下の説明には unicode.org の対応する “Code Charts” の URL も記しておきましたので、個別の字面とコード値の確認のためにご参照ください。
MySQLの文字コード事情 2017版
"Портирование Web SDK с JS на TS" Петров Григорий, Voximplantit-people
Rails 5 と MySQL 5.6 環境における utf8mb4 を扱う設定について - Qiita
development: adapter: mysql2 pool: 5 username: root password: database: utf8mb4_sample_development charset: utf8mb4 collation: utf8mb4_bin encoding: utf8mb4 以降では、ここで設定した charset, collation, encoding がどういう役割を担っていくかの一部を見ていきます。 charset と collation 設定 上記の database.yml に設定した状態で、bin/rails db:create を行うと以下のようになっています。 character_set_database 以外はサーバー自体の設定が utf8 なので気にしないでください。 私が利用している Aurora の設定に合わせてあるだけです。
Unicodeのgrapheme cluster (書記素クラスタ) | hydroculのメモ
Unicodeのgrapheme cluster (書記素クラスタ) 2015/10/25 Unicodeテキストを1文字ずつ分割するアルゴリズムをUnicodeの仕様として定められており、grapheme cluster (書記素クラスタ)と呼ばれる。 普通はUnicodeのコードポイント1つずつ文字が割り当てられているので、ほとんどはコードポイント1つが1文字になるのだが、たまにコードポイント2つ以上で1文字になるものもあり、 1文字ずつテキストを分解するのは意外と複雑なルールになる。 Grapheme cluster について書かれている公式のドキュメントは以下にある。 Unicode® Standard Annex #29 UNICODE TEXT SEGMENTATION http://unicode.org/reports/tr29/ この記事は公式ドキュメントを読んで理解した
空白を削除する - Qiita
普通に今まで、'/([\s]|[\xe3\x80\x80])/'とか、こんな感じでいいと思ってたら、そうでもなかった件が出てきたのでメモ書き <?php function remove_white ($str){ return preg_replace('/(?:[\s]|[\xe3\x80\x80])+/', '', $str); } 半角スペース「 」とタブ「 」とU+3000 の全角スペース「 」だけでいいと思ってたけど、wikipediaの http://ja.wikipedia.org/wiki/スペース を見たらそれだけではない様子。 U-Point UTF-8 (in literal) Name
MacJapanese, CP932, Shift_JIS の違いと Ruby での取り扱い - Qiita
ローマ数字のⅠ,Ⅱ,Ⅲ... の他に囲み文字 ①,②,③... もそれぞれ異なるバイト列になります。 MacJapanese が使われているアプリケーション ほとんど見かけないのですが、絶滅しているわけではありません。Microsoft Excel のファイル *.xls または *.xlsx を Mac 版 Office で CSV 出力すると MacJapanese になります。Windows 版 Office で同じ操作をすると CP932 の CSV ファイルが出力されます。非常にややこしいですね。また、Mac 標準のメーラーも MacJapanese を使っているようです。 Ruby で Shift_JIS, CP932, MacJapanese のファイルを読み込むことを考えます。Shift_JIS や CP932 であれば、File.read("hoge.txt", enco
MySQL :: MySQL 8.0 リファレンスマニュアル :: 10.9.2 utf8mb3 文字セット (3 バイトの UTF-8 Unicode エンコーディング)
BMP 文字のみをサポート (補助文字はサポートされません) マルチバイト文字ごとに最大 3 バイトが必要です。 UTF-8 データを使用するが補助文字のサポートが必要なアプリケーションでは、utf8mb3 ではなく utf8mb4 を使用する必要があります (セクション10.9.1「utf8mb4 文字セット (4 バイトの UTF-8 Unicode エンコーディング)」 を参照)。 utf8mb3 および ucs2 では、まったく同じ文字セットを使用できます。 つまり、これらは同じ repertoire を持ちます。 utf8 は utf8mb3 のエイリアスです。文字制限は、名前に明示的ではなく暗黙的です。 utf8mb3 文字セットは非推奨であり、将来の MySQL リリースで削除される予定です。 かわりに utf8mb4 を使用してください。 utf8 は現在 utf8mb3
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
utf8_unicode_ci に対する日本の開発者の見解 - かみぽわーる
RailsがMySQLのcollationをサーバー側のデフォルトのutf8_general_ciからutf8_unicode_ciにわざわざ変えてるのどうせ大した理由じゃないだろと思って掘ってみたらやっぱり大した理由じゃなかった… https://t.co/6NeetGhTF0— Ryuta Kamizono (@kamipo) April 18, 2014 Railsでcollationとしてutf8_unicode_ci(RailsのDEFAULT_COLLATION)が採用されるのはcharsetが未指定もしくはutf8(RailsのDEFAULT_CHARSET)のときだけで、utf8mb4にすることとかは全く考慮されてない。— Ryuta Kamizono (@kamipo) April 19, 2014 @frsyuki MySQLのcharset utf8のときのデフォルト
Rails を utf8mb4 で動かす
絵文字などを格納できるようにするため、MySQL の encoding を utf8mb4 にすると、1文字が最大 4バイトになる。すると、primary key と unique key として使うカラムが、InnoDB の最大長 767バイトを超えるために、 ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes というエラーが発生する。 それを乗り越えるための手順は以下の通り。 1) まず、my.cnf に以下を追加して restart させる。 character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci innodb_file_per_table = 1 innodb_file_format = Barracu
Gmailが日本語など非アルファベット文字を含むメールアドレスとの送受信に対応
Googleは本日、日本語を含む非アルファベット文字を使うメールアドレスとの送受信に対応させると発表しました。 Official Google Blog: A first step toward more global email http://googleblog.blogspot.jp/2014/08/a-first-step-toward-more-global-email.html 従来、メールアドレスに使える文字はAからZまでのラテン文字(アルファベット)だけで、非アルファベットを使用した場合、Gmailから認識することはできず、メールの送受信は不可能でした。この状況を改善して、Googleは日本語や中国語、アクセントつきのラテン特殊文字などをGmail側から認識できるようにしました。これにより、例えば、「武@メール.グーグル」というメールアドレスからのメールを受信でき、またこの
Complete List of Emoji
Complete List of Emoji Image Name Other aliases Unicode hash U+0023 U+20E3 zero U+0030 U+20E3 one U+0031 U+20E3 two U+0032 U+20E3 three U+0033 U+20E3 four U+0034 U+20E3 five U+0035 U+20E3 six U+0036 U+20E3 seven U+0037 U+20E3 eight U+0038 U+20E3 nine U+0039 U+20E3 copyright U+00A9 registered U+00AE U+2002 U+2002 U+2003 U+2003 U+2005 U+2005 bangbang U+203C interrobang U+2049 tm U+2122 information_s
文字コード地獄秘話 第1話：Unicodeにおける全角・半角 - ALBERT Engineering Blog
ごあいさつ 皆様はじめまして、文字コードおじさんです。細々とカメラ屋を営んでおりましたが、エンジニアとしての技量を評価され、ALBERTのシステム開発・コンサルティング部で働くことを許されました。特技はサーバーの統廃合です。 今回は最初ということですが、Unicodeにおける全角・半角の取り扱いについて触れてみようと思います。なお、さも連載するかのように第1話と銘打っていますが、上層部の無慈悲な裁決によっては1話打ち切りもありえますので、その際はご容赦ください。 固定観念を捨てよう 「全角50文字、半角100文字まで」といったような文言を見かけたことがあると思います。 特にUnicode以前のレガシーな処理系では全角文字に2バイト、それ以外は1バイトという割り当てが慣習となっていました。 このため、「全角=2バイト文字、半角=1バイト文字」という観念が世間に定着しているのが現状です。 しか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - sunfmin/unicode_japanese: Japanese charset converter especially for hankaku and zenkaku characters
IPA、あらゆる人名の文字化けがない「IPAmj明朝フォント」 ～約6万漢字を国際標準文字コードに対応
Remove `DEFAULT_CHARSET` and `DEFAULT_COLLATION` by kamipo · Pull Request #22061 · rails/rails
GitHub - whitequark/rack-utf8_sanitizer: Rack::UTF8Sanitizer is a Rack middleware which cleans up invalid UTF8 characters in request URI and headers.
