Visual Studio の UTF-8 BOM と Git の設定で悩まされた話 - しばやん雑記
ぽちぽちと git を使っていたら、変更したはずのないファイルが変更扱いになっていて悩みました。 Visual Studio で変更してないのに Ctrl+S を押すと git では変更扱いになるの何でだ— しばやん (@shibayan) May 29, 2013 他のリポジトリでは発生していなくて、ある一つのリポジトリだけでこの現象が起きていたので Twitter で呟いたところ、UTF-8 の BOM が原因だと教えてもらいました。 @ishisaka @shibayan 手元のVST4GやTortoiseGitは反応し無いようなので、BOMや改行コードの問題な気が...— Kaoru Nakajima (@kaorun) May 29, 2013 Visual Studio はデフォルトで UTF-8 のファイルに BOM を付けるようになっているので、プラグインを入れて BOM
Visual Studioの規定値でUTF-8にBOMを付けないようにする - Neutral Scent
VSが規定値でUTF-8のテキストファイルにByte-Order-Mark(BOM)を付けてくるのは有名ですが、それが思わぬ副作用を生むことがあります。 なので、なんでByte-Order関係ないUTF-8にBOM付けるねん、逐一ファイルのエンコーディング設定なんて面倒なんじゃ、と考えるのがお約束。(ただし一律にBOMを外してしまうとそれはそれで問題があるようです) そこでツールの投入ですよ、と。 Fix File Encoding - Prevent Visual Studio 2012/2010 from adding BOM to UTF-8 files - Sergey Vlasov Studio (Visual Studio add-ins, extensions and tools) http://www.svprogramming.net/fix-file-encoding/
全角半角混在の文章で 1 行に半角何文字分あるか調べる方法
「ソースコードは 1 行あたり 80 文字以内」とか「コミットログは横幅 72 文字以内」とか、文字数に関するルールはいろいろある。 ルールを徹底するには機械的に判定したい。と思って、簡単なスクリプトを書こうとした瞬間、意外と「1 行あたりの文字数」をカウントするのが難しいことに気付いた。 たとえば、「あA」は「全角 1 文字＋半角 1 文字」なので半角 3 文字分としてカウントしたい。 しかし、UTF-8 の世界では「あA」の文字長は 2 だし、バイト数は 4 (あ=0xE38182、a=0x41) である。 EUC-JP や Shift-JIS の時代なら、単純に「あA」は 3 バイトなので「半角 3 つ分」とすぐ分かったのだけども… (逆に文字長を調べるのが面倒だった)。 はて、どうするか？ というのがこの記事でいいたいこと。 East Asian Width を見よ いろいろとググ
perl - 最速のUTF-8処理法 : 404 Blog Not Found
2013年03月04日14:45 カテゴリTipsLightweight Languages perl - 最速のUTF-8処理法 Perl Cookbook (English, Kindle Ed.) Christiansen / Torkington [邦訳: Perlクックブック] というわけで解説。 2013/03/04:Unicode::UTF8 がガチ爆速すぎる - bayashi.net encode より decode のが差が大きい感じ。encode だけだと、文字列長くなると Encode の方が速いっぽい。 まずは改めて検証してみましょう。 https://gist.github.com/dankogai/5079930 確かにその通りになっています。Unicode::UTF8はEncodeはおろかPerl組み込みのutf8::decodeより高速なのか(文字列をコピ
UTF-8 対応の msysGit 1.7.10 リリース！ いよいよ Windows で git できるよ!!!
UTF-8 対応の msysGit 1.7.10 リリース！ いよいよ Windows で git できるよ!!! 先日、msysGit（Git for Windows）がいよいよ公式に UTF-8 をサポート！ という記事で「UTF-8 対応のコードがコミットされた」ことをお伝えしましたが、ついに、UTF-8 対応の新バージョン、msysGit 1.7.10 がリリースされました。 いよいよ Windows でも日本語ファイル名を扱えるようになったので、「git では "詳細設計仕様書.xlsx" をコミットできないんでしょ？」とブーブーいってた人を説得できる材料はそろいました!!!! それを記念して、この記事では UTF-8 対応の msysGit 1.7.10 を試してみたブーブーいう人を黙らせるための「GUI で git する Windows 向けツール」まとめ の2本立てでお送り
[php] mb_convert_encoding と UTF-8 の誤変換問題（株式会社コネクティボしゃいん☆のブログ）
このような誤変換を防ぐための一つの手法としてよく挙げられているのが、「sjis-win」または「eucjp-win」というエンコーディングを使って回避する方法である。 $s_in = "～"; $s_out = mb_convert_encoding( mb_convert_encoding( $s_in, "sjis-win", "UTF-8" ), "UTF-8", "sjis-win" ); echo ($s_in == $s_out) ? "OK" : "NG"; 表示結果: OK このようにすると、上記表に挙げた文字を mb_convert_encoding を使って変換しても、正しく元に戻すことができる。 「sjis-win」または「eucjp-win」を使えば解決？と思いきや、逆も真なりとはこのことかと思うような問題も存在する。たとえば、 $s_in = "〜"; $s_ou
![[php] mb_convert_encoding と UTF-8 の誤変換問題（株式会社コネクティボしゃいん☆のブログ）](https://cdn-ak-scissors.b.st-hatena.com/image/square/386e571ff1c466762059b21b6324a144c69f2922/height=288;version=1;width=512/http%3A%2F%2Fshain.blog.conextivo.com%2Fimg%2Fshainblog_mark_base.jpg)
iPhoneの文字化けを防ぐ魔法の呪文 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
昨日のエントリ（「iPhoneのMailから送ったメッセージ全体が文字化け」のまとめ）読みましたよー。iPhoneから送るメールの文字化け防止策は、署名に「♡」を入れておけばOKなんですよね？ うん。ただまあ、ちょっと気にする人はいるかもなあ。 男子に誤解されちゃう、と？ いや、そういうのじゃなくて、つまり、化けちゃうんだよね。 えっ？ 相手の環境によっては「♡」が化けるんだよ。 何ですかそれ。文字化け対策で入れた文字が化けたら意味ないじゃないですか。 意味はあるよ。iPhoneから送ったメールは相手先で全体が化けて読めなくなる可能性があるけど、「♡」でcharset=UTF-8にしておけば、この「全体化け」を防げるんだから。ただし、相手がケータイだったりすると、「♡」自体は「･」とか「?」とかになっちゃうってこと。 自らは捨て石となってメッセージ全体を救うということですか。UTF-8にな
msysGit 1.7.10 の Git Bash に日本語が入力できない件について少し調べた - てっく煮ブログ
git先日の UTF-8 対応の msysGit 1.7.10 リリース！ いよいよ Windows で git できるよ!!! という記事で、msysGit 1.7.10 の Git Bash で IME からの日本語入力できない件を伝えていたが、この件についてもう少し深入りしてみた。.inputrc を設定してもうまくいかない記事へのコメントで指摘をいただいたのが、.inputrc に set convert-meta off set meta-flag on set output-meta on と設定してみる、という方法だった。しかし、この通りに設定しても期待通りの結果にはならなかった。いろいろ検索してみると、生の MSYS では「この方法でうまくいく」と記述してあるページは多かった。生の MSYS ではうまくいくのに、msysGit ではうまくいかない理由はなぜか。この原因を調べ
UTF-8 対応の msysGit 1.7.10 リリース！ いよいよ Windows で git できるよ!!! - てっく煮ブログ
git先日、msysGit（Git for Windows）がいよいよ公式に UTF-8 をサポート！ という記事で「UTF-8 対応のコードがコミットされた」ことをお伝えしましたが、ついに、UTF-8 対応の新バージョン、msysGit 1.7.10 がリリースされました。いよいよ Windows でも日本語ファイル名を扱えるようになったので、「git では "詳細設計所仕様書.xlsx" をコミットできないんでしょ？」とブーブーいってた人を説得できる材料はそろいました!!!!それを記念して、この記事では UTF-8 対応の msysGit 1.7.10 を試してみた ブーブーいう人を黙らせるための「GUI で git する Windows 向けツール」まとめの2本立てでお送りしたいと思います。UTF-8 対応の msysGit 1.7.10 を試してみたさっそく Google Code
EUC-UTF8の可能性 : 404 Blog Not Found
2007年03月18日06:00 カテゴリCodeLightweight Languages EUC-UTF8の可能性 404 Blog Not Found:シフトJISを残すべきか?のコメント欄の、UTFCPのLightConeさんとMatzさんの会話をぼ〜っと眺めているうちに、ひらめきました。 EUCとUTF-8って、マッシュアップできなくね? 鍵は\xFFにあります。このバイト、EUCにもUTF-8にも絶対あらわれないのです。 さすれば、あとはこう定義するだけです。 EUC-UTF8-CHAR = EUC-CHAR | \xFF + UTF-8-CHAR LightConeさん曰く、 UTFCP2の特徴として，日本と中国の漢字の主要部分が二バイトで現せる 特徴もありますが．他に， 後ろのバイトから正確に一文字づつ逆戻りできるという事があるのを知ってますか． 正確に逆戻り出来るのは，プ
Snow LeopardのMailはUTF-8のメールを量産する - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
Apple Mail（Mail.app）がcharset=ISO-2022-JPのメッセージを表示する際の変換テーブルが、おかしい。 WindowsとMacでは、JIS X 0208に含まれる文字の範囲において、下図のようなUnicodeマッピングの相違が存在する。たとえばWindowsはJIS X 0208の1区33点「〜」（波ダッシュ）をU+FF5E FULLWIDTH TILDEと解釈し、Macは同じ文字をU+301C WAVE DASHと解釈する。 ところがMac OS X 10.6 Snow LeopardのMail 4.1（1076）は、Apple製の（そしてもちろんMac専用の）アプリケーションであるにもかかわらず、上図のすべての文字について、Windows側のマッピングによってcharset=ISO-2022-JPのメッセージを解釈する。 その一方でMailは、「Unico
XSS対策パッチを当ててもRailsに残る脆弱性 - 岩本隆史の日記帳（アーカイブ）
どのような脆弱性か 先日書いた「Rails 2系のXSS脆弱性がRuby 1.9では影響なしとされる理由」という記事に、奥さん（id:kazuhooku）より、下記のブックマークコメントをいただきました。 たとえばブログの場合、誰かに壊れたUTF-8を含むコメントを書き込まれちゃうと、そのブログ全体にアクセスできなくなる(最新コメント一覧に出るから)んじゃないか。XSSが発生しないだけで脆弱性があることは変わらない はてなブックマーク - kazuhookuのブックマーク / 2009年9月26日 まったくおっしゃる通りです。アプリケーションの構成によっては、サービス自体が提供できなくなる可能性があります。 このような脆弱性を何とよぶのでしょうか。すでに統一的な呼称があるのかどうか、私は知りません。サービス不能という観点からは広義のDoS脆弱性といえるのかもしれません。 追記（2009-0
#perl - utf8::decode()ではなくEncode::decode_utf8()を使うべき理由 : 404 Blog Not Found
2009年09月13日13:00 カテゴリLightweight Languages #perl - utf8::decode()ではなくEncode::decode_utf8()を使うべき理由 駄目です。 [を] Perl の utf8 まわりのおまじない 最近良く使うおまじない、というかイディオム。 utf8::decode($text) unless utf8::is_utf8($text); こういう場合は、Encode::decode_utf8()でないと。 以下をごらんください。 #!/usr/bin/perl use strict; use warnings; use Encode; use Devel::Peek; for my $bytes ( "\x2F", "\xC0\xAF", "\xE0\x80\xAF", "\xF0\x80\x80\xAF" ) { my $u
UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか？を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、（2/3）SQLインジェクションを根絶！セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題：ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『￥』は？」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
perl - use utf8; #って何だ? : 404 Blog Not Found
2009年06月15日07:00 カテゴリLightweight Languages perl - use utf8; #って何だ? id:otsuneに建設予定フラグがたてられていたので。 冬通りに消え行く制服ガールは、夢物語にリアルを求めない。 - subtech Perl の utf8 関係が未だ全く理解できない。わからないことがわからないので整理 use utf8はいつフラグをたてるか use utf8 しててもフラグたたないことがある…… これは、以下の実例を見ていただくのが一番よいだろう。 #!/usr/bin/perl use strict; use warnings; use utf8 (); sub check_flag{ my $str = shift; print qq("$str" ), utf8::is_utf8($str) ? 'is' : 'IS NOT',
perl - use encoding; #は黒歴史 : 404 Blog Not Found
2009年06月08日14:30 カテゴリLightweight Languages perl - use encoding; #は黒歴史 ぎゃあぁぁ length関数で文字列の長さを求める - perl初心者BLOG - Hatena::Group::Perl 日本語の文字数を正確に求めたい場合、use encodingを指定する use encoding;は、jperlなど、かつて存在したL10Nされたperl用に書かれたレガシースクリプトを、モダンperlで動かすときのためのおまじないです。こういう目的で利用すべきではありません。 このあたりのことは、以前 404 Blog Not Found:perl - no encoding; # whenever possible でも書いたのですが、大事なことなのでまた書きます。 スクリプトはUTF-8で書き、use utf8;する のがモ
UTF-8→SJIS/EUC-JPの重複文字をまとめてみた - hnwの日記
文字エンコーディングの変換を行うと、異なる2文字が同じ文字に変換されることがあります。このような文字を重複文字と呼ぶことにします。UTF-8→Shift_JISおよびUTF-8→EUC-JPについて、重複文字を自分用の資料としてまとめてみました。 MacOSX上のPHP5.2.9での実験結果ですが、プログラミング言語や環境によらず気をつけるべき文字一覧ということになると思います。 色のついている部分が重複している部分です。「-」となっているのは変換できなかった文字です。また、ヘッダのカッコ数字ごとに文字エンコーディング変換に利用した関数が異なります。詳細は下記の通りです。 (1) mb_convert_encoding($char, "Shift_JIS", "UTF-8") (2) mb_convert_encoding($char, "SJIS-win", "UTF-8") (3) i
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発終了宣言された「FFFTP」がオープンソースとして開発再開・バージョンアップ
netatalkは自前でUTF-8-MACをサポートする：HAT：So-net blog