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
encodingに関するa2ikmのブックマーク (110)
-
a2ikm 2019/12/08
-
円記号問題とウェブブラウザ - はてなるせだいあり
起源 円記号問題の始まりは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統合漢字ってあんまり問題にはなってないと思うんですよね。中国語フォントと日本語フォントを切り替えないといけないって問題はありますけど、それ
-
-
Rails 5 と MySQL 5.6 環境における utf8mb4 を扱う設定について - Qiita
mysql> use utf8mb4_sample_development; mysql> show variables like "chara%"; +--------------------------+------------------------------------------------------+ | Variable_name | Value | +--------------------------+------------------------------------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8mb4 | | character_set_filesyste
-
絵文字がある種の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
半角スペース「 」とタブ「 」とU+3000 の全角スペース「 」だけでいいと思ってたけど、wikipediaの http://ja.wikipedia.org/wiki/スペース を見たらそれだけではない様子。 | U-Point | UTF-8 (in literal) | Name| |:---|--:|:--| --:| |U+0009 | \x09 | CHARACTER TABULATION | |U+0020 | \x20 | SPACE | |U+00A0 | \xc2\xa0 | NO-BREAK SPACE | |U+2002 | \xe2\x80\x82 | EN SPACE | |U+2003 | \xe2\x80\x83 | EM SPACE | |U+2004 | \xe2\x80\x84 | THREE-PER-EM SPACE | |U+2005 | \xe
-
MacJapanese, CP932, Shift_JIS の違いと Ruby での取り扱い - Qiita
ローマ数字のⅠ,Ⅱ,Ⅲ... の他に囲み文字 ①,②,③... もそれぞれ異なるバイト列になります。 MacJapanese が使われているアプリケーション ほとんど見かけないのですが、絶滅しているわけではありません。Microsoft Excel のファイル *.xls または *.xlsx を Mac 版 Office で CSV 出力すると MacJapanese になります。Windows 版 Office で同じ操作をすると CP932 の CSV ファイルが出力されます。非常にややこしいですね。また、Mac 標準のメーラーも MacJapanese を使っているようです。 Ruby での取り扱い Ruby で Shift_JIS, CP932, MacJapanese のファイルを読み込むことを考えます。Shift_JIS や CP932 であれば、File.read("hog
-
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
これは，こちらのサイトによると， Depending on your requirements, this may or may not be what you want, but it is certainly consistent with the overall design of the String type to abstract away as many Unicode details as possible. Rule of thumb: if two strings look equal to the user, they will be equal in your code. つまり，「Unicodeでの実装にかかわらず，ユーザ側からの見た目が同じであるからには，コード上でも同一として扱われるべきである」という原則に基づいているとのことです。 実際，この仕様はApple
-
-
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側から認識できるようにしました。これにより、例えば、「武@メール.グーグル」というメールアドレスからのメールを受信でき、またこの
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました