GitHub - knu/ruby-unf: A wrapper library to bring Unicode Normalization Form support to Ruby/JRubyYou 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
Ruby 1.8 と 1.9 の両方で動作する簡易 CSV 形式データ処理を考える。 - 自分の歩いた道に落ちてるコード
この違いはとても大きいです。Ruby 1.9 では日本語の１文字を１文字として扱いますが、Ruby 1.8 ではそうはいきません。 Ruby 1.8 では同じ日本語でも、それを構成しているバイトコードの中身まで見えてしまうのです。 同じ日本語でもエンコードの方法によっては違うバイトコードの並びになります。 その中には今回区切り文字や囲み文字として採用したカンマ(,)やダブルクオーテーション(")に該当してしまうものが存在するかもしれません。 かといって、Ruby 1.8 でエンコードを意識して文字単位で処理をするのはとても難しいような気がします。 少なくとも、僕が持っている文字コードの知識にそんなものはありません。処理系がやってくれているからできることであり、自分で実装するとなるとどれほどの労力がかかることやら…という感じです。 しかし、この問題を解決するのが UTF-8 というエンコード
新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能 | 日経 xTECH（クロステック）
普段使用する漢字の指針となる「常用漢字表」が、2010年度にも改正される。新たに追加される196文字の中に、文字コード「シフトJIS」にない漢字が含まれているため、情報システムに大きな影響を与えそうだ。最新のJIS規格「JIS X 0213:2004」の改正に委員としてかかわった京都大学人文科学研究所附属東アジア人文情報学研究センターの安岡孝一准教授が、問題の核心を解説する。 （日経コンピュータ） 2009年11月10日、文部科学省の「文化審議会国語分科会」において、常用漢字表の改正案が承認された。現行の常用漢字表にある1945字から「銑」「錘」「勺」「匁」「脹」の5字を削除し、新たに196字を追加する改正案で、2010年度の内閣告示を目指している。 新しい常用漢字表が告示されると、「シフトJIS」や「EUC-JP」といった従来からある文字コードを使用するシステムで大きな問題が生じ
セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?
(Last Updated On: 2018年8月13日)一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。 その間違いとは 意図の取り違い – 誤読 言語の仕様と実装の理解不足 HTTPやPHP仕様の理解不足 セキュリティ対策をすべき場所の理解不足 です。(※0) 徳丸さんは非常勤とは言え、国の出先機関の研究員であるし、その出先機関は職務放棄とも言える文書（「例えば、PHPを使用しない」と勧める文書）を公開している(いた?)のでしっかり反論しておく必用がありますね。IPAのあの文書は職務放棄と言える文書だと思っています。これについても後で意見を述べます。 意図の取り違い – 誤読 最初の間違いは私のブログのエントリ「何故かあたり前にならない文字エンコーディングバリデーション」に対する理解です。特にPHPユーザに
第4回 Ruby M17N 事始め：文字コード編 | gihyo.jp
はじめに 今回は文字列を扱う際には忘れてはならない文字コードについて、日本人が知っておくべきエンコーディングを中心に解説していきます。 US-ASCII ASCIIは、ASA（American Standards Association、のちにUSASIを経てANSI）によって、1963年6月17日にASA X3.4-1963として制定され、1967年7月7日にUSASI（United States of America Standards Institute、ASAから1966年8月24日に改組）によってUSAS X3.4-1967へと改訂されてほぼ現在の形となりました。 その後の多くの文字コードがASCIIのスーパーセットとして作られたため、ASCIIは共通のサブセットとして特別な位置に置かれるようになりました。RubyでもASCIIに含まれる文字のみで構成されるStringは、ASC
Mac OS Xのリッチテキストの扱いに関する問題 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
works014さんの「テキストのコピー&ペーストと配置」を追試してみた。InDesignとエディタでテキスト・データのやり取りをする際、その方法の違いによって一部の文字の符号が変わってくるというもの。 わたしの環境（Mac OS X 10.5.2）では、エディタの設定が標準テキスト・モードの場合は問題は発生しなかったが、エディタをリッチテキスト・モードにしたところ、ほぼ再現。WindowsとMacでマッピングの異なる文字が、リッチテキストの受け渡しをする際に化けているかんじ。 下図は、JIS X 0208の範囲内の文字のうち、WindowsとMacでUnicodeマッピングが異なるもの。 上図のうち「Mac側の文字」をリッチテキスト・モードのJedit Xで1行目に入力し、これをコピーして2行目にペーストしたのが下図。ペーストした瞬間に、すべて「Win側の文字」に化ける。同じデータを標準
Apple Mailが送信する謎のハイブリッドCP932について - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
Apple MailがMacJapanese（90pv）のシステム外字を「ISO-2022-JPもどき」で符号化し、送信することについては、以前に指摘した。今回は、Apple MailがMacJapaneseのシステム外字を「CP932もどき」で符号化し、送信することについて。 符号化のルール自体は単純で、次のようにまとめることができる。「CP932に含まれる文字は、その符号位置となる。また、CP932に含まれない文字のうちMacJapaneseに含まれるものは、その符号位置となる」 たとえば「丸付き数字の1」（U+2460 CIRCLED DIGIT ONE）は、CP932に含まれるし（0x8740）、MacJapaneseにも含まれる（0x8540）。この場合、Apple Mailの送信するCP932において、「丸付き数字の1」は（当然だが）0x8740で符号化される。 一方「黒ハート
Apple Mailにおけるテキストエンコーディングの優先順位 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
以前のエントリで以下のように書いたが、ちょっと訂正。 Apple Mail（バージョン2.1（752/752.2）で確認）は、日本語環境においては、送信しようとしているメールに含まれる文字の種類によって、US-ASCII＞ISO-2022-JP＞CP932＞UTF-8の優先順位でcharsetを決定しているようだ（CP932というcharsetはIANAに登録されていないという議論は、ここでは措く）。 表が修正版。下に行くほど優先順位が低い。上記の引用部分との違いは、SHIFT_JISが追加されている点である。 文字の範囲 Apple Mailの符号化方法 ASCII US-ASCII JIS X 0201ラテン文字集合 SHIFT_JIS MacJapanese ISO-2022-JP CP932 CP932 Unicode UTF-8 不思議な表である。「MacJapaneseの範囲の
ロケールテーブル - MoodleDocs
イントロダクション 定義: ( Wikipedia - 英文 より ) ロケールは、ユーザがユーザインターフェースで表示するための、言語、国および表記規則を設定する変数です。通常、ロケール識別子 （ LCID：LoCale IDentifiers ） は、言語および地域の識別子を含みます。 現在、ロケールはUnixベースおよびWin32ベースのプラットフォームでは、異なる名前付けがなされています。そのため、私たちはMoodleが必要に応じてそれらを使用するため、分けて定義する必要があります。Moodleで利用できる各「言語パック」では、locale値 ( Unixロケール ) および localewin値 ( Win32ロケール ) を指定してください。両ストリング ( 非強制 ) は、Moodle1.6以上の言語パックがロケールストリングを適切に表示するため定義すべきです。 ロケールの一
Language Identifier - Language Detection - Rosette Text Analytics
Instantly identify the language of whole documents or multiple language regions within each document What is language detection? Language identification is the first step in any text analysis or natural language processing pipeline. If the language of a document is misidentified, all subsequent language specific models will produce inaccurate results. Errors at this stage of analysis can snowball
[R3]miniturbo.org - 携帯電話での文字コード対応表 まとめ#extended
このリストを見る限り、最近の機種は殆どが対応しているようです。SO506iCがEUC-JPに対応しているのは意外でした。 各社の仕様書を見比べると、Shift JISは全社とも対応していて、DoCoMoのXHTML対応機種に限りUTF-8にも対応していることが記載されていました。また、SoftBankの携帯電話はメール及びウェブの文字コードを手動選択できるようです。各社の仕様書を以下にリンクいたしましたので、ご覧ください。 iモード対応HTMLの概要 iモード対応XHTMLの概要 EZWeb サーバ設定・文字コード指定 SoftBank Developers Support Site なお、検証への誘導をしていただいた真琴さんと、多くの機種を検証していただいたreaさん、サンプルを怪しみながらも協力してくれた僕の友人、それからわざわざコメントorトラックバックしていただいた皆々様方に深く感
miniturbo.org - EZWebでの文字コード
miniturbo.orgは携帯でも一応見れるのですが(コンテンツ量が多すぎるとメモリエラーがおきるかも)、それもこれもXHTMLで書いているからなのです。そこでふと疑問に思うことが。 昔、課題として携帯用のコンテンツを作成していたときに3キャリアの仕様書をにらめっこしていたのですが、どのキャリアもサポートする文字コードはShift JISだったのです。しかし、miniturbo.orgはUTF-8にて書かれています。なのに文字化けしないのはどうしてなんだろう…。 と、いうことで検証に協力してください！ サンプルページに直接飛べるQRコードを作成いたしましたので、「別に手伝ってあげてもいいんだからねっ」という方はご協力お願い致します!「QRコード対応してないんだけど…」という方は、お手数ですが http://tinyurl.com/2d25jy からご確認お願いいたします。 お使いの携帯電
リアルな資産運用の結果をお見せします。海外投資が調子良い！
「私のリアルな海外投資の結果をお見せします」を運営している管理者です。お越しいただきありがとうございます。 投資全般が好きな私は国内株式や海外への不動産投資や株式・定期口座など多くの投資をしています。 情報収集で多くの投資ブログを閲覧していますが、圧倒的に「投資に失敗している人」が海外投資を批判する内容の記事が多いことに驚きました。 海外投資に失敗している方の特徴はどれも中間業者の選定に間違いがあると感じています。そう海外投資には必ず資産を運用する会社があってこの運用会社の投資の腕にかかってるのです。この選定さえきちんとすれば確実に海外投資はよい結果が期待できます。投資なのでリスクは必ずありますがそのリスクを極力少なくする私の経験を交えて情報を配信したいと思います このサイトは「将来の日本は大丈夫だろうか？」「国家破たんもあるの？」「日本に資産を置いても全然増えない！」でも海外投資は怖いし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
