新元号「令和」と文字コード(主にUnicode)の問題境 真良@iU/GLOCOM/METI（あーりん推し/芸能人スキャンダル要らない） @sakaima 「令和」ですが、「令」はUnicode「U+4EE4」、UTF-8だと「E4 BB A4」、シフトJISだと「97DF」、また「和」はUnicode「U+548C」、UTF-8で「E5 92 8C」、シフトJISだと「9861」です。とりあえずご参考まで。 #さてお仕事ですよ 2019-04-01 11:46:49
絵文字を支える技術の紹介 - Qiita
絵文字を扱う上で知っておくと良いかもしれないことをまとめてみました。 Ruiさんの記事を見て、「EmojiはSurrogate Pair以外にも、色々とおもしろい技術があるんですよ〜」思って書いてみました。 なお、書いた人はAndroidの人間なので、特に表記していない場合は主にAndroid上での動作のことを書いてます。 またQiita初めてなので読みにくい部分等がありましてもご容赦ください。 サロゲートペア(Surrogate Pairs) このエントリーを書くきっかけにもなったサロゲートペア。なぜこれが導入されたかの経緯は、Ruiさんのブログエントリーに譲るとして、技術的な解説をします。 サロゲートペアは、U+0000..U+FFFFに収まりきらなかった範囲のUnicodeコードポイント(U+10000..U+10FFFF)を、なんとか16bitでエンコードしようとして導入されました
MySQLの文字コード事情 2017版
こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk
Unicodeと、C#での文字列の扱い
進化の過程で煩雑な文字コード体系になっているUnicodeは、プログラミングでの取り扱いが面倒だ。C#とUnicodeの関係はどうなっているのか？ C#が抱える課題とその解決策について見てみよう。 ← 前回 連載 INDEX 前編では、文字コード、そしてUnicodeがこれまでにどのような進化の道程を歩んできたかを見た。そこで説明したように、文字コード自体が結構な複雑さになっている。当然、プログラミング言語における文字列の扱いにも面倒が付きまとう。 後編である今回は、C#のstring型がどういう実装になっているかや、現状抱えている課題、それに対して検討している解決策などについて説明していく（以下、文字コードは全て16進数で表記する）。 文字列型 まずは、プログラミング言語内部での文字列の扱いについて話そう。Unicodeの歴史で話した通り、もともと、Unicodeは2Bytes固定長の文
Rubyの内部文字コードはUTF-8ではない...だと...？！｜TechRacho by BPS株式会社
こんにちは、hachi8833です。 少し前に、babaさんから「Rubyの内部文字コードはUTF-8じゃないよ」とツッコミがありました。 （追記: 上は会話の途中から切り取りましたのでご了承ください） いきなりの展開にくらくらきましたが、babaさんはさらにたたみかけます。 こうしたことはとっくにご存じの方も多いと思いますが、「Rubyといえば2.0以来UTF-8完全対応なんじゃないの」と勝手に思い込んでた私は脳に掌底を食らったような思いです。ああ、でもこういうことがあるから面白い。 ⚓ プログラミング言語と内部文字コードの関係 まず最初に押さえておきたい点です。プログラミング言語で文字コードに関連する部分は、「文字列」「正規表現」「入出力」「コード中の文字リテラル（""の中など）」「コード中の文字リテラル以外の要素（変数名など）」「ファイル名」などが中心になります。そして文字列に関連し
どんぶらこDESIGN 我78がひとつなり
全然気がつかなかったのだけれど、先日のお姐さんのコメントにあった「斜め線」の不思議について。 Windowsだけで起こるバグのようなもので、Mac上ではたとえChromeを使っていようともそのような表示は見られませんでした。 要はこういうこと。 Googleで「我78がひとつなり」と検索すると、検索結果の中に斜め線が現れます。 詳しく観ると、「ส้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้」という検索結果の中の文字から点線が斜めに伸びていることが確認できます。この「ส้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้้」という文字はタイ語で「HD」っていう意味を持つ文字らしい。「超」みたいなものか？（笑） これがMacではそうならないのだけれど、「ส็็็็็็็็็็็็็็็็็็็็็็็็็็」と「ส้้้้้้้้้้้้้้้้้
Mac OS X の NFD 問題での対策諸々 - Qiita
おさらい。 ∥ Unicode正規化 - Wikipedia 正規化形式 NFC: Normalization Form Canonical Compression | 文字に何がくっついていようと、組み合わせて作られた文字であろうと、「一文字」は「一文字」じゃ。圧縮形式。Linux のファイルシステムや Windows の NTFS などが普通に使っている。 NFD: Normalization Form Canonical Decompression | 濁点・半濁点を、あるいはウムラウト等のダイアクリティカルマークを、本体の文字とは分離してエンコードした形式。OS X の HFS+ が、これを採用してくれちゃっている。 基本としては、OS X 上に置かれるファイルは NFD であってくれて、Linux や Windows 上にあるファイルは NFC であってくれると平和で助かる。 追
Shift_JIS 文字コード表
注 このページはWindowsMeというOSでJavaの学習をしていた時代にファイル内の文字コードを見るときの参考に書かれものです。ページの文字コードもShift_JISのままにしてあります。 このページで説明している文字コードは、JIS X 0208 にNEC選定IBM拡張文字とIBM拡張文字を加えたものです。最近では拡張文字を含んだものをwindows-31jとかCP932とよんで、Shift_JISは拡張文字を含まない場合をいう傾向にあります。 Windows7から JIS X 0213 に対応しましたが、これをShift_JIS(Shift_JIS:2004)にすると拡張文字の部分が0213で追加された文字とは衝突します。Windowsでは互換性の確保の観点からShift_JISのテキストファイルはWindows-31jにしますから、ここに書かれた情報はいまでも合致するはずです。た
Visual Basicの全角キーワード
Visual Basicでは、BASIC時代からずっとですが、アルファベットの大文字と小文字を区別しないことは皆さまもご存知かと思われます。 で、実は、大文字小文字だけじゃなくて、半角全角も区別しないという。以下のコード、コンパイルして実行することもできるし、Visual Studio上ではちゃんと、Ｍｏｄｕｌｅとかの部分が青色(キーワードの色)で表示されます。 Ｍｏｄｕｌｅ Module1 Ｓｕｂ Main() Ｄｉｍ x = 10 Console.WriteLine(x) Ｅｎｄ Ｓｕｂ Ｅｎｄ Ｍｏｄｕｌｅ まあ、今のVisual Studio上では、全角文字でキーワードを打つと、自動補完で打ったそばから半角CamelCaseに変換されていくんで、自動補完に直されるたびにCtrl+Zで元に戻したりしないとこのソースコードを作れなかったりはするんですが。 もちろんRoslynでもいまだ
UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか？を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、（2/3）SQLインジェクションを根絶！セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題：ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『￥』は？」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
第4回 UTF-8の冗長なエンコード | gihyo.jp
今回は、文字コードに関連するセキュリティの話題では古参ともいえるUTF-8の冗長なエンコードというテーマについて紹介します。 UTF-8とは UTF-8は、各文字を1～4バイトの可変長で表現するUnicodeの符号化方式のひとつです。 U＋0000からU＋007Fの範囲の文字を0x00から0x7Fの1バイトで表現しているため、US-ASCIIと互換性がある、バイト列の途中からでも文字の先頭バイトを簡単に検出できる、多バイト文字の途中に0x00や0x5C（\）、0x2F（/）などが現れない、などの特徴があります。 UTF-8での文字のビットパターンは表1のようになります。 表1 UTF-8でのビットパターン
Unicode版 文字コード表
+15 ここで先ほどメモした「0159」という数値が役に立ちます。 まず、上３桁と下１桁に分割し、上３桁には末尾に０を、下３桁には頭に＋をつけます。 ＜例＞ 「0159」→「0150」と「+9」という風に分割します。 そこで上の表の一番左の列の "0150" と書かれてあるところから右にたどっていき、一番上の行の "+9" と書かれているところから下にたどっていった場合に交わる場所に ř という文字を見つけることが出来ます。 そこで、今度は左から２列目と上から２行目に書いてある数値が登場します。 これは、一番左の列は一番上の行に書いてある「16進数の数字」を「10進数の数字」に変換したものです。 これによると、"0150" は 10進数で "336"、"+9" は 10進数で そのまま "+9" と変換できます。 この２数を足した値、"345" が ř という文字の10進数での文字コードに
U+FFFF以上の文字ってなんや → サロゲートペアってなんや → Spring Web Services が言うことを聞きません！ とかで一日潰れた話 - エンジニア的なネタを毎週書くブログ
表題のような感じなのですが、これまで理解が曖昧だったUnicodeとか何とかが今までよりわかったのでメモ。 尚、こちらのサイトを非常に参考にさせていただきました。 Unicodeについて コードポイントとは 文字コードとは 今日覚えた単語その一。Unicodeに限らず、文字をコンピュータ上で表現する際、1つの文字に1つの数値を対応させるわけですが、この文字に対応する数値をコードポイントというそう。 いままでASCIIコードとか呼んでました。 そして、文字と数値の割り当てのルールのことを「文字コード」と言うんだそうです。 Unicodeとは から UTF-XXは何が違うんじゃ という話へ Unicode誕生 文字コードが乱立したため、あるコードポイントで表現される文字が、文字コードによって、てんでばらばらという状況に。 ややこしいから、ひとつの統一した文字コードをつくろう！ ということで「U
Shift_JIS、CP932、MS932、Windows-31J（文字コード関連） | 読み物 | ウナのIT資格一問一答
Windows標準の文字コードはShift_JISではなく、Windows-31Jです。 それらの違いやCP932、MS932といった用語もあわせて整理してみましょう。 まずはShift_JIS。 これは日本語の文字集合を符号化する文字符号化方式のうちの一つです。 Microsoftにより、MS-DOSの標準日本語コードとして採用され、CP932という管理番号を与えられるとともに独自の拡張が行われました。 MicrosoftはこのCP932を独自に拡張することを、OEMメーカー（MS-DOSを搭載したパソコンを販売するメーカー）に許していたため、各OEMメーカーごとに異なる拡張が行われました。 その後、MicrosoftはWindows3.1の日本語版を出すにあたり、OEMメーカーにCP932の独自拡張を許すという方針を撤回し、当時、日本のパソコン市場で特に大きなシェアを持っていたIBMと
文字コード表 シフトJIS(Shift_JIS)
シフトJISの1バイトコード（半角文字）のエリア 0x00～0x1f、0x7f は制御コードです 0x20～0x7e はASCII文字です 0xa1～0xdf は半角カタカナです シフトJISの2バイトコード（全角文字）のエリア（JIS X 0208の漢字エリア） 上位1バイト 0x81～0x9f、 0xe0～0xef 下位1バイト 0x40～0x7e、 0x80～0xfc ですが機種に依存しない観点より、ＨＴＭＬで以下の水色エリアは使用しないのが無難です 水色エリアはJIS X 0208 (1990) to Unicode 漢字コード表に存在しないコードです 0x8540～ 0x889e は機種依存文字の主なエリアです 0xeb40～ 0xeffc はMacOS では縦書用文字、Windows では特殊な外字エリアです 0xf040～ は外字エリアです（記載していません） perlで
Unicode 空白文字等調査 - s_hiiragiの活動メモ
Unicode 'Other, Format'カテゴリ (Cf) コード 意味 バージョン コメント U+200B ZERO WIDTH SPACE Unicode 1.1.0 幅の無い空白 U+200C ZERO WIDTH NON-JOINER Unicode 1.1.0 U+200D ZERO WIDTH JOINER Unicode 1.1.0 U+FEFF ZERO WIDTH NO-BREAK SPACE Unicode 1.1.0 幅の無い改行しない空白 Unicode 'Separator, Line'カテゴリ (Zl) コード 意味 バージョン コメント U+2028 Line Separator Unicode 1.1.0 LS Unicode 'Separator, Paragraph'カテゴリ (Zp) コード 意味 バージョン コメント U+2029 Paragr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ハッシュタグ #tlをส็็็็็็็็็็็็็็็็็็็็็็็
http://www.eva.hi-ho.ne.jp/cgi-bin/user/zxcv/decodeUTF8.cgi
文字化け
UnicodeのWAVE DASH例示字形が、25年ぶりに修正された理由 
