处理二进制数据和 mb_function 重载?
Dealing with binary data and mb_function overloading?
我这里有一段代码,我需要保证,或者 "no no no!" 关于我是否以正确或完全错误的方式思考这个问题。
这要处理在特定位置切割二进制数据的变量,还要处理多字节重载函数。例如 substr
实际上是 mb_substr
而 strlen
是 mb_strlen
等等
我们的服务器设置为 UTF-8
内部编码,所以我做了一件奇怪的小事来绕过它进行二进制数据操作:
// $binary_data is the incoming variable with binary
// $clip_size is generally 16, 32 or 64 etc
$curenc = mb_internal_encoding();// this should be "UTF-8"
mb_internal_encoding('ISO-8859-1');// change so mb_ overloading doesnt screw this up
if (strlen($binary_data) >= $clip_size) {
$first_hunk = substr($binary_data,0,$clip_size);
$rest_of_it = substr($binary_data,$clip_size);
} else {
// skip since its shorter than expected
}
mb_internal_encoding($curenc);// put this back now
我无法真正显示输入和输出结果,因为它是二进制数据。但是使用上述方法进行的测试似乎工作正常,没有任何问题...
然而,我的部分大脑在尖叫"what are you doing... this can't be the way to handle this"!
备注:
- 传入的二进制数据是这两部分的串联。
- 第一部分的大小始终已知(但会发生变化)。
- 第二部分的大小完全未知。
- 这非常接近于加密并在前面填充 IV 并再次撕掉它(奇怪的是,我发现一些旧代码也做同样的事情哈哈)。
所以,我想我的问题是:
- 这样做真的好吗?
- 或者我忽略了一些非常明显的东西?
However, parts of my brain are screaming "what are you doing... this can't be the way to handle this"!
你的脑子是对的,你一开始就不应该在 PHP 中这样做。 :)
Is this actually fine to be doing?
这取决于您编写代码的目的。
我看不出有任何理由像那样剪切二进制文件。所以我的第一直觉是 "no no no!" 使用 unpack() 将二进制文件正确解析为可用变量。
话虽这么说,如果您只是因为某些原因需要拆分二进制文件,那么我想这很好。只要您的测试确认代码对您有效,我就看不出有任何问题。
附带说明一下,我并没有完全针对这种用例使用 mbstring 重载 - 即,当您需要默认字符串函数时。
我的解决方案
我不喜欢回答我自己的问题...但我还是想分享我的决定。
尽管我有 "worked",但我仍然想更改字符集编码的 hack-job-altering。我承认这是旧代码,但出于某种原因,我从来没有看过 hex2bin
bin2hex
这样做。所以我决定将其更改为使用这些。
生成的新代码:
// $clip_size remains the same value for continuity later,
// only spot-adjusted here... which is why the *2.
$hex_data = bin2hex( $binary_data );
$first_hunk = hex2bin( substr($hex_data,0,($clip_size*2)) );
$rest_of_it = hex2bin( substr($hex_data,($clip_size*2)) );
if ( !empty($rest_of_it) ) { /* process the result for reasons */ }
使用十六进制函数,将混乱变成 mb 无法解决的问题。一个 100 万次的工作台循环,表明这个过程没有什么值得担心的(而且它 运行 与自身并行比 mb_encoding mangle 方法更安全)。
所以我要这样做。它更适合我的想法,并暂时解决了我的问题......直到我在几年后再次访问这段旧代码并去 "what was I thinking ?!".
我这里有一段代码,我需要保证,或者 "no no no!" 关于我是否以正确或完全错误的方式思考这个问题。
这要处理在特定位置切割二进制数据的变量,还要处理多字节重载函数。例如 substr
实际上是 mb_substr
而 strlen
是 mb_strlen
等等
我们的服务器设置为 UTF-8
内部编码,所以我做了一件奇怪的小事来绕过它进行二进制数据操作:
// $binary_data is the incoming variable with binary
// $clip_size is generally 16, 32 or 64 etc
$curenc = mb_internal_encoding();// this should be "UTF-8"
mb_internal_encoding('ISO-8859-1');// change so mb_ overloading doesnt screw this up
if (strlen($binary_data) >= $clip_size) {
$first_hunk = substr($binary_data,0,$clip_size);
$rest_of_it = substr($binary_data,$clip_size);
} else {
// skip since its shorter than expected
}
mb_internal_encoding($curenc);// put this back now
我无法真正显示输入和输出结果,因为它是二进制数据。但是使用上述方法进行的测试似乎工作正常,没有任何问题...
然而,我的部分大脑在尖叫"what are you doing... this can't be the way to handle this"!
备注:
- 传入的二进制数据是这两部分的串联。
- 第一部分的大小始终已知(但会发生变化)。
- 第二部分的大小完全未知。
- 这非常接近于加密并在前面填充 IV 并再次撕掉它(奇怪的是,我发现一些旧代码也做同样的事情哈哈)。
所以,我想我的问题是:
- 这样做真的好吗?
- 或者我忽略了一些非常明显的东西?
However, parts of my brain are screaming "what are you doing... this can't be the way to handle this"!
你的脑子是对的,你一开始就不应该在 PHP 中这样做。 :)
Is this actually fine to be doing?
这取决于您编写代码的目的。
我看不出有任何理由像那样剪切二进制文件。所以我的第一直觉是 "no no no!" 使用 unpack() 将二进制文件正确解析为可用变量。
话虽这么说,如果您只是因为某些原因需要拆分二进制文件,那么我想这很好。只要您的测试确认代码对您有效,我就看不出有任何问题。
附带说明一下,我并没有完全针对这种用例使用 mbstring 重载 - 即,当您需要默认字符串函数时。
我的解决方案
我不喜欢回答我自己的问题...但我还是想分享我的决定。
尽管我有 "worked",但我仍然想更改字符集编码的 hack-job-altering。我承认这是旧代码,但出于某种原因,我从来没有看过 hex2bin
bin2hex
这样做。所以我决定将其更改为使用这些。
生成的新代码:
// $clip_size remains the same value for continuity later,
// only spot-adjusted here... which is why the *2.
$hex_data = bin2hex( $binary_data );
$first_hunk = hex2bin( substr($hex_data,0,($clip_size*2)) );
$rest_of_it = hex2bin( substr($hex_data,($clip_size*2)) );
if ( !empty($rest_of_it) ) { /* process the result for reasons */ }
使用十六进制函数,将混乱变成 mb 无法解决的问题。一个 100 万次的工作台循环,表明这个过程没有什么值得担心的(而且它 运行 与自身并行比 mb_encoding mangle 方法更安全)。
所以我要这样做。它更适合我的想法,并暂时解决了我的问题......直到我在几年后再次访问这段旧代码并去 "what was I thinking ?!".