回答編集履歴
2
latin1 -> hexに変更
test
CHANGED
|
@@ -1,16 +1,22 @@
|
|
|
1
|
-
[https://sta
|
|
1
|
+
[https://shmztkyk.hatenablog.com/entry/2013/11/12/165457](https://shmztkyk.hatenablog.com/entry/2013/11/12/165457)
|
|
2
|
+
|
|
3
|
+
|
|
4
|
+
|
|
5
|
+
> utf8じゃなくてhexでとれってさ。
|
|
2
6
|
|
|
3
7
|
|
|
4
8
|
|
|
5
9
|
> ```js
|
|
6
10
|
|
|
7
|
-
> var
|
|
11
|
+
> var token = notification.device['token']
|
|
8
12
|
|
|
9
|
-
>
|
|
13
|
+
> console.log(token.toString('hex', 0, token.length));
|
|
10
|
-
|
|
11
|
-
> var b2 = Buffer.from(s, 'latin1');
|
|
12
14
|
|
|
13
15
|
> ```
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
> すると `3fa1327c1e25b58dc351c110d1b55a613168cd6b91a7b911e47ef88ce3XXXXXX` みたいな文字列になってちゃんと取れました。
|
|
14
20
|
|
|
15
21
|
|
|
16
22
|
|
|
@@ -36,7 +42,7 @@
|
|
|
36
42
|
|
|
37
43
|
const bin = fs.readFileSync("sample.png");
|
|
38
44
|
|
|
39
|
-
const str = Buffer.from(png).toString("
|
|
45
|
+
const str = Buffer.from(png).toString("hex");
|
|
40
46
|
|
|
41
47
|
fs.writeFileSync("sample.txt", str);
|
|
42
48
|
|
|
@@ -52,7 +58,7 @@
|
|
|
52
58
|
|
|
53
59
|
const str = fs.readFileSync("sample.txt");
|
|
54
60
|
|
|
55
|
-
const bin = Buffer.from(png, "
|
|
61
|
+
const bin = Buffer.from(png, "hex");
|
|
56
62
|
|
|
57
63
|
fs.writeFileSync("test.png", bin);
|
|
58
64
|
|
|
@@ -100,12 +106,14 @@
|
|
|
100
106
|
|
|
101
107
|
|
|
102
108
|
|
|
103
|
-
これが上で使った`
|
|
109
|
+
これが上で使った`hex`のやっていることです。
|
|
104
110
|
|
|
111
|
+
`latin1`や`askii`指定はバイナリ文字列を無理やりUTF-8への変換を挟む事になりそう。
|
|
112
|
+
|
|
105
|
-
|
|
113
|
+
編集前の回答も上手く動いて無かったので、多分不可逆になってデータが壊れてますね。
|
|
106
114
|
|
|
107
115
|
|
|
108
116
|
|
|
109
|
-
お約束として記載しておきますが、
|
|
117
|
+
最後にお約束として記載しておきますが、
|
|
110
118
|
|
|
111
119
|
やってる事が意味があるか無意味かで言えばまぁほぼ無意味ですけどね。
|
1
詳細解説を追加
test
CHANGED
|
@@ -63,3 +63,49 @@
|
|
|
63
63
|
Node.jsの`Buffer.from`は色んな型を放り込んでよしなに動いてくれますが、
|
|
64
64
|
|
|
65
65
|
動かなかったら`readFileSync`後に`.toString()`をかませて様子を見てください。
|
|
66
|
+
|
|
67
|
+
|
|
68
|
+
|
|
69
|
+
> そもそもこの方法でpngとして復元することは可能でしょうか
|
|
70
|
+
|
|
71
|
+
|
|
72
|
+
|
|
73
|
+
仕様を考えれば十分いける範囲ですね
|
|
74
|
+
|
|
75
|
+
コンピュータは`101010`という二進数で動いているという話がありますが、
|
|
76
|
+
|
|
77
|
+
これだと区切りがわからなくて人間が死ぬので、
|
|
78
|
+
|
|
79
|
+
実際は`1111`の4桁を1文字に纏めた16進数で管理しています。
|
|
80
|
+
|
|
81
|
+
|
|
82
|
+
|
|
83
|
+
16進数の表現方法は普通の0-9にA-Fを追加した16文字を使います。
|
|
84
|
+
|
|
85
|
+
この16進数2桁の00-FFを1バイトと表現します
|
|
86
|
+
|
|
87
|
+
※因みに機械語の01の二進数1桁分を指して1ビットと呼ぶ
|
|
88
|
+
|
|
89
|
+
|
|
90
|
+
|
|
91
|
+
なので愚直にファイルの先端から読み取ったビット列をバイトの並びとして取り出して
|
|
92
|
+
|
|
93
|
+
`0F1E2D3C...`みたいな感じのテキストファイルに加工してやればシリアライズ(文字列化)は可能です。
|
|
94
|
+
|
|
95
|
+
|
|
96
|
+
|
|
97
|
+
逆にこのテキストファイルをビット列に変換しながら挿入していき、
|
|
98
|
+
|
|
99
|
+
1個のファイルに格納すればデシリアライズ(文字列からの復号)を行った事になります。
|
|
100
|
+
|
|
101
|
+
|
|
102
|
+
|
|
103
|
+
これが上で使った`latin1`のやっていることです（多分、違ったらごめん）
|
|
104
|
+
|
|
105
|
+
ASKII指定だと上手く動かないかと思います。
|
|
106
|
+
|
|
107
|
+
|
|
108
|
+
|
|
109
|
+
お約束として記載しておきますが、
|
|
110
|
+
|
|
111
|
+
やってる事が意味があるか無意味かで言えばまぁほぼ無意味ですけどね。
|