サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
Last update 日本語には、いろんな文字コードがあります。 ややこしすぎるので、嫌です。 文字集合 エンコード + 文字コード 変換表 基礎知識 文字セット、エンコード(符号化方式)、2種類にわけて、この組み合わせで1つの文字コードになります。Unicodeをベースにしていることもあるのでさらに変換表的なものも加わると恐ろしいぐらいいろいろあります。 文字セットは、JISの場合、区点番号という区(row)と点(cell)と呼ばれる2つのコードを合わせて漢字1文字を指定します。区と点は1バイト目と2バイト目のような関係です。JISの区点はそれぞれ1〜94です。JIS X 0213やUnicodeになると区点では不足するため面(plane)という区点を区別するコードを加え、面区点の3つで区別します。 ISO-10646などでは、面区点でも不足する可能性があるため群(group)とい
お知らせ ('12/4/10) 「msysGit」「Git forWindows」v1.7.10が公開、UTF-8のファイル名に対応('12/4/10 窓の杜) ようやく本家 Git forWindows がUTF-8ファイル名に対応しました。このページで公開していたUTF-8 ファイル名対応 Git forWindows はこれでお役御免となります。一応、資料としてページはここに残しておきますが、今後は本家 Git forWindows をお使いください。 なお、本家にはここで公開しているパッチは取り込まれていません。本家のパッチは KarsteenBlees 氏によるものです。 やっている内容はここに記載した方針と少し違い、POSIXAPI レベルで差し替えるのではなく、mingw.c 内にある ANSIAPI 呼び出しを UnicodeAPI に変更しているようで
Unicode® 6.0.0 Released: 2010 October 11 (Announcement) Version 6.0.0 has been superseded by the latest version of the Unicode Standard. Unicode 6.0.0 is a major version of the Unicode Standard. This page summarizes the important changes for the Unicode Standard, Version 6.0.0. In the discussion below, shortened references to "Unicode 6.0" or "Version 6.0" specifically refer to Version 6.0.0. Cont
This RFC is labeled as "Legacy";it was published before a formal source was recorded. This RFC is not endorsed by the IETF and has no formal standing in the IETF standards process.Network Working Group M. Ohta Request for Comments: 1554 Tokyo Institute ofTechnology Category: Informational K. Handa ETL December 1993 ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP Status of this Memo This me
Network Working Group K. Tamaru Request for Comments: 2237Microsoft Corporation Category: Informational November 1997Japanese Character Encoding for Internet Messages Status of this Memo This memo provides information for the Internet community.It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1997)
Copyright (c) 2017 Ministry of Economy,Trade and Industry. All Rights Reserved.
written on May 25, 2010 Yesterday after my talk about WSGI onPython 3 I announced an OpenSpace about WSGI. However only two people showed up there which was quite disappointing. On the bright side however:it was in parallel to some interesting lighting talks and I did not explain to well what the purpose of this OpenSpace was. In order to do better this time around, I want to summarize the curre
起源 円記号問題の始まりは1960年代にまで遡ります。1967 年に文字コード最初の国際規格である ISO R 646 が制定されましたが、その規格では 0x5C をはじめとして一部の文字が置き換え可能になっていました。アメリカの制定した ASCII では 0x5C に対して REVERSESOLIDUS を割り当てました。一方、日本版である JIS X 0201 では YEN SIGN を割り当てました。 問題の拡大 7bit では扱いきれない文字を扱うため、世界で ISO 646 系のコードを拡張した文字コードが生まれました。日本ではシフトJIS、日本語 EUC、いわゆる JIS コードの三種類の文字コードが現れ、それぞれに多くの亜種が生まれました。では、それぞれの文字コードの 7bit 領域は ASCII と JIS X 0201 のどちらだったのでしょうか。 日本語 EUC 日本
珍しく書評です。まだ書きかけなんですが、完成を待つと忘れそうなのでとりあえず。 断片的に見た感じとして、現在ある文字コード本では最高峰なんじゃないでしょうか。人に勧める文字コード本としては*1、長らく文字コード超研究がベストだったと思うのですが、今後はこれでしょう。Ruby 1.8/1.9 ざっと見た限りでは誤りを見つけられませんでした。と、いうわけでこれはよい記述だと思います。 UCS-2 下記で引用を交えつつ紹介していますが、UCS-2は「文字集合」ではなく「文字符号化方式」でしょう。ISOの文書自身でもUCS-2を文字集合であるかのように扱っている記述があるのがアレなんですが、定義を見ればISO/IEC 10646を見てもUnicodeを見ても文字符号化方式だと解釈するのが妥当です。 http://d.hatena.ne.jp/nurse/20090325 http://d.hat
2009/2/8追記: 今はもう↓の公式ドキュメントやid:macksさんのドキュメントなどいろんな情報が出ているので、このメモの存在意義は微妙ですが、一応1.9.1に合わせて修正しておきました。 多言語化 class String class IO この辺のドキュメントが見つからず（まだない？）、いろいろ試行錯誤して分かったことをメモ。 まず、Ruby 1.9では文字列オブジェクトがそれぞれ文字コードを持っている。 p "a".encoding #=> #<Encoding:US-ASCII> ファイルの先頭に # -*- encoding:UTF-8 -*- と書いておくと、文字列リテラルのencodingがUTF-8になる。 p "あ".encoding #=> #<Encoding:UTF-8> p "a".encoding #=> #<Encoding:UTF-8> これを書か
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
