物語の始まり 事の発端は納品後。 先方からメッセージが届きました。 クライアント様「このファイルの文字コードがShift_JISになっておりますので、UTF-8で再納品をお願いいたします。」 拙者（あれ…UTF-8にしてたと思うんだけどな） 拙者「確認いたします。」 文字コードを確認する 本案件はいわゆる更新案件で、今回の納品時に言われていたのは、「文字コードがUTF-8ではないものは変換して納品してくれ」ということ。 そして、ご指摘いただいたのは、今回の更新案件で中身はいじらなかったJavaScriptファイル。 本来ならば納品するファイルではないのですが、文字コード変換という要件があったため、納品ファイルとして加えられたものでした。 一括で文字コードを変えたので作業漏れかなぁと思っていました。 ファイルの中身は記事用にかなり適当につくったものですが、まあだいたいこんな感じです。
竈門禰󠄀豆子をMySQL5.6のテーブルにinsertしようとすると正しく格納できず、竈門禰となってしまうケースがあるという話を聞き、調べてみました。 実践 まずは試しにやってみます。 mysql> show create table verification\G *************************** 1. row *************************** Table: verification Create Table: CREATE TABLE `verification` ( `name` varchar(100) COLLATE utf8_bin DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin 1 row in set (0.01 sec) mysql> inse
かつて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ビッグエ
Unicode 版美乳テーブルを探せ
美乳テーブルとは 「美乳テーブル」という物がある。 「EUC-JP の文章を Shift_JIS だと誤認識されない様に、EUC-JP 固有のバイト値を文章先頭付近に埋め込んでおく」という物。 具体的に、Shift_JIS には 0xFD と 0xFE が現れず、EUC-JP にはそれが現れるので、その値を含む文字コードを書いておこうという事で、その文字の集合に付いた名前。 “美” = 0xC8FE、“乳” = 0xC6FD。 各文字エンコーディングの事情 但し、これは EUC-JP での話。 一応、文章の先頭付近に日本語の文字を書いておくのは、他の文字エンコーディングでも認識のヒントにはなるけど。 逆に「Shift_JIS の文章を EUC-JP だと誤認識されない様にする」には、EUC-JP にはないバイト値の 0x80〜0xA0 を書けばいいんだろうけど、これは沢山ありそうだから、慎
アイヌ語仮名「ㇷ゚」に対する正規表現の罠
導入 アイヌ語は日本語と異なり、閉音節（子音で終わる音節）も存在するので、表記の際音素文字であるラテン文字なら、そのまま p, t, k, m, n, s, r などの子音文字を後ろの付ければ良いわけなので、アイヌ語ローマ字表記では、何も問題が生じない。しかし、元々開音節言語である日本語に特化したカタカナのような仮名文字で表記する際、鼻音 n は「ン」でなんとかなる（実はそれでもまずい事になっているけどここでは割愛する）が、p, t, k, m, n, s, r, h はどうしようもないので、特殊の捨て仮名（小書き仮名文字）を利用することになっている。 具体的には以下のような特殊仮名文字（通称 アイヌ語仮名）である。 ㇷ゚ -p ッ -t ㇰ -k ㇺ -m ㇱ -s ㇻ -(a)r, ㇼ -(i)r, ㇽ -(u)r, ㇾ -(e)r, ㇿ -(o)r お分かり頂けただろうか… 問題 r
HTMLファイルで特殊記号を使う際、① は ①、© は © のように置き換えて書かないといけないものだと思いこんでいないでしょうか。 現代ではそれは誤解です。 UTF-8では特殊記号の文字参照は不要 そもそも環境依存文字とは、データを扱う機種・ソフトウェアなどの違い（文字コードの割り当ての違い）により表示に違いが出てしまう文字のことでした。 例えばShift_JISには © が含まれておらずそもそも保存できなかったり、 ① などの丸数字は含まれているものの、WindowsとMac OS（当時）の割り当ての違いにより正しく表示できなかったりしました。[1] しかし現在ではUnicodeによって文字コードは統一化されており、その問題はほとんど起きなくなっています。 近年では多くの場合 UTF-8 でファイルを記述すると思います。 HTMLファイルの文字エンコーディングが
第39回関西PHP勉強会 のスライドです。 （おことわり） スライド上では全て文字エンコーディングのことを「文字コード」と表記していますので、ご了承ください。 やりたいこと 郵便局が提供している郵便番号一覧データをDBに入れる 文字コードが「SJIS」 文字コードの変換が必要 データ件数が約12万件と大きい ファイル操作に工夫が必要 1つめの困りごと：文字コードが「SJIS」 【SJIS（Shift_JIS）】 日本語を含む文字列を表現するために用いられる文字コードの一つ SJISとSJIS-winがあり、SJIS-winの方が対応文字数が多い（①②、はしご高など） ガラケーなどの用いられている 扱いにくい... [参考] PHPの文字コードではSJISじゃなくてSJIS-win、EUC-JPじゃなくてeucJP-winを 【UTF-8】 表示範囲が広く、どの国の文字も文字化けしない 世界
utf8とutf8mb4の違い【MySQL】
（なぜ2種類あるのかはMySQLの歴史によるものらしいのですが、私はいまいち分かっていないので詳しく知りたい方はググってみてください･･。） 保存できる文字の違い これはつまり、UnicodeのコードポイントがU+FFFFを超える文字は、utf8では保存できないってことです。 例えば 崎（U+5D0E）←保存できる 﨑（U+FA11）←保存できる 😀（U+1F600）←保存できない 𩸽（U+29E3D）←保存できない ※ちなみにこの漢字はホッケと読みます みたいな感じ。 絵文字などを保存したい場合はutf8mb4を使わないといけません。 MySQLのutf8はUTF-8ではないのでは･･？ UTF-8は「世界中の文字を1つの文字コードで表そうぜ！」な文字集合であるUnicodeを表すための文字符号化方式の1つなわけですが 本来UTF-8は、1～4バイトで文字を表すルールです。 なので、
UTF-8からSJISに変換する時にはShift-JIS系エンコードの種類だけじゃなくてUNICODE正規化も気にしないとダメという話 利用シーン UTF-8で記述されたテキストをShift-JISエンコードに変換する機会はあります。 UNICODEで表現できる文字の種類の方がShift-JISに比べて圧倒的に広いのですべての文字が変換できるわけではありませんが、「これは変換できてよかろう」というものまでこぼれ落ちるケースは多数あります。 以下こぼれ落ちる例とその対応を示します。 サンプルコード まずはサンプルコード。 rubyで記述していますが、原理はどの言語でも同じです。 str = "あ～あ①髙島屋パバぱ" sjis = str.encode(Encoding::Shift_JIS, :invalid => :replace, :undef => :replace) File.
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「ASCIIをUTF-8にして」それが『できない』ことを理解してもらえなかった話 - Qiita
UTF-8のテーブル(MySQL5.6)に竈門禰󠄀豆子が格納できない問題を調べてみた - Qiita
BOMなしUTF-8によってWindowsでもたらされる困惑 (1/2)
「HTMLでは環境依存文字（①や©など）を文字参照にしなければいけない」という誤解と、本当に置換すべき文字
PHPでSJISのデカイCSVデータを扱った時に困ったこと - Qiita
UTF-8からSJISに変換する時にはShift-JIS系エンコードの種類だけじゃなくてUNICODE正規化も気にしないとダメという話