Re: Remove zero padding from excel mangled Ip addresses

Think about when you need to remove zeros, then write a regex that does that. Be warned, it's trickier than you think and needs somewhat beyond basic level regex knowledge.

The requirements come down to remove all leading 0 digits except where there is no following digit. Consider:

use strict;
use warnings;

while (<DATA>) {
    s/(?<!\d)0+(?=\d)//g;
    print;
}


__DATA__
010.231.000.049,41145,010.231.000.049,1363,CDU01V43
010.231.000.050,20,010.116.223.024,2803,ZVC629
[download]

Prints:

10.231.0.49,41145,10.231.0.49,1363,CDU1V43
10.231.0.50,20,10.116.223.24,2803,ZVC629
[download]

The (? bits are look back and look ahead anchors. See the perlre documentation for more info on what they do (look for "Look-Around Assertions").

True laziness is hard work

Comment on Re: Remove zero padding from excel mangled Ip addresses Select or Download Code

Replies are listed 'Best First'.
Re^2: Remove zero padding from excel mangled Ip addresses by raybies (Chaplain) on Mar 21, 2012 at 16:50 UTC
Just a nitpick, cuz you did tell him to play with it, but notice that CDU01V43 got changed to CDU1V43... that is most likely not an expected behavior. The above regex removes all 0's unless preceded by a number and followed by a number, which means words with 0's in them will be removed as long as there's a digit following them. So you might want to split on commas and detect an IP address (dotted quartet) prior to running the above regex (which works great on all IPs I tested).	[reply]
Re^3: Remove zero padding from excel mangled Ip addresses by GrandFather (Saint) on Mar 21, 2012 at 22:42 UTC
or just change the \d to a \w: `s/(?<!\w)0+(?=\d)//g;`. True laziness is hard work	[reply] [d/l]
Re^4: Remove zero padding from excel mangled Ip addresses by raybies (Chaplain) on Mar 22, 2012 at 14:44 UTC
Beautiful! Testing this one, the only possible unexpected output I had was when I had a bareword (not a dotted quartet) that was all numbers with leading 0's. input:> 040.300.000.048,00145,010.030.000.049,CDU00U04V43 Output:> 40.300.0.48,145,10.30.0.49,CD00U04V43 Which I think most of us would agree is acceptable, assuming the second field is a raw integer value, and not intended to be a code that requires leading zeroes preserved. The nice thing is the word (last field) is preserved. Nice, anyhow, thanks for sharing your expertise.	[reply]