「比較:(日本語 (Mac) - x-mac-japanese) (日本語 (シフト JIS) - CP932) - 文字コード表」の文字コード表です

Content-Length: 349715 | pFad | http://b.hatena.ne.jp/rabbit2go/UTF-8/
UTF-16のことをUnicodeと記しているソフトウェア(Windowsのメモ帳など)もありますのでUnicodeとあったらそれはUTF-16を使って変換したものなのだな、というふうに理解してください。 そうなってしまっている理由はこちらで解説されていました。 これでUnicodeとUTF-8の違いはバッチリですね!おわり。 読んで分かりやすかったり少しでも何か学べたと思えたら いいね や コメント をもらえるとこれからの励みになります! もう少し時間がある方へ 手計算で文字をUTF-8での符号まで計算してみましょう。 理解が一気に深まります。手順は以下。 文字のコードポイントをUnicodeから見つけてくる。 コードポイントをUTF-8の方式で変換してみる。 **Omiitaの「お」**をUTF-8による符号まで変換してみます。 文字「お」のコードポイントをUnicodeから見つけてく
TL;DR: UTF-8をデフォルトで使いたい人は環境変数に PYTHONUTF8=1 を設定しよう Python は文字列が unicode なので、あちこちで「適切」なエンコーディングを選択する必要があります。残念ながら後方互換性やWindows固有の事情によりまだ ANSI Code Page (日本語なら cp932) がデフォルトで使われる場面があります。 ざっと Python と外の世界との入出力をあげてみます。 テキストファイルを読み書きする時のデフォルトのエンコーディング = ACP 標準入出力のエンコーディング 標準入出力がコンソールのとき = UTF-16 で WriteConsoleW 等を呼ぶ 標準入出力がコンソールでない時 = ACP 子プロセスとのPIPE = ACP 最近 chcp 65001 を使って UTF-8 を使う方法が広まっているように思います。これ
今さらですけど、自分でもちゃんと把握してなかったので調べてみました。 MySQLのCharsetのうちシフトJIS系のものはsjisとcp932の二つあります。 どちらもコードの範囲は次のように同じです。 1バイト文字 0x00-0x7F, 0xA1-0xDF 2バイト文字の1バイト目 0x81-0x9F, 0xE0-0xFC 2バイト文字の2バイト目 0x40-0x7E, 0x80-0xFC 違いは文字集合です。1バイト文字はどちらも同じ(ASCII + JIS X 0201 カナ)ですが、2バイト文字はsjisはJIS X 0208 で、cp932はWindows-31Jです。 sjisに含まれていない文字 cp932はsjisよりも文字が多く、丸囲み数字(「①」「②」「③」等)、ローマ数字(「Ⅰ」「Ⅱ」「Ⅲ」等)、組文字(「㍉」「㌍」「㍻」等)、その他「彅」「髙」等の JIS X 0
動機 Redmine上で絵文字を記入し保存しようとすると… ゴール 文字コードがutf8で初期化されたDBをutf8mb4に変換し、Redmineで絵文字(4バイト文字)が書き込めるようにする 参考リンク MySQLでテーブルとカラムの文字コードを一括変更する - Be an Idealistic Realist ActiveRecordをutf8mb4で動かす - Qiita MySQL(InnoDB) で "Index column size too large. The maximum column size is 767 bytes." いわれるときの対策 - かみぽわーる 前提 これの続き Redmine を LXC on Ubuntu 14.04で動かす - Dig that groovy! といってもあまりコンテナうんぬんは関係ない MySQL 5.5.43-0ubuntu0
はじめに Twitterで、文字化けネタを幾つかつぶやきました。 サッちゃんはね サチコっていうんだ ほんとはね だけど ちっちゃいから 自分のこと SJISで 保存するんだよ おかしいな 繧オ繝ちゃん — ロボ太 (@kaityo256) 2017年10月10日 「私 魔女のキキです。こっちはSJISの繧ク繧ク」 — ロボ太 (@kaityo256) 2018年1月6日 UTF-8「もしかして…」 SJIS「私達…」 「「入れ替わ縺縺ヲ繧九≦縲懶シ†」」 — ロボ太 (@kaityo256) 2018年2月13日 どれもUTF-8で保存された文字をSJISとして解釈したための文字化けを表現したものですが、パッと見で「糸偏の漢字が多いな」ということがわかるかと思います。なぜそうなるかを簡単に説明してみようと思います。 なお、文字コードはいろいろ面倒なので、ここではざっくりとしたことしか言い
MySQL を UTF-8 で使おうと思ってハマりがちなのは charset utf8 を指定してしまうことです。 MySQL の UTF-8 には歴史的事情により utf8 と utf8mb4 の二つあります。 UTF-8 は1バイト〜4バイトで1文字が構成される文字コードですが、MySQL の utf8 は4バイト文字を扱うことができません。ハマりたくなければ utf8mb4 を使いましょう。 utf8 を使ってしまった場合に4バイト文字がどのように扱われるか、自分でもうろ覚えだったのでメモしておきます。 登録 接続が utf8mb4 でカラムが utf8mb4 あたりまえですが、そのまま登録されます。 mysql> insert into utf8mb4 (c) values ('美味しい🍣と🍺'); mysql> select * from utf8mb4; +--------
[2017/05/02 追記有り] Rubyの``やsystemで外部コマンド実行するときに、実行ファイル自体や引数にUTF-8文字(SJISマッピング無し)が渡せないのであれこれ悩んだ問題。 確認はWindows7 64bit & Ruby1.9.3p0(ActiveScriptRuby) 前提。WindowsはファイルシステムがNTFSならUTF-8ファイル名を命名できる。内部コードもUTF-8になっている(はず)。しかし古いAPIを触ったり、INPUT/OUTPUT周りを見るとまだShiftJIS(Windows-31J)が多い。このズレは厄介で、ハマりどころのA代表。特にRubyの場合、UNIX寄りでWindows特有処理のケアはやっぱり甘い… 閑話休題。Windows&UTF-8の扱いが比較的良くなっているRuby1.9系(Dir.globの引数に.encode('utf-8')
この前「Rubyのエンコーディング」という記事を書いたのですが、それをネタに 8/25 の NSEG で発表しました。 Rubyのエンコーディング from Masahiro Tomita この中で、エンコーディングが原因で予期しないところで落ちてしまうことが結構あるという話もしたんですが、今回はプログラムが落ちないようにするにはどうすればいいかを考えてみます。 エンコーディングが原因で落ちてしまうのは大体次のパターンのようです。 文字列や正規表現のエンコーディングが異なる 文字列中に不正な文字が含まれている 文字列や正規表現のエンコーディングが異なる 正規表現をリテラルで生成していれば、エンコーディングは敢えて指定しない限りは普通はスクリプトエンコーディングになってると思うので、問題は文字列の方です。 特にファイルから読み込んだ文字列のエンコーディングが何になっているかに注意しましょう。
Windows 環境でコマンドプロンプトを使って日本語を表示させようとして躓いたのでメモ。ソースコードを UTF-8 で書きたい人を対象にしています。 環境 Windows7 コマンドプロンプトデフォルトのままでコードページ 932 Ruby 1.9.2-p136 まとめ 先にまとめを書いておきます。 ソースコードを UTF-8 (BOM 無し) で書く。 ソースコードのエンコーディングを正しく判断できるように -*- encoding: utf-8 -*- をソースコードの先頭に書く ruby のオプションで -U を使うか、-Eexternal_encoding:internal_encoding を使う File.open する時は、デフォルトの外部エンコーディングで読みに行くので、オプションで適切なエンコーディングを指定する 例: File.open("test.txt", "r:
前回からの続き。 改行コードの違いを体感してみる - ザリガニが見ていた...。 文字エンコードとロケールを体感する - ザリガニが見ていた...。 改行コードの違いも知った。文字コードとロケール、ターミナルの言語環境との関係も知った。これで文字にまつわる悩みとはおさらばできると思ったら、まだダメだった...。 実験環境 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
Twitterをterminalで見ていると、ごく稀に変な文字が入っているtweetがあって、それがUTF-8-MACだとgeta6に教わった。 Macだと「ぱぴぷぺぽ」など一部の日本語をファイル名にすると変な事が起こるのだが、それの原因がUTF-8-MACらしい。 そういう文字をDBに保存するとのちのち良くないので、Rubyで変換した。 Iconv使ったら簡単だった。 ■例 touch ぱぴぷぺぽ echo は<309a>ひ<309a>ふ<309a>へ<309a>ほ<309a> となる。 ただし、TerminalやiTerm2で「ぱぴぷぺぽ」をechoやlsしてもふつうに「ぱぴぷぺぽ」になってしまって、Rubyに渡して変換を試せない。 GNU Screen上でechoやlsするとUTF-8-MACの文字を出力できる。 ■Rubyで変換 インストール brew install iconv
JDK5だとUTF-8なのですが、JDK6だとSJISになります。Terminalの文字コードはUTF-8なので、ちょくちょく書く時に問題が出てしまいます。JDK5を使えばいいのでしょうが、JDK6が必要になったときに困ります。なので環境変数JAVA_OPTIONSにこのように設定しました。 export JAVA_OPTIONS="-Dfile.encoding=UTF-8" ひとまずこれで良しとします。 ちなみにJDK6を使用した理由ですが、以前どっかの本でAndroid SDKを使うにはJDK6にしないといけないとか読んだ気がするからです。ですが今 http://developer.android.com/sdk/1.5_r2/requirements.html を読んだら JDK 5 or JDK 6 (JRE alone is not sufficient) と書いてあって No
Androidプラットホームの標準の文字エンコーディングはUTF-8だが、日本ロケールのWindowsでSDKのツールを使うと、OS標準のエンコーディング(日本の場合MS932)以外に上手く対応できず、英数字以外は正しく表示できない場合がある。 具体的にはログを出力するLogcatだが、Eclipse ADTのDDMSパースペクティブでは以下のように日本語が文字化けしてしまう。 04-03 17:49:15.649: DEBUG/Log test(444): æ—\本語ã�§æ£ã�—ã��表示ã�•ã‚Œã�¦ã�„ã‚‹ã�‹ã�ª?同機能はEclipseからフォントを変更できるのだが、エンコーディング自体をUTF-8に変更できる訳ではないので、どんなフォントにしても結局日本語を正しく表示することができない。 Logcatはコマンドプロンプトから実行することもできるの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/rabbit2go/UTF-8/
Alternative Proxies: