Pythonで出力したUTF-8のCSVを渡したら「文字化けしてExcelで読めない」と言われて困りました 原因は文字コードがUTF-8の時によく問題になるBOM(バイトオーダーマーク)です バイトオーダーマーク - Wikipedia UTF-8のファイルにはBOMが付いている場合と付いていない場合があります ExcelはBOMが付いていないと正しく読み込んでくれません なので、例えばメモ帳で開いて保存し直すと、BOMが付いてExcelでも開けるようになります 今回の問題とは逆にBOMがついていると動かないこともあって、以前BOMが付いたUTF-8のファイルをChromeに渡したら何故か動かなくて悩みました Google Chrome のユーザースクリプトで名前やバージョン番号が反映されない - 唯物是真 @Scaled_Wurm ちなみにPythonだと文字コードにutf-8ではなくu
寒くなってきた今日このごろ、おでんが食べたくなったらUnicodeのU+1F362がある。 しかしU+1F362には大きな間違いがある。 それはUnicode Character Code ChartsのMiscellaneous Symbols and Pictographsに載っている。 seafood on skewer、日本語にすると「串に刺さったシーフード」である。 確実に僕の知っているおでんの定義じゃない。 念の為、「seafood on skewer」で画像検索してみる。 やっぱり僕の知らないおでんだった。 おまけ1 おでんの定義、ドラフト時には更によくわからなく、SEAFOOD CASSEROLE (Temporary Notes: seafood hotchpotch, oden)、日本語に訳すと「シーフード鍋料理(シーフードの鍋、おでん)」である。 SEAFOOD CA
ごあいさつ 皆様はじめまして、文字コードおじさんです。細々とカメラ屋を営んでおりましたが、エンジニアとしての技量を評価され、ALBERTのシステム開発・コンサルティング部で働くことを許されました。特技はサーバーの統廃合です。 今回は最初ということですが、Unicodeにおける全角・半角の取り扱いについて触れてみようと思います。なお、さも連載するかのように第1話と銘打っていますが、上層部の無慈悲な裁決によっては1話打ち切りもありえますので、その際はご容赦ください。 固定観念を捨てよう 「全角50文字、半角100文字まで」といったような文言を見かけたことがあると思います。 特にUnicode以前のレガシーな処理系では全角文字に2バイト、それ以外は1バイトという割り当てが慣習となっていました。 このため、「全角=2バイト文字、半角=1バイト文字」という観念が世間に定着しているのが現状です。 しか
Unicodeを送られてLINEを初期化されたんですけど、強力なUnicodeありませんか? お願いします。
エクセルマクロの文字コード変換について。UTF8からSJIS変換 VBA初心者です。 以下のコードを使用してファイルの変換を行うと、変換元のファイルが上書きされてしまいます。 有識者の方、コードの詳しい説明と解決方法をご教授下さい。 Sub UTF8toSJIS(ByVal InFile As String, ByVal OutFile As String) Const adTypeText = 2 Const adSaveCreateOverWrite = 2 Dim myST1 As Object, myST2 As Object Set myST1 = CreateObject("ADODB.Stream") Set myST2 = CreateObject("ADODB.Stream") myST1.Type = adTypeText myST1.Charset = "UTF-8"
前回からの続き。 改行コードの違いを体感してみる - ザリガニが見ていた...。 文字エンコードとロケールを体感する - ザリガニが見ていた...。 改行コードの違いも知った。文字コードとロケール、ターミナルの言語環境との関係も知った。これで文字にまつわる悩みとはおさらばできると思ったら、まだダメだった...。 実験環境 OSX 10.8 Mountain Lion以前((OSX 10.9 Mavericksでは、Mac仕様なNFDのUTF-8を表示しようとするとエラーになってしまったため、10.8以前の環境で実験した。Assertion failed: (width > 0), function conv_c, file /SourceCache/shell_cmds/shell_cmds-175/hexdump/conv.c, line 137. ** ** Abort trap: 6
説明 a2ps で直接 UTF-8 なテキストファイルを印刷しちゃおうという試みです。 Fedora や Ubuntu あたりのパッチだと、EUC-JP は印刷できるけど UTF-8 の ファイルを直接印刷しようとすると文字化けしてしまうのです。 UTF-8 なテキストファイルを iconv とかで EUC-JP に変換するようなラッパー スクリプトを書いちゃえば良いと言えばそれまでですが、一応そのまま印刷でき るようなパッチを作成してみました。 とはいえ、a2ps の中で nkf (libnkfm)使って EUC-JP に変換してるだけとい う、かなりお粗末なものなので、もちろんw 日本語にしか対応していません。 m(__)m あと、エラー処理なんてしてませんので、気になる方は適当に直していただけ ますでしょうか。修正したものをフィードバックしてもらえるとうれしかったり します。 a2p
Oracleで文字列を入れるための項目属性 Oracleのデータベースの項目属性を定義する時、VARCHAR2()があります。 VARCHAR2()は、可変長の文字列です。 ()の中の数字が、挿入できるbyte数となります。 このByte数を超えると、ORA-12899値が大きすぎますというエラーがでます。 では、実際何文字入るのでしょうか。 VARCHAR()とVARCHAR2()は何が違うの? 本論に行く前に、少し余談です。 例えば、MySQLでは文字列の属性としてVARCHAR()があります。 しかし、OracleではVARCHAR2()です。 何故、Oracleは2なのでしょうか? 実は、Oracleも以前はVARCHAR()で定義していました。 しかし、ある時から廃止になり、現在はVARCHAR2()のみが利用されています(経緯不明)。 OracleのVARCHAR2(10)は何
コード変換において、JIS X 0208/0213の波ダッシュ「〜」(1面1区33点、 シフトJISでは8160)をUnicodeの「FULLWIDTH TILDE」(U+FF5E)にうつす実装は 不適切である。適切な変換先はWAVE DASH (U+301C)である。以下に理由を述べ る。 JISの規格では「〜」は「波ダッシュ」と記述されており、文字名称は WAVE DASHと規定されている。よってUnicodeのWAVE DASHに対応すると考える のが妥当。UnicodeのもとになったJIS X 0208-1990においてもやはり「波ダッ シュ」であった。チルダではない。 区点の並びからも、ダッシュやハイフンのような一般の記述記号の中にあ り、チルダが属すべきダイアクリティカルマークとは離れている。 Unicode仕様書のWAVE DASHの説明には「JIS punctuation」
ローカルに Wiki があるとメモに便利だと思ってインストールした。 いろんな種類がある Wiki だけど シンプルなアピアランス 日本語が不自由無く使えて ちゃんとした HTML を出力する Ruby で実装されている ということで Hiki を選んだ。 しかしこれは EUC-JP で出力され、まぁ特に不自由はしないんだけど、UTF-8 が好きなので UTF-8 でやりとりするように改造してみた。 とりあえず nkf で各テキストファイルを UTF-8 にする % find . -type f -exec nkf --in-place -w {} \; % find ~/hiki/data -type f -exec nkf --in-place -w {} \; ここで、~/hiki/data は hikiconf.rb の @data_path とする。 hiki.cgi の $KC
少し前からTwitterで見かけるようになった、上下に飛び出す変な顔文字。 気持ち悪いのであまり関わらないようにしていたのだが、この顔文字の謎が明らかになったのでお伝えしたい。 いつものようにiPhoneのApp Storeをぶらぶらしていた時のこと。 Unicoder Lite (App Store)というアプリが気になりダウンロードした。 起動するとなにやら見慣れた文字が。 顔文字でよく使われるギリシャ文字やキリル文字だ。 しばらく眺めているとこんな符号が。 合成用区分符号 これが上と下の行にはみ出す顔文字の正体だった。 ためしに作ってみよう。 ベースとなる顔文字を置く。 左目に合成用区分符号を入れる。 続いて右目に。 見事にはみ出す。 Unicode(ユニコード)とは、世界中のコンピュータの文字を符号化したもの。その "U+0300-036F" に配置されているダイアクリティカルマー
mysql> status; -------------- mysql Ver 14.7 Distrib 4.1.20, for redhat-linux-gnu (i386) using readline 4.3 Connection id: 36 Current database: staff2006 Current user: maiha@localhost SSL: Not in use Current pager: lv Using outfile: '' Using delimiter: ; Server version: 4.1.20 Protocol version: 10 Connection: Localhost via UNIX socket Server characterset: latin1 Db characterset: latin1 Client char
「プログラマのための文字コード技術入門」を読んで自分なりに理解した点をザックリとまとめてみる。 それほど正確性を求めて書いているわけではないので、間違ってる可能性大です。 間違いなどあればコメントなど頂けるとありがたいです。 それぞれの文字コードはどう違うのか? 日本語の文字コードは大きく以下の2つに分けられる JIS X 0208 文字集合をベースにしたもの Unicode文字集合をベースにしたもの JIS X 0208 文字集合をベースにした文字コードには、EUC-JP, Shift_JIS, ISO-2022-JP がある。 Unicode文字集合をベースにした文字コードには、UTF-8, UTF-16 などがある。 上で挙げた「文字コード」とは正確には「エンコーディング(文字符号化方式)」の事を指す。 文字符号化方式 文字集合って? 読んでそのまんま”文字の種類の集まり”。「キャラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く