寿司=ビール問題 : MySQL 8.0でのUTF8サポート入門 (MySQL Server Blogより) | Yakst
これまでのMySQLでよく問題になった、絵文字や日本語の文字の照合やソート順序の問題に関して、来たるMySQL 8.0では大幅な改善が加えられる予定になっている。この問題の概要と今後の改善方針について、MySQL開発チームからの解説。 免責事項 この記事はManyi Lu氏によるMySQL Server Blogの投稿「Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0」(2017/1/13)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 8.0での私たちの計画として、utf8のサポートを大幅に改善します。utf8サポート自体はMySQL 4.1の頃にさかのぼりますが、いくつかの制限が存在しています。記事タイトルにもある「寿司 = ビール」問題は、バグ#76553のことを指しています。少
HTML URL Encoding Reference
W3Schools offers a wide range of services and products for beginners and professionals, helping millions of people everyday to learn and master new skills. Free Tutorials Enjoy our free tutorials like millions of other internet users since 1999
Unicode正規化 - Wikipedia
Unicode正規化（ユニコードせいきか、英語: Unicode normalization）とは、等価な文字や文字の並びを統一的な内部表現に変換することでテキストの比較を容易にする、テキスト正規化処理の一種である。一般に、正規化はテキストの文字列を検索や整列のために比較（照合、英語: collation）するときに重要である[1]。 合成と分解[編集] Unicodeの正規化手段の基礎は、文字の合成と分解という概念である。文字の合成とは、基底文字と結合文字の組み合わせによる結合文字列を、単一の符号位置である合成済み文字にする手続きである。たとえば、基底文字 n と結合文字 ~ の組み合わせを単独の ñ 文字に変換する、仮名文字と濁点の結合文字の組み合わせを単独の濁点つき仮名とするなど。分解はその逆で、合成済み文字を結合文字列にする。分解は単一の符号位置を別の単一の符号位置に変換することも
Git and the Umlaut problem on Mac OS X
Today I discovered a bug for Git on Mac OS X. For example, I will commit a file with the name überschrift.txt with the German special character Ü at the beginning. From the command git status I get following output. Users-iMac: user$ git status On branch master # Untracked files: # (use "git add <file>..." to include in what will be committed) # # "U\314\210berschrift.txt" nothing added to commit
Unicode lookup
Character set up to date to Unicode 12. The tool as a whole is a new version, public in early stages. As I work on it, it will be missing features, occasionally its data, and sometimes give errors. Input currently recognised: String with any characters, e.g. ㋛ ☺ ㋡ or € or (ノಠ益ಠ)ノ彡┻━┻ or ᘛ⁐̤ᕐᐷ or ༼ つ ◕_◕ ༽つ or ♥︎ ♥️ or ◡̈. Refereces to one or more codepoints (one style at a time) U+205AC, U+1F9C0,
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
Rubyでinvalidなバイト列を含むUTF-8文字列を扱う - yarbの日記
Ruby 1.9系ではStringオブジェクトにエンコーディング情報が付加されていて、マルチバイトや複数エンコーディングを扱う日本人としては嬉しい限りだけど、時々エンコーディング関連で例外が発生して落ちすぎるぐらい落ちるように感じるときがある。ちょっとイラッと来るけど、考えてみたら、例外を出さずに処理を進めてしまうことの弊害のほうが大きいだろうから、これはありがたいこと。 外部のHTMLを読み込んで正規表現でマッチするコードで、次のようなエラーが出た。 invalid byte sequence in UTF-8これは文字通り、UTF-8的におかしなシーケンスがあるということ。問題のHTMLを調べてみたら、UTF-8のHTMLの中に、Shift_JISが混じってしまっていた。どうも、JavaScriptで突っ込んだ文字列らしい……。いかにもありそうなことだ。どの程度の頻度で世の中にそういう
Rubyの文字列がエンコード情報を持っている話 - 西尾泰和のはてなダイアリー
Rubyの文字列はエンコード情報を持っているという話。 struct RString { struct RBasic basic; union { struct { long len; char *ptr; union { long capa; VALUE shared; } aux; } heap; char ary[RSTRING_EMBED_LEN_MAX + 1]; } as; }; あれ？持ってないぞ？ と思ったら int rb_enc_get_index(VALUE obj) { ... case T_STRING: case T_REGEXP: i = ENCODING_GET_INLINED(obj); if (i == ENCODING_INLINE_MAX) { VALUE iv; iv = rb_ivar_get(obj, rb_id_encoding()); i =
Rubyのエンコーディング - tmtms のメモ
Ruby 1.9 から文字列や正規表現オブジェクトはそれぞれエンコーディング(いわゆる文字コード)を保持するようになりました。 たとえば 0xB1 0xB2 という２バイトは EUC-JP エンコーディングでは「渦」、SHIFT_JIS エンコーディングでは「ｱｲ」という文字になります。つまり同じバイト列でもエンコーディングが異なれば異なる文字として解釈されます。 1.8 では文字列はただのバイト列でした。なので、それがどのような文字を表しているのか、つまりエンコーディングが何なのかはプログラムが知っている必要がありました。 1.9 では文字列オブジェクト自身が自分が何のエンコーディングかを知っています。同じ 0xB1 0xB2 というバイト列でも、それが EUC-JP の「渦」なのか SHIFT_JIS の「ｱｲ」なのかは、文字列自身が知っています。 スクリプトエンコーディング スクリプ
Encodings, Unabridged
I wrote somewhat extensively about the problem of encodings in Ruby 1.9 in general last week. For those who didn't read that post, let me start with a quick refresher. What's an Encoding? An encoding specifies how to take a list of characters (such as "hello") and persist them onto disk as a sequence of bytes. You're probably familiar with the ASCII encoding, which specifies how to store English c
mysqlでskip-character-set-client-handshakeはもう使わないほうがいいと思われ | へぼい日記
ホーム > mysql | perl > mysqlでskip-character-set-client-handshakeはもう使わないほうがいいと思われ 新しい 古い skip-character-set-client-handshake を [mysqld] セクションに追記すると、クライアントがどんな文字コード設定をもっていようが問答無用で character_set_* を (_system をのぞいて) すべて同じ値に統一してくれる http://d.hatena.ne.jp/a666666/20090826/1251270979 ふーむ。 skip-character-set-client-handshakeを薦める文書がネット上にはやたら転がってるんだけど、これには大きな落とし穴がある。 たしかに表示されるcharacter_set_*は統一されるかもしれないがこれはあくま
MySQLとsequelで文字列の照合順序について調べる
概要MySQLで文字列を検索対象にした場合、一般的なデフォルト設定では大文字・小文字を区別しない。この問題にしっかりハマってしまったので、調査と対策を行ったメモを晒すことにした。 基本的なことがらなのにものすごく長いので「ダイジェスト」を読んでいただければおおむねOKにしてある。検証過程に興味のある方はその続きをどうぞ。 ダイジェストMySQLはデフォルトで運用すると文字列の比較 / 並び替えで大文字 / 小文字を区別しない。 大文字小文字を区別して検索するには… テーブル単位カラム単位クエリ単位…での対応が可能。 データ定義テーブル単位 -- CREATE TABLE時にテーブルのデフォルト文字コードと照合順序を指定する CREATE TABLE hoge1 ( id INTEGER PRIMARY KEY AUTO_INCREMENT, str VARCHAR(16) ) ENGINE
iconv - Wikipedia
iconv（アイコンブ）は異なる文字コード間の相互変換を行う標準API。または、そのAPIに付属する文字コード変換ユーティリティプログラム。名前は「International Codeset Conversion Library」に由来する[1]。GNUによる実装[2]が有名で、変換ライブラリ libiconv のライセンスはLGPL、変換プログラム iconv のライセンスはGPLである。 iconv API[編集] iconvのAPIは、おもにUNIX環境で文字列の文字コード変換を行う標準インタフェースである。iconvは最初HP-UXで開発され、後にPOSIX規格として標準化された。そのため、ほとんどのUnix系のシステムで使用できる。 iconv APIは文字コード変換プログラムのほか、既存のプログラムを国際化または多言語化するためにも用いられる。例えば、Sambaの国際化にはic
Ruby 1.9.1のm17nについてメモ - monthly gimite
2009/2/8追記: 今はもう↓の公式ドキュメントやid:macksさんのドキュメントなどいろんな情報が出ているので、このメモの存在意義は微妙ですが、一応1.9.1に合わせて修正しておきました。 多言語化 class String class IO この辺のドキュメントが見つからず（まだない？）、いろいろ試行錯誤して分かったことをメモ。 まず、Ruby 1.9では文字列オブジェクトがそれぞれ文字コードを持っている。 p "a".encoding #=> #<Encoding:US-ASCII> ファイルの先頭に # -*- encoding: UTF-8 -*- と書いておくと、文字列リテラルのencodingがUTF-8になる。 p "あ".encoding #=> #<Encoding:UTF-8> p "a".encoding #=> #<Encoding:UTF-8> これを書か
PythonのUnicodeEncodeErrorを知る - HDEラボ
Pythonにはじめて触って、いつのまにか1年が過ぎたのですが、一番はまったのは、やっぱりunicodeの扱いだったと思います。 特に、 UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-12: ordinal not in range(128) のようなエラーにはさんざん悩まされました。ここがたとえばrubyなど他の言語と比べてわかりにくいために、Pythonが取っつきにくい言語になっているのではないか、と個人的には思います。 そこで、このエラーに関係するはまりどころとTipsをいくつか列挙してみました。これからPythonに触れられる方の参考になればと思います。 なお、環境はUNIX上のPython 2.4, 2.5を想定しています。 u1はunicode型で、s1はstr型です。s1にどのよ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - polygonplanet/encoding.js: Convert and detect character encoding in JavaScript
- ぬぞうWiki