GitHub - kuroda/mail-iso-2022-jp: A patch that provides 'mail' gem with iso-2022-jp conversion capability.You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
円記号問題とウェブブラウザ - はてなるせだいあり
起源 円記号問題の始まりは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
char8_tによせて - なるせにっき
C++標準化委員会、ついに文字とは何かを理解する: char8_tという記事が話題だってので、つらつらと書いてみました。 「グリフ」について グリフ（glyph）という言葉の定義をめぐって でも触れられていますが、「グリフ」という言葉が「字体」を指すのか「字形」を指すのかってのは議論がありますね。文字コードの文脈では普通「字形」の意味だとして話を進めることが多いように思います。 CJK統合漢字について Wikipediaの記事にまとまっていますが、実際に推進していたのは中国みたいですね。うまくやればあんまり問題なかったんでしょうが、あんまりうまく行かなかったんですが、それでも国ごとにその国の過去にあった文字コードとの互換性は取れているので、実際の所CJK統合漢字ってあんまり問題にはなってないと思うんですよね。中国語フォントと日本語フォントを切り替えないといけないって問題はありますけど、それ
Dockerでbundle installしたときにinvalid byte sequence in US-ASCII (ArgumentError)が出る場合の対処法
Dockerでbundle installしたときにinvalid byte sequence in US-ASCII (ArgumentError)が出る場合の対処法 問題 Dockerで作ったRuby環境でbundle installしたときにinvalid byte sequence in US-ASCII (ArgumentError)というエラーが出た。 bundle install --without production --retry=3 --path vendor/bundle /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf-8) Your Gemfile lists the gem byebug (>= 0) more than once. You should probabl
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バグを世界から一掃しつつある件について｜Rui Ueyama
UnicodeのUTF-16エンコーディングではほとんどの文字（コードポイント）は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語
ZIP中のファイル名の文字化け - @tmtms のメモ
こんな記事がありました。 gihyo.jp これはMacユーザー用の書籍の宣伝記事らしいのですが、「Windowsを使ってる人のためにMac側がひと手間かけてあげよう」なんて殊勝なことをマカーが言うとは時代も変わったもんです。（[追記] はてブのコメントを見たらさすがマカーという意見が並んでて安心しました） まあ私はWindowsユーザーでもMacユーザーでもないのでどうでもいいのですが、文字化けなネタなので食いついてみます。 記事中に、「付物出稿.zip」というファイルを開いた時の画像が載ってます。 文字の並びからして、UTF-8文字列をシフトJIS(CP932)とみなして表示してしまった文字列でしょう（「繧ｫ繝上ｙ繝ｼ繝輔か繝ｫ繧ｿ繧･」の元の文字は「カバーフォルダ」で、「蟶ｯ繝輔か繝ｫ繧ｿ繧･」は「帯フォルダ」）。 つまり、Macはファイル名をUTF-8でZIPに書き込み、Wi
空白を削除する - 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
MIMEヘッダエンコーディングは複雑すぎてつらい - tmtms のメモ
これは NSEG Advent Calender の7日目の記事です(内容は NSEG とも長野とも関係ありませんが…)。 www.adventar.org メールの送信者(From)や件名(Subject)は本来ASCII(の一部の文字)しか書くことができないんですが、MIME(RFC2047)の登場によって日本語等の非ASCII文字を記述することができるようになりました。 とは言ってもメールアプリから見て日本語が表示できているだけで、内部的にはASCII文字にエンコードされています。MIMEヘッダエンコーディングと呼ばれています。 たとえば、「日本語」という文字列は =?utf-8?b?5pel5pys6Kqe?= や =?iso-2022-jp?b?GyRCRnxLXDhsGyhC?= に変換されています。 この処理が実は非常に複雑で、正しくエンコードされてない場合がかなりあります。
Electronを使ってMac向けのアプリを開発する時のファイル名の扱いについて (所謂UTF-8-MAC問題) - Qiita
以前Nodeで作っていたものをElectronで作り直していて、同じ問題にまたハマったので書いておく。 所謂、UTF-8-MAC問題である。もう遥か昔にNodeでハマった時の記事がある。 node.jsでUTF-8-MACを扱う - joker1007の日記 Macのファイルシステムはファイル名に対してNFDとかいう正規化を行っていて、ファイルシステムにアクセスする時に勝手に変換しやがる仕組みになっている。 このせいで、濁点が入ると急に死ぬとか、本当辛い問題が起きる。何の嫌がらせなんだと……。この世界は文字が8ビットで済む様な国ばっかじゃねえんだよ！ とりあえずMac NFDでググると辛いのは俺だけじゃない気持ちになれる。 で、昔は上で貼ったブログに書いたような方法で解決していたのだが、正直、この解決策は2015年にもなって面倒過ぎるだろと思っていた。 (マジかよーってググって自分の記事が
「文字列」について - 2014-11-07 - はてなるせだいあり
序 「文字列を文字の列とみなす単純化」について議論がありますが、前提が抜け落ちてるように思うので書くことにします。 そもそもこの話はどのような文脈の上にあるかというと、テキスト処理 (wikipedia:en:Text_processing) の文脈になります。ここでいう「テキスト処理」とは plain text (wikipedia:プレーンテキスト) の検索・加工のことで、ここでは特に UNIX Text Processing の系譜が念頭に置かれています。つまり、複雑な装飾を含むリッチテキストではなく、処理の対象を ASCII 文字列といくつかの制御文字へと抽象化することで、正規表現のような強力な道具を用いた処理を可能とした世界です。UNIX でのお話ですから、ここでの具体的な処理の単位は char であり、全体としては char[] になります。この char の中身は上で述べたと
「文字列を文字の列とみなす単純化」ってどういうこと？解説編 - 西尾泰和のはてなダイアリー
先日 @shyouhei さんのTweetに反応して文字列が文字の列かどうかが言語によって異なるという話をTweetしました。 shyouheiさんの投稿: PythonはどうかしらんがRubyの設計思想は「世の中はシンプルじゃない」だからな。文字列を文字の列とみなす発想その物がすでにRubyからすると過度に世界を単純化しすぎている。 https://twitter.com/shyouhei/status/528106973565165568 もうちょっと言っておくと数値計算で勝ち目のないRubyは文字列処理にめっちゃ注力してるんで。文字列処理こそがRubyの主戦場。そこでRubyが文字列をあえてカタマリで扱ってることにはそれなりの理由というものがある。つまり分解しようとするほうが困りごとが増える。IVSとか。 https://twitter.com/shyouhei/status/528
RubyでMac版ExcelでインポートできるCSVデータを作成する - Qiita
Mac版ExcelはBOM付きUTF-16LEでないと正常にインポートできません。 以下Railsのコントローラーからの抜粋。 ポイントは、BOMのバイト列を force_encoding("UTF-16LE") しているところです。 こうしないと、output（UTF-16LE）と連結する際にエラーが出ます（ソースコードがUTF-8だとBOMのバイト列も当然UTF-8文字列とみなされるので）。 format.csv { header = "ID,氏名,住所,年齢,電話番号\r\n" CSV.generate(output = header) do |csv| @users.each do |user| csv << [user.id, user.name, user.address, user.age, user.tel] end end bom = "\xFE\xFF".force_e
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
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側から認識できるようにしました。これにより、例えば、「武@メール.グーグル」というメールアドレスからのメールを受信でき、またこの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - whitequark/rack-utf8_sanitizer: Rack::UTF8Sanitizer is a Rack middleware which cleans up invalid UTF8 characters in request URI and headers.
